Có 3 cấp độ lập kế hoạch trong Agile. Đó là kế hoạch phát hành (Release Planning), kế hoạch phân đoạn (Iteration Planning) và kế hoạch hàng ngày (Daily Planning). Các cuộc họp lập kế hoạch này giúp Scrum Master, Product Owner và các thành viên khác trong nhóm hiểu được sản phẩm sẽ được phân phối như thế nào, độ liên quan và trách nhiệm hàng ngày của họ trong việc bàn giao sản phẩm. Bây giờ chúng ta sẽ đi vào chi tiết về Kế hoạch phát hành, Lập kế hoạch phân đoạn và Lập kế hoạch hàng ngày.

Lập kế hoạch phát hành trong mô hình phát triển Agile

• Kế hoạch phát hành thường được thực hiện trong sprint đầu tiên của dự án (Sprint zero) khi mà chưa có sản phẩm release.
• Toàn bộ Sprint được dành riêng để lập kế hoạch phát hành tiếp theo.
• Xác định trước các vấn đề sau: mục tiêu release là gì, những tính nào sẽ được chuyển giao trong đợt release. Ngoài ra, cũng cần xác định danh sách release - release backlog, các tính năng và user stories (bản tóm tắt nhu cầu người dùng), các yếu tố chấp nhận của từng stories cũng như ước tính các user stories
• Lập kế hoạch phát hành cũng giúp các thành viên trong nhóm xác định chiến lược kiểm thử và lập kế hoạch tiếp cận kiểm thử cho tất cả các phân đoạn kế tiếp.
• Kế hoạch phát hành có thể thay đổi khi có những Stories mới được thêm hoặc xóa đi.
• Trạng thái của bản phát hành được theo dõi trong mỗi Sprint để nắm được những chức năng/hạng mục phát hành đã chính xác.

Khi bắt đầu lập kế hoạch phát hành, Product Owner đặt mục tiêu và khung thời gian phát hành. The Product Owner cũng cộng tác với team phát triển, dựa trên user stories( bản tóm tắt nhu cầu của người dùng), thực hiện đánh giá kiến ​​trúc và ước tính nỗ lực trong Agile.

Người kiểm thử có liên quan đến việc lập kế hoạch phát hành và thực hiện các hoạt động sau:

• Viết User stories và tiêu chí chấp nhận kiểm thử
• Tìm kiếm làm rõ về những bản User stories nơi mà mà thông tin chưa đầy đủ.
• Xác định chiến lược kiểm thử ở tất cả các cấp độ cho toàn bộ phiên bản.
• Chỉ ra bất kỳ rủi ro kiểm thử nào sản phẩm có thể xảy ra.
• Làm một kế hoạch kiểm thử cấp cao.
• Xác định số lượng các cấp độ kiểm thử sẽ được thực hiện.

Lập kế hoạch phân đoạn trong phát triển Agile

Lập kế hoạch phân đoạn 1 được thực hiện sau khi kế hoạch phát hành được thiết lập.

• Nhóm nghiên cứu kéo các User stories trong Sprint Backlog từ Product Backlog nhóm chúng thành các task với estimate thường sẽ ít hơn 8 giờ.
• Thực hiện đánh giá rủi ro về các User stories và quyết định một kế hoạch mang tính thuyết phục về cách giải quyết các rủi ro khi dịch chuyển các Sprint
• Nhóm đặt câu hỏi cho Product Owner về việc làm rõ các vấn đề có thể khiến team hiểu Stories theo cách chân thực hơn.
• Số lượng Stories mà nhóm kéo trong mỗi Sprint có thể phụ thuộc vào năng lực hoặc tốc độ của đội.
• Việc lập kế hoạch theo năng lực của team được thực hiện trong vài giờ và việc lập kế hoạch tốc độ được thực hiện theo Story point.
• Nhóm thực hiện cam kết tới Sprint Backlog và những sự thay đổi trong Sprint Backlog khi nó hiện lên.

Những người kiểm thử cũng tham gia vào việc phân đoạn và có thể đóng góp tương tự theo các cách sau:

• Chia nhỏ các User Stories thành các task kiểm thử.
• Xác định phạm vi kiểm tra của mọi Story.
• Tạo bản kiểm thử chấp nhận dành cho các User Stories.
• Ước tính các task kiểm thử như tạo chiến lược kiểm thử, kế hoạch kiểm thử và các Testcase cụ thể cho các User Stories.
• Hiểu và lập kế hoạch tự động hóa các User Stories của người dùng và hỗ trợ các mức độ kiểm thử khác nhau.

