EN |
VN
Định nghĩa về sự hoàn tất – DoD (Definition of ‘Done’) có lẽ là khái niệm dễ bị hiểu nhầm nhất của Scrum Framework. Trong bài viết này, chúng ta sẽ thảo luận về 2 vấn đề:
- Định nghĩa về sự hoàn tất là gì?
- Làm thế nào để sử dụng DoD trong các sự kiện của Scrum?
Định nghĩa về sự hoàn tất là gì?
“Định Nghĩa về Sự Hoàn Tất là một mô tả chính thức về trạng thái của Increment khi nó thoả các quy chuẩn về chất lượng của sản phẩm.” Theo Scrum Guide .
DoD cung một cái nhìn chung giữa Scrum Team bao gồm: Developers, Product Owner, Scrum Master với những người kiểm ta (các bên liên quan). Nó xác định ý nghĩa của việc hoàn thành công việc.
Mục tiêu của một Sprint là tạo ra một phần gia tăng có khả năng phát hành increment. Do đó, định nghĩa về sự hoàn tất đóng một vai trò quan trọng trong việc triển khai thành công khung Scrum trong việc mang lại giá trị. DoD là cam kết dành cho một trong những tạo tác của Scrum – ‘Increment’.
DoD hỗ trợ chủ nghĩa thực nghiệm bằng cách cung cấp tính minh bạch thông qua việc xây dựng một cái nhìn chung về những yếu tố được yêu cầu trong suốt quá trình phát triển sản phẩn để biến các hạng mục trong Product Backlog (Product Backlog Item – PBI) thành một phần gia tăng có thể sử dụng được, có giá trị và có thể phát hành.
Ai chịu trách nhiệm chính cho “Định Nghĩa về Sự Hoàn Tất”
Có một “Định Nghĩa về Sự Hoàn Tất” là trách nhiệm của toàn bộ Scrum Team. Tuy nhiên, nếu tổ chức đã có sẵn một số tiêu chuẩn thì các Scrum Team phải tuân thủ nó như một yêu cầu tối thiểu và có thể mở rộng khi cần thiết.
Ví dụ, nhiều tổ chức sẽ phải tuần thủ theo một số quy định, tiêu chuẩn của ngành nghề,…Những quy định, tiêu chuẩn đó phải được áp dụng cho các sản phẩm nên nó phải là một phần của Định nghĩa về sự hoàn tất cho sản phẩm đó.
Một ví dụ khác, có thể có một số tiêu chuẩn và chính sách bảo mật ở cấp độ tổ chức mà tất cả các sản phẩm phải tuần thủ. Những tiêu chuẩn và chính sách này sẽ trở thành một phần trong định nghĩa về sự hoàn tất.
Scrum Team có thể thêm các tiêu chí kỹ thuật và chất lượng sản phẩm của mình để làm cho sản phẩm có thể sử dụng được, có giá trị và có thể phát hành. Họ cũng có thể thêm một số quy trình nội bộ để nâng cao chất lượng tổng thể của sản phẩm. Ví dụ như đánh giá mã (Code Reviews), lập trình đôi (Pair Programming), kiểm thử tự động (Automation Testing),…
Định nghĩa về sự hoàn tất trong mối quan hệ với 5 sự kiện của Scrum
DoD hỗ trợ khung Scrum thông qua các sự kiện trong Scrum
1. Sprint Planning
Định nghĩa về sự hoàn tất giúp Scrum Team hiểu những hoạt động nào được yêu cầu để hoàn thành trong công việc và từ đó giúp việc phân rã các hạng mục trong Product Backlog thành một kế hoạch khả thi. Dựa trên điều này, Developers có thể dự báo cần bao nhiều công sức để chuyển một hạng mục trong product backlog thành một phần increment hoàn thành. Điều này giúp Scrum Team lựa chọn khối lượng công việc có thể lấy từ Product Backlog.
Ví dụ, DoD phải là một trong những yếu tố trong quy trình “tạo ghi chú phát hành”. Nhóm cần cân nhắc mất bao nhiêu thời gian để viết ghi chú cho các tính năng mà nhóm đang xây dựng và lập kế hoạch phù hợp.
💡Mẹo: Hiển thị DoD xuyên suốt Sprint Planning. Yêu cầu Developers tham khảo nó thường xuyên
2. Daily Scrum
DoD giúp các nhóm nhận ra rằng ngay cả khi các thành viên riêng lẻ đã hoàn thành nhiệm vụ của mình liên quan đến một hạng mục trong Product Backlog thì hạng mục đó cũng sẽ không được coi là “hoàn thành” cho đến khi định nghĩa được đáp ứng hoàn toàn. Điều này giúp xây dựng tư duy “Mục tiêu của nhóm hơn mục tiêu cá nhân” và daily scrum mà sự kiện tốt nhất cho điều đó.
💡Mẹo: Xây dựng quy trình làm việc mà tại đó Scrum Team biết cách làm thế nào để đạt được “Hoàn Thành”. Sử dụng các cột để thể hiện luồng công việc. Bắt đầu từ phải qua trái trong suốt Daily Scrum. Các mục bên phải sẽ tiến gần đến “hoàn thành” hơn và từ đó có thể chuyển đổi thành giá trị.
3. Sprint Review
DoD cung cấp một cái nhìn chung giữa các bên liên quan và Scrum Team về ý nghĩa của “Hoàn thành” và về các tiêu chí chất lượng của sản phẩm hiện có. Điều này giúp tăng cường tính minh bạch giữa những người tham gia và hỗ trợ thuyết thực nghiệm.
Scrum Team nhận được phản hồi tốt nhất khi họ chia sẻ Increment “hoàn thành” với các bên liên quan. Những công việc chưa hoàn thành làm giảm tính minh bạch và đôi khi có thể gây nhầm lẫn cùng những kỳ vọng phi thực tế.
“Nếu một hạng mục trong Product Backlog không thoả Định Nghĩa về Sự Hoàn Tất, nó không thể được phát hành và thậm chí không được trình bày trong Sprint Review. Theo Scrum Guide ”
Thỉnh thoảng, Sprint Review có thể là một điểm kích hoạt để điều chỉnh Định nghĩa của sự hoàn tất.
Chuyện của tác giả
Vào khoảng – , tôi là thành viên của một đội phát triển ứng dụng dành cho thiết bị điện thoại di động của một công ty dịch vụ tài chính. Vì đây là sản phẩm mang tính chiếu lược nên nhiều lãnh đạo cấp cao quan tâm và thường xuyên tham dự buổi Sprint Review. Trong một buổi Sprint Review, khi chúng tôi chia sẻ về increment với các bên liên quan và bắt đầu thảo luận về lộ trình trong tương lai, Trưởng bộ phần Kỹ Thuật số đã hỏi chúng tôi rằng “Chào mọi người, tôi không thấy bất kỳ yếu tố nào của GDPR” (những người không biết GDPR là gì – Đó là quy định của luật EU về bảo vệ dữ liệu và quyền riêng tư cho tất cả các cá nhân trong Liên minh châu Âu và Khu vực kinh tế châu Âu).
Khi đó, với vai trò là Product Owner, tôi không biết gì về GDPR và đã trả lời: “GDPR…GDPR là gì?”
Có thể bạn đang cười nhưng tôi thật sự không biết về nó lúc đó, quy định GDPR rất mới. Tuy nhiên, cuộc thảo luận đó không chỉ kích hoạt các hạng mục mới trong Product Backlog trong tương lai mà còn cả nhu cầu điều chỉnh về định nghĩa về sự hoàn tất.
4. Sprint Retrospective
Đây là sự kiện tốt nhất để DoD được điều chỉnh nhằm cải thiện chất lượng sản phẩm và quy trình nội bộ. Nhiều nhóm bắt đầu với những DoD ít nghiêm ngặt hơn trong giai đoạn đầu của sản phẩm. Tuy nhiên, mục tiêu dài hạn phải là giảm nợ kỹ thuật có thể bị tích lũy do DoD chưa chặt chẽ.
Ví dụ, khi tôi lần đầu tiên phát triển khóa học trực tuyến của mình, DoD thì không quá chặt chẽ. Nó không có các yếu tố như “Không lỗi chính tả”, “Phải sử dụng cùng một phông chữ trong suốt khóa học”,…Tôi tập trung nhiều hơn vào nội dung. Nhưng tôi đã học được từ các ý kiến phản hồi và DoD đã tốt hơn theo thời gian bằng cách thêm nhiều tiêu chí chất lượng hơn.
5. Sprint
“Các Sprints đóng vai trò như nhịp tim đối với Scrum, trong đó, các ý tưởng được biến thành giá trị. Tất cả công việc cần thiết để đạt Product Goal, bao gồm Sprint Planning, Daily Scrum, Sprint Review và Sprint Retrospective đều diễn ra trong các Sprints. Theo Scrum Guide ”
Các Sprint cung cấp sự nhất quán giúp quản lý sự phức tạp trong phát triển sản phẩm. Cách chúng ta chọn độ dài của một Sprint cũng phụ thuộc vào khả năng của các Scrum Team trong việc tạo ra các Increment “hoàn thành”. Do đó, định nghĩa về sự hoàn tất đóng vai trò rất quan trọng trong đó.
Tất cả công việc đáp ứng Product Goal và Sprint Goal đều diễn ra trong Sprint. Làm thế nào chúng ta có thể đạt được các mục tiêu của mình mà không có những Increment “hoàn thành”?
Cam kết của chúng ta đối với việc có một Increment “hoàn thành” biến các ý tưởng và giả định thành giá trị. Trong suốt Sprint, Developers nên luôn ghi nhớ về DoD. “Công việc của chúng ta không phải là hoàn thành trên Jira hay Rally, công việc của chúng ta là mang lại giá trị thông qua việc tạo ra increment “hoàn thành”.
Tổng kết
Không xây dựng định nghĩa về sự hoàn tất tốt hoặc không tuân theo DoD là một trong các lý do chính làm giảm chất lượng sản phẩm và tích lũy nợ kỹ thuật. Điều này làm giảm tính bền vững và khả năng mở rộng của sản phẩm về lâu dài. Đôi khi, việc không có khả năng duy trì và mở rộng quy mô này sẽ làm tê liệt các tổ chức.
Nguồn: Definition of ‘Done’: What It Is and How It Supports Scrum Events
