Kế hoạch release và iteration trong Agile

Ý nghĩa chủ yếu của ước lượng tốt là nó có ích cho việc lập kế hoạch dự án. Trong dự án nhất là thời kỳ đầu có rất nhiều sự không chắc chắn chung quanh các ước lượng. Vì vậy chúng ta thay vì mong muốn “các ước lượng chính xác 100%” thì chúng ta nhằm đến “các ước lượng có ích và có độ chính xác” (với hàm ý là ước lượng là phép đo bao gồm cả nỗ lực lao động và chứa đựng cả định lượng đại diện cho sự không chắc chắn).

Ích lợi của ước lượng thể hiện ở các khía cạnh sau đây:

Nó cung cấp sự thấu hiểu các rủi ro của dự án
Sự thường xuyên đánh giá lại khi hiểu biết về dự án được tích lũy theo thời gian cho phép bạn giảm bớt độ không chắc chắn của ước lượng
Ước lượng đáng tin cậy dẫn đến sự bàn giao sản phẩm đáng tin cậy và thiết lập sự tin tưởng giữa các chuyên gia phát triển phần mềm với cấp quản lý
Ước lượng hỗ trợ việc ra quyết định nhờ cung cấp hiểu biết sâu về chi phí và lịch trình của dự án

Các thách thức lớn nhất bạn phải đối mặt khi làm ước lượng để lập kế hoạch dự án là gì?

Sự khác biệt giữa ước lượng và cam kết thường bị che mờ. Cần phải chỉ rõ sự khác biệt hai khái niệm này.
Thường thường các feature chưa được sắp xếp ưu tiên và được chọn ngẫu nhiên để lập trình. Hậu quả là nếu dự án sau đó bị trễ tiến độ và bắt buộc một số feature chưa thực hiện phải bị hi sinh để giữ đúng lịch release thì những feature này rất có thể lại đáng giá hơn là các feature đã thực hiện.
Khi các ước lượng được trình ra hoặc được thông tin rộng rãi trong tổ chức người ta thường thường lờ đi không lưu tâm đến sự không chắc chắn của ước lượng. Hoặc ước lượng thoạt đầu có range khá rộng mà cấp quản lý không thích và không chấp thuận.
Lập kế hoạch thường dựa trên các task phải làm mà không dựa trên feature. Khi lập kế hoạch dựa trên sự hoàn thành của các task thì do sự phụ thuộc lẫn nhau các task này dẫn đến sự trễ dây chuyền một khi task bị trễ tiến độ. Khi lập kế hoạch theo task hãy nhớ đến nội dung của luật Parkinson (Parkinson’s law). Luật Parkinson phát biểu rằng “các tác vụ sẽ tự động tràn ra choán hết khung thời gian được phân bổ cho nó”. Và hậu quả là các task được lập kế hoạch có xu thế tự nhiên bị trễ tiến độ hơn là được hoàn thành sớm.

Cuối cùng, có một giả định rằng nếu có thêm người xúm vào cùng xử lý vấn đề thì dự án sẽ hoàn thành nhanh hơn. Thực tế là thêm người vào dự án chưa chắc đã đẩy nhanh được tiến độ công việc. Hơn nữa việc thêm người vào dự án sẽ làm tăng số line của thông tin, truyền thông trở nên phức tạp hơn và có thể làm dự án trì trệ.

Mike Cohn đã tóm lược các nguyên tắc cơ bản của lập kế hoạch dự án agile như sau:

