Hiểu nhầm về việc trong Scrum, các Bản phát hành chỉ được hoàn thành ở cuối Sprint
Ngày nay vẫn tồn tại rất nhiều những nhầm lẫn về Scrum, đặc biệt khi những hiểu lầm kiểu “Scrum linh hoạt do những Bản phát hành mới chỉ có sau khi kết thúc Sprint” hoặc “DevOps/Kanban phù hợp tốt hơn cho chúng ta bởi vì chúng cho phép phát hành nhanh hơn”. Ở cả hai trường hợp trên, cốt lõi của sự nhầm lẫn nằm ở chỗ Scrum chỉ cho phép các nhóm phát hành phần mềm ở cuối Sprint, việc này làm giảm tốc độ và giảm sự linh hoạt nếu các nhóm có khả năng thực hiện nhanh hơn.
“Bắt bệnh” hiểu lầm
Sự nhầm lẫn này là một ví vụ việc tạo ra một khung làm việc quan trọng hơn mục tiêu, mặc dù ở trường hợp này là xuất phát từ sự hiểu lầm về khung làm việc. Mục đích của khung làm việc Scrum là phát triển các sản phẩm, giải quyết các vấn đề phức tạp bằng cách sử dụng quy trình thực nghiệm để thúc đẩy các phản hồi nhanh chóng. Ở những phân đoạn ngắn, chúng ta sử dụng cả nhận xét/đánh giá từ bên trong và bên ngoài nhóm. Do vậy chúng ta tránh được việc giải quyết nhầm vấn đề và/hoặc thực hiện một giải pháp chưa tối ưu. Với mục tiêu đó, làm thế nào mà Scrum buộc các nhóm chỉ được chuyển giao phần mềm ở cuối Sprint?
Mục tiêu của Sprint là tạo ra khoảng thời gian tối ưu cho Nhóm Phát triển để chuyển một số các đầu mục công việc từ Product Backlog sang Phần tăng trưởng Hoàn thành, hoàn toàn mới và có thể sử dụng được. Quan điểm “Hoàn thành” phụ thuộc vào những góc nhìn khác nhau của các nhóm liên quan. Đối với một số nhóm, Phần tăng trưởng “Hoàn thành” là khi mã đã được viết xong và nằm trong một nhánh chia sẻ của Kho chứa (Repossitory). Đối với các nhóm khác, Phần tăng trưởng “Hoàn thành” là khi họ đã triển khai tới môi trường tiền sản xuất (Staging, Q&A và Tích hợp – Integration) hoặc là đã tới môi trường sản xuất.
Việc hoàn thành của Phần tăng trưởng được xác định bởi lượng thời gian cần thiết để đưa được Phần tăng trưởng đó tới người dụng (Ví dụ, tới sản xuất).
Nếu cần nhiều thời gian hơn, tổ chức sẽ kém Agile hơn. Sau cùng, Phần tăng trưởng chỉ thật sự có giá trị nếu chúng đến được tay của người dùng. Đồng thời, chất lượng và việc hoàn thành các nhận xét/đánh giá cũng bị giảm, giống như sự hoàn thành phần tăng trưởng.
Như vậy, Sprint đại diện cho một giới hạn tối thiểu để chuyển giao một Phần tăng trưởng “Hoàn thành”. Trong một Khung làm việc Scrum, không gì có thể ngăn cản các Nhóm Scrum phát hành phần mềm chạy suốt trong Sprint, miễn là Product Owner gắn liền tới việc ra quyết định phát hành. Scrum thực sự khuyến khích các nhóm mở rộng khái niệm “Hoàn thành” các Phần tăng trưởng của họ tới phiên bản đầy đủ nhất (ví dụ như Phát hành ra Sản xuất). Điều này giúp tối đa hoá giá trị của Lý thuyết thực nghiệm, cũng chính là nền tảng của Scrum, khi nhận xét/ đánh giá trở nên thực tế hơn, có tính ứng dụng cao hơn.
Nhầm lẫn bắt nguồn do đâu
Sự nhầm lẫn trước tiên nằm ở sự hiểu nhầm về cái gọi là “Phần tăng trưởng” (increment). Hướng dẫn Scrum (Scrum Guide) định nghĩa đơn giản Phần tăng trường là tổng của tất cả các hạng mục Product Backlog đã hoàn thành trong Sprint. Phần tăng trưởng có thể là một gói các tính năng mới dự định sẽ được triển khai cùng nhau vào cuối Sprint. Nhưng không bắt buộc phải là như vậy. Một phần tăng trưởng cũng có thể là tổng của các chức năng được phát hành trong Sprint.
Thứ hai, việc sử dụng các thuật ngữ như “Phần tăng trưởng sản phẩm có thể phát hành được” hay “Phần tăng trưởng sản phẩm có thể chuyển giao được” cũng góp phần tạo ra những hiểu nhầm về Phần tăng trưởng. Mặc dù không phải do cố ý, vô tình những người làm nhiệm vụ kiểm định có thể tạo ra một niềm tin rằng các Phần tăng trưởng đó chỉ có tiềm năng “phát hành” hay “chuyển giao” ở cuối một Sprint.
Ngoài ra, nhiều sự hiểu nhầm khác xuất phát từ việc phân biệt giữa Scrum và DevOps. Có nhiều người tin rằng DevOps tối ưu hơn Scrum bởi vì nó cho phép các nhóm phát hành phần mềm nhanh hơn. DevOps không có khái niệm Sprint, do vậy DeveOps tin rằng việc ra mắt phần mềm có thể thực hiện ở bất kì thời điểm nào mà nhóm thấy “sẵn sàng”.
Nhưng Scrum và DevOps có mối quan hệ gần gũi, cả hai đều cố gắng để thực hiện lý thuyết thực nghiệm với chu kỳ phản hồi ngắn nhất có thể. Trong khi Scrum tập trung nhiều hơn vào quy trình cần thiết để xây dựng những nhu cầu của bên liên quan. DevOps tập trung giải quyết những yếu tố về kĩ thuật và thực hành cho phép điều đó xảy ra. Theo một cách diễn giải khác, Scrum cung cấp một chiếc la bàn, một đích đến, còn DevOps cung cấc những đôi ủng chắc chắn để hỗ trợ cho việc thực hiện một hành trình mà không gặp trở ngại. Cả hai giống như hai mặt của một đồng xu vậy.
Còn Sơ kết Sprint thì sao?
Nếu mọi thứ được phát hành ở trong Sprint, vậy mục đích của Sơ kết Sprint là gì? Nếu Sơ kết Sprint chỉ dành để trình diễn phần tăng trưởng, vậy thì sự kiện sẽ diễn lại những việc bạn đã biết. Nhưng trình diễn phần mềm hoạt động tốt chỉ là một phần nhỏ của Sơ kết Sprint. Mục đích căn bản của cuộc họp là nhằm thanh tra những công việc đã hoàn thành trong Sprint và để ra quyết định cho Sprint tới, nhằm tối đa hoá giá trị.
Càng nhiều Phần tăng trưởng “Hoàn thành”, càng nhiều phản hồi có giá trị được thu thập.
Do đó, nếu một nhóm đã phát hành phần mềm sử dụng được trong Sprint thì sẽ giúp cho Sơ kết Sprint trở thành một cơ hội tuyệt vời để thanh tra các phản hồi từ người dùng thật và thích ứng dựa trên những thông tin thu thập được từ đó. Giá trị của Sơ kết Sprint thật sự tăng lên khi “Định nghĩa về Hoàn thành” của nhóm chuyển thành “Phát hành tới Sản phẩm”.
Thủ thuật
- Nếu bạn là một ScrumMaster, hãy huấn luyện nhóm của mình liên tục mở rộng “Định nghĩa Hoàn thành”. Nói đơn giản, ScrumMaster hãy giúp nhóm giảm đi khối lượng công việc còn lại sau khi xem xét nó là đã hoàn thành ( ví dụ: kiểm thử, giám sát chất lượng, phát hành, viết tài liệu).
- Đầu tư vào việc tìm hiểu sâu về DevOps và phương pháp liên quan, ví dụ kiểm thử tự động, nền tảng như là mã nguồn (infrastructure as code), ảo hoá và chuyển giao liên tục. Đó là những yếu tố quan trọng cho phép việc phát hành nhanh hơn mà không phải thoả hiệp về chất lượng hay sự ổn định.
- Nếu Sơ kết Sprint chỉ là để trình diễn phần mềm, và nhóm của bạn có khả năng phát hành trong Sprint, hãy sử dụng Sơ kết Sprint cho mục đích nhằm thu thập các phản hồi về những phần tăng trưởng đã được chuyển giao, Product Backlog, điều kiện kinh doanh và thúc đẩy hợp tác giữa những người liên quan.
- Trong khuôn khổ nhóm và tổ chức của bạn, rà soát lại khối lượng công việc cần hoàn thành sau khi nhóm cân nhắc về một phần tăng trưởng “Hoàn thành” ( ví dụ QA, triển khai). Giúp đỡ nhóm/tổ chức để thay đổi các quy trình và phương pháp nhằm giảm đi khối lượng các công việc “chưa hoàn thành”.
Lời kết
Trong bài này, chúng ta đã thảo luận về sự hiểu nhầm rằng các Nhóm Scrum cung cấp bản phát hành tốt nhất vào cuối Sprint, do vậy giới hạn năng lực các nhóm có khả năng thực hiện nhanh hơn việc phát hành. Trong bài này chúng tôi đã chỉ ra rằng Scrum thật sự khuyến khích các nhóm cải thiện quy trình, cơ sở hạ tầng và phương pháp để phát hành sản phẩm có thể thực hiện trong suốt cả Sprint. Điều này gia tăng tối đa chất
Nguồn: medium.com
