Trong chương này...
• Quản lí sản phẩm bằng Product Backlog
• Duy trì một Product Backlog tốt theo tiêu chuẩn DEEP • Sử dụng Sprint Backlog để quản lí cơng việc
• Một số kiểu Sprint Backlog thơng dụng
• Chuyển giao Phần tăng trưởng cuối mỗi Sprint • Xây dựng Định nghĩa Hồn thành
• Các biểu đồ Burndown
Hành trình vạn dặm bắt đầu với một bước chân nhỏ.
Lão Tử
Tạo tác Scrum
Các tạo tác Scrum gồm một cơng cụ quản lí u cầu sản phẩm gọi là Product Backlog, một cơng cụ kế hoạch thích ứng trực quan cho nhóm cộng tác là Sprint Backlog, và bản thân gói tăng trưởng
chuyển giao được (Increment) ở cuối Sprint. Tạo tác (artifact) ở đây vừa là công cụ vừa là đồ được Nhóm Scrum tạo ra và duy trì liên tục trong quá trình làm việc. Các tạo
tác cung cấp sự minh bạch, hỗ trợ q trình thanh tra và thích nghi. Việc sử dụng và duy trì tốt các tạo tác này giúp cho tất cả các bên liên quan có được thơng tin đầy đủ, hiểu đúng và có cùng một cách hiểu về tình trạng phát triển sản phẩm. Ngồi các tạo tác tiêu chuẩn của
Scrum, các nhóm có thể dùng những công cụ khác để theo dõi tiến độ và thúc đẩy cộng tác.
45
• Danh sách ưu tiên mơ tả các tính năng và kết quả của sản phẩm • Có thể chỉnh sửa được
46
• Danh sách các cơng việc cần hồn thành trong Sprint • Được cập nhật hằng ngày
47
• Tổng tất cả các hạng mục Product Backlog đã được hoàn thành trong một Sprint và giá trị của những phần tăng trưởng của những Sprint trước
• Được chuyển giao ở cuối mỗi Sprint
PRODUCT BACKLOG
Product Backlog là danh sách các tính năng mong muốn của sản phẩm. Danh sách này được sắp xếp dựa trên độ ưu tiên của từng hạng mục. Các hạng mục có độ ưu tiên cao hơn nằm ở phía trên của danh sách và sẽ được Nhóm Phát triển lựa chọn để đưa vào sản xuất sớm, các hạng mục có độ ưu tiên thấp hơn sẽ nằm ở phía cuối của danh sách và được phát triển muộn hơn.
Các Nhóm Scrum có thể dùng nhiều hình thức khác nhau để làm ra Product Backlog. Một lựa chọn thường thấy là bảng trắng hoặc một mảng tường và thẻ chỉ mục (Index Card). Nhiều nhóm (đặc biệt là các nhóm phát triển các sản phẩm lớn hoặc sản phẩm dài ngày) thường dùng phần mềm để làm Product Backlog như Speadsheet
(Excel hoặc Google Spreadsheet), hay các cơng cụ quản lí chun dụng như Trello, Redmine, Asana, Pivotal Tracker v.v..
48
Ví dụ 1: Product Backlog dùng Spreadsheet
49 a
Ví dụ 2: Product Backlog sử dụng cơng cụ quản lí dự án
a1
Product Owner là người chịu trách nhiệm quản lí và bảo trì Product Backlog, bao gồm xác định nội dung, đánh giá độ ưu tiên và sắp xếp các hạng mục, làm mịn các hạng mục, làm rõ và giữ cho nội dung của Product Backlog luôn minh bạch với tất cả các bên.
Hạng mục Product Backlog
50
Product Backlog chứa các hạng mục Product Backlog. Các hạng mục này thường mơ tả tính năng của sản phẩm, ngồi ra cịn có thể có các hạng mục khác như lỗi, cơng việc liên quan đến kĩ thuật, công việc nghiên cứu.
Scrum khơng quy định hình thức cụ thể để thể hiện hạng mục
Product Backlog, nhưng trong thực tế thì kĩ thuật được sử dụng phổ biến là User Story (xem chi tiết trong Chương 7).
Scrum khơng quy định hình thức cụ thể để thể hiện hạng mục
Product Backlog, nhưng trong thực tế thì kĩ thuật được sử dụng phổ biến là User Story.
51
Các hạng mục trong Product Backlog được sắp xếp dựa trên độ ưu tiên, do đó nhiệm vụ của Product Owner là đánh giá độ ưu tiên của từng hạng mục. Product Owner cần phải xem xét một số yếu tố khác nhau để xác định độ ưu tiên này, chẳng hạn như:
• Giá trị đối với phần lớn khách hàng hay người dùng
• Giá trị đối với những khách hàng hay người dùng quan trọng • Chi phí
• Thời gian để triển khai
• Mối quan hệ với các hạng mục khác • Rủi ro và cơ hội
Độ ưu tiên của các hạng mục có thể được cập nhật liên tục trong quá trình phát triển, khi Product Owner đã có thêm những thơng tin mới, hiểu biết nhiều hơn về sản phẩm và có thể có những điều chỉnh về lộ trình của sản phẩm.
Ước tính các hạng mục Product Backlog
Mỗi hạng mục Product Backlog được ước tính kích thước, tức là lượng nỗ lực cần để triển khai nó. Việc này được thực hiện bởi Nhóm Phát triển. Kích thước của một hạng mục có thể ảnh hưởng đến độ ưu tiên của nó trên Product Backlog.
Việc ước tính có thể được thực hiện theo nhiều cách khác nhau. Các nhóm Scrum thường sử dụng trị chơi Planning Poker để làm việc này (xem Chương 7).
Kết thúc việc ước tính các hạng mục Product Backlog, bạn có thể gán các giá trị xác định độ lớn, ví dụ: số điểm, lên trên các hạng mục Product Backlog. Bạn cũng có thể gán kích thước giống như cỡ áo (ví dụ: XS, S, M, L, XL, XXL, XXXL) để đánh dấu độ lớn
tương ứng của các hạng mục. Việc này sẽ giúp bạn quản lí Product Backlog thuận lợi hơn. Đặc biệt, nó sẽ giúp bạn làm mịn Product Backlog sau này.
Làm mịn Product Backlog
52
Các hạng mục Product Backlog có kích thước khác nhau, mức độ chi tiết khác nhau và chúng thường cần phải được làm mịn trước khi sẵn sàng để đưa vào sản xuất. Những hạng mục ở phần trên thường là “mịn” hơn so với những hạng mục ở dưới.
Việc làm mịn có thể đơn giản là chi tiết hố một hạng mục nào đó cịn chung chung. Ví dụ một hạng mục “Quản lí user” có thể được phân tách thành “Thêm user”, “Sửa user”, “Liệt kê tồn bộ user” và “Tìm kiếm một user”. Làm mịn cũng có thể bao gồm cả việc bẻ nhỏ những hạng mục có kích thước lớn (ví dụ: những hạng mục cỡ XL trở lên) thành những hạng mục cỡ nhỏ hơn. Càng nhỏ, càng chi tiết, càng rõ ràng thì càng mịn.
Một Nhóm Scrum có thể phải dành ra khoảng 10% thời gian của một Sprint để ngồi cùng với nhau để họp và làm mịn lại Product Backlog, đảm bảo cho các phiên Lập kế hoạch Sprint tiếp theo được thuận lợi, cũng như luôn cập nhật trạng thái hiểu biết tốt nhất về yêu cầu sản phẩm. Phiên họp làm mịn Product Backlog này diễn ra
trong Sprint, có thể là theo nhu cầu, hoặc cố định, tuỳ sắp đặt của nhóm.
Tiêu chuẩn DEEP dành cho Product Backlog
DEEP là một tiêu chuẩn được sử dụng khá phổ biến hướng đến việc xây dựng một Product Backlog tốt.
DEEP quy định 4 tính chất mà một Product Backlog nên có, bao gồm: