Việc có một định nghĩa hoàn thành (Definition of Done – DoD) là cực kỳ quan trọng đối với nhóm Scrum hiệu năng cao. Dưới đây là những đặc điểm mà các bạn nên có trong DoD của nhóm mình. Việc xác minh DoD của nhóm có đạt những tiêu chí này hay không sẽ đảm bảo rằng nhóm đang cung cấp các tính năng thực sự hoàn tất, không chỉ về mặt chức năng mà còn cả về chất lượng.
DoD là một danh sách kiểm tra (checklist) các hoạt động có giá trị cần thiết để sản xuất phần mềm.
DoD đơn giản là một danh sách các hoạt động (viết mã, chú thích cho mã, kiểm thử đơn vị, kiểm thử tích hợp, bản ghi chú phát hành, tài liệu thiết kế, v.v…) giúp thêm vào những giá trị có thể kiểm chứng và xác minh được cho sản phẩm. Việc tập trung vào các phần giá trị gia tăng cho phép Đội sản xuất dồn sức vào những công việc quan trọng phải hoàn thành để xây dựng phần mềm đồng thời loại bỏ các hoạt động lãng phí gây phức tạp hóa nỗ lực phát triển phần mềm.
DoD như là một cơ chế báo cáo chủ đạo cho Đội sản xuất (Development Team).
Việc báo cáo đôi khi đơn giản chỉ với một câu: “chức năng này đã hoàn thành”. Nhưng rốt cuộc, một chức năng hay một hạng mục Product Backlog là hoàn thành hay không hoàn thành? DoD là một công cụ đơn giản để làm rõ thêm câu nói “chức năng này đã hoàn thành”. Việc sử dụng DoD như là sự tham khảo trong các cuộc hội thoại kiểu này khiến cho một thành viên có thể cập nhật một cách hiệu quả thông tin tới các thành viên khác trong nhóm và cho Product Owner.
DoD là thông báo thực.
Scrum đòi hỏi Đội sản xuất cung cấp “sản phẩm phần mềm hoàn chỉnh chuyển giao được” khi kết thúc một Sprint. Sản phẩm phần mềm hoàn chỉnh chuyển giao được có thể được hiểu là những tính năng sẽ có ở bản phát hành, với những hạn chế lưu ý cho người dùng (end-user) căn cứ theo quyết định của Product Owner. Những sản phẩm đó thậm chí có thể được chuyển giao tới người dùng trong vòng hai, ba ngày với lý do được hợp lý hóa bằng việc cho rằng nó ở trạng thái hoàn chỉnh chuyển giao được. Một cách lý tưởng là việc “hoàn chỉnh chuyển giao được” tương đương với DoD.
Trên thực tế, nhiều đội phát triển phần mềm đang làm việc hướng tới trạng thái hoàn chỉnh có tiềm năng chuyển giao được. Mỗi đội này có thể có một DoD khác nhau với nhiều cấp độ:
- DoD cho chức năng (User Story hay hạng mục Product Backlog)
- DoD cho Sprint (các tính năng được phát triển trong Sprint)
- DoD cho Bản phát hành (Release) (trạng thái hoàn chỉnh chuyển giao được)
Có nhiều yếu tố ảnh hưởng đến việc một hoạt động có được đưa vào trong DoD cho chức năng, cho Sprint hay cho Bản phát hành hay không. Đánh giá cuối cùng dựa trên việc trả lời cho ba câu hỏi sau:
- Chúng ta có thể làm việc này cho mỗi chức năng? nếu không thì…
- Chúng ta có thể làm việc này cho mỗi Sprint? nếu không thì…
- Chúng ta phải làm việc này cho Bản phát hành?
Chris Sterling khuyên rằng đối với những công việc không thể đưa vào trong Sprint, đội nên thảo luận “tất cả những điều gây cản trở họ nếu hoạt động này được lựa chọn trong mỗi Sprint”.
Những nguyên nhân gốc rễ thường gặp đối với các trở ngại bao gồm:
- Đội thiếu tập kỹ năng cần thiết để thực hiện theo đúng DoD cho sprint hay cho chức năng.
- Đội thiếu bộ các công cụ cần thiết (Ví dụ: môi trường tích hợp liên tục, tự động dựng, máy chủ v.v…)
- Thành viên đội sản xuất thực hiện sprint của họ theo kiểu mini-waterfalls
(A ha! Đây lại là một cơ hội để “liên thủ” và chia sẻ trách nhiệm nhiều hơn trên các khối chức năng)
DoD không bất biến.
DoD thay đổi theo thời gian. Hỗ trợ việc tổ chức và khả năng đội sản xuất tháo gỡ các trở lực, có thể cho phép bổ sung thêm các hoạt động mới vào trong DoD đối với chức năng hoặc Sprint.
DoD là một danh sách kiểm tra có thể thẩm tra được.
Các tính năng được phân nhỏ thành các công đoạn (task) trong cả quá trình lên kế hoạch cho sprint cũng như trong suốt Sprint. DoD được sử dụng để xác định xem tất cả các khâu quan trọng có được hoạch toán (về số giờ còn lại). Đồng thời, sau khi một chức năng hoặc sprint hoàn thành, DoD được sử dụng như là một danh sách kiểm tra để xác minh xem tất cả các hoạt động gia tăng đã được hoàn tất hay chưa.
Điều quan trọng cần lưu ý là các DoD nói chung tồn tại những hạn chế. Không phải tất cả các hoạt động gia tăng giá trị sẽ áp dụng được cho mỗi chức năng khi mà DoD được coi như là một bản danh sách toàn diện. Đội sản xuất có ý thức tự giác quyết định việc áp dụng các hoạt động gia tăng giá trị trên từng tính năng cơ bản. Ví dụ, cho rằng hướng dẫn sử dụng người dùng cho chức năng cung cấp điểm tích hợp (như webservice chẳng hạn) tới hệ thống khác không thể áp dụng được cho một tính năng cụ thể; tuy nhiên đối với những tính năng khác trong hệ thống có thực hiện việc giao tiếp với con người thì hướng dẫn sử dụng cho người dùng là cần thiết.
Tổng kết
DoD là trực giao với tiêu chuẩn chấp nhận của người dùng (chấp nhận về chức năng) đối với một tính năng. Nó là một danh sách kiểm tra toàn diện những thứ cần thiết, hoạt động gia tăng giá trị giúp khẳng định chất lượng của một chức năng hoặc phi tính năng của chức năng đó. DoD là báo cáo thực để nắm bắt các hoạt động có thể được cam kết là thực sự hoàn thành bởi đội sản xuất tại các cấp độ khác nhau (tính năng, sprint, bản phát hành).
Dịch từ “What is Definition of Done? (DoD)” của Dhaval Panchal tại ScrumAlliance.org | Theo HanoiScrum.net.
