Một phần tăng trưởng sản phẩm chỉ có hai trạng thái “hoàn thành” hoặc “chưa hoàn thành”, chứ không có khái niệm “gần xong” hay là “hầu như xong” ở đây. Nhờ việc tạo ra và chuyển giao những phần mềm đã “hoàn thành” sau mỗi Sprint, Scrum có thể giúp giảm rủi ro lãng phí nguồn lực và tài chính. Qua đó, một phiên bản mới của sản phẩm có thể được phát hành cho người dùng sử dụng. Sau đây là phần biên dịch lại từ bài viết “Why Scrum Requires Completely “Done” Software Every Sprint” đăng trên Scrum.org của Christiaan Verwijs, trong đó tác giả giải thích rất kỹ ý nghĩa của “hoàn thành” trong Scrum.
Định nghĩa “hoàn thành”
Tiêu chí xác định “Done” phụ thuộc nhiều vào ngữ cảnh. Việc xây dựng môt trang web cho khách hàng bên ngoài có tính chất công việc tương đối khác so với việc xây dựng phần mềm cho người dùng nội bộ tổ chức. Nó phụ thuộc vào bộ tiêu chí đánh giá chất lượng sản phẩm của tổ chức mà bạn đang làm việc, mức độ quan trọng của phần mềm đó đối với doanh nghiệp, mức độ tham gia của người dùng, công nghệ được sử dụng và nhiều yếu tố khác.
Giả sử rằng bạn đang xây dựng một tính năng mới cho sản phẩm của mình trong Sprint hiện tại. Việc xây dựng tính năng này đòi hỏi một quy trình làm việc bao gồm tất cả các công đoạn cần thiết, từ viết mã đến kiểm thử đơn vị, từ thiết kế đến thử nghiệm trên các thiết bị di động, từ kiểm thử chấp nhận đến tích hợp, và cuối cùng là triển khai tính năng cho người dùng cuối của bạn. Việc này đòi hỏi tất cả các kỹ năng của nhóm phát triển và một luồng công việc hiệu quả để thực hiện toàn bộ các công việc này trong một Sprint. Điều này có thể khiến nhóm phát triển giới hạn lại phạm vi của định nghĩa hoàn thành (DoD) dựa trên những việc mà nhóm có thể làm.
Nhiều nhóm mới thực hành Scrum cho rằng không thể làm tất cả những điều này vì những trở ngại về kỹ thuật và tổ chức. Họ giới hạn định nghĩa hoàn thành trong phạm vi mà nhóm có thể đạt được sau mỗi Sprint và thống nhất về định nghĩa “hoàn thành” chỉ với những tiêu chí như sau:
- Code đã được kiểm tra bởi một thành viên khác trong nhóm
- Bộ Unit test đã được viết ra và kiểm tra thành công
- Code đã được tích hợp vào mã nguồn thành công
Cụ thể hơn, nhóm phát triển sẽ chuyển các hạng mục công việc sang trạng thái “hoàn thành” trên bảng Scrum khi nó đã đạt được những tiêu chí ở trên.
“Hoàn thành” và “chưa hoàn thành”
Nhóm phát triển nghĩ rằng họ đang chuyển giao phần tăng trưởng đã “hoàn thành” sau mỗi Sprint, họ đã đạt được tất cả các tiêu chí đề ra trong định nghĩa “hoàn thành”. Nhưng chúng có thực sự “hoàn thành” không? Với định nghĩa “hoàn thành” chỉ tập trung vào việc đảm bảo phần code chạy được, Product Owner sẽ khó có thể đánh giá phần tăng trưởng được tạo ra. Mọi phản hồi trên kết quả trung gian sẽ không đầy đủ. Hậu quả là những công việc khác có thể sẽ phát sinh thêm trong Sprint tiếp theo. Một số ví dụ cụ thể như sau:
- Sau khi xem xét tính năng, Product Owner thấy bị thiếu một số phần quan trọng đã hứa với các bên liên quan, yêu cầu phải thay đổi trong Sprint sau
- Trong lúc kiểm thử tính năng, người dùng phát hiện một lỗi cần được sửa trong Sprint tiếp theo
- Bị lỗi khi tích hợp tính năng với nhóm khác trên cùng một sản phẩm, yêu cầu nhóm phát triển giải quyết xung đột này trong Sprint sau
- Tính năng không tương thích trên một số thiết bị di động, yêu cầu nhóm phát triển phải sửa trong Sprint sau.
- Khi triển khai tính năng cho khách hàng, quá trình cài đặt bị thất bại. Trong suốt Sprint sau đó, nhóm phát triển phát hiện ra vấn đề là do thiếu thư viện hỗ trợ
- Quá trình quét bảo mật phát hiện ra tính năng dễ bị tấn công bởi SQL Injection, yêu cầu nhóm phát triển khắc phục vấn đề này trong Sprint sau.
- Sau khi triển khai tính năng, độ trễ đường truyền mạng tang lên rất cao
- Do thiếu tài liệu hỗ trợ, nên nhóm phát triển phải mất thời gian trả lời các cuộc gọi hỗ trợ từ khách hàng chỉ để xử lý những vấn đề đơn giản
- Những người có thị lực kém không thể sử dụng tính năng này, đây là một nhóm người dùng quan trọng nên yêu cầu phải chỉnh sửa trong Sprint sau.
Về căn bản, những vấn đề này không được phát hiện trong Sprint hiện tại, mà là trong Sprint tương lai. Đây là những ví dụ về những phần công việc chưa hoàn thành; những phần công việc này thực sự cần thiết để hoàn thành một hạng mục trong Product Backlog nhưng lại không nằm trong định nghĩa “hoàn thành”. Những phần công việc chưa hoàn thành này sẽ gây ra bốn hậu quả sau:
- Gây lãng phí thời gian và năng lực của nhóm phát triển. Khoảng cách càng lớn giữa những gì nhóm xác định là “hoàn thành” và những gì thực sự cần, càng có nhiều gián đoạn xảy ra ở các Sprint sau do phần công việc “chưa hoàn thành”. Nhóm Scrum sẽ ngày càng khó đưa ra dự báo về tiến độ công việc trong các Sprint kế tiếp;
- Bởi vì công việc chưa hoàn thành không được phát hiện trong Sprint hiện tại, nên không biết và không thể đoán trước tần suất nó diễn ra. Điều này làm giảm tính minh bạch của phần tăng trưởng và các tính năng đang được phát triển. Cụ thể hơn, sẽ khó trả lời các bên liên quan về việc một tính năng có “hoàn thành” hay chưa;
- Nhóm Scrum tự đánh lừa mình rằng họ đang thành công bằng cách “luôn luôn bận rộn”. Họ kéo rất nhiều công việc vào Sprint Backlog của họ, velocity của họ có thể trông rất tốt, mọi người đều làm việc rất chăm chỉ trong suốt thời gian đó. Nhưng khi kết thúc Sprint, họ không tạo ra được bất kỳ phần tăng trưởng sản phẩm có thể chuyển giao nào cho khách hàng.
- Rủi ro cao cho cả phần tăng trưởng và các tính năng của nó, cũng như lượng công việc chưa hoàn thành còn lại, đều không minh bạch. Chúng ta vẫn không thể xác thực các giả định về tính năng hoặc toàn bộ sản phẩm vì nó chưa thực sự “hoàn thành”.
Tóm lại, theo thời gian điều này sẽ làm xói mòn niềm tin về nhóm Scrum vì các bên liên quan và ban quản lý sẽ không còn tin vào những gì nhóm có thể chuyển giao cho họ.
Định nghĩa Hoàn thành là “công cụ giúp phát hiện rủi ro”
Trong Scrum, đối với những công việc mang tính phức tạp, một định nghĩa “hoàn thành” đủ tốt là công cụ hiệu quả nhất giúp phát hiện những rủi ro tìm tàng. Nó giúp hạn chế rủi ro phát sinh thêm những phần công việc chưa hoàn thành bằng cách làm rõ tất cả những gì cần thiết để tạo ra phần tăng trưởng sau mỗi Sprint. Nó cũng giúp chỉ rõ tất cả những khó khăn đang cản trở việc đạt được mục tiêu này.
Tất nhiên rủi ro không thể được hạn chế hoàn toàn. Đây vẫn là một vấn đề phức tạp, không thể đoán trước được.
Cần phải làm gì bây giờ?
Rõ ràng việc tạo ra các phần tăng trưởng sau mỗi Sprint là một ưu tiên hàng đầu đối với bất kỳ nhóm Scrum nào và không dễ để đạt được điều đó. Nhưng những điều dưới đây có thể giúp ích cho bạn:
- Duy trì sự tập trung có tính kỷ luật cao vào những việc để “hoàn thành” phần mềm. Nếu bạn đang không thể tạo ra một phần tăng trưởng tiềm năng có thể chuyển giao được sau mỗi Sprint, đừng cố gây ấn tượng bằng cách lắp đầy Sprint Backlog của bạn bằng những công việc mà bạn cho rằng sẽ tạo ra nhiều giá trị. Thay vào đó, chỉ đưa vào Sprint Backlog những gì thực sự cần thiết để tạo ra các phần tăng trưởng tiềm năng có thể chuyển giao được. Điều này đôi khi bao gồm cả những điều chỉnh về cơ sở hạ tầng, học tập thêm các kỹ năng hoặc công nghệ và loại bỏ các trở ngại của tổ chức.
- Minh bạch khoảng cách giữa những gì bạn có thể làm và những gì cần “hoàn thành”. Đừng chọn cách dễ dàng và giới hạn định nghĩa hoàn thành của bạn dựa trên những gì bạn có thể làm. Thay vào đó, hãy xác định rõ những gì bạn nên làm để “hoàn thành”phần tăng trưởng và bù đắp bằng những gì hiện tại bạn có thể làm. Liệt kê tất cả những điều vướng mắc, khó khăn, xem nó như những trở ngại cần được giải quyết để rút ngắn khoảng cách đó và luôn nhắc nhở mọi người liên quan, đặc biệt là ban quản lý, rằng những rủi ro chỉ thực sự bắt đầu giảm đi khi khoảng cách này được rút ngắn.
- Làm nhỏ hơn và đơn giản hơn. Một sự thật đơn giản nhất trong Scrum và Agile là hãy làm cho nó nhỏ hơn và đơn giản hơn. Đây là lý do tại sao làm mịn là một hoạt động quan trọng trong Scrum. Nếu không thể thực hiện tất cả các bước cần thiết cho phần tăng trưởng, hãy tách nó thành các phần nhỏ hơn và chỉ tập trung hoàn thành các phần nhỏ thực sự cần thiết trong một Sprint.
- Giảm rủi ro, tối đa hóa giá trị và làm rõ các trở ngại đang mắc phải. Bạn có thể cho rằng những gì Scrum yêu cầu là không thể và bất khả thi. Nhưng trong thế giới phức tạp như lĩnh vực phát triển phần mềm thì một quy trình mang tính thích nghi (như Scrum) là công cụ tốt nhất mà chúng ta có thể dùng để giảm thiểu rủi ro và tối đa hóa giá trị chuyển giao cho các bên liên quan. Hơn nữa, nó là cách tốt nhất để làm cho mọi thứ kiềm hãm bạn - như thành phần nhóm, thủ tục và các điểm nghẽn trong tổ chức – trở nên minh bạch và (do đó) có thể giải quyết được.
Một sự thật khó chấp nhận
Có một sự thật là nếu bạn không thể “hoàn thành” một phần tăng trưởng (ít nhất) trong mỗi Sprint, thì bạn chưa là Scrum. Bạn có thể tự hào về hành trình của mình đang hướng tới Scrum, nhưng đừng tự lừa dối mình bằng cách gọi nó là Scrum. Bởi vì khả năng phát hiện rủi ro của bạn vẫn còn rất hạn chế, bạn sẽ thấy rất ít lợi ích của quy trình thực nghiệm mà Scrum có thể mang lại. Nhưng tin tốt là việc duy trì sự tập trung có tính kỷ luật cao vào việc tạo ra phần mềm đã “hoàn thành” trong mỗi Sprint sẽ khiến mọi thứ trở nên trực quan rất nhiều.