Công việc được thực hiện qua các iteration (vòng lặp), trong mỗi iteration có một nhóm các feature được chọn ra phải hoàn thành và có thể trở thành một increment được bàn giao cho khách hàng.
Lập kế hoạch dự án ở 2 cấp độ riêng biệt, là iteration planning và release planning.
Sắp xếp thứ tự ưu tiên các feature của release, sao cho các feature (hoặc các user story) có giá trị cao phải được bàn giao trước. Đồng thời phải định nghĩa được điều kiện thỏa mãn (hay điều kiện chấp thuận nghiệm thu) ở cả mức từng feature lẫn ở mức dự án, và do đó mục tiêu của từng iteration và từng release được xác định cụ thể.
Thường xuyên cập nhật kế hoạch, và sắp xếp lại thứ tự ưu tiên, khi hiểu biết về dự án được tích lũy theo thời gian.
Toàn bộ team cùng nhau chịu trách nhiệm đưa ra các ước lượng và cùng nhau hoàn thành bàn giao các feature. Nếu cả team có tinh thần tập thể cùng chịu trách nhiệm thì sẽ ít có có hội phát sinh vòng tròn đổ lỗi cho nhau và ít cơ hội các thành viên padding vào các ước lượng (chủ ý kéo dài thêm ước lượng).
Qui mô team chỉ nên không hơn 9 thành viên (trung bình 7 người), nếu không thì sẽ phát sinh sự phức tạp và kém hiệu quả trong truyền thông và lập kế hoạch do đông người.

Ước lượng

Một ước lượng không nên thay đổi chừng nào các giả thiết, các yêu cầu và các dependency liên quan còn chưa thay đổi. Ước lượng là con số ước tính về khối lượng nỗ lực phải bỏ ra để đáp ứng/thực hiện một điều gì đó và không nên bị thay đổi vì sức ép của lãnh đạo hay lịch trình ràng buộc. Với dự án phát triển phần mềm chính các kỹ sư (ở đây là từ gọi chung các thành viên của development team, từ lập trình viên, kiểm thử đến chuyên gia phân tích …) chịu trách nhiệm xác định và tính đến các rủi ro của dự án khi đưa ra ước lượng. Thế nhưng development team lại không phải là người chịu trách nhiệm mitigate các rủi ro đó. Khi phát sinh sự sai lệch đáng kể giữa lịch trình cam kết, chẳng hạn 6 tháng, với ước lượng thời gian hoàn thành của development team, chẳng hạn 12 tháng, thì vấn đề sai lệch này phải được ghi nhận và xử lý sai lệch phải đòi hỏi hỗ trợ và đồng thuận của cấp quản lý. Việc gây sức ép lên development team để thay đổi ước lượng cho khớp với lịch trình cam kết không làm ra chút giá trị nào, vì hầu như chắc chắn dự án sẽ bị quá hạn và không có hành động nào diễn ra để khắc phục hậu quả!

Theo cách này rõ ràng việc đưa ra ước lượng tốt (nghĩa là các ước lượng có ích cho lập kế hoạch) là cốt tử để lập kế hoạch dự án một cách hiệu quả.

Trong lập kế hoạch dự án agile một khái niệm quan trọng là thực hiện ước lượng size của các user story một cách độc lập với kết quả đo lường velocity của development team. Bằng cách tiếp cận này bạn có thể hình dung qui mô dự án một cách đúng đắn không bị thiên lệch, rồi sau đó mới tính đến việc làm thế nào để đạt được các cam kết về thời gian và phạm vi của dự án.

Story points

Ước lượng ở cấp độ release được thực hiện thông qua sizing các feature hoặc user story bằng số story points. Story points là thước đo tương đối về kích thước của một user story. Mỗi user story được gắn với một số story points tương đương với tổng khối lượng nỗ lực bỏ ra và có tính đến các rủi ro/sự không chăc chắn khi thực hiện user story. Tổng khối lượng nỗ lực nghĩa là bao gồm từ khâu khám phá tìm hiểu, phân tích, thiết kế, phát triển, kiểm thử, đến triển khai bàn giao user story (hoặc feature). Ví dụ theo phương pháp Planning poker thì một user story được sizing theo một giá trị nằm trong chuỗi số Fibonacci 1, 2, 3, 5, 8, 13, 21… Khi sizing một epic (hay là một user story kích thước lớn) mà các yêu cầu của nó chưa được phát biểu và phân tích đầy đủ bạn có thể ước lượng số story points 50, 100, 200 không thuộc dãy Fibonacci. Sau này khi phân rã epic thành nhiều user story bạn lại áp dụng Planning poker để sizing từng user story. Tổng số story points của các user story con không cần phải bằng số story points của epic trước đó.

