Release trong phương pháp Scrum

Bài viết này trình bày một cách để phân phối sản phẩm ở cuối mỗi sprint. Trong một tình huống mà các đội Scrum là thực sự tham gia vào việc phát triển, nâng cao, hoặc duy trì các sản phẩm, họ chưa thực hiện tốt việc triển khai sản phẩm vào cuối mỗi sprint.
article

Cách để triển khai thành công sản phẩm
Thay vì làm nổi bật những lý do không thành công của một sprint, tôi sẽ giải thích cách để thành công trong việc release sản phẩm ở cuối mỗi sprint.

Consolidate planning
Backlog refinement  meeting là một hoạt động cần được thực hiện liên tục. Chủ sở hữu sản phẩm làm việc trên các ưu tiên và các chi tiết trong danh sách mong muốn của họ hàng ngày. Lập kế hoạch thống nhất được thực hiện để có được một tổ chức ưu tiên nói chung. Đây là cuộc họp trong từng sản phẩm mà chủ sở hữu trình bày việc tồn đọng của mình để các bên liên quan kinh doanh và đảm bảo rằng sản phẩm cá nhân backlogs được liên kết với các mục tiêu của tổ chức. Tần số của các cuộc họp có thể là mỗi quý, hoặc hai lần một năm. Sau khi kế hoạch hợp nhất được chấp thuận, các đội bắt đầu công việc vào mục ưu tiên cao nhất từ việc tồn đọng này. Những gì đội quyết định làm việc trong một sprint trở thành backlog sprint cho đội Scrum.
 
Xác định một cadence sprint
Theo kích thước thông thường sprint thuận lợi cho đội. Các đội lập kế hoạch, xây dựng, và xem xét tại một cadence thường xuyên. Họ có sự tự tin hơn ở vận tốc và do đó tang cường độ chính xác trong các estimations.
 
Thực hành continuous integration 
Việc sử dụng công cụ hội nhập liên tục và áp dụng kỹ thuật thực tiễn tốt nhất cho các đội phát triển, đặc biệt là khi có nhiều đội Scrum làm việc trên các tính năng khác nhau cho cùng một sản phẩm. Thực hiện theo một chiến lược phân nhánh để xử lý mã hàng ngày check-in và nhập vào các chi nhánh phát hành. Kiểm soát kết hợp với các chi nhánh phát hành bằng cách xác định các tiêu chí sẵn sàng phát hành. Chỉ có mã đáp ứng tiêu chí sự sẵn sàng này được sáp nhập với các chi nhánh phát hành.
 
Xác định những thứ sẵn sàng
Tương tự như xác định các tiêu chí chấp nhận của một câu chuyện, bạn phải cũng xác định tiêu chí sẵn sàng để release những câu chuyện. Tiêu chí chấp nhận của các câu chuyện có thể được mở rộng để bao gồm các tiêu chí sẵn sàng release. Thách thức là làm sao để đáp ứng tất cả các tiêu chuẩn trong cùng một sprint. Các tác vụ cần thiết để xây dựng phần mềm sẽ đứng trước những nhiệm vụ cần thiết để package và release nó. Nếu họ kết hợp và thực hiện lại với nhau, tôi sẽ gọi đây là một DevOps thực hiện thành công.

Đánh giá tình trạng release 
Vào cuối mỗi khi xem xét sprint, những câu chuyện được đánh dấu “Done" với sự phát triển và thử nghiệm xây dựng hàng ngày. Danh sách này được thực hiện trở thành backlog cho bản phát hành. Backlog phát hành xem xét và chuẩn bị cho việc triển khai sản xuất trong sprint tiếp theo. Tất cả các tác vụ cần thiết để có được những câu chuyện phát triển kênh phân phối và triển khai sản xuất được hoàn thành trong thời gian chạy của sprint sau đó.

Source: www.scrumalliance.com