Phân tích yêu cầu và thiết kế trong Scrum

Khi nào các hoạt động phân tích yêu cầu (requirement analysis) và thiết kế(design) diễn ra trong mô hình Scrum? Làm thế nào để có sự hiểu biết về phân tích yêu cầu và thiết kế trong Scrum? Phân tích yêu cầu là một trong những hoạt động chính trong việc chuẩn bị Backlog (các hoạt động khác có thể bao gồm: estimate, tách ticket…). Khi PO lấy được ý tưởng thông qua quá trình làm việc với khách hàng và thêm một item chưa rõ ràng vào Product Backlog, item đó sẽ được xem xét đầu tiên. Cân nhắc độ ưu tiên, các item này và các item nhỏ hơn sẽ được chuẩn bị kĩ càng qua nhiều vòng trong khi team sẵn sàng cho Sprint Planning. Các item đã được hiểu rõ sẽ được ưu tiên làm trước. Tiêu chí chấp nhận có thể được chuẩn bị và đưa ra trước buổi họp Sprint Planning. Trong phần đầu của buổi họp Sprint Planning, chúng ta có thể phân tích requirement, nếu được chuẩn bị kĩ lưỡng và đủ thời gian thì requirement có thể được làm rõ ngay trong giai đoạn này. Tuy nhiên vì các item sẽ chỉ được lựa chọn để làm khi mà team chắc chắn là họ có thể thực hiện được nó, team sẽ tiếp tục xác định các điểm tiếp theo (ví dụ: phạm vi chính xác, kịch bản) để làm rõ hơn cho các item này. Điều này có thể được tiến hành bằng cách làm chi tiết hơn trong trong acceptance test. Hoạt động phân tích yêu cầu không dừng lại ở phần đầu của cuộc họp Sprint Planning mà sẽ còn tiếp tục trong suốt quá trình thực hiện Sprint. Trong phần thứ 2 của cuộc họp Sprint Planning, qua quá trình tách nhỏ các task thì sự mơ hồ về requirement có thể được làm rõ. Trong suốt Sprint, test case design, modeling workshop, thảo luận về requirement trong design và code, tất cả đều góp phần làm rõ requirement. Ngay cả trong Sprint review cũng có thể thấy hoạt động phân tích requirement được thực hiện thông qua feedback và các đề xuất cải tiến. Khi nào chúng ta bắt đầu thiết kế? Theo truyền thống, chúng ta bắt đầu thiết kế để chuyển từ vấn đề khách hàng sang giải pháp ngay lập tức sau khi nhận được các item lớn từ Backlog. Tuy nhiên việc này sẽ làm giảm tính linh hoạt khi thiết lập độ ưu tiên và không được khuyến cáo trong phát triển Agile. Thay vì thế thì chúng ta sẽ tiếp tục làm việc với các vấn đề bằng cách theo sát định hướng của khách hàng càng nhiều càng tốt trong khi chia tách các item. Việc chia tách xảy ra trong quá trình chuẩn bị Backlog, chúng ta cũng estimate kích thước của các item. Đôi khi sẽ gặp khó khăn trong việc estimate, có thể do yêu cầu ko rõ ràng hoặc do team thiếu kinh nghiệm. Nếu các yêu cầu chưa rõ ràng, requirement analysis có thể tiếp tục được thực hiện trong các vòng lặp tiếp theo. Nếu các giải pháp gồm các kĩ thuật mới chưa được biết đến hoặc cần thiết kế thêm thì có thể tách nhỏ các item này ra và đưa ngược trở lại Backlog. Các item này thường được giới hạn thời gian và các tiêu chí hoàn thành của nó khác với các item thông thường khác trong Backlog. Đầu ra là sự hiểu biết đầy đủ về spec để có thể estimate và lên kế hoạch. Trong bối cảnh nhiều nhóm làm việc trên cùng một code base, một buổi design workshop chung có thể được tiến hành để đồng bộ hóa thiết kế giữa các nhóm. Trong phần thứ hai của cuộc họp Sprint Planning, team sẽ cam kết phải làm gì trong Sprint tới. Để thực hiện cam kết team thường đưa ra kế hoạch chi tiết bằng cách phân tích các item nhỏ bên trong các task lớn và estimate cho chúng. Cam kết có thể được thực hiện dựa trên tốc độ làm việc, nhưng team vẫn có thể nghĩ thêm các task cần thiết để họ có được các mục đã cam kết. Để có được các task thì phải thực hiện việc thiết kế. Trong phần thứ hai của Spring Planning, một số team nhảy vào quá trình phân tích task và nhận được một danh sách các task tương tự như: design, coding, unit testing, review, functional testing. Điều này cho thấy sự thiếu trong design. Việc design được đưa ra trong buổi họp Sprint Planning phải đủ để hỗ trợ lập kế hoạch. Mục đích của Sprint Planning không phải là thiết kế, mặc dù có một yếu tố thiết kế trong cuộc họp này. Bên cạnh đó, cuộc họp Planning meeting bị hạn chế thời gian, do đó team phải tìm cách để tận dụng thời gian. Việc design vẫn tiếp tục được thực hiện trong suốt Sprint. Team có thể tổ chức design workshop, hoặc có một cuộc thảo luận ad-hoc modeling trong khi coding và đó cũng chính là design. Design được coi là đã hoàn thành khi item đã hoàn thành. Cuối cùng, bạn có thể thấy được giá trị của requirement understanding và design trong hoạt động Scrum dưới đây. Requirement: backlog grooming (several rounds) -> Sprint Planning part 1 -> Sprint Planning part 2 -> Sprint -> done -> sprint review Design: backlog grooming -> spike item (when necessary) -> Sprint Planning part 2 -> Sprint -> done Luồng công việc này cho phép phân tích yêu cầu và thiết kế trong khuân khổ Scrum framework

Nguồn: https://www.scrumalliance.org/community/articles/2009/december/requirement-analysis-and-design-flow-in-scrum