Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Agile scrum
Ähnlich wie Agile scrum (20)
Agile scrum
- 2. Agile-Scrum Tại sao lại cần dùng Agile/Scrum??? 2
- 3. Agenda Agile/WaterFall • Giới thiệu về agile-waterfall Tổng quan về Agile • Nhập môn agile • Lập kế hoạch cho project agile Tổng quan về Scrum • Khái quát về scrum • Scrum team • Scrum event • Scrum Artifacts Nguồn tham khảo • Agile Samurai • Scrum • Scrum ガイド • Scrum現場ガイド 3
- 4. Agile/WaterFall ■ Khái quát về agile và WaterFall 4
- 5. Tổng quan về agile ■ Nhập môn agile – Nguyên lý agile ■ Release sản phẩm hàng tuần (tiến trình) ■ Phần mềm chạy được là công cụ đánh giá tiến độ chính xác nhất ■ Người hiểu biết business và dev phải làm việc cùng nhau 5
- 6. Tổng quan về agile ■ Nhập môn agile – 3 sự thật trong phát triển phần mềm ■ Trước khi bắt đầu project không thể làm rõ được toàn bộ yêu cầu ■ Sau khi chốt yêu cầu thì gần như chắc chắn là yêu cầu đó sẽ có sự thay đổi ■ Những việc cần làm luôn nhiều hơn so với schedule và cost 6
- 7. Tổng quát về agile ■ Lập kế hoạch – User Story – Estimate – Lên plan 7
- 8. Tổng quát về agile ■ Lập kế hoạch – User Story ■ Là bản ghi lại 1 cách đơn giản những tính năng khách hàng muốn thực hiện ■ 1 User story tốt khi đáp ứng đầy đủ điều kiện INVEST – I: Independent -> Tính độc lập – N: Negotiable -> Có thể đàm phán – V: Valuable -> Có giá trị Business – E: Estimatable -> Có thể estimate – S: Small -> Nhỏ – T: Testable -> Có thể test 8
- 9. Tổng quát về agile ■ Lập kế hoạch – User Story ■ ストーリーカード 9
- 10. Tổng quát về agile ■ Lập kế hoạch – Estimate ■ Tiêu chí estimate trong agile: – Estimate theo kích cỡ size tương đối của user story – Quản lý project theo số point 10
- 11. Tổng quát về agile ■ Lập kế hoạch – Lên Plan ■ Tạo Master Story ■ Ước lượng quy mô project ■ Set độ ưu tiên cho user story ■ Ước lượng velocity của team ■ Dự kiến deadline 11
- 12. Tổng quát về agile ■ Lập kế hoạch – Sự thật về tính năng trong phần mềm 12
- 13. Tổng quát về Scrum ■ Khái quát về scrum – Đặc điểm ■ Gọn nhẹ ■ Simple, dễ hiểu ■ Rất khó để vận dụng thành thạo – Nguyên lý ■ Tính minh bạch ■ Kiểm tra (Inspection) ■ Áp dụng (Adaptation) 13
- 14. Tổng quát về Scrum ■ Scrum Team – Role ■ Product Owner ■ Scrum Master ■ Dev Team – Đặc điểm ■ Chủ động trong công việc ■ Có khả năng tự giải quyết vấn đề ■ Không phân chia cấp bậc 14
- 15. Tổng quát về Scrum ■ Scrum Event – Sprint – Sprint Planning – Daily Meeting – Sprint Review – Sprint Retrospective 15
- 16. Tổng quát về Scrum ■ Scrum Artifacts – Product Baclog – Sprint Backlog – Increment 16
- 17. 17 - Customer, end-users, team và stakeholders khác. - Đưa ra yêu cầu cho Product Owner Bring a team together - Là người đại diện cho enduser về business product - Là người trực tiếp trao đổi thương lượng với enduser - Là người quản lý product backlog Create product backlog 1 2 Skateholders Product Owner
- 18. 18 - Hiểu rõ về scrum, giúp dự án chạy đúng theo scrum - Giúp các member trong team hiểu rõ hơn về scrum - Support Product Owner - Support Dev Team - Support Tổ chức Scrum Master - Có tính chủ động cao - Tự quản lý task, công việc - Team size khoảng 3-9 người Development Team 3 4
- 19. 19 - Thống nhất, làm rõ scop phát triển - Không thực hiện thay đổi ảnh hưởng đến sprint goal - Không hạ thấp mục tiêu về chất lượng sản phẩm The Sprint - Sprint sẽ thực hiện những story nào - Để hoàn thành mục tiêu thì cần làm gi Sprint planning 5 6
- 20. 20 - Thời gian khoảng 15 phút - Thực hiện hang ngày, cùng thời gian, cùng địa điểm - Hôm qua đã làm gì để hoàn thành sprint goal - Để hoàn thành sprint goal dự kiến nay sẽ làm gì - Có phát hiện ra vấn đề nào trở ngại đến việc hoàn thành sprint goal không Daily Scrum - Thể hiện status project hiện tại - Dự kiến thời gian hoàn thành Scrum Board & Burndown Chart 7 8
- 21. 21 - Những item đã hoàn thành đến thời điểm hiện tại tuân thủ theo định nghĩa done mà team đã đề ra Increment - Scrum team sẽ cùng với stackholder review lại tính năng đã hoàn thành trong sprint - Demo tính năng và trả lời câu hỏi của stackholder - PO giải thích về product hiện tại và đưa ra dự kiến deadline - Thảo luận lại về business của product và quyết định item cho sprint tiếp theo Sprint Review 9 10
- 22. 22 - Đánh giá sprint vừa qua trên quan điểm: con người, mối quan hệ giữa các thành viên, process, tool phát triển - Sắp xếp lại những vấn đề cần cải thiện - Lập kế hoạch cải thiện Sprint Retrospective 11
- 23. 23
- 24. Nguồn tham khảo ■ アジャイルサムライ ■ スクラム ■ スクラムガイド ■ スクラム実践入門 ■ スクラム現場ガイド 24
- 26. THANK YOU
Hinweis der Redaktion
- Product Owner: Là người chịu trách nhiệm cho việc tối ưu hoá giá trị sản phẩm được tạo ra bởi Development team. Là người chịu trachhs nhiệm chính cho Product Backlog: + Mô tả 1 cách rõ ràng các Product Backlog + Sắp xếp thứ tự các Backlog 1 cách hợp lí để phù hợp với mục tiêu và nhiệm vụ + Đảm bảo rằng các backlog này hiện hữu, rõ ràng và thể hiện được rằng việc zì sẽ được làm kế tiếp. + Đảm bảo Product backlog được Development team hiểu được ở level chấp nhận được.
- Scrum Master: + Đảm bảo rằng Scrum được hiểu đúng và thực thi bằng cách đảm bảo nhóm Scrum tuân thủ lý thuyết, kĩ thuật thực hành và các quy tắc của Scrum + Là một người lãnh đạo phục vụ (servant-leader): giúp dodwx người ngoài hiểu Scrum để tương tác với 1 nhóm Scrum hiệu qủa nhất. Đối với Product Owner: cải thiện product backlog, tạo điều kiện cho các Scrum event, giúp nhóm Scrum hiểu đưuowcj các hạng mục của Product Backlog Đối với Development team: Huấn luyện Dvelopment team về cross functionallity, và self-organiation, loại bỏ các rào cản trong quá trình phát triển, giúp nhóm phát triển tạo ra các sản phẩm có giá trị cao, training Scrum Đối với Tổ chức : Dẫn dắt huấn luyện tổ chức Scrum, lập kế hoachj triển khai Scrum, làm việc với các Scrum Master khác để tăng hiệu quả làm việc. Development team: +Tự quản: không ai có quyền yêu cầu nhóm làm việc làm thế nào để chuyển product backlog thành các thành phần có thể chuyển giao được + Liên chức năng: có tất cả các kĩ năng cần thiết để tạo phần tăng trưởng của sản phẩm + Scrum không chấp nhận bất cứ 1 chức danh nào khác trong nhóm ngoài Development team member + Không chứa nhóm con nào khác như Tester, BA + Mỗi 1 cá nhân có thể có khả năng riêng biệt nhưng chịu trách nhiệm vẫn thuộc về cả nhóm.
- Trái tim của Scrum là 1 Sprint nơi mà development sẽ lựa chọn ra một số sprint backlog để hoàn thành các phần tăng trưởng thoả mãn các yêu cầu được đặt ra, có thể sử dụng và phát hành được. Không cho phép bất cứ thay đổi nào ảnh hưởng tới mục tiêu của Sprint Mục tiêu chất lượng không được cắt giảm và nếu có thay đổi gì thì cần được thương lượng lại giữa Product Owner và Development team Huỷ 1 Sprint: Có thể huỷ sản phẩm khi chuyển hướng kinh doanh hoặc công nghệ có sự thay đổi - Các thành phần đã thay đổi có thể xem xét lại. Tuy nhiên là sẽ làm lãng phí nguồn lực do đó nên họp lại và cân nhắc cụ thể Sprint planning: + Nhóm có thể bàn giao được phần việc nào cho Sprint sắp tới + Làm thế nào để giao nộp được các phần tăng trưởng đó + Dựa vào product backlog và các phần tăng trưởng gần nhất để quyết định sẽ làm gì tiếp theo. + Chỉ 1 lượng công việc vừa đủ được đưa vào. + Kết thúc buổi họp. Nhóm phát triển phải giải thích được cho Product Owner là họ dự định sẽ làm như thế nào để hoàn thành được mục tiêu và tạo ra phần tăng trưởng theo đúng yêu cầu
- 3. Daily Scrum + Đánh giá tiến độ công việc đối với mục tiêu sprint và đánh gia xu hướng tiền triển của công việc trong SPrint backlog + Chỉ có Development team mới được tham gia cuộc họp Scrum hàng ngày + Nhằm mục đích cải tiến việc giao tiếp và lược bỏ các buổi họp không cần thiêt,s nhận biết và loại bỏ sớm các trở ngại trong quá trình giao tiếp, nhấn mạnh và phát huy việc đưa ra quyêt địnhnhanh và nâng cao mức độ hiểu biết của nhóm phát triển về dự án
- Tăng trưởng là tổng hợp của tất cả những Product Backlog items đã được hoàn thiện trong suốt 1 Sprint và đã đạt được Definition of Done. Sprint Review; được tổ chức để rà soát lại phần tăng trưởng vừa làm ra trong Sprint. + Bao gồm Scrum team và những người liên quan được Product Owner mời tới. + Thảo luận về các vấn đề gặp phải và cách giải quyết các vấn đề đó + Thuyết trình về các phần viếc đã Done và trả lời câu hỏi của Product owner về các gói tăng trưởng. + Đánh giá lại sản phẩm, xu hướng thị trường để quyết định là sẽ làm gì tiếp trong các Sprint sắp tới. + Làm mịn lại Product Backlog
- 5. Sprint Retrospective: After the Sprint Review and just before the Sprint is over, the Development Team holds an internal meeting to review the Sprint and use it to improve the process (lessons learned) in the next Sprint. This meeting is called Sprint Retrospective.