Bài viết

Biểu đồ Sprint Burndown có vai trò gì trong Scrum?

Biểu đồ Sprint Burndown thể hiện các ước tính cập nhật hàng ngày về khối lượng công việc còn lại tới khi hoàn thành. Biểu đồ Sprint Burndown lấy dữ liệu ước tính từ Sprint Backlog.

Ví dụ với bảng công việc như Hình 1 thì ta có Biểu đồ Sprint Burndown như Hình 2.
Cập nhật Sprint Backlog

Hình 1. Bảng công việc

Biểu đồ sprint burndown

Hình 2. Biểu đồ sprint Burndown

Biểu đồ Sprint Burndown giúp nhóm biết được trạng thái công việc hiện tại. Nếu xu hướng công việc đang tiến triển đang chậm hơn so với kỳ vọng, một dự báo rằng Sprint này có thể không thể hoàn thành hết công việc, như vậy Nhóm nên tập trung hoàn thành những nội dung quan trọng nhất để đạt mục tiêu Sprint và thậm chí làm việc với PO. Cũng trong trường hợp chậm này, Nhóm cũng nhìn thấy rằng mình đang gặp một số trở ngại để tiến tới mục tiêu Sprint. Lúc này Nhóm có thể cùng thanh tra để tìm ra nguyên nhân của những trở ngại và hành động thích nghi phù hợp.

Tuy nhiên, biểu đồ này chỉ thể hiện một ước lượng, do đó Nhóm không nên quá tin tưởng vào biểu đồ mà nên liên tục thanh tra và thích nghi dựa vào những công việc thực tế khác.

 

Phần tăng trưởng có vai trò gì trong Scrum?

Phần tăng trưởng là tên gọi ngắn của Phần tăng trưởng Sản phẩm Có khả năng Chuyển giao được (Potentially Shippable Product Increment) là phần sản phẩm Nhóm Phát triển tạo ra cuối mỗi Sprint. Đây là một khái niệm quan trọng trong Scrum tạo ra sự khác biệt lớn về mặt sản phẩm so với các phương pháp truyền thống. Scrum không chỉ đơn giản tách quá trình phát triển thành các Sprint nhỏ liên tiếp nhau, mà cuối mỗi Sprint đòi hỏi Nhóm Phát triển phải chuyển giao một phần tính năng “hoàn chỉnh” của sản phẩm. Hoàn chỉnh ở đây được hiểu theo nghĩa được Product Owner chấp nhận dựa theo Định nghĩa Hoành thành đã được thống nhất trước đó.

Đối với sản xuất phần mềm, điều đó có nghĩa là cuối mỗi Sprint, Nhóm Phát triển cần bàn giao một gói tính năng hoạt động tốt, đã được kiểm thử, tích hợp vào hệ thống và có đầy đủ tài liệu người dùng theo yêu cầu. Nhờ vậy, ở bất cứ thời điểm cuối Sprint nào thì sản phẩm đều đạt được trạng thái sẵn sàng phát hành mà không cần làm thêm bất cứ công việc nào liên quan đến đóng gói, tích hợp hay tinh chỉnh nhỏ. Điều này mang lại lợi ích cho nhiều phía từ các góc độ khác nhau, chẳng hạn như gia tăng sự minh bạch, sớm chuyển giao được giá trị kinh doanh và giảm thiểu rủi ro…

Khái niệm “chuyển giao được” ở đây không có nghĩa là sản phẩm phải được phát hành ngay. Việc có phát hành sản phẩm hay không là phụ thuộc vào quyết định liên quan đến kinh doanh. Còn trạng thái “chuyển giao được” thể hiện sự “tin tưởng” vào tính sẵn sàng của sản phẩm.

Có thể nói, việc chuyển giao được một Phần tăng trưởng ở cuối mỗi Sprint là nhiệm vụ cốt lõi và không hề dễ dàng đối với Nhóm Phát triển. Thông thường thì đối với các nhóm mới sử dụng Scrum, họ thường thất bại trong những Sprint đầu tiên. Bởi vì, để đạt được kết quả mong muốn này, Nhóm Phát triển cần phải áp dụng rất nhiều kỹ năng, công cụ, cộng tác và đưa ra các quyết định tốt trong suốt quá trình diễn ra Sprint. Có thể kể đến một số yếu tố ảnh hưởng đến việc này như:

  • Nhóm Phát triển có đảm bảo tính liên chức năng để thực hiện các công việc như được thống nhất trong Định nghĩa Hoàn thành không?
  • Nhóm Phát triển có biết cách lập kế hoạch Sprint để đảm bảo thuận lợi cho việc tạo ra phần tăng trưởng không?
  • Nhóm Phát triển có được trang bị các công cụ tự động để giúp cho quá trình phát triển, kiểm thử, tích hợp,… được diễn ra nhanh chóng không?
  • Nhóm Phát triển có vận hành tốt để đạt được mục tiêu chung hay không?
  • Khung thời gian của Sprint có đủ dài để hoàn thành các công việc hay không?

Hạng mục Product Backlog là gì

Hạng mục Product Backlog là tên gọi dùng cho các phần tử của một Product Backlog. Product Backlog là một tập hợp của nhiều Hạng mục Product Backlog.

Một Hạng mục Product Backlog có thể được mô tả dưới bất cứ hình thức nào, chẳng hạn như: User Story, User Case, User Scenario,…

Các Hạng mục Product Backlog thường được ước tính giá trị (đối với khách hàng) và độ lớn (lượng nỗ lực cần thiết để hoàn thành).

Những hạng mục ở phía trên của Product Backlog thì được làm mịn hơn so với những hạng mục ở phía dưới, bởi vì những hạng mục ở phía trên sẽ được đưa vào phát triển sớm hơn.

Làm mịn Product Backlog là gì?

Việc làm mịn Product Backlog là hoạt động thêm vào các chi tiết, ước lượng, và trình tự của các hạng mục trong Product Backlog. Đây là quá trình liên tục, theo đó Product Owner và Nhóm Phát triển thảo luận về các chi tiết của từng hạng mục. Trong suốt quá trình làm mịn này, các hạng mục liên tục được xem xét và rà soát cẩn thận.

Nhóm Scrum quyết định cách thức và thời điểm để làm mịn Product Backlog. Có những nhóm có hoạt động làm mịn Product Backlog là một sự kiện diễn ra vào giữa Sprint để chuẩn bị yêu cầu cho sprint tiếp theo. Hoạt động làm mịn product backlog không chiếm nhiều hơn 10% thời gian của Nhóm Phát triển. Tuy thế, các hạng mục Product Backlog có thể được cập nhật tại bất kì thời điểm nào theo chủ quan của Product Owner.

Cải tiến Sprint

Cải tiến Sprint là một sự kiện quan trọng trong Scrum diễn ra ngay sau buổi Sơ kết Sprint nhằm mục đích thanh tra và thích nghi quy trình làm việc. Nói cách khác đây là dịp để Nhóm Scrum nhìn lại quá trình làm việc của một Sprint và xác định những thay đổi cần thiết đối với quy trình để làm việc tốt hơn trong Sprint sau.

Thành phần tham dự: Nhóm Phát triểnScrumMaster bắt buộc phải tham dự. Product Owner có thể tham dự hoặc không. Ngoài ra Nhóm Phát triển còn có thể mời thêm những người khác cùng tham dự nếu cần thiết.

Thời gian: Sự kiện này được đóng khung trong 3 giờ đối với Sprint 1 tháng. Với các Sprint ngắn hơn thì thời gian có thể ngắn hơn, vào khoảng 45 phút tương ứng với 1 tuần làm việc của Sprint.

Mục đích của buổi Cải tiến Sprint bao gồm:

  • Thanh tra lại Sprint trước, về các yếu tố liên quan đến con người, giao tiếp, quy trình và công cụ.
  • Liệt kê những hạng mục đã làm tốt và những hạng mục có thể cải tiến được.
  • Lên kế hoạch triển khai các cải tiến về cách làm việc của Nhóm Scrum.

Có rất nhiều kỹ thuật để tiến hành một buổi Cải tiến Sprint, chẳng hạn như Glad-Sad-Mad, SpeedBoat, SailBoat,… Trang RetrospectiveWiki có liệt kê một số kỹ thuật thường được dùng.

Có một lỗi mà các nhóm thường gặp phải đó là buổi cải tiến chỉ tập trung vào những vấn đề làm chưa tốt để cải tiến. Điều này thường dẫn đến tình trạng các thành viên có cảm giác không thích thú với sự kiện này và xem nó như một cuộc họp mang tính tiêu cực. Hãy cố gắng tạo ra sự hứng thú và tinh thần tích cực trong các thành viên bằng cách động viên thông qua những công việc đã làm tốt.

Mặc dù việc cải tiến có thể diễn ra bất cứ lúc nào, nhưng sự kiện Cải tiến Sprint vẫn là thời điểm chính thức được quy định để làm việc này. Tuân thủ và thực hiện tốt sự kiện này là cách để tạo một thói quen thanh tra và thích nghi quy trình làm việc trong nhóm.

Đọc thêm:

Cải tiến Sprint với Speedboat

Cải tiến Sprint với Sailboat

Cải tiến Sprint với Glad, Sad, Mad.