Thực hiện phát triển sản phẩm theo phương pháp Agile Scrum

Scrum là khung làm việc được xây dựng dựa trên lý thuyết quản lý tiến trình thực nghiệm (empirical process control). Lý thuyết này chỉ ra rằng tri thức đến từ kinh nghiệm và việc ra quyết định được dựa trên những gì đã biết. Vậy làm thế nào để áp dụng agile thành công trong phát triển phần mềm? Các công ty phần mềm áp dụng agile như thế nào? ... Tài liệu này sẽ giải đáp các thắc mắc đó cho bạn

HƯỚNG DẪN Thực phát triển sản phẩm theo phương pháp Agile Scrum Hướng dẫn: Thực phát triển sản phẩm theo phương pháp Agile Scrum MỤC LỤC GIỚI THIỆU 1.1 Mục đích 1.2 Phạm vi 1.3 Tài liệu tham khảo 1.4 Thuật ngữ NỘI DUNG HƯỚNG DẪN 2.1 Tổng quan Agile scrum 2.2 Khung làm việc agile scrum 2.3 Mô hình phát triển agile scrum 2.4 Trình tự công việc Sprint 2.5 Các vai trò trách nhiệm đội ngũ agile Scrum 2.6 Vai trò “Gà” mô hình Scrum 10 2.7 Các hoạt động Agile 10 2.8 Các tạo tác (Artifact) Scrum 13 2.9 Những lưu ý chạy sprint 22 2/23 Hướng dẫn: Thực phát triển sản phẩm theo phương pháp Agile Scrum GIỚI THIỆU 1.1 Mục đích Tài liệu có mục đích hướng dẫn IT có nhìn khái quát việc phát triển phần mềm theo phướng pháp Agile Scrum, nêu rõ vai trò trách nhiệm member dự án phát triển phần mềm theo phương pháp Agile Scrum 1.2 Phạm vi Tài liệu áp dụng cho toàn nhân viên IT có tham gia vào dự án phần mềm mô hình Agile scrum (PM, BA,DEV, Tester, QA…) 1.3 Tài liệu tham khảo Tên tài liệu STT SCRUMstudy-SBOK-Guide-2013.pdf Scrum-Guide-VI_3.pdf Giải thích 1.4 Thuật ngữ Viết tắt thuật ngữ STT Product Backlog Giải thích Được gọi High Level Document, ghi mô tả tình cấn có hệ thống mức tổng quan Sprint Backlog Danh sách nhiệm vụ xác định công việc nhóm Sprint Sprint Một phân đoạn (iteration), chu kỳ lặp lặp lại công việc tương tự nhằm tạo phần tăng trưởng (increment) cho hệ thống Sprint thường kéo dài từ tuần tới tháng.Trong suốt dự án, thời gian cho Sprint cố định Từ “sprint” có nghĩa giai đoạn nước rút, ám gấp gáp tập trung cao độ khoảng thời gian ngắn để làm việc Release Là sản phẩm đầy đủ chức theo yêu cầu chủ sản phẩm, có khả bán thị trường hay chuyển tới người dùng Team (hay Development Team) Đội phát triển User Story Là tóm tắt nhu cầu người dùng Đây công cụ sử dụng phổ biến Scrum phương pháp Agile khác để thể 3/23 Hướng dẫn: Thực phát triển sản phẩm theo phương pháp Agile Scrum nhu cầu người dùng Thông thường, user story khách hàng, đại diện khách hàng, người thực hiểu nghiệp vụ nắm bắt xác yêu cầu nhóm phát triển Product Backlog Item Một yêu cầu chức hay phi chức vấn đề độ ưu tiên product backlog Độ xác ước lượng phụ thuộc vào tầm quan trọng độ chi tiết hạng mục Phần có độ ưu tiên cao chọn Sprint để làm việc Burndown Chart Là biểu đồ thể xu hướng công việc lại theo thời gian Sprint, phát hành (Release), sản phẩm Dữ liệu cho Biểu đồ Burndown lấy từ Sprint Backlog Product Backlog, với công việc lại theo dõi trục tung khoảng thời gian (các ngày Sprint, nhiều Sprint) theo dõi trục hoành Biểu đồ Burndown dùng cho Bản phát hành (khi gọi Release Burndown) cho Sprint (gọi Sprint Burndown) Scrum Team Đây nhóm liên chức gồm Product Owner, Scrum Master Development Team (Nhóm Phát triển) Nhóm Scrum cộng tác với theo khung làm việc Scrum để thực hóa mục tiêu Product Owner 10 Velocity Là nâng suất xử lý đội Scrum Sprint 4/23 Hướng dẫn: Thực phát triển sản phẩm theo phương pháp Agile Scrum NỘI DUNG HƯỚNG DẪN 2.1 Tổng quan Agile scrum Scrum khung làm việc xây dựng dựa lý thuyết quản lý tiến trình thực nghiệm (empirical process control) Lý thuyết tri thức đến từ kinh nghiệm việc định dựa biết Khung làm việc Scrum sử dụng để quản lý trình phát triển sản phẩm phức tạp từ đầu năm 1990  Scrum hoạt động dựa giai đoạn nước rút (Sprint), thông thường kéo dài khoảng – tuần để nhanh chóng đưa dần yêu cầu khách hàng vào hệ thống phần mềm thực tế sử dụng  Scrum mô hình thúc đẩy tương tác gia tăng cho hoạt động quản lý dự án dựa việc tổ chức nhóm nhỏ khoảng – người có khả chuyên sâu làm việc phụ thuộc lẫn khoảng thời gian cố định  Scrum phát triển Ken Schwaber Jeff Sutherland với mục tiêu cung cấp sản phẩm có gia trị ngày gia tăng khoảng thời gian cố định gọi Sprint 2.1.1 Bốn tuyên ngôn (Agile Agile Manifesto) Con người tương tác Quy trình công cụ Phần mềm chạy tốt tài liệu đầy đủ Công tác với khách hàng đàm phán hợp đồng Phản hồi với thay đổi bám sát kế hoạch 2.1.2 Mười hai nguyên lý Agile Ưu tiên cao thỏa mãn khách hàng thông qua việc chuyển giao sớm liên tục phần mềm có giá trị Chào đón việc thay đổi yêu cầu, chí muộn trình phát triển Các quy trình linh hoạt tận dụng thay đổi cho lợi cạnh tranh khách hàng Thường xuyên chuyển giao phần mềm chạy tốt tới khách hàng, từ vài tuần đến vài tháng, ưu tiên cho khoảng thời gian ngắn Nhà kinh doanh nhà phát triển phải làm việc hàng ngày suốt dự án Xây dựng dự án xung quanh cá nhân có động lực Cung cấp cho họ môi trường hỗ trợ cần thiết, tin tưởng họ để hoàn thành công việc Phương pháp hiệu để truyền đạt thông tin tới nhóm phát triển nội nhóm phát triển hội thoại trực tiếp Phần mềm chạy tốt thước đo tiến độ Các quy trình linh hoạt thúc đẩy phát triển bền vững Các nhà tài trợ, nhà phát triển, người dùng trì nhịp độ liên tục không giới hạn Liên tục quan tâm đến kĩ thuật thiết kế tốt để gia tăng linh hoạt 10 Sự đơn giản – nghệ thuật tối đa hóa lượng công việc chưa xong – 11 Các kiến trúc tốt nhất, yêu cầu tốt nhất, thiết kế tốt làm nhóm tự tổ chức 12 Nhóm phát triển thường xuyên suy nghĩ việc để trở nên hiệu hơn, sau họ điều chỉnh thay đổi hành vi cho phù hợp 5/23 Hướng dẫn: Thực phát triển sản phẩm theo phương pháp Agile Scrum 2.1.3 Giá trị Scrum Commitment: Tính cam kết cao công việc Focus: Tập trung vào mục tiêu, chiến lược thời điểm định Openness: Giá trị mở dự án, thông tin minh bạch công khai Respect: Giá trị gắn kết thành viên dự án với nhau, với khách hàng tổ chức Courage: Giá trị can đảm lãnh nhận cam kết với công việc, can đảm công khai minh bạch thông tin… 2.1.4 Trọng tâm Scrum Timeboxing: Khoảng thời gian cố định Sprint dự án Learning from mistakes and self managing (Adaptive): Học hỏi, rút kinh nghiệm từ sai lầm mắc phải tự chủ động quản lý Shippable Code: Code đặt trọng tâm vào mục tiêu ngắn hạn sản phẩm đóng gói thành nhiều lần theo giai đoạn để sử dụng thử cải tiến 2.2 Khung làm việc agile scrum 2.3 Mô hình phát triển agile scrum Khác với mô hình phát triển sản phẩm theo waterfall, agile scrum phát triển sản phẩm theo vòng lặp tăng trưởng, vòng lặp xác định thời gian 2-4 tuần kết thúc vòng lặp có sản phẩm chạy 6/23 Hướng dẫn: Thực phát triển sản phẩm theo phương pháp Agile Scrum 2.4 Trình tự công việc Sprint  Scrum master & development team nhận requirement từ Product owner (Product Backlog)  Scrum master & development team ngồi với để thiết lập quy tắc làm việc cho đội định nghĩa hoàn thành  Scrum master & development team ngồi họp kế hoạch sprint - Thiết lập mục tiêu sprint - Lựa chọn việc hoàn thành sprint - Đưa giải phát để hoàn thành công việc 7/23 Hướng dẫn: Thực phát triển sản phẩm theo phương pháp Agile Scrum - Mỗi member development team tự đưa estimate thời gian hoàn thành công việc - Sau có thống member với toàn team scrum master, team thực log task cần thực lên Jira, số lượng công việc, thời gian hoàn thành cần theo kế hoạch đề buổi họp (QA check cài này)  Scrum master người Start sprint Jira => bắt đầu trình phát triển Development team bắt đầu tham gia vào trình thực công việc theo plan đề - Hàng ngày, all member team cần log work lên Jira, việc log work cần làm thường xuyên tốt, phản ánh trạng thực tế task - Khi task trình thực hiện, cần đổi trạng thái xác tương ứng để scrum master có nhìn tổng quát sprint - Mỗi ngày team cần họp Scrum hàng ngày  Đồng hóa công việc toàn team  Cập nhập kế hoạch tiến độ công việc  Nêu khó khăn, issue gặp phải để team đứa solution giải kịp thời  - Ví trí họp nên cố định, thời gian họp ko nên kéo dài (15-30 mins) Scrum master phải thường xuyên theo dõi Burndown chart sprin để xem tiến độ sprint nhanh hay chậm => từ đưa phương án giải giúp development team  Mọi công việc phải tuân thủ theo mô hình: design, code, test Sau kết thúc spint, lúc task công việc hoàn thành (Done Jira), toàn team ngồi họp tổng kết sprint (bao gồm scrum master, PO, Development team) - Trình bầy hạng mục hoàn thành Product backlog hạng mục chưa hoàn thành (nếu có) - Cần trình rõ ràng lý do, phương án thực để giải issue cho PO - PO cần sử dụng kỹ nghiệp vụ để xác định sản phẩm đạt chất lượng mong muốn hay chưa  Họp cải tiến sprint (retrospective) - Thành phần gồm Scrum master, Development team, có PO - Câu hỏi đặt cho toàn team là: Đã làm tốt gì, chưa tốt  Mỗi member chuẩn bị tờ giấy ghi điểm tốt, điểm chưa tốt sprint vừa  Tổng hợp tất kết quả, nêu kết nhắc đến nhiều  Cả team đưa ý kiến, cách khắc phục vấn đề tồn đọng  Lưu ý buổi họp mang tính xây dựng, không nên đặt câu hỏi sai ? chưa đạt ? mà nên đưa ý kiến để giải vấn đề tốt 8/23 Hướng dẫn: Thực phát triển sản phẩm theo phương pháp Agile Scrum 2.5 Các vai trò trách nhiệm đội ngũ agile Scrum Heo: Là người cam kết làm việc với dự án trực tiếp thực công việc thực tế  dự án Gà: Không phải vai trò có thật Scrum, phải đưa vai trò vào  số buổi họp, đặc biệt bàn giao sản phẩm Vì người người sử dụng tác động đến sản phẩm hay trình xây dựng sản phẩm 2.2.1.1 Vai trò “Heo” mô hình Scrum Product owner  Xác định lộ trình phát triển sản phẩm  Xác định thứ tự ưu tiên cho tính sản phẩm  Thiết lập qui tắc việc phát triển sản phẩm  Mô tả trì mức độ chi tiết cho tính sản phẩm  Sẵn sàn chuẩn bị cho đàn phám xảy  Định hướng nghiệp vụ trình phát triển sản phẩm  Chấp nhận xác định mức độ chấp nhận sản phẩm (xác định thời điểm kết thúc việc phát triển sản phẩm)  Vị trí là: Trưởng phòng sản xuất, trưởng phòng kinh doanh, quản trị dự án… khách hàng Scrum master  Bảo vệ nhóm giữ cho họ tập trung tới mục tiêu xác định  Loại bỏ trở ngại nhóm để hướng tới mục tiêu Sprint  Chấp hành, thi hành qui tắc nhóm 9/23 Hướng dẫn: Thực phát triển sản phẩm theo phương pháp Agile Scrum  Là thành viên điều phối nhóm  Đại diện cho nhóm trước bên liên quan  Kỹ cần thiết cho Scrum Master:  Đặt việc phục vụ nhóm lên dàng đầu  Lắng nghe đồng đội bên liên quan  Phương pháp làm việc hướng tợi việc tự tổ chức nhóm  Tạo điều kiện (loại bỏ trở ngại) Development Team  Làm việc đa dự án (có thể làm nhiều công việc khác không phụ thuộc chuyên môn)  Không phân cấp thứ bậc dự án (không quản lý ai)  Tất chịu trách nhiệm với sản phẩm bàn giao cho khách hàng  Báo cáo tình hình công việc làm cho Scrum Master Team 2.6 Vai trò “Gà” mô hình Scrum Stakeholders (customers, vendors)  Đây người cho phép dự án triển khai người mà dự án phụ thuộc soạn thỏa thuận lợi ích việc phát triển phần mềm dự án  Những người tham gia trực tiếp vào dự án buổi demo bàn giao sản phẩm để kiểm chứng khả thực tế hệ thống phần mềm Managers  Những người thiếp lập/xây dựng môi trường làm việc cho phát triển sản phẩm tổ chức 2.7 Các hoạt động Agile Họp kế hoạch (Sprint Planning meeting)  Thời gian: Kéo dài tối đa (2 với Sprint tuần, với Sprint tuần…)  Thành phần tham gia: Product Owner, Scrum Master Team  Thiết lập mục tiêu Sprint  Lựa chọn việc cho sprint (Sprint backlog) 10/23 Hướng dẫn: Thực phát triển sản phẩm theo phương pháp Agile Scrum - Product Owner cần chuẩn bị Product Backlog (đủ chi tiết để hiểu) trước tiến hành Sprint Planning Meeting - Team thực kéo yêu cầu từ Product Backlog vào Sprint Backlog dựa theo thứ tự ưu tiên Velocity Team - Mở rộng (làm rõ) yêu cầu cách phân rã tính thành Task viết User Story mức vừa đủ chi tiết để lên kế hoạch cho chúng - Các ước lượng điều chỉnh lại xem xét thảo luận buổi họp Các task sprint backlog phân rã để giá trị ước lượng nằm từ đến 16 giời - Các thành viên Team tự nhận task cho - Các công việc (nội dung, ước tính, người thực hiện…) thay đổi trình thực Sprint cho đạt xuất cao - Tính có mức độ ưu tiên thấp đưa vào Sprint Backlog phù hợp với Velocity Product Owner chấp thuận  Một số lưu ý lập kế hoạch cho sprint - Xác định độ dài cho Sprint (2-4 tuần) không đổi suốt dự án - Tính toán công suất cho team: thường ngày làm việc tiếng/ ngày hiệu quả, dự đoán ngày nghỉ có buffer cho rủi ro 20% - Những task chưa có người nhận không nên thực giao buổi họp kế hoạch - Sprint backlog kế hoạch thay đổi theo thời gian, thường 30-40% công việc sprint backlog bị thay đổi trình thực sprint Vì buổi họp kế hoạch sprint thông tin chưa rõ ràng yêu cầu làm rõ mức đơn giản đủ để hiểu lên kế hoạch cho chúng Việc làm rõ chi tiết người đảm nhận task làm rõ với PO họ chuẩn bị tiến hành task Họp sprint hàng ngày (Daily Scrum/standup meeting)   Mục địch: - Đồng hóa công việc - Cập nhật kế hoach tiến độ công việc Cuộc họp phải tiến hành hàng ngày với địa điểm thời gian xác đặt cố định suốt Sprint  Thành phần tham gia: Tất người chào đón tham gia buổi họp (Product Owner, Customer, Managers, Other Teams…) “Heo” (Product Owner, Scrum Master, Team) phép lên tiếng  Thời gian: Buổi họp tiến hành vòng 15 phút (có thể nhiều tùy vào số lượng thành viên Team, không vượt 30 phút) 11/23 Hướng dẫn: Thực phát triển sản phẩm theo phương pháp Agile Scrum   Ba câu hỏi bắt buộc thành viên Team phải trả lời: - Đã làm kể từ lần họp trước? - Sẽ làm từ lần họp tiếp theo? - Bạn có gặp vấn đề hay khó khăn công việc không? Scrum Master người điều phồi thời gian để người tập trung vào mục tiêu buổi họp, Các thành viên báo cáo cho nhau, KHÔNG báo cáo cho Scrum master   Sau buổi họp đội thực hiện: - Cập nhật Burn Down Chart ghi lại vấn đề khó khăn mà Team gặp phải - Cập nhật Sprint Backlog với task đánh giá - Scrum master hỗ trợ nhóm xử lý trở ngại/ khó khăn Lưu ý: Scrum hàng ngày có hiệu hay không cần trả lời câu hỏi sau • Nhóm có tự quản lý? • Nhóm có chia sẻ công việc? • Các báo cáo nhóm có rõ ràng? • Các nhiệm vụ lớn? • Nó có lâu không? • Có trở ngại tìm không? • Có vướng mắc tháo gỡ không? • Có hành động cải tiến không? Họp sơ kết sprint (Sprint Review Meeting)  Cuộc họp diễn vào ngày cuối Sprint  Mục đích:  - Xem xét lại công việc làm chưa làm Sprint - Kiểm tra có đạt mục tiêu Sprint hay không Nội dung: - Team trình bày hạng mục hoàn thành Proudct backlog với Product onwner bên liên quan (demo sản phẩm) - Không trình bày tính chưa “hoàn thành” - Các phản hồi đưa – Product Backlog đánh giá lại độ ưu tiên - Đây buổi DEMO, chuẩn bị 30 phút - Product Owner nên sử dụng kĩ thuật kiểm thử chấp nhận để đánh giá tính  Thời gian: Cuộc họp kéo dài tối đa tiếng  Thành phần tham gia: Product Owner, Scrum Master, Team bên liên quan  Chú ý: hạn chế không dùng Power Point để trình bày mà phải demo sản phẩm thật 12/23 Hướng dẫn: Thực phát triển sản phẩm theo phương pháp Agile Scrum Họp cải tiến (Sprint Retrospeciton meeting)  Mục đích: - Xem xét lại toàn trình làm việc vào cuối Sprint - Tìm kiếm cải tiến  Thành phần tham gia: Chỉ bao gồm Scrum Team  Nội dung: Tất thành viên Team tự đánh giá thân phản ánh vấn đề làm tốt chưa tốt Team Sprint vừa qua   Có hai câu hỏi cần trả lời buổi họp: - Những điểm làm tốt Sprint vừa qua gì? - Những điểm cần cải thiện Sprint tới? Scrum Master giúp nhóm tìm hiểu, không đưa câu trả lời tổng kết lại thứ tự ưu tiên vấn đề cần cải thiện dựa thống Team  Thời gian: Buổi họp kéo dài tối đa tiếng Các họp khác nhóm  Họp Kế hoạch Phát hành - Hiểu rõ mục tiêu cần phát hành - Hiểu chi tiết nội dung yêu cầu khách hàng - Ước tính đặt thứ tự ưu tiên Backlog - Tính toán giá trị velocity team - Tạo nên kế hoạch phát hành - Lên kế hoạch cho cập nhập sau phát hành - Đối tượng tham dự gồm: Product Owner, SCRUM Master, Delivery Team, Customers Managers  Họp làm mịn Product Backlog - Phân tách hạng mục backlog thành nhóm Thực thi chờ Product Backlog - Những hạng mục thuộc nhóm Thực thi triển khai - Các hạng mục Chờ xác định lại độ ưu tiên tiếp tục làm mịn sau  Họp review User story  Họp Rà soát mã nguồn (Code Review) 2.8 Các tạo tác (Artifact) Scrum Product Backlog 13/23 Hướng dẫn: Thực phát triển sản phẩm theo phương pháp Agile Scrum a) Khái niệm  Là tài liệu mức độ cao dự án (tài liệu tổng quan quan trọng nhất) Là list Product backlog Item  Product owner xác định giá trị nghiệp vụ PBI xếp theo thứ tự ưu tiên nhu cầu nghiệp vụ  Tài liệu xác định việc dự án cần làm sản phẩm mà không quan tâm tới việc làm người thực  Lưu ý: - Tài liệu Product Owner quản lý Đội Scrum có quyền bổ sung công việc vào Product Backlog phê duyệt Product owner - Ước tính kích cỡ (size) công sức (effort) PBI scrum team thống đưa - Bugs khách hàng tìm không sửa ngày lúc team thực sprint khác nên cần phải đưa vào Product Backlog để thực sprints sau Product Backlog phát triển lớn dần theo thời gian có tính chất không hoàn thành Như dự án kết thúc Product Owner cảm thấy hài lòng sản phẩm định dừng việc phát triển lại, cho dù thời điểm Product Backlog có hoàn thiện phần trăm - Các tính cần mô tả mức chi tiết đủ để Scrum Team hiểu đưa vào triển khai Sprint Mọi chi tiết với yêu cầu Scrum Team làm rõ với Product Owner triển khai yêu cầu thực tế Sprint  Một số thông tin bắt buộc cần có Product Backlog: - Product Backlog Item: User Stories, Features, Bugs… - Business Value: Giá trị nhu cầu nghiệp vụ (Extra High, High, Medium, Low) - Product Size: Kích thước ước tính Team với Item 14/23 Hướng dẫn: Thực phát triển sản phẩm theo phương pháp Agile Scrum - Priority: Thứ tự ưu tiên thực Item (phụ thuộc vào Business Value Product Size) b) Xác định thư tự ưu tiên Product backlog Item  Mục đích: Sắp xếp thứ tự ưu tiên thực Product Backlog Item  Các bước: - Đầu tiên cần xác định giá trị yêu cầu nghiệp vụ trước - Sau ưu tiên thực yêu cầu nghiệp vụ có giá trị quan trọng cao Lưu ý:  - Thứ tự ưu tiên sở hữu điều chỉnh Product Owner, Scrum Team thỏa thuận với Product Owner cần thay đổi thứ tự ưu tiên - Chúng cần xem xét lại điều chỉnh có yêu cầu yêu cầu thay đổi phát sinh Các tiêu chí cho việc xác định thứ tự ưu tiên sau:  - Business Priority: Đặt ưu tiên cao cho Item có nhu cầu nghiệp vụ cao - Risk: Đặt ưu tiên cao cho Item có khả rủi ro cao để xử lý chúng trước, tránh bị kéo dài cuối Sprint - Estimates: Đặt ưu tiên lựa chọn thực Item cho vừa đủ với thời gian Sprint Ví dụ Product backlog: Priority Size Value (from Team) (from Product Owner) Description Feature A Extra-High Feature B Extra-High Feature C High Feature D Extra-High 15/23 Hướng dẫn: Thực phát triển sản phẩm theo phương pháp Agile Scrum Feature E High Feature F Medium Feature G 13 High Feature H Low c) Các kỹ thuật xác định độ ưu tiên Product backlog Item  Phương pháp ước lượng Story Points: o Thiết đặt size theo giá trị số Geometric series: 1,2,4,8,16,32… o Thiết đặt size theo giá trị số Fibonacci series: 1,2,3,5,8 o Việc ước lượng size mang tính tương đối, xác tuyệt đối o Ưu điểm: Độ xác size không quan trọng tính quán chúng (Sự quán tính lớn tính nhỏ phải thể hiện, không dùng số bừa bãi) o Nhược điểm: Giá trị ước tính Team cụ thể áp dụng cho Team khác, mang so sánh hay đong đếm chung với Team khác  Phương pháp T-Shirt Sizing: o Sử dụng kí hiệu: S, M, L, XL o Thường ưu tiên lựa chọn sử dụng sau Story Point tính đơn giản o Là cách thức tốt cho việc ước tính kích thước tương đối o Ưu điểm: Dễ dàng sử dụng nắm bắt o Nhược điểm: Khá khó khăn cho việc so sánh kích thước với thời gian cần tiêu tốn để thực  Phương pháp Playing Pocker: 16/23 Hướng dẫn: Thực phát triển sản phẩm theo phương pháp Agile Scrum o Việc ước lượng Size cho Product Backlog Item thường thực thông qua cách thức chơi Planning Pocker o Với cách thức thành viên Team có Pocker với giống lựa chọn phù hợp theo phương pháp estimate nói o Mỗi người úp định chấm điểm Size cho Item nhắc tới, sau lật Nếu thành viên chấm điểm lệch người cho cao thấp giải thích lý do, tiếp Team chấm điểm lại lần để thống Size cho Item  Phương pháp MoSCoW o Được áp dụng chủ yếu với Product Owner việc ước tính Business Value o Nó kỹ thuật hiểu lời khẳng định nhu cầu nghiệp vụ User Story với bên liên quan - Must have: Bắt buộc phải có - Should have: Nên có - Could have: Có thể có không - Won’t have: Không cần thiết Sprint Backlog  Khái niệm: - Sprint Backlog kết trình lập kế hoạch cho Sprint 17/23 Hướng dẫn: Thực phát triển sản phẩm theo phương pháp Agile Scrum - Là tài liệu chứa thông tin việc làm để Team xây dựng tính Sprint Các tính chia thành nhiều Task khác để thực - Các tính Product Backlog lựa chọn đưa vào Sprint Backlog bóc tách thành Task để thực dựa  Tài liệu công việc cần làm, thời gian thực người thực Lưu ý: - Các Sprint task Sprint Backlog (nội Team) thu thập đồng thuận team - Thành viên Team tự nhận task cho để thực hiện, không giao việc cho họ mà họ chủ động tự quản - Các task ước lượng thời gian thực ghi lại vào Sprint Backlog Việc ước lượng thực Team - Các task chia nhỏ để ước lượng thời gian thực từ đến 16 - Mọi thành viên Team phép cập nhật Sprint Backlog suốt trình thực Sprint cho phù hợp với công việc thực tế - Sprint Backlog tài sản chung Team, thành viên phải có trách nhiệm nghĩa vụ quản lý  Ví dụ sprint backlog: Product Backlog Item Task Volunteer Effort (h) Day1 Day2 Day3 Day4 Day5 Task1 DEV1 Task2 DEV4 Task3 DEV2 4 Task4 DEV3 3 Task5 DEV4 Task6 DEV1 Task7 DEV2 Task8 DEV3 Feature Feature Total: 34 18/23 14 Hướng dẫn: Thực phát triển sản phẩm theo phương pháp Agile Scrum 3) Năng suất làm việc team (Velocity) cách xác định  Khái niệm: - Là xuất Scrum Team hoàn thành Product Backlog Item Sprint  Được đo tính toán Story Point Ý nghĩa: Sau xác định Velocity dùng để lập kế hoạch dự án, kế hoạch phát hành (bàn giao) sản phẩm dự báo trước ngày hoàn thành sản phẩm  Lưu ý: - Được xác định cách review tổng hợp thông số từ vài Sprint với thành phần Scrum Team thời gian thực Sprint không đổi - Không nên thay đổi thành phần Scrum Team, thời gian Sprint giá trị Velocity nhiều  Để xác định Velocity cho Scrum Team mới, cho Scrum Team chạy Sprint – Sprint tự mà Velocity, sau Sprint thứ tổng hợp giá trị Velocity xác Tuy nhiên giả lập Velocity cho Team từ đầu, sau điều chỉnh dần Sprint thứ Ví dụ: 19/23 Hướng dẫn: Thực phát triển sản phẩm theo phương pháp Agile Scrum User Story  Khái niệm: - Được gọi Details Document, ghi mô tả chi tiết tính - Do người chịu trách nhiệm xử lý trức tiếp trao đổi với Product Owner/Customer để làm rõ viết User Story, sau break thành task để thực - Là công cụ sử dụng phổ biến Scrum phương pháp Agile khác để thể nhu cầu người dùng   Cách viết theo phương pháp INVEST: - Independent: Story phải độc lập, không bị phụ thuộc vào Story khác - Negotiable: Có thể thỏa thuận để thay đổi (thêm/bớt) - Valuable (to users/customers): Phải có giá trị người dùng/khách hàng - Estimable: phải đủ chi tiết để ước lượng - Small: Chỉ cần ngắn gọn, không nhiều, dài dòng - Testable: Phải rõ ràng để chứng thực Nội dung user story: - Là , Tôi muốn để Định nghĩa hoàn thành (Definition of Done)  Khái niệm: - Khi hạng mục Product backlog Item gói tăng trưởng (Incremental) cho hoàn thành, người phải hiểu rõ “Hoàn thành” nghĩa nào? 20/23 Hướng dẫn: Thực phát triển sản phẩm theo phương pháp Agile Scrum - Việc định nghĩa “hoàn thành” phụ thuộc vào nhóm Scrum, thành viên phải chia sẻ chung cách hiểu việc hoàn thành công việc, để đảm bảo tính minh bạch suốt - Định nghĩa “ Hoàn thành” dùng để đánh giá công việc thực hoàn thành gói tăng trưởng sản phẩm - Định nghĩa hoàn thành đươc thiết lập buổi thảo luận Product owner với đồi Scrum vào đầu dự án - Định nghĩa hoàn thành thay đổi theo thời gian Hỗ trợ việc tổ chức khả đội sản xuất tháo gỡ trở lực, cho phép bổ sung thêm hoạt động vào Định nghĩa hoàn thành chức Sprint -  Cần có định nghĩa hoàn thành cho: User story, Sprint Release Ví dụ định nghĩa hoàn thành: - DOD for User Story  User story đội hiểu giống  Tất user story product owner phê duyệt  Sự thay đổi user story phải product owner phê duyệt product backlog phải update - DOD for Sprint     Các task print phải họp tiến sprint, đưa solution scrum master giải vấn đề team Nếu có effort, QA nên giúp team phát triển đảm bảo chất lượng sản phẩm làm  Các sản phẩm làm phải có check list  QA review check list sản phẩm làm  Comment có  Sản phẩm release sau QA FI hoàn thành chấp nhận 23/23 [...]... dẫn: Thực hiện phát triển sản phẩm theo phương pháp Agile Scrum 4 User Story  Khái niệm: - Được gọi là Details Document, ghi mô tả chi tiết các tính năng - Do người chịu trách nhiệm xử lý trức tiếp trao đổi với Product Owner/Customer để làm rõ và viết User Story, sau đó được break thành các task để thực hiện - Là công cụ được sử dụng phổ biến trong Scrum và các phương pháp Agile khác để thể hiện nhu... Sprint     Các task trong print phải ... waterfall, agile scrum phát triển sản phẩm theo vòng lặp tăng trưởng, vòng lặp xác định thời gian 2-4 tuần kết thúc vòng lặp có sản phẩm chạy 6/23 Hướng dẫn: Thực phát triển sản phẩm theo phương pháp Agile. .. Hướng dẫn: Thực phát triển sản phẩm theo phương pháp Agile Scrum GIỚI THIỆU 1.1 Mục đích Tài liệu có mục đích hướng dẫn IT có nhìn khái quát việc phát triển phần mềm theo phướng pháp Agile Scrum, ... biến Scrum phương pháp Agile khác để thể 3/23 Hướng dẫn: Thực phát triển sản phẩm theo phương pháp Agile Scrum nhu cầu người dùng Thông thường, user story khách hàng, đại diện khách hàng, người thực