Điều quan trọng là sizing các user story là công việc của toàn bộ development team, là nhóm người trực tiếp thực hiện công việc. Thảo luận nhóm ở đây là hữu ích giúp bạn có được ước lượng chính xác hơn.

Các user story chỉ nên được sizing lại (ước lượng lại) nếu có sự thay đổi. Chẳng hạn nếu các yêu cầu về xác thực và phân quyền người dùng bổ sung thêm, nghĩa là user story đã trở nên lớn hơn so với ước tính ban đầu, thì bạn có thể phải sizing lại, và có thể iteration đó phải hoàn thành nhiều story points hơn dự kiến. Tuy nhiên bạn nên ước lượng lại toàn bộ các user story khác mà đòi hỏi phải thỏa mãn yêu cầu phân quyền người dùng mới bổ sung này. Việc này có thể kéo theo tổng số story points của release thay đổi, và do đó lập kế hoạch tiếp sau đó cũng phải tính toán lại.

Số lượng story points được hoàn thành trong một iteration được gọi là velocity của team. Số story points của một user story sẽ được cộng vào velocity chỉ khi nào user story đó được hoàn thành trọn vẹn. Ở những iteration đầu tiên velocity của team sẽ thấp nhưng chắc chắn sẽ tăng lên và dần ổn định theo thời gian khi các iteration tiếp theo diễn ra.

Có áp lực để chỉ báo cáo tốt về dự án nhưng nếu bạn báo cáo một feature là “done” trong khi thực tế chưa xong thì sẽ có sự cộng dồn theo thời gian của khối công việc kỹ thuật còn lại trong iteration và sẽ dẫn đến các hậu quả về sau. Phương pháp luận agile coi việc sớm nhận dạng rủi ro và mitigate rủi ro sớm là điều tích cực và quan trọng để thành công.

Lập kế hoạch

Lập kế hoạch dự án agile cần tối thiểu ở 2 cấp độ là release planning và iteration planning. Ngoài ra daily stand-up (hay daily scrum) cũng được coi là một thực hành lập kế hoạch hằng ngày của agile, nhưng ít có tính cấu trúc và chỉ dựa vào truyền thông trực tiếp giữa các thành viên trong team về công việc đã done và công việc sẽ thực hiện của từng cá nhân.

Release planning

Lập kế hoạch release bạn hãy đi theo qui trình sau:

Định nghĩa điều kiện thỏa mãn (các tiêu chí nghiệm thu)
Xác định các user story phải thực hiện để thỏa mãn điều kiện nghiệm thu
Ước lượng size của các user story theo phương pháp planning poker nói ở trên.
Ước lượng velocity của team (số story points hoàn thành trong một iteration). Điều này sẽ dễ thực hiện nếu bạn đã đo đếm velocity từ một số iteration trước đó của dự án và đưa ra ước lượng velocity dưới dạng dải từ [Min] đến [Max] tính đến sự không chắc chắn.
Chon độ dài iteration, thường từ 2 đến 4 tuần. Lưu ý nếu bạn nghĩ rằng các yêu cầu dự án và thứ tự ưu tiên sẽ có sự thay đổi tương đối rộng thì nguyên tắc chọn iteration ngắn thì tốt hơn.
Sắp xếp ưu tiên các user story khi cân nhắc tới giá trị, chi phí, khối lượng kiến thức cần tích lũy và rủi ro đi kèm với user story. Có nhiều phương án và kỹ thuật sắp xếp ưu tiên khác nhau có thể sử dụng. Cơ bản thì feature/user story có giá trị cao hơn với chi phi thấp sẽ có mức ưu tiên cao hơn. Ngoài ra khi xem xét yếu tố rủi ro thì feature/user story có rủi ro cao hơn nên được ưu tiên thực hiện sớm hơn vì như vậy bạn có khả năng nhận diện rủi ro sớm và ứng phó với rủi ro tốt hơn ngay ở giai đoạn đầu dự án. Khối lượng kiến thức có thể tích lũy được cũng có thể được tính đến khi sắp xếp ưu tiên các feature.
Lựa chọn feature/user story và ngày release. Sự lựa chọn sẽ khác nhau tùy theo yêu cầu về lịch trình được ưu tiên hơn hay yêu cầu về [phạm vi] các feature cần release được ưu tiên hơn. Chẳng hạn trường hợp ưu tiên đặt vào việc phải cam kết ngày release thì bạn lấy độ dài release chia cho độ dài đã chọn cho iteration sẽ tính ra được số lượng iteration phải trải qua trong release đó. Nhân với velocity dự kiến bạn biết được số story points phải thực hiện (tương đương khối lượng nỗ lực) của release. Rồi căn cứ thứ tự ưu tiên các user story và size của chúng bạn sẽ tính ra release sẽ được thực hiện phải dừng ở story nào trong danh sách ưu tiên. Trái lại nếu ưu tiên đặt vào danh sách cụ thể các feature cần phải bàn giao trong release thì sau khi tính ra tổng số story points của các feature trong release đem chia cho velocity bạn sẽ tính được số iteration phải hoàn thành cho release đó.
Bạn cần thường xuyên, trong suốt quá trình dự án, đo lường tiến độ thực hiện (đo velocity), rà soát và điều chỉnh kế hoạch release căn cứ số đo thực tế cũng như theo sự sắp xếp ưu tiên mới các feature [nếu có sự thay đổi từ bên nghiệp vụ và/hoặc từ Product Owner] và ứng phó với các rủi ro mới được nhận biết, cũng như sự thay đổi của velocity.

Mấu chốt của toàn bộ quá trình nói trên chính là sự thường xuyên trao đổi thông tin và có phản hồi từ team, từ product owner và các bên liên quan khác sao cho yêu cầu thay đổi và kỳ vọng của các bên liên quan được hiểu rõ.

Tránh đưa ra kế hoạch với ước lượng “quá chính xác”. Chẳng hạn nếu bạn nói “27 ngày” thì người nghe sẽ hiểu rằng bạn rất chắc chắn về thời gian. Cần đưa ra ước lượng theo dải (range estimates).
Phân rã phạm vi của release theo feature chứ không phân rã theo task (công việc). Bằng cách này bạn tập trung vào bàn giao giá trị (value-driven delivery) mà tránh việc bàn giao từng mảnh công việc rời rạc.
Hãy sử dụng release burndown charts để hiển thị minh bạch tiến độ công việc cho tất cả các bên liên quan thấy rõ và được cập nhật. Trục X chỉ số iteration, trục Y chỉ số story points còn lại chưa hoàn thành.
Sử dụng một dải ước lượng velocity ([Tốt nhất], [Trung bình], [Tệ nhất]) để đưa ra dự báo cho dự án. Bằng cách này sự không chắc chắn của dự báo được truyền thông rõ ràng.

Điều đó cho phép bạn thương xuyên đánh giá lại và cập nhật kế hoạch release tùy theo diễn biến của dự án. Một vòng lặp được hình thành: (i) hoàn thành thực hiện iteration -> (ii) nhận phản hồi -> (iii) cập nhật điều chỉnh kế hoạch release -> (i) hoàn thành thực hiện iteration, và nhờ đó bạn càng hiều nhiều về dự án bạn càng ứng phó tốt hơn và giảm dần các rủi ro và sự không chắc chắn, giữ vững được động lực đạt đến mục tiêu chung cuối cùng team và các bên liên quan trong dự án.

Iteration planning

Chọn mục tiêu của iteration. Review kết quả iteration trước và dựa vào product backlog đã cập nhật thứ tự ưu tiên các feature để team xác định mục tiêu của iteration
Lựa chọn các user story khớp với mục tiêu
Phân rã user story thành các task nhỏ. Lưu ý rằng tất cả các bug phát hiện trong iteration phải được xử lý trong iteration đó, nghĩa là phải có task để fix bug và được tính vào các ước lượng iteration backlog. Trong bối cảnh blog này bug được hiểu là lỗi trong quá trình development và được phát hiện ở khâu test, và được gửi trở lại để các developer xử lý triệt để. Còn những lỗi do phát biểu yêu cầu, do giả định không phù hợp, hoặc có vấn đề ở thiết kế của sản phẩm thì gọi là defect.
Ước lượng các task. Ước lượng thời gian cho task là công việc tập thể cả team thực hiện. Và không sử dụng story point để ước lượng mà nên sử dụng ideal day hoặc ideal hour (ngày lý tưởng hoặc giờ lý tưởng) để ước lượng task. Ngày hoặc giờ lý tưởng nghĩa là thời gian các thành viên tập trung 100% cho task và giả thiết không có sự ngắt quãng nào xảy ra, không có meeting nào cần dự, không có email nào cần trả lời … Story points được coi là thước đo thô. Còn khi bước vào ước lượng task thì team đã có hình dung chi tiết về công việc nên cần sử dụng ideal day/hour là thước đo tinh. Trong một ngày làm việc số ideal hour có thể cam kết của một thành viên sẽ phụ thuộc vào môi trường làm việc và có thể xác định chính xác hơn theo tiến trình dự án. Trong một vài iteration đầu tiên nhiều khả năng là không phải tất cả các user story đều được hoàn thành đúng lịch.
Yêu cầu sự cam kết của team hoàn thành user story đã chọn trong khung thời gian iteration. Sau khi ước lượng tổng số ideal hour cho toàn bộ các task của một user story cả team phải đồng thuận cam kết hoàn thành user story đó trong khung thời gian của iteration. Nếu tính trung bình mỗi ngày công của một team member tương đương từ 4 đến 6 ideal hour được cam kết thì team có thể cam kết hoàn thành user story đã chọn. Nếu trái lại team chạm đến ngưỡng số ideal hour cam kết thì cần bỏ user story đó hoặc thay bằng user story khác có size nhỏ hơn. Và lại lặp lại quá trình ước lượng và cam kết nêu trên.

Hình dưới đây là ví dụ về một task board hay Kanban board dùng để hiển thị quá trình thực hiện các task trong iteration. Task board này cho một hiển thị cụ thể task nào đang xếp hang chờ thực hiện cho từng user story, task nào đang được xử lý, user story nào đã có các test script ở trạng thái sẵn sàng, và số hour còn lại cho từng user story. Trong phương pháp XP (Extreme Programming) có thực hành gọi là test-driven development, mà theo đó các task phát triển chỉ bắt đầu thực hiện [in progress] sau khi các test script đã sẵn sàng cho việc kiểm thử.

Không nên đòi hỏi ước lượng chính xác vì nếu làm như vậy người đưa ra ước lượng sẽ có xu hướng cố tình thêm buffer vào ước lượng của mình. Cũng không nên đo đếm “velocity” của cá nhân thành viên trong team vì điều này đi ngược với nguyên tắc “tất cả cùng nhau”, khiến từng thành viên tập trung ưu tiên làm xong việc của mình và xem nhẹ sự hợp tác chia sẻ và trao đổi thông tin và chú trọng làm nhanh hơn là đảm bảo chất lượng công việc.

Lưu ý

Vì hiểu biết và thông tin được tích lũy theo tiến trình làm dự án việc tái lập kế hoạch và điều chỉnh kế hoạch giúp bạn giảm dần sự không chắc chắn và rủi ro
Ước lượng và lập kế hoạch là công việc tập thể cả team cùng tham gia.
Lập kế hoạch thực hiện ở cả mức release planning lẫn iteration planning.
[High-level planning, hay Visioning, là cấp độ lập kế hoạch cao nhất trong Agile]
Ước lượng luôn luôn bao hàm cả nỗ lực thực hiện công việc lẫn mức độ rủi ro, không chắc chắn
Iteration ngắn hơn cho phép feedback mau chóng hơn và khả năng ứng phó giảm thiểu rủi ro tốt hơn

Theo Carmel Eve

A beginner’s guide to agile estimation and planning