1. 6 Điều kiện để áp dụng
2.2.3. Phân tách các nhóm trong dự án
Nhiều suy nghĩ truyền thống rằng việc phân tách các nhóm (đặc biệt là nhóm mới và nhóm cũ) là dựa trên các hoạt động mà các nhóm đó thực hiện. Vì vậy,
việc phân tích và thiết kế đƣợc thực hiện trên các đội gần với khách hàng hơn, còn việc phát triển, kiểm thử thƣờng đƣợc các nhóm mới, ít kinh nghiệm về hệ thống thực hiện. Điều này rõ ràng rất phù hợp với mô hình phát triển định hƣớng kế hoạch nhƣ mô hình thác nƣớc.
Trái lại, trong quá trình phát triển phần mềm theo XP, chúng ta có thể cải thiện vấn đề khi cho nhóm mới xử lý các hoạt động nhiều nhất có thể. Vì vậy họ làm đƣợc nhiều công việc phân tích và thiết kế nhất có thể, nhƣng chịu sự hạn chế bởi các yêu cầu đƣợc các nhóm cũ hoặc khách hàng đƣa ra. Khi chia nhỏ sự nỗ lực giữa các nhóm phát triển với nhau, theo XP thì cần phải làm điều này theo chức năng chứ không phải là căn cứ hoạt động. Chúng ta cần chia hệ thống thành các khối mã nguồn mở rộng và cho phép các thành viên mới giải quyết một số trong những khối mã nguồn này. Tuy nhiên không giống nhƣ hầu hết các nhóm đã làm việc này, XP không thực hiện một nỗ lực lớn nào để thiết kế và cố định các giao diện giữa các phân hệ: tích hợp liên tục và quyền sở hữu mã nguồn yếu cho phép các giao diện của khối mã nguồn đƣợc phát triển liên tục giống nhƣ mã nguồn.
Hình 2-4 Phân tách nhóm trong XP
Một phần quan trọng của việc này là để các nhóm cùng phân tích các tính năng. Việc càng nhiều ngƣời ở trong các nhóm hiểu đƣợc nghiệp vụ và các yêu cầu cần phát triển, thì càng có nhiều nhóm có thể phát triển hiệu quả. Thay vì phải chờ đợi khách hàng hay nhóm phân tích, thiết kế để trả lời một câu hỏi, nhóm phát triển có thể nhận đƣợc câu trả lời ngay lập tức và loại bỏ đƣợc các khúc mắc để cùng phát triển. Điều này cần có thời gian, nhƣng những kiến thức
chuyên môn là một phần quan trọng để hiểu và áp dụng các kiến thức nghiệp vụ vào công việc.