Clean Coder – Chương 13 – Nhóm Và Dự Án

Điều gì xảy ra nếu bạn có rất nhiều dự án con phải hoàn thành? Bạn phân chia những dự án đó cho các lập trình viên như thế nào? Điều gì xảy ra nếu bạn có một dự án thực sự lớn phải hoàn thành?

Nó có bị trộn lẫn không?

Tôi đã từng tư vấn cho một số các ngân hàng và công ty bảo hiểm nhiều năm qua. Họ dường như có điểm chúng một điều đó là cách thức kỳ lạ mà họ phân chia các dự án.

Thông thường một dự án tại ngân hàng sẽ là một công việc tương đối nhỏ chỉ cần một hoặc hai lập trình viên làm trong vài tuần. Dự án này sẽ thường được giao cho một quản lý dự án, người này cũng quản lý các dự án khác. Nó sẽ bao gồm một người phân tích nghiệp vụ, người này cũng sẽ cung cấp những yêu cầu phần mềm cho các dự án khác. Nó sẽ bao gồm vài lập trình viên cũng đang làm việc cho các dự án khác. Một hoặc hai người kiểm tra sẽ được giao nhiệm vụ, và họ cũng sẽ làm việc ở các dự án khác.

Bạn nhìn thấy cách làm việc ở đây chưa? Dự án đó quá nhỏ để giao cho một cá nhân nào đó làm toàn thời gian. Mỗi người sẽ làm việc tại dự án đó 50% hoặc thậm chí 25% thời gian của họ.

Hiện tại có một quy tắc là: Không có thứ gì gọi là nửa người cả.

Không có ý nghĩa gì khi nói với một lập trình viên là dành nửa thời gian của họ cho dự án A và phần thời gian còn lại của họ cho dự án B, đặc biệt là khi hai dự án này có hai người quản lý dự án khác nhau, những người phân tích nghiệp vụ khác nhau, những lập trình viên khác nhau, và những người kiểm tra khác nhau. Sao có thể gọi một đội hình quái dị như vậy là một nhóm được? Đó không phải là một nhóm, đó là thứ gì đó chui ra từ một máy xay sinh tố.

Nhóm gắn kết

Để một nhóm hình thành thì cần thời gian. Các thành viên trong nhóm bắt đầu hình thành mối quan hệ. Họ học cách để cộng tác với những người khác. Họ học thói quen, điểm mạnh, và điểm yếu của người khác. Cuối cùng thì nhóm đó mới bắt đầu gắn kết được.

Có một vài phép màu thực sự đối với một nhóm gắn kết. Họ có thể làm ra những điều kỳ diệu. Họ đoán trước được những người khác, che chở cho nhau, hỗ trợ lẫn nhau, và đòi hỏi những người khác phải làm những gì tốt nhất. Họ thực hiện được mọi thứ.

Một nhóm gắn kết thường bao gồm khoảng một chục người. Nhiều thì nó có thể là 20 người hoặc ít thì là 3 người, nhưng con số tốt nhất có lẽ là ở quanh con số 12. Nhóm cần phải bao gồm các lập trình viên, người kiểm tra, và người phân tích nghiệp vụ. Và nó cũng cần phải có một người quản lý dự án.

Tỷ lệ của lập trình viên trên người kiểm tra và người phân tích nghiệp vụ có thể thay đổi lớn, nhưng tỷ lệ 2:1 là một con số ổn. Vậy nên một nhóm gắn kết đẹp 12 người có thể có 7 lập trình viên, 2 người kiểm tra, 2 người phân tích nghiệp vụ, và 1 người quản lý dự án.

Những người phân tích nghiệp vụ sẽ xây dựng các yêu cầu phần mềm và viết các bài acceptance test tự động cho nhóm. Những người kiểm tra cũng viết các bài acceptance test tự động. Sự khác biệt giữa hai nhóm đó là ở góc nhìn. Cả hai đều viết yêu cầu hệ thống. Nhưng những người phân tích nghiệp vụ tập trung vào giá trị doanh nghiệp; còn người kiểm tra thì tập trung vào tính chính xác. Người phân tích nghiệp vụ viết các bài test của các trường hợp “happy path”; còn người kiểm tra lo về những gì có thể xảy ra sai sót, và viết các bài test của trường hợp lỗi và các giới hạn biên.

Người quản lý dự án theo dõi tiến độ của nhóm, và đảm bảo rằng nhóm hiểu rõ lịch làm việc và thứ tự ưu tiên.

Mỗi thành viên của nhóm có thể chơi một vai trò phụ là huấn luyện viên, hoặc thầy dạy, với trách nhiệm bảo vệ quy trình và các kỷ luật của nhóm. Họ đóng vai trò thức tỉnh nhóm khi nhóm có dấu hiệu đi lệch quy trình do áp lực về lịch trình làm việc.

Sự lên men

Cần phải có thời gian để một nhóm như vậy thấy được sự khác biệt của họ, thống nhất với nhau và thực sự gắn kết. Việc này có thể mất 6 tháng. Nó có thể thậm chí mất 1 năm. Nhưng một khi điều này xảy ra, đó sẽ là một phép màu. Một nhóm gắn kết sẽ lập kế hoạch cùng nhau, giải quyết vấn đề cùng nhau, đối mặt với các vấn đề cùng nhau, và hoàn thành mọi thứ.

Một khi điều này xảy ra, sẽ thật lố bịch khi phá vỡ nhóm chỉ bởi vì một dự án sắp kết thúc. Tốt nhất là hãy giữ nhóm đó lại với nhau và tiếp tục dự án.

Điều gì tới trước, Nhóm hay Dự án?

Các ngân hàng và các công ty bảo hiểm luôn cố gắng hình thành các nhóm xoay quanh các dự án. Đây là một cách tiếp cận xuẩn ngốc. Những nhóm như vậy đơn giản là không thể gắn kết. Các cá nhân chỉ làm việc với dự án trong một thời gian ngắn, và chỉ trong một phần trăm thời gian của họ, và do đó họ không bao giờ học được cách làm việc với những người khác.

Các tổ chức phát triển phần mềm chuyên nghiệp phân bố các dự án cho những nhóm gắn kết đang có, họ không dựng nên các nhóm xoay quanh các dự án. Một nhóm gắn kết có thể chấp nhận nhiều dự án đồng thời và sẽ phân chia công việc dựa theo ý kiến, kỹ năng và khả năng của chính họ. Một nhóm gắn kết sẽ hoàn thành được các dự án.

Nhưng bạn làm cách nào để quản lý được nhóm đó?

Mỗi nhóm có một tốc độ riêng. Tốc độ của nhóm đơn giản là khối lượng công việc mà nó có thể hoàn thành trong một khoảng thời gian cố định. Một số nhóm đo lường tốc độ của họ bằng điểm mỗi tuần, trong đó điểm là một đơn vị của mức độ phức tạp. Họ chia nhỏ các chức năng của mỗi dự án mà họ đang làm và ước lượng chúng thành các điểm số. Sau đó họ đo xem họ đã hoàn thành được bao nhiêu điểm mỗi tuần.

Tốc độ là một con số đo lường thống kê. Một nhóm có thể đạt được 38 điểm hoàn thành 1 tuần, 42 điểm vào tuần tiếp theo, và 25 điểm vào tuần tiếp nữa. Tính trung bình các con số này trong một khoảng thời gian sẽ ra tốc độ trung bình.

Người quản lý có thể đặt mục tiêu cho mỗi dự án mà nhóm phụ trách. Lấy ví dụ, nếu tốc độ trung bình của một nhóm là 50 và họ có 3 dự án đang làm, thì người quản lý có thể đề nghị họ phân chia tốc độ cho mỗi dự án là 15, 15, và 20.

Bên cạnh việc có một nhóm gắn kết làm việc trong các dự án của bạn, ưu điểm của cách làm này là trong trường hợp khẩn cấp, công ty có thể nói “Dự án B đang gặp khủng hoảng; hãy dành 100% sức lực của các cậu vào dự án đó trong 3 tuần tiếp theo nhé.”

Phân bố lại mức độ ưu tiên một cách nhanh chóng là điều gần như không thể với những nhóm sinh ra theo kiểu máy xay, nhưng các nhóm gắn kết đang làm việc trong hai hoặc ba dự án đồng thời thì có thể thực hiện được điều này trong một nốt nhạc.

Song đề chủ dự án

Một trong những khó chịu đối với cách tiếp cận mà tôi đang ủng hộ đó là các chủ dự án sẽ mất đi an tâm và quyền lực. Các chủ dự án có một nhóm chuyên tâm cho dự án của họ thì họ có thể dựa vào nỗ lực của nhóm đó. Họ biết điều đó bởi vì việc hình thành và giải tán một nhóm là một hành động đắt giá, công ty sẽ không loại bỏ nhóm đó vì những lý do ngắn hạn.

Mặt khác, nếu các dự án được đưa cho những nhóm gắn kết, và nếu những nhóm này chạy vài dự án cùng một lúc, thì công ty sẽ không phải thay đổi mức độ ưu tiên khi cần. Điều này có thể làm cho người chủ dự án không an tâm về tương lai. Các tài nguyên mà người chủ dự án phụ thuộc vào có thể đột nhiên bị lấy mất.

Thành thực mà nói thì tôi thích tình huống sau hơn. Công ty sẽ không bị trói tay bởi những khó khăn trong việc hình thành và giải tán các nhóm. Nếu công ty quyết định rằng một dự án có mức độ ưu tiên cao hơn dự án khác, nó có thể phân bố lại tài nguyên một cách nhanh chóng. Trách nhiệm của người chủ dự án là phải tạo điều kiện cho dự án của anh ta.

Kết luận

Các nhóm làm việc khó để xây dựng được hơn là các dự án. Bởi vậy tốt hơn hết là hãy hình thành những nhóm làm việc đi cùng nhau lâu dài từ dự án này sang dự án khác và có thể đảm nhận nhiều hơn một dự án vào một thời điểm. Mục tiêu trong việc hình thành một nhóm đó là tạo điều kiện cho họ có đủ thời gian để gắn kết, và sau đó giữ họ lại với nhau để trở thành một cỗ máy giúp cho nhiều dự án được hoàn thành.

Tham khảo

[RCM2003]: Robert C. Martin, Agile Software Development: Principles, Patterns, and Practices, Upper Saddle River, NJ: Prentice Hall, 2003.

[COHN2006]: Mike Cohn, Agile Estimating and Planning, Upper Saddle River, NJ: Prentice Hall, 2006.

Trả lời

Email của bạn sẽ không được hiển thị công khai.