Scrum được định hướng là một khung làm việc đơn giản nhưng hiệu quả để phân phối các sản phẩm phức tạp. Scrum không phải là một giải pháp cho mọi vấn đề, một lời giải tuyệt đối cho những vấn đề hóc búa hay một phương pháp toàn diện. Thay vào đó, Scrum đề ra những giới hạn tối thiểu trong việc nhóm có thể tự tổ chức để giải quyết một vấn đề phức tạp nào đó theo hướng thực tiễn, quan sát và thực hành thay vì chỉ lý thuyết chung chung. Sự tối giản này chính là sức mạnh lớn nhất của Scrum, nhưng cũng chính là nguồn cơn của rất nhiều lời đồn đoán và sự hiểu lầm xung quanh nó. Trong loạt bài viết này, chúng tôi – Christiaan Verwijs và Barry Overeem – sẽ “giải mã những hiểu lầm” của bạn, sẽ đề cập đến những đồn đoán và hiểu lầm phổ biến nhất. Thea Schukken là tác giả của những minh họa tuyệt vời cho loạt bài viết này. Trong phần trước, chúng tôi đã “giải mã” hiểu lầm về việc ScrumMaster bắt buộc phải tham dự Scrum Hằng Ngày.
Barry Overeen và Christiann Verwjis, những người “giải mã” các hiểu lầm về Scrum
Hiểu lầm về việc Sprint Backlog không thể thay đổi trong suốt Sprint
Rất nhiều người lầm tưởng rằng Sprint Backlog không thay đổi trong suốt Sprint. Nhóm Phát triển cam kết thực hiện tất cả các hạng mục công việc trong Sprint Backlog, không cho phép có bất kì sự thay đổi nào điễn ra trong Sprint (không thêm, không bớt). Điều này giúp nhóm có được sự tập trung cần thiết để hoàn thành các cam kết đã đề ra.
Vậy, tại sao việc này lại là một sự hiểu lầm?
“Bắt bệnh” hiểu lầm
Sprint Backlog trình bày các công việc mà một Nhóm Phát triển cần thực hiện để đạt được Mục tiêu Sprint. Mục tiêu Sprint được đặt ra bởi Nhóm Scrum trong cuộc họp Lập kế hoạch Sprint. Mục tiêu Sprint cần thể hiện được giả thuyết mà nhóm muốn thử nghiệm và muốn đạt được. Mặc dù Mục tiêu Sprint là cố định, nhưng Sprint Backlog thì không. Điều này có vẻ không đúng, nếu chúng ta nhìn lại những tiền đề cốt lõi của Scrum: Chúng ta không thể tạo ra các bản kế hoạch chi tiết cho tương lai. Thậm chí tương lai chỉ gói gọn trong một Sprint, hoàn toàn vẫn có thể xuất hiện những vấn đề mới hay các trở ngại Sprint khi Nhóm Phát triển thực hiện các công việc trong Sprint Backlog.
Một nhóm có thể biết rằng, công nghệ mà được chọn vẫn có thể không được như mong muốn. Hoặc một hạng mục quan trọng cần thiết để đạt được Mục tiêu Sprint lại bị bỏ sót khi thực hiện Lập kế hoạch Sprint. Khi các vấn đề xuất hiện, những thay đổi với Sprint Backlog cần được đảm bảo nhằm đạt được Mục tiêu Sprint.
Nhóm Phát triển sẽ đàm phán lại về Sprint Backlog với Product Owner. Tóm lại, một Sprint Backlog có thể linh hoạt, miễn là những thay đổi không ảnh hưởng tới Mục tiêu Sprint.
Scrum Hằng ngày giúp các nhóm có cơ hội để thanh tra và thích nghi với tiến độ đạt được Mục tiêu Sprint và tạo ra các điều chỉnh thích hợp cho Sprint Baclog khi cần thiết.
Cam kết và Dự đoán
Liên quan tới vấn đề này, Hướng dẫn Scrum (Scrum Guide) đã và đang thay đổi kể từ một vài năm trước đây. Trong khuôn khổ nội dung về Sprint Backlog, từ “Cam kết” được thay thế bằng từ “Dự đoán”. Trong cuốn hướng dẫn mô tả Sprint Backlog như là một dự đoán của Nhóm Phát triển về chức năng có thể sẽ là một phần của Gói tăng trưởng tiếp theo và các công việc cần làm để hoàn thành chức năng đó và đưa vào Gói tăng trưởng phần mềm “Hoàn thành”. Điều này nhấn mạnh rằng các thông tin và các vấn đề không mong đợi có xu hướng xảy ra trong giai đoạn phát triển, dù cho đó chỉ là trong khuôn khổ của một Sprint.
Tuy nhiên, các nhóm vẫn duy trì các Cam kết. Họ tự cam kết với các việc:
- Hoàn thành Mục tiêu Sprint;
- Tạo ra các phần mềm chất lượng cao, có thể sử dụng được, đáp ứng được mong đợi của khách hàng và người dùng;
- Chỉ làm việc trên các hạng mục Product Backlog với giá trị cao nhất;
- Tập trung vào cải tiến, học tập liên tục, và kĩ thuật xuất sắc;
- Thanh tra và thích nghi liên tục với những trải nghiệm được hỗ trợ;
- Hợp tác với tất cả nhân sự thuộc mảng kinh doanh có liên quan;
- Giá trị và các thành phần cơ bản của Khung làm việc Scrum.
Khi Sprint Backlog là đầu ra được trông đợi, Mục tiêu Sprint chính là kết quả mà chúng ta muốn đạt được. Thay vì cố gắng “nhồi” nhiều hạng mục nhất có thể vào một Sprint, chúng ta nên đạt được một kết quả đáng trông đợi (Mục tiêu Sprint) với số lượng hạng mục ít nhất (Sprint Backlog).
Bám lấy bản chất thay đổi của Sprint Backlog. Khuyến khích Nhóm Phát triển thay đổi, cải thiện và điều chỉnh Sprint Backlog trong suốt Sprint. Nếu một công việc mới phát sinh, Nhóm Phát triển cần đưa vào Sprint Backlog. Ngược lại, loại bỏ khỏi Sprint Backlog nếu công việc đó được chứng minh là không cần thiết. Những điều chỉnh với các thay đổi này hoàn toàn phụ thuộc vào nhóm, và họ có thể thông báo với Product Owner nếu thấy điều đó là cần thiết. Bất kì sự thay đổi nào trong Sprint Backlog được “hoàn thành” thì Mục tiêu Sprint cũng “hoàn thành” và tạo ra Phần tăng trưởng “hoàn thành”.
Lời kết
Trong bài viết này, chúng tôi đã miêu tả hiểu lầm về việc Sprint Backlog là không thay đổi trong Sprint. Chúng tôi đã gỡ bỏ các hiểu lầm này bằng cách đưa ra góc nhìn từ Hướng dẫn Scrum và mô tả sự khác biệt giữa Dự đoán và Cam kết.
Bạn có suy nghĩ gì về hiểu lầm này? Chúng tôi luôn sẵn sàng lắng nghe và học hỏi từ kinh nghiệm của bạn!!!
Nguồn: medium.com
