Phương pháp Agile là một cách chú trọng vào việc lặp lại liên tục sự phát triển và kiểm thử xuyên suốt vòng đời phát triển phần mềm của dự án. Cả 2 hoạt động phát triển phần mềm và kiểm thử của mô hình Agile đều hoàn toàn khác biệt với mô hình Waterfall.
QUẢN LÝ DỰ ÁN VỚI PHẦN MỀM AGILE Bài 2: Quản lý yêu cầu Nội dung học Quy trình Scrum Thu thập yêu cầu cho Product Backlog Quy tắc SMART Quy tắc CUTFIT Bộ lập kế hoạch Quy trình Scrum Sprint Phân đoạn ngắn để tạo phần chức hoàn chỉnh Ngắn 30 ngày Mỗi Sprint có mục tiêu Giữ độ dài Sprint khơng đổi để tạo nhịp đập cho nhóm Sản phẩm thiết kế, lập trình kiểm thử Sprint Sprint ngắn, chi phí quản lý lớn Thu thập yêu cầu cho Product Backlog Để có Product Backlog tốt, cần có cách thức tốt để thu thập yêu cầu dạng user story Quá trình thu thập cách trực quan yêu cầu gồm giai đoạn: Xác định người liên quan mục tiêu họ Sử dụng chiến thuật “rừng cây” để thu thập yêu cầu Mẫu Product Backlog Xác định người liên quan mục tiêu họ Thu thập yêu cầu cho Product Backlog Khi bắt đầu dự án, cố gắng xác định tất người có quyền lợi có tham gia, cần thiết cho sản phẩm phần mềm Xác định mục tiêu họ cách đặt câu hỏi sau: Mục tiêu hay mục đích kinh doanh bạn gì? Tại bạn lại cần sản phẩm phần mềm mới? Làm để xác định mức hoàn thành mục tiêu đó? Quy tắc SMART Có nhiều cách để xác định mục tiêu, số quy tắc SMART Rõ ràng: tất có cách hiểu mục tiêu Đo được: xác định cách khách quan đạt mục tiêu chưa Quy tắc SMART Có nhiều cách để xác định mục tiêu, số quy tắc SMART Có thể đạt được: người liên quan đồng ý mục tiêu hướng đến Thực tế: phải có khả đạt mục tiêu dự án với tài nguyên sẵn có Dựa thời gian: phải có đủ thời gian để đạt mục tiêu Chuẩn bị cho họp Chuyên gia yêu cầu phải hiểu rõ user story Chuẩn bị cho thành viên tập Mỗi thể ước lượng đánh giá cho story Chuẩn bị cho họp Ví dụ giá trị đánh giá cho bài: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 1, 2, 3, 5, 8, 13, BIG ½, 1, 2, 3, 4, 5, 6, 7, ∞ Cuộc họp Mỗi thành viên cầm Người trung gian trình bày user story thời gian khơng q phút Sau thành viên hỏi thơng tin user story Mỗi thành viên chọn thẻ mà không tiết lộ cho biết Khi tất thành viên chọn xong, tất lật lúc Trong vòng đầu tiên, ước lượng thành viên khác đáng kể Cuộc họp Trong trường hợp có khác biệt lớn, giá trị thấp cao chứa thơng tin giải thích Sau thành viên thảo luận ngắn user story ước lượng đánh giá thành viên Các thành viên tiếp tục suy nghĩ độc lập ước lượng sau lúc công bố Nếu ước lượng khác nhiều, tiến trình tiếp tục lặp lại Cuộc họp Khi ước lượng gần giống nhau, kết thúc chuyển sang user story Nếu lần thứ 3, ước lượng khác nhiều, có khả tiếp theo: Cùng thử tiếp lần Người dùng chia story thành phần nhỏ Lấy giá trị cao nhất, thấp trung bình Ví dụ User story: Tạo yêu cầu bán hàng Đội gồm thành viên Vòng 1: Ví dụ Thành viên thứ thứ giải thích lý ước lượng story Vòng 2: Ví dụ Vòng bỏ phiếu xảy Có thể lấy giá cho ước lượng story Ưu điểm phương pháp lập kế hoạch Thu nhiều ý kiến đóng góp chuyên gia Hội thoại thành viên đưa đến kết ước lượng xác Các nghiên cứu ước lượng trung bình thảo luận nhóm cho kết tốt Khuyết điểm phương pháp lập kế hoạch Khó thu xếp họp tất thành viên Người điều phối phải cẩn thận điều khiển họp diễn đủ ngắn Một số nhân tố ảnh hưởng đến ước lượng: trị, văn hóa, chủ nghĩa cá nhân Phần mềm kế hoạch Vào trang web planningpoker.com Các thành viên đăng ký thành viên tiến hành đánh giá User Story Thảo luận trao đổi tình Tại sử dụng thẻ mục dán lên tường cho user story? Workshop Chuẩn bị trước buổi Workshop: Các nhóm trao đổi trình bày yêu cầu cho Product Backlog dự án (sử dụng mẫu Product Backlog cung cấp LMS) Lưu thông tin yêu cầu Product Backlog dạng file word nộp lên LMS Lưu thông tin họp trao đổi yêu Product Backlog dạng file word nộp lên LMS Nội dung buổi Workshop Các nhóm trao đổi trình bày yêu cầu cho Product Backlog dự án Giảng viên trao đổi góp ý với nhóm Tổng kết nội dung học Thu thập yêu cầu cho Product Backlog Quy tắc SMART Quy tắc CUTFIT Bộ lập kế hoạch