Các kế hoạch phát hành không phải là tài liệu tĩnh và chúng có thể thay đổi khi các yếu tố bên ngoài và bên trong thay đổi khi việc thực thi các phân đoạn diễn ra.

• Các kế hoạch phát hành cũng có thể thay đổi do các yếu tố nội bộ khác nhau như khả năng của nhóm devivery, tốc độ của nhóm và năng lực kỹ thuật.
• Các ví dụ về các yếu tố bên ngoài là sự thay đổi trong các phân khúc mục tiêu, mối đe dọa từ các sản phẩm thay thế, thay đổi được kích hoạt bởi sản phẩm của đối thủ cạnh tranh vượt trội.
• Ngày phát hành có thể được điều chỉnh hoặc phạm vi có thể được cắt giảm để điều chỉnh các thay đổi.
• Theo Scrum, Product Owner không cho phép thay đổi trong giai đoạn nước rút.
• Product Owne không thể thêm các User Stories mới vào trong Sprint Backlog.

Master Scrum phải giúp nhóm thấy rằng Product Owner không làm phiền nhóm, bằng cách chèn công việc mới vào nhóm.

Nhóm phát triển, đặc biệt là người kiểm thử phải hiểu được bức tranh tổng thể để phát hành một sản phẩm chất lượng tốt. Bất kỳ sự mơ hồ nào liên quan đến việc lập kế hoạch kiểm thử phải được xem xét cẩn thận sau khi tham khảo ý kiến ​​với phần còn lại của nhóm.

Lập kế hoạch phát hành và phân đoạn rộng rãi giúp nhóm chuẩn bị lập kế hoạch lên checklist kiểm thử liên quan đến các mục sau đây:

• Các thành viên trong nhóm đều có trách nhiệm kiểm tra.
• Phạm vi và mục tiêu kiểm thử sẽ được thực hiện.
• Môi trường kiểm thử cần được thiết lập.
• Dữ liệu kiểm thử được thu thập giúp ích cho nhóm kiểm thử.
• Trình tự các hoạt động kiểm thử, phụ thuộc và giao diện liên quan đến kiểm thử.

Kế hoạch hàng ngày / Cuộc họp thường trực trong phát triển Agile

Cuộc họp lập kế hoạch hàng ngày cũng được gọi là ‘Stand up meetings' . Đây là nơi nhóm phát triển và nhóm kiểm thử gặp nhau hàng ngày để thảo luận:

• Những xử lý trong nhiệm vụ được giao ngày hôm qua.
• Những nhiệm vụ họ đã lên kế hoạch thực hiện ngày hôm nay.
• Có bất kỳ trở ngại hoặc trở ngại nào ngăn cản họ hoàn thành nhiệm vụ.

Ngoài các yếu tố trên, mỗi thành viên phải nói rằng họ sẽ mất bao lâu để hoàn thành nhiệm vụ được giao trong Sprint.

• Nếu bất kỳ nhiệm vụ còn lại hoặc đang chờ xử lý của bất kỳ thành viên nào trong nhóm không được hoàn thành trong Sprint cụ thể đó thì họ sẽ chia sẻ các vấn đề gây cản trở đó trong các cuộc họp hàng ngày.
• Theo đó, các tác vụ đang chờ xử lý từ lần chạy Sprint trước được chú ý trong lần chạy Sprint tiếp theo.
• Tương tự như vậy nếu có bất kỳ thay đổi nào trong yêu cầu từ khách hàng hoặc bất kỳ vấn đề build hoặc bất kỳ vấn đề chặn nào thì cũng sẽ được thảo luận trong các cuộc họp.

Kết luận:

Qua bài viết trên, mọi người đã nắm rõ các khái niệm phát hành và phân đoạn trong mô hình Agile hiểu được sẽ không có sự cứng nhắc trong việc phát hành và phân đoạn phát triển phần mềm đồng thời mô hình phát triển luôn tạo điều kiện lắng nghe ý kiến của các thành viên trong team để xây dựng sản phẩm một cách tốt nhất

Tài liệu tham khảo: http://tryqa.com/what-is-release-and-iteration-planning-in-agile-methodology/