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?

Sprint Backlog là gì?

Sprint Backlog là bảng công việc được Nhóm Phát triển sử dụng để quản lý quá trình phát triển trong một Sprint. Sprint Backlog được Nhóm Phát triển tạo ra trong buổi Lập kế hoạch Sprint và cập nhật trong suốt Sprint. Sprint Backlog chứa danh sách các hạng mục được phát triển trong Sprint và các công việc cần làm tương ứng với từng hạng mục để hoàn thành nó. Một Sprint Backlog cơ bản có cấu trúc như sau:

Sprint Backlog

Cấu trúc của Sprint Backlog

Trong đó, cột “Hạng mục trong Product Backlog” chứa danh sách các hạng mục được phát triển trong Sprint. Cột “Công việc trong Sprint” là danh sách công việc cần thực hiện tương ứng với từng hạng mục Product Backlog. Cột “Ước tính khối lượng công việc ban đầu” chứa giá trị ước tính mà Nhóm Phát triển đã đưa ra ở đầu Sprint. Sau mỗi ngày làm việc, nhóm sẽ cập nhật lại các giá trị này tương ứng với lượng công việc còn lại cần thực hiện cho từng nhiệm vụ. Ví dụ, sau 3 ngày thì Sprint Backlog có thể được cập nhật như sau:

Cập nhật Sprint Backlog

Cập nhật Product Backlog

Các công việc trong Sprint Backlog có thể được cập nhật (thêm, chỉnh sửa, loại bỏ,….) tùy theo tình hình phát triển hiện tại.

Nhóm Phát triển có thể sử dụng công cụ chuyên nghiệp, excel hay các bảng vật lý để thể hiện Sprint Backlog. Lý tưởng nhất vẫn là một bảng vật lý đặt ngay tại không gian làm việc của Nhóm Phát triển để giúp các thành viên luôn luôn nắm rõ được tình hình phát triển của Sprint.

Dựa trên Sprint Backlog, nhóm có thể sử dụng thêm Biểu đồ Sprint Burndown (Sprint Burndown Chart) để thể hiện tiến độ của Sprint qua từng ngày.

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 với Sailboat

Sailboat là một kỹ thuật để tiến hành buổi cải tiến dựa trên hình ảnh ẩn dụ của một chiếc thuyền buồm. Nhóm xác định các neo (trở ngại) và gió (yếu tố tích cực) và chọn một vùng để cải tiến. Kỹ thuật này được sử dụng phổ biến trong các buổi Cải tiến Sprint của Scrum.

Chuẩn bị

Để bắt đầu buổi cải tiến, cần chuẩn bị một bảng đủ lớn để cả nhóm có thể dán các ý kiến của mình lên đó. Cần vẽ sẵn chiếc thuyền buồm lên trên bảng (tham khảo hình dưới).

Thuyền buồm

Thuyền buồm

Đối với một chiếc thuyền buồm, có những thứ làm cho nó di chuyển chậm lại, chẳng hạn như là các neo; cũng có những thứ làm cho nó di chuyển nhanh hơn, chẳng hạn như gió. Đối với một nhóm cũng vậy, có những yếu tố gây trở ngại cho nhóm và có những yếu tố thúc đẩy nhóm.

Thu thập dữ liệu

Người hỗ trợ yêu cầu các thành viên liệt kê lần lượt những yếu tố trở ngại và thuận lợi. Mỗi một ý kiến được ghi trên một tờ giấy dán.

Một người có thể ghi hết một lượt các ý kiến của mình rồi sau đó dán lên cùng một lúc, nhưng tốt nhất thì nên viết được cái nào thì dán ngay lên cái đó. Người hỗ trợ cần quan sát để đảm bảo rằng các thành viên đang tham gia tích cực. Nếu không, có thể đẩy một vài người “làm gương” để những người khác tích cực hơn. Thời gian này cần được đóng khung.

Thu thập thông tin

Người hỗ trợ yêu cầu các thành viên đọc các ý kiến và gộp những ý kiến trùng nhau hoặc có liên quan với nhau lại thành các nhóm. Sau đó, một người sẽ đặt tên cho từng nhóm, đại diện cho những ý kiến nằm trong nhóm đó.

Lựa chọn hành động cải tiến

Người hỗ trợ yêu cầu các thành viên bỏ phiếu để lựa chọn nhóm ý kiến (hoặc 1 ý kiến) mà mình muốn cải tiến. Có thể sử dụng hình thức “bỏ phiếu chấm”, tức là mỗi thành viên được quyền chọn 3 hạng mục mà mình mong muốn bằng cách ghi lên đó một dấu chấm, các hạng mục nào được nhiều người chấm nhất thì được lựa chọn.

Sau khi đã xác định được những vấn đề muốn cải tiến, hãy thảo luận trong nhóm để tìm ra nguyên nhân gốc rễ của vấn đề và đưa ra các thay đổi sẽ thực hiện trong thời gian tới.

Đọc thêm:

Cải tiến sprint

Cải tiến Sprint với Speedboat

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