Scrum - Đồ tạo tác

Scrum Artifacts cung cấp thông tin chính mà Nhóm Scrum và các bên liên quan cần biết để hiểu sản phẩm đang phát triển, các hoạt động đã thực hiện và các hoạt động đang được lên kế hoạch trong dự án. Các tạo tác sau được định nghĩa trong Khung quy trình Scrum:

Tồn đọng sản phẩm
Sprint backlog
Biểu đồ ghi xuống
Increment

Đây là những tạo tác bắt buộc tối thiểu trong một dự án scrum và những tạo tác của dự án không bị giới hạn bởi những điều này.

Tồn đọng sản phẩm

Product Backlog là danh sách theo thứ tự các tính năng cần thiết như một phần của sản phẩm cuối cùng và nó là nguồn yêu cầu duy nhất cho bất kỳ thay đổi nào đối với sản phẩm.

Product Backlog liệt kê tất cả các tính năng, chức năng, yêu cầu, cải tiến và bản sửa lỗi cấu thành những thay đổi sẽ được thực hiện đối với sản phẩm trong các bản phát hành trong tương lai. Các mục Product Backlog có các thuộc tính mô tả, đơn hàng, ước tính và giá trị. Những mục này thường được gọi là Câu chuyện của người dùng. Chủ sở hữu sản phẩm chịu trách nhiệm về Product Backlog, bao gồm nội dung, tính khả dụng và đặt hàng của nó.

Product Backlog là một hiện vật đang phát triển. Phiên bản sớm nhất của nó có thể chỉ chứa các yêu cầu ban đầu được biết đến và hiểu rõ nhất. Product Backlog được phát triển như một sản phẩm và môi trường mà nó sẽ được sử dụng, tiến triển. Product Backlog liên tục thay đổi để kết hợp những gì cần thiết để làm cho nó hiệu quả. Miễn là một sản phẩm tồn tại, Product Backlog của nó cũng tồn tại.

Khi sản phẩm đang được xây dựng được sử dụng và thu được giá trị, Product Backlog trở thành một danh sách lớn hơn và đầy đủ hơn. Những thay đổi về yêu cầu kinh doanh, điều kiện thị trường hoặc công nghệ, gây ra những thay đổi trong Product Backlog, khiến nó trở thành hiện vật sống động.

Tinh chỉnh Product Backlog có nghĩa là thêm chi tiết, ước tính và thứ tự ưu tiên vào các mục Product Backlog. Đây là một quá trình liên tục được thực hiện bởi Product Owner và Nhóm. Nhóm Scrum quyết định cách thức và thời điểm thực hiện sàng lọc.

Các hạng mục Product Backlog có thể được cập nhật bất kỳ lúc nào bởi Product Owner hoặc theo quyết định của Product Owner.

Các mục Product Backlog được đặt hàng cao hơn thường rõ ràng và chi tiết hơn những mục có thứ tự thấp hơn. Các ước tính chính xác hơn được thực hiện dựa trên độ rõ ràng hơn và tăng chi tiết. Thứ tự càng thấp, càng ít chi tiết.

Các hạng mục Product Backlog có thể là yêu cầu ứng viên cho Sprint sắp tới được tinh chỉnh để các hạng mục này có thể được phát triển trong Sprint. Các hạng mục Product Backlog mà Nhóm có thể phát triển trong một Sprint được coi là đã sẵn sàng để lựa chọn trong cuộc họp lập kế hoạch Sprint.

Sprint backlog

Sprint Backlog là tập hợp các hạng mục Product Backlog được chọn cho Sprint, cùng với một kế hoạch để cung cấp Phần tăng trưởng của sản phẩm và thực hiện Mục tiêu Sprint.

Sprint Backlog là dự báo của Nhóm về chức năng nào sẽ được cung cấp trong Phần tiếp theo và công việc cần thiết để cung cấp chức năng đó như một Phần tăng thêm sản phẩm đang hoạt động.

Sprint Backlog là một kế hoạch có đủ chi tiết để có thể hiểu được nhưng Nhóm cần theo dõi trong Scrum Hằng ngày. Nhóm điều chỉnh Sprint Backlog trong suốt Sprint và Sprint Backlog xuất hiện trong Sprint. Sự xuất hiện này xảy ra khi Nhóm làm việc thông qua kế hoạch và tìm hiểu thêm về công việc cần thiết để đạt được Mục tiêu Sprint.

Khi công việc mới được yêu cầu, Nhóm sẽ thêm nó vào Sprint Backlog. Khi công việc được thực hiện hoặc hoàn thành, công việc ước tính còn lại sẽ được cập nhật. Khi các yếu tố của kế hoạch được coi là không cần thiết, chúng sẽ bị loại bỏ. Chỉ Nhóm có thể thay đổi Sprint Backlog của mình trong Sprint. Sprint Backlog là một bức tranh thời gian thực, dễ nhìn thấy về công việc mà Nhóm dự định hoàn thành trong Sprint và nó chỉ thuộc về Nhóm.

Tăng

Phần tăng thêm là tổng của tất cả các hạng mục Product Backlog đã hoàn thành trong một Sprint kết hợp với phần tăng thêm của tất cả các Sprint trước đó. Vào cuối Sprint, Phần tăng thêm mới phải là một sản phẩm đang hoạt động, có nghĩa là nó phải ở trong tình trạng có thể sử dụng được. Nó phải ở trong tình trạng hoạt động bất kể Product Owner quyết định phát hành nó thực sự hay không.

Nhóm Scrum cần có sự đồng thuận về những gì được coi là Phần gia tăng. Điều này thay đổi đáng kể đối với Nhóm Scrum, nhưng các thành viên trong nhóm phải có sự hiểu biết chung về ý nghĩa của việc hoàn thành công việc. Điều này được sử dụng để đánh giá khi nào công việc hoàn thành trên Phần tăng trưởng sản phẩm.

Sự hiểu biết tương tự sẽ hướng dẫn Nhóm nghiên cứu biết số lượng hạng mục Product Backlog mà Nhóm có thể chọn trong Lập kế hoạch Sprint. Mục đích của mỗi Sprint là cung cấp các Phần mở rộng của chức năng có thể liên quan.

Các nhóm cung cấp Sự gia tăng chức năng của sản phẩm mỗi Sprint. Phần tăng thêm này có thể sử dụng được, vì vậy Chủ sở hữu sản phẩm có thể chọn phát hành nó ngay lập tức. Nếu sự hiểu biết về phần gia tăng là một phần của các quy ước, tiêu chuẩn hoặc hướng dẫn của tổ chức phát triển, thì tất cả các Nhóm Scrum phải tuân theo mức tối thiểu đó. Nếu đó không phải là quy ước của tổ chức phát triển, Nhóm Scrum phải xác định định nghĩa về Phần tăng trưởng phù hợp với sản phẩm.

Mỗi Phần tăng thêm là phụ gia cho tất cả các Phần tăng thêm trước đó và được kiểm tra kỹ lưỡng, đảm bảo rằng tất cả các Phần tăng thêm hoạt động cùng nhau.

Khi Nhóm Scrum trưởng thành, dự kiến rằng định nghĩa của họ về Phần tăng thêm sẽ mở rộng để bao gồm các tiêu chí nghiêm ngặt hơn để có chất lượng cao hơn. Bất kỳ một sản phẩm nào cũng nên có một định nghĩa về Tăng trưởng là tiêu chuẩn cho bất kỳ công việc nào được thực hiện trên đó.

Biểu đồ ghi xuống nước rút

Tại bất kỳ thời điểm nào trong Sprint, có thể tính tổng công việc còn lại trong Sprint Backlog. Nhóm nghiên cứu theo dõi tổng số công việc còn lại này cho mỗi buổi Scrum Hằng ngày để dự đoán khả năng đạt được Mục tiêu Sprint. Bằng cách theo dõi các công việc còn lại trong suốt Sprint, Nhóm có thể quản lý tiến độ của nó.

Sprint Burn-Down Chart là một phương pháp thực hành để xác định xu hướng công việc được Nhóm Scrum thực hiện. Điều này đã được chứng minh là một kỹ thuật hữu ích trong việc theo dõi tiến trình Sprint hướng tới Mục tiêu Sprint.

Chủ sở hữu sản phẩm theo dõi tổng số công việc còn lại này ít nhất mỗi Sprint Review. Product Owner so sánh số tiền này với công việc còn lại trong các buổi Đánh giá Sprint trước để đánh giá tiến độ hoàn thành công việc dự kiến theo thời gian mong muốn cho mục tiêu. Thông tin này được chia sẻ với tất cả các bên liên quan.

Phần kết luận

Các vai trò, sự kiện, hiện vật và quy tắc của Scrum là không thể tránh khỏi. Nếu chỉ một số phần của Scrum được triển khai, kết quả không phải là Scrum. Scrum cần được triển khai toàn bộ và hoạt động tốt nếu phù hợp với các kỹ thuật, phương pháp luận và thông lệ khác.

Reference