24. Nguyên tắc lập kế hoạch dự án Agile

Nguyên tắc lập kế hoạch dự án Agile

Được gọi là phương pháp “Adaptive Planning”, lập kế hoạch trong dự án Agile ứng dụng 9 nguyên tắc sau đây:

  • Lập kế hoạch ở nhiều cấp độ

Ở mức high-level planning chúng ta xác định phạm vi tổng thể dự án và định nghĩa các tiêu chí thành công của cả dự án. Tiếp đến chúng ta lập user story maps và product roadmap. Ở cấp độ release planning kế hoạch cần xác định các feature gì cần được phát triển , có bao nhiêu iteration trong mỗi release, và sẽ được phát hành khi nào. Cuối cùng ở mức iteration planning các chi tiết được vạch ra cụ thể hơn nữa: trong iteration sẽ cần phát triển các user story nào, tiêu chí nghiệm thu từng user story là gì, và các mục công việc cần làm trong iteration là gì và do ai thực hiện.

  • Có sự tham gia tích cực của cả đội dự án và khách hàng

Trong dự án của công việc trí óc hiếm khi người lãnh đạo dự án có đủ tất cả thông tin cần thiết để thỏa mãn yêu cầu của khách hàng. Do đó phải có sự tham gia tích cực của cả đội dự án và khách hàng trong công tác lập kế hoạch. Nhờ đó có thể tận dụng được hiểu biết chuyên sâu kỹ thuật của đội dự án và tạo ra sự gắn bó và sự cam kết thực hiện của đội dự án (buy-in & commitments) với kế hoạch được vạch ra.

  • Quản lý kỳ vọng các bên liên quan bằng cách thường xuyên trình bày tiến trình công việc và dự báo tốc độ thực hiện

Agile team luôn luôn trình bày rõ các kết quả công việc đã làm trong suốt quá trình dự án. Nhờ đó các bên liên quan được cung cấp thông tin cập nhật khiến họ gắn kết tốt hơn với diễn biến dự án và kỳ vọng của họ về kết quả cuối cùng của dự án được điều chỉnh một cách thực tế. Các dự báo về dự án cũng căn cứ vào kết quả, tốc độ thực hiện của đội dự án ở các iteration trước đó, chứ không chỉ là sự phỏng đoán hay là sự hy vọng đơn thuần.

  • Áp dụng và điều chỉnh quá trình thực hiện sao cho phù hợp với các đặc điểm riêng biệt của dự án

Các dự án qui mô lớn sẽ đòi hỏi nhiều công sức lập kế hoạch hơn là ở các dự án nhỏ. Nếu như dự án có các yêu cầu cũng như giải pháp kỹ thuật được xác định và hiểu rõ, thì lập kế hoạch chi tiết ngay từ đầu là cách tiếp cận an toàn và hợp lý hơn. Trái lại nếu các yếu tố này khó xác định rõ và hiểu đầy đủ thì lập kế hoạch kỹ ngay từ đầu sẽ không phù hợp. Đội dự án sẽ phải thận trọng làm các nghiên cứu khả thi về các lựa chọn giải pháp kiến trúc (architectural spikes, POC proof of concept) và dựa vào kết quả xác nhận sự phù hợp của giải pháp được chọn để lập ra kế hoạch dự án.

  • Cập nhật kế hoạch dựa theo các thứ tự ưu tiên của dự án

Bên nghiệp vụ (business) là người đặt ra thứ tự ưu tiên của dự án, và điều này được phản ánh thông qua thứ tự ưu tiên các item của Product backlog do Product owner quản lý và quyết định nhờ có sự hợp tác của đội dự án và các bên liên quan (khách hàng, đơn vị nghiệp vụ). Khi chúng ta nhận biết được có sự thay đổi thì phải rà soát xem xét lại thứ tự ưu tiên trong product backlog cũng như khả năng phải cập nhật các release plans.

  • Đảm bảo rằng các ước lượng của kế hoạch có tính bao trùm, nghĩa là ước lượng đã tính đến các yếu tố rủi ro, và thời gian sẵn sàng của nguồn lực

Các nhà tài trợ  dự án luôn cần biết thời gian hoàn thành dự án. Vì vậy các ước lượng trong dự án nếu không tính đến các yếu tố rủi ro đã nhận diện được thì sẽ không có ích gì, và không khả thi. Để cho ra các ước lượng tốt, chúng ta cần dựa trên số đo về velocity các iteration đã làm trước đó và xu thế thay đổi (velocity trend), cũng như phải tính đến sự vắng mặt (có kế hoạch, hoặc bất chợt) của nguồn nhân lực trong tương lai của quá trình dự án do họ được điều động làm những việc bên ngoài hoặc nghỉ phép, nghỉ ốm.

  • Áp dụng ước lượng theo dải một cách thích hợp để phản ánh độ không chắc chắn của ước lượng

Nếu chúng ta khá tự tin hiểu rõ một cái đích trước mắt thì các ước lượng của chúng ta có dải xê dịch nhỏ là chấp nhận được. Trái lại đưa ra dự báo cho những mục tiêu dài hạn hơn và có nhiều sự không chắc chắn thì dải ước lượng trong các dự báo sẽ phải lớn hơn, do khả năng xuất hiện các vấn đề, khó khăn trong quá trình thực hiện là cao hơn. Dải ước lượng của các dự báo nếu đặt ra hợp lý sẽ góp phần quản lý kỳ vọng các bên liên quan. Chẳng hạn một câu phát biểu ước lượng theo dải: “Tôi hy vọng sẽ vẽ xong tranh chân dung của cả gia đình trong vòng từ 5 đến 8 ngày, tùy theo thời gian có mặt của các thành viên trong gia đình.”

  • Các dự báo phải tính toán dựa trên tốc độ hoàn thành công việc ở các iteration trước đó

Nếu trong tay chúng ta có được số đo về velocity các iteration đã làm trước đó và xu thế thay đổi (velocity trend) thì kế hoạch và dự báo của dự án phải dựa trên số liệu thực tế đã có này. Vì đây là dữ liệu phản ánh khả năng thực sự của đội dự án, trong môi trường dự án thực. Các yếu tố như sự phân tán điều chuyển nguồn lực, tỷ lệ lỗi phát sinh phải khắc phục trong dự án, và khoảng thời gian nonproductive (làm việc không hiệu quả) của nhân lực đều đã thực sự “có” trong các dữ liệu lịch sử này.

  • Tính đến sự điều chuyển nguồn lực của dự án và công việc phải làm bên ngoài

Nhân sự có thể phải bị gọi về (tạm thời) xử lý vấn đề do các dự án họ làm trước đó, nghỉ phép hay nghỉ ốm. Vì vậy chúng ta sẽ không lập kế hoạch với giả định 100% sẵn sàng và có năng suất cao của nhân lực dự án.

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *

error: