D- Detailed appropriatezly (Đủ chi tiết hợp lý): Những hạng mục
P rioritized (Được sắp xếp ưu tiên): Các hạng mục trong
Product Backlog được sắp xếp theo độ ưu tiên. Những hạng mục có độ ưu tiên cao hơn sẽ được đưa vào sản xuất sớm, chúng nằm phía trên của Product Backlog.
⇒ Dừng và Nghĩ
Nhóm của bạn có quản lí u cầu một cách có hệ thống khơng? Cần làm gì để làm tốt hơn nữa việc này?
SPRINT BACKLOG
Sprint Backlog là bảng công việc được Nhóm Phát triển sử dụng để quản lí q trình sản xuất trong một Sprint. Nội dung cơ bản của một Sprint Backlog bao gồm danh sách các hạng mục Product
Backlog đã lựa chọn cho Sprint hiện tại và danh sách các cơng việc cần thực hiện trong Sprint để hồn thành các hạng mục Product Backlog đó.
img636
Một nhóm Scrum đang đứng họp Scrum Hằng ngày trước Sprint Backlog được dán lên tường.
Thông thường, sau buổi họp này, các thành viên sẽ cập nhật Sprint Backlog và biểu đồ Sprint Burndown.
Sprint Backlog do Nhóm Phát triển duy trì
53
Sprint Backlog do Nhóm Phát triển sở hữu và vận hành bởi vì quá trình làm việc trong Sprint cũng do Nhóm Phát triển tự quản lí, đây là một đặc điểm quan trọng trong Scrum. Nhóm Phát triển tạo Sprint Backlog ở trong buổi Lập kế hoạch Sprint và vận hành nó cho đến khi Sprint kết thúc.
Giống như Product Backlog, các nhóm có thể sử dụng các phương tiện khác nhau để làm ra Sprint Backlog tiện lợi nhất cho mình. Nhưng điều quan trọng hơn cả là ln đảm bảo Sprint Backlog hiện diện và cập nhật.
54
Sprint Backlog dạng Spreadsheet
Có nhiều cách để thể hiện Sprint Backlog, tùy theo sự lựa chọn và tính phù hợp đối với nhóm.
Ví dụ, cách trình bày dưới dạng một bảng truyền thống như sau: 55
Sprint Backlog dạng Kanban
Một dạng cấu trúc khác được ưa chuộng và áp dụng rộng rãi hiện nay là bảng Kanban bao gồm các cột.
Với dạng này, Sprint Backlog được trình bày như sau: 60
Phần tăng trưởng (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) 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.
Khác biệt với tư duy phát triển truyền thống
Ở các phương pháp phát triển truyền thống, quá trình phát triển sản phẩm được tiến hành lần lượt theo từng bước, chẳng hạn đi từ thu thập yêu cầu, phân tích và thiết kế, xây dựng, kiểm thử rồi đi đến phát hành. Do đó, ở phần lớn thời gian đầu, kết quả thu được là rất nhiều tài liệu, bao gồm cả tài liệu mô tả yêu cầu lẫn tài liệu thiết kế. Trong khi đó thiếu vắng một sản phẩm thật có thể sử dụng được bởi người dùng.
61
Trong phương pháp phát triển truyền thống, sản phẩm chỉ được hình thành ở giai đoạn cuối của chu trình phát triển
Scrum có một hướng tiếp cận khác, 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 hồn chỉnh của sản phẩm.
62
Các phần tăng trưởng được tạo ra liên tục ở mỗi Sprint
Các đặc điểm của Phần tăng trưởng
• Sử dụng được: Tính năng đạt được sau mỗi Sprint là thật và sử dụng được ngay chứ không chỉ là một bản thiết kế hay một bản mẫu.
• Có khả năng chuyển giao được: Phần tăng trưởng ở cuối mỗi Sprint cần phải có khả năng chuyển giao được, Điều này khơng có nghĩa là nó phải lập tức được chuyển giao ngay, mà có nghĩa là nó đạt được trạng thái sẵn sàng chuyển giao.
• Hồn thành: Phần tăng trưởng phải tuân thủ theo Định nghĩa Hoàn thành đã được thống nhất trước đó.
Tại sao chúng ta cần Phần tăng trưởng?
Việc tạo ra được các phần tăng trưởng sau mỗi Sprint mang lại rất nhiều lợi ích từ những góc độ khác nhau, có thể kể đến như:
• Sớm có được phản hồi: Các phản hồi này sẽ được ghi nhận để đưa ra những điều chỉnh cho sản phẩm nếu cần thiết.
• Sớm thu được giá trị: Chúng ta sớm thấy được giá trị của sản phẩm và giá trị này cũng đến tay người dùng sớm hơn.
• Tăng minh bạch: Sau những khoảng thời gian ngắn, chúng ta đã có được những phần sản phẩm thực sự “hoàn thành” mà tất cả mọi người đều có thể nhìn thấy được, tương tác được.
• Giảm rủi ro: Phần tăng trưởng giúp giảm thiểu rủi ro, xét về cả mặt kinh doanh lẫn kĩ thuật.
ĐỊNH NGHĨA HỒN THÀNH
63
Định nghĩa Hồn thành là một danh sách quy định những công việc cần được thực hiện xong trước khi một hạng mục được công nhận là đạt trạng thái có khả năng chuyển giao được.
Định nghĩa Hồn thành là một cơng cụ quan trọng để đảm bảo tính minh bạch của các tạo tác trong Scrum, tiêu chuẩn để thành viên nhóm tự kiểm tra và đạt được chất lượng tự thân.
Ngoài ra, Định nghĩa Hoàn thành giúp mọi người hiểu chung về yêu cầu công việc, ngăn ngừa những mâu thuẫn do hiểu nhầm hoặc không hiểu rõ. Gia tăng tính minh bạch về u cầu giúp nhóm tự tổ chức hiệu quả hơn.
Nội dung của Định nghĩa Hoàn thành
Nội dung của Định nghĩa Hồn thành dành cho từng nhóm và từng sản phẩm là khác nhau, điều này phụ thuộc vào một số yếu tố như: • Đặc điểm của sản phẩm đang xây dựng
• Cơng nghệ và kĩ thuật đang được sử dụng • Các quy định của tổ chức
• Trình độ của Nhóm Phát triển
Chẳng hạn, nếu một sản phẩm được cung cấp ở nhiều thị trường khác nhau thì có thể có những quy định liên quan đến ngơn ngữ hiển thị, tiền tệ, định dạng thời gian. Nếu là một ứng dụng web thì có thể có những quy định liên quan đến việc hỗ trợ tốt trên các loại trình duyệt khác nhau. Nếu tổ chức có những quy ước liên quan đến việc phát triển thì có thể có những quy định liên quan đến việc tuân thủ các quy ước này. Nếu trình độ của Nhóm Phát triển cao thì có thể có những quy định rất chặt chẽ về mã nguồn, ví dụ như là các phương thức khơng vượt q 8 dịng mã, v.v..
64
Nhóm Scrum xây dựng Định nghĩa Hồn thành
Việc xây dựng Định nghĩa Hồn thành cần có sự tham gia của tồn bộ Nhóm Scrum, tức là bao gồm các thành viên Nhóm Phát triển, Product Owner và ScrumMaster. Thơng thường, Product Owner là người có vai trị xác nhận cuối cùng đối với Định nghĩa Hồn thành. Định nghĩa Hồn thành cũng khơng phải là một tài liệu cố định mà sẽ được cải tiến theo q trình trưởng thành của nhóm để phản ánh
sự trưởng thành này cũng như nâng cao chất lượng của sản phẩm. 65