Definition of Done (DoD) là một thoả thuận cơ sở để xác định điều kiện nghiệm thu công việc hoàn thành của Scrum Team theo từng bối cảnh cụ thể của dự án Agile. Vậy DoD là gì? Có bao nhiêu loại DoD? Và DoD giúp gì cho các vai trò trong đội dự án và các thành viên liên quan?… Vâng, đó là những câu hỏi phổ biến mà tôi nhận được khi trao đổi với nhiều bạn đã và đang tham gia dự án Agile trong các đơn vị phát triển phần mềm.
DoD là gì?
- DoD la danh sách các điều kiện cơ sở để nghiệm thu các các công việc được hoàn thành bởi các thành viên của đội dự án.
- DoD có thể được hiểu như là một hợp đồng cam kết giữa đội dự án với khách hàng.
- DoD được tạo ra từ sự nỗ lực tương tác giữa các vai trò trong dự án Agile Scrum như Product Owner, Scrum Master, Develoment Team.
- DoD được phát triển ở Sprint Planning đầu tiên của mỗi iteration và tiếp tục xem xét và điều chỉnh ở các iteration trong tương lai.
Các mục trong Định nghĩa hoàn thành nhằm áp dụng cho tất cả các mục trong product backlog, không chỉ một User story đơn lẻ. Nó có thể được tóm tắt như sau:
- Thuật ngữ này áp dụng cho toàn bộ sản phẩm
- Trong hầu hết các trường hợp, thuật ngữ này có nghĩa là sản phẩm có thể được giao (delivery).
- Thuật ngữ này được định nghĩa trong Hướng dẫn Scrum.
- Được sử dụng như một phương tiện giao tiếp giữa các thành viên trong nhóm khi trao đổi về:
+ Chất lượng phần mềm tổng thể
+ Liệu phần gia tăng có thể delivery hay chưa?
Mục tiêu của DoD
- Xây dựng sự hiểu biết chung trong nhóm về chất lượng và tính chính trực
- Sử dụng làm danh sách kiểm tra để kiểm tra User story (hoặc PBI - Product Backlog Item)
- Đảm bảo rằng các sản phẩm được delivery trong giai đoạn nước rút có chất lượng cao và chất lượng đó được tất cả mọi người tham gia hiểu rõ.
Có bao nhiêu loại DoD?
Việc phân loại DoD tạo điều kiện cho các thành viên tham gia dự án phân biệt rõ ràng, dễ nhớ và tự nghiệm thu công việc của thân mình, và của đội đã cam kết. Thông thường nên phân làm 3 loại DoD, đó là: DoD cho User Story; DoD cho Sprint và DoD cho Release.
a) DoD cho User Story: Là danh sách các điều kiện làm cơ sở để xác định User Story đã hoàn thành trong việc phát triển yêu cầu, triển khai code, kiểm thử,… ví dụ như:
- User Story đã xác định có điều kiện nghiệm thu (acceptance criteria) rõ ràng. Nếu chưa xác định được thì Development team có thể từ chối chọn vào Sprint Board trong sự kiện Sprint Planning.
- Code phải được thực hiện review chéo và ghi lại báo cáo kết qủa review.
- User Story phải thực hiện Unit Test và phải passed 70% các case (tuỳ thuộc năng lực của team và đặt thù dự án).
- Code phải hoàn thành submit lên server và đã chạy không bị lỗi với các công cụ test automation.
- Tính năng liên quan User Story không tồn tại bất kỳ lỗi nào (bug).
- Product Owner phải nghiệm thu nếu User Story đã thoả mãn các điều kiện nghiệm thu,…
b) DoD cho Sprint: Là danh sách các điều kiện cơ sở để xác định một Sprint thành công hay thất bại ví dự như:
- Product Owner phải xác định rõ Goal cho Sprint.
- Tất cả các User Story đã hoàn thành phải được nghiệm thu và chấp nhận bởi Product Owner.
- Development team phải host sản phẩm lên server trước thời gian của sự kiện Sprint Reivew.
- Development team hoàn thành công việc demo sản phẩm thành công.
- Các chức năng liên quan các User Story chọn để phát triển không gây lỗi cho các tính năng đã phát hành trước đó.
- Một số tài liệu thiết kế đã bàn giao trước thời gian Sprint Review,…
c) DoD cho Release: Là danh sách các điều kiện cơ sở để xác định những công việc cần hoàn thành cho một đợt phát hành, vi dụ như:
- Product đã hoàn thành trước ngày phát hành.
- Có những tài liệu ghi thông tin phiên bản phát hành, hướng dẫn cài đặt.
- Có tài liệu hướng dẫn sử dụng cho người dùng cuối liên quan đến những tính năng có trong kế hoạch phát hành.
- Tất cả các User Story trong đợt phát hành đã được hoàn thành và đã được nghiệm thu.
- Không còn bất kỳ lỗi nào còn tồn đọng liên quan đợt phát hành.
- Sản phẩm đã hoàn thành kiểm thử trên môi trường thử nghiệm độc lập,…
DoD giúp gì cho các vai trò trong đội dự án và các thành viên liên quan?
Thật khó để xác định một công việc hoàn thành. Chúng ta cần xây dựng cơ sở để xác định những công việc đã hoàn thành. Và nó đảm bảo cho tính minh bạch (Transparency) với tất cả các thành viên tham gia và nỗ lực để hoàn thành công việc đã cam kết. Bên dưới là những gia trị mà các thành viên có thể nhận được:
- Với vai trò Product Owner: Họ sẽ hình dung rõ ràng trách nhiệm hỗ trợ của mình trong việc lênh kế hoạch phát hành, trách nhiệm nghiệm thu, và trách nhiệm chuẩn bị thật tốt các yêu cầu và hỗ trợ tối đa để team đạt hiệu suất cao trong công việc,…
- Với vai trò Development team: Họ hình dung rất rõ công việc cần hoàn thành, thúc đẩy các thành viên trong nhóm chủ động, can đảm đưa ra cam kết và là tiền đề để xây dựng nhóm tự quản (Self-Organizing), thúc đẩy họ điều chỉnh quy trình làm việc để nâng cao hiệu suất,…
- Với vai trò Scrum Master: Là cơ sở để giải quyết vấn đề xung đột giữa Product Owner, Development team và các đối tượng liên quan, là cơ sở để xác định các trở ngại và tìm ra những hạn chế trong hành vi các thành viên liên quan để đưa ra hướng đào tạo, huấn luyện phù hợp,…
- Với Stakeholders: Đây là cơ sở để họ nâng cao niềm tin với các thành viên của đội dự án và thúc đẩy họ đưa ra cách tương tác phù hợp hơn để đội dự án cho ra sản phẩm chất lượng, phát hành nhanh và giúp họ đạt được cơ hội kinh doanh sớm hơn.
