Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Basic advanced scrum framework

6,085 views

Published on

Giới thiệu & lịch sử Scrum
Scrum cơ bản
Scrum nâng cao
Những câu hỏi thường gặp
Các tình huống thực tế
Bộ công cụ Agile/Scrum
Trao đổi/thảo luận

Published in: Education
  • Be the first to comment

Basic advanced scrum framework

  1. 1. BASIC/ADVANCED Scrum Framework Nguyễn Vũ Hưng 2016/12/26
  2. 2. Who Am I 1. Nguyễn Vũ Hưng, 1978 2. Agile/Managment Training/Consultant 3. CTO, Fuji Technology 4. POS: a. Agile b. Open Source c. Project Management "Nguyen Vu Hung is the CTO of Fuji Technology.He has numerous years of IT and software development, project/product management in both Japan and Vietnam. Considering himself as a FOSS and Agile evangelist and being a Agile lover and an CTO, he is also interested in not-so-related domains such as human resource management and (organization) (re)structuring." facebook.com/nguyenvuhung vuhung16plus@gmail.com +84-904-28-7878
  3. 3. Agenda/Index 1. Giới thiệu & lịch sử Scrum 2. Scrum cơ bản 3. Scrum nâng cao 4. Những câu hỏi thường gặp 5. Các tình huống thực tế 6. Bộ công cụ Agile/Scrum 7. Trao đổi/thảo luận
  4. 4. How to Use This Document for Training 1. Option #1 a. 2 days b. 4 hour for 4 times c. More in depth d. Theory & workshops with case studies 2. Option #2 a. 2 ~ 4 hours b. Inspiration c. Main keywords, ideas d. Self studies + online/off-training discussion 3. Option #3 a. Self-study
  5. 5. Scrum & Rugby “A scrum (short for scrummage) is a method of restarting play in rugby that involves players packing closely together with their heads down and attempting to gain possession of the ball.”
  6. 6. Agile/Scrum History
  7. 7. What is Scrum? 1. Scrum là một khung (framework) làm việc 2. Là một bộ nguyên tắc, triết lý, giá trị làm việc
  8. 8. What is NOT Scrum? 1. Scrum không phải là một quy trình 2. Scrum != vạn năng 3. Scrum không đồng nhất với Agile 4. Scrum không đồng nghĩa với “luôn luôn thành công"
  9. 9. Why Scrum? 1. Thay đổi tư duy 2. Đối ứng với sự thay đổi RẤT nhanh a. Thế giới công nghệ b. Nghiệp vụ c. Thị trường d. Yêu cầu phần mềm 3. Đối ứng với dự án (phần mềm) khó, phức tạp, không rõ ràng 4. Mọi người thoải mái hơn khi làm việc
  10. 10. Ví dụ (xấu) về quản lý dự án (1) 1. Đọc một case study 2. Trao đổi a. Điểm xấu b. Điểm tốt c. Nhận định chung
  11. 11. Ví dụ (xấu) về quản lý dự án (2) 1. Đọc một case study 2. Trao đổi a. Điểm xấu b. Điểm tốt c. Nhận định chung
  12. 12. Khung làm việc Scrum (cho một nhóm)
  13. 13. Scrum Events 1. The Sprint 2. Sprint Planning 3. Daily Scrum Meetings 4. The Sprint Review 5. The Sprint Retrospective
  14. 14. Ba nguyên tắc Scrum 1. Thanh tra 2. Thích nghi 3. Minh bạch
  15. 15. Giá trị cốt lõi của Scrum (Xem Agile Manifesto)
  16. 16. Nhóm Scrum & các vai (Lướt qua) 1. Product Owner 2. ScrumMaster 3. Team Members
  17. 17. Sự tự quản trong Scrum 1. Cách làm 2. Tự quản vs. hiệu suất 3. Tự quản và triết lý quản lý cổ điển
  18. 18. ScrumMaster là ông nào? 1. Đảm bảo nhóm chạy dự án theo khung Scrum 2. Osin 3. Chuyên đi giúp người khác (team members, PO) 4. SM bảo vệ team (khỏi PO, stakeholders) 5. Làm quy trình 6. Proxy giữa người giao việc và người làm việc 7. Hoà giải vấn đề (impediments), mâu thuẫn 8. Làm trao đổi nhanh chóng hơn 9. SM != leader, project leader, project manager 10. SM không nói “chúng mày làm cái này đi"
  19. 19. Chuyển đổi PM → ScrumMaster 1. Chuyển đổi tư duy 2. Chuyển đổi thói quen 3. Quản lý “vô vi" a. Tự quản b. Tự chủ c. Tự vận hành d. Liên chức năng 4. “Osin" = giúp đỡ 5. Metrics khác
  20. 20. Chuyển đổi Product Manager → Product Owner Với PO: 1. Tư duy Agile 2. Từ “Manager" thành “member" 3. Nghĩ việc và giao việc 4. Không trực tiếp “quản lý"
  21. 21. Chuyển đổi tổ chức truyền thống → Agile 1. Thế nào là tổ chức Agile 2. Scaling Agile a. Agile team b. Agile department c. Agile product (team) d. Agile company 3. Follow Agile core values and principles 4. New roles 5. *NEW STYLE* Managers → SM, PO, facilitator, helper, consultants, coach, mentor...
  22. 22. Đặc trưng nhóm phát triển (sản xuất) 1. Làm việc 2. Tự quản 3. Liên chức năng
  23. 23. (10-day) Scrum Timeframe
  24. 24. DoD: Định nghĩa hoàn thành 1. Thế nào là xong, không xong 2. Giao việc rõ ràng 3. Chỉ làm đúng DoD 4. DoD cho việc tích hợp 5. DoD cho người làm việc thứ N và N + 1 trong một luồng công việc 6. Quy định của nhóm (ground rules) 7. Một số DoD phổ biết a. Use story b. Coding c. Unit test d. Integration test e. Release f. Deployment
  25. 25. Độ dài Sprint thế nào là hợp lý ● Thường sprint dài 2 tuần ● 1 tuần = quá ngắn? ● 3 tuần: Quá lẻ không? ● 4 tuần: Quá dài và feedback chậm
  26. 26. Product Backlog 1. Là danh sách những công việc (TODO list) của cả sản phẩm/dự án 2. Được quản lý chính bởi PO 3. Mọi người đều có quyền thêm công việc vào backlog 4. PO: Prioritizing 5. PO: Cắt việc từ Product backlog sang từ Sprint backlog 6. Ví dụ về PB 7. Thô hay tinh 8. DoD ở mức nào? 9. LUÔN thay đổi & biến động 10. Estimate (bằng points, (giờ?)) 11. Re-estimate: a. Luôn luôn b. Đầu và cuối sprint (PO + team) 12. Một số loại công việc a. (New features) b. Bugs c. Kiến thức
  27. 27. Sprint Backlog 1. Công việc trong một sprint 2. Trách nhiệm + Công việc của team. 3. Sprint planning a. Rõ ràng b. Ngày nào làm việc làm c. Ai làm việc/task nào d. Cần bao nhiêu giờ? 4. Estimation bằng points (hour?) 5. Team capacity: Làm được bao nhiêu?
  28. 28. Plan vs. Planning ● Plan: Bản kế hoạch ● Planning: Việc lên kế hoạch ● Agile/Scrum ○ Có thể không cần plan (dài hạn) ○ Nhưng việc planning là cần thiết ● Plan trong từng sprint: Luôn rõ ● Plan dài hạn ○ Strategies ○ Vision ○ PO + team ● Plan ngắn hạn ○ Theo từng sprint ○ Team làm
  29. 29. Burndown chart (vs. Gantt Chart) 1. Waterfall: Gantt chart 2. Burndown: Scrum 3. Planned vs. Actual 4. EVM với Scrum 5. Với Scrum, tạo được cả burndown và Gantt?
  30. 30. (Some) Agile Engineering Practices 1. Pair Programming 2. Test Driven Development/Unit Testing 3. Continuous Integration 4. Refactoring 5. Acceptance Testing 6. Small Releases
  31. 31. Khó khăn chuyển đổi sang Scrum 1. Ngại thay đổi 2. Thiếu thông tin 3. Thực thi yếu 4. Không biết hỏi ai
  32. 32. Bạn bè của Scrum 1. Kanban: Không hẳn là Agile 2. Lean: Không hẳn là Agile 3. Nhưng hiệu quả 4. Và thích hợp với một số loại dự án/công việc
  33. 33. Scrum Team Culture 1. Xây dựng từ core values/principle của Agile 2. Xây dựng từ core values/principle của Scrum 3. Xây dựng từ Agile practices 4. Văn hoá team → văn hoá doanh nghiệp? 5. Scaling văn hoá theo chiều ngang? 6. Scaling văn hoá theo chiều dọc (cá nhân, team 1 → team 2, phòng ban, công ty)
  34. 34. Ai thích hợp vị trí ScrumMater 1. Bất kỳ ai 2. Project Manager → ScrumMaster: Thường thấy 3. Project Leader → ScrumMaster: Thường thấy 4. PMO → SM 5. Kỹ năng cứng: Ít cần (hơn) 6. Kỹ năng mềm: Cần nhiều 7. Kỹ năng giải quyết vấn đề 8. Mâu thuẫn con người 9. Quan hệ rộng 10. Hiểu biết rộng 11. Kỹ năng coaching/mentoring 12. Kinh nghiệm nhiều (cả kỹ thuật và quản lý)
  35. 35. Ai thích hợp vị trí Product Owner 1. Product Managers 2. Producers 3. Project Managers 4. Designers/Artists 5. Investors
  36. 36. Agile có phải là Scrum không? 1. Agile là một bộ giá trị, nguyên tắc 2. Scrum là một khung làm việc
  37. 37. Vừa làm PO vừa làm SM được không? 1. Không nên 2. PO: Người giao việc 3. SM: Người trung gian điều phối giới người giao việc và người nhận việc (dev team)
  38. 38. Vừa làm PO vừa làm team member được không? 1. Không nên; 2. Hoặc tuyệt đối không 3. Mâu thuẫn giữa 2 hats a. PO: Người giao việc b. Team members: Người nhận việc
  39. 39. Một team member làm nhiều việc được không? 1. Được, hoàn toàn được 2. Scrum team là cross-functional 3. Trong một scrum team cần có đủ người làm đủ bộ tất cả những việc và dự án cần
  40. 40. Scrum có cần tài liệu không? 1. Có 2. Scrum ưu tiên hơn sản phẩm chạy được 3. Chứ không phủ nhận tài liệu 4. Khi cần, team vẫn làm tài liệu (thiết kế) 5. Nhưng độ ưu tiên thấp hơn
  41. 41. Sprint và Iteration đồng nghĩa không? Both Sprints of Scrum and Iterations of Iterative Incremental model deliver working product increments. However, these differ in that: 1. Lifecycles of Sprint and Iteration are different. 2. Sprints are time-boxed, while Iterations are not. 3. Duration of Sprints is much less compared to durations of Iterations.
  42. 42. Agile Estimation 1. Planning Poker 2. Tương đối vs. Tuyệt đối 3. Estimate/Plan theo từng sprint 4. Estimate dài hạn vs ngắn hạn 5. Bottom-up vs top-down estimation 6. Team engagement in estimation/planning 7. Agile budgeting
  43. 43. Agile Tools 1. (Task) management tools a. Atlassian: JIRA (Agile) b. Backlogtool (backup.jp) c. Trello d. Redmine (Scrum2B) e. VersionOne 2. CI/CDs a. Bamboo b. Jenkins c. TeamCity 3. Sticky Notes 4. Boards (kanban, Scrum) 5. Charts (burndown, burnup, velocity, Cumulative flow diagram…)
  44. 44. Viết User Stories hiệu quả As a Customer, I want to withdraw cash from an ATM, So that I don't have to wait in line at the Bank 1. Simple and Concise 2. Start with Epics 3. Refine the Stories until They are Ready 4. Add Acceptance Criteria (DoD for user stories) 5. Use Paper Cards 6. Keep your Stories Visible and Accessible 7. Think of NFR. Don’t Solely Rely on User Stories
  45. 45. Chứng chỉ Scrum 1. Scrum Alliance: a. CSM: Certified ScrumMaster b. CSPO: Certified Scrum Product Owner c. CSD: Certified Scrum Developer d. CSP: Certified Scrum Professional 2. Scrum.org a. PSM: Professional ScrumMaster b. PSPO: Professional Scrum Product Owner c. PSD: Professional Scrum Developer d. SPS: Scaled Professional Scrum
  46. 46. Ai chịu trách nhiệm viết Sprint backlog? 1. Team (cả team) 2. Sprint backlog: Là backlog sau khi PO đã “giao việc" cho team 3. Lưu ý: PO chịu trách nhiệm với Product backlog
  47. 47. Bao nhiêu point trong một sprint là đủ? 1. Là một FAQ (rất hay bị hỏi) 2. Không có câu hỏi chính xác 3. Tương đối với từng team 4. Tuỳ vào team (không có giá trị tuyệt đối với nhiều team) 5. Tuỳ vào cách định nghĩ “point đơn vị" 6. Thế nào là 1 point? 7. Một chức năng cơ bản (như login) đáng giá mấy point? 8. Số point có thay đổi theo từng sprint không? 9. Với 2 teams trong cùng một sản phẩm thì cách tính point khác nhau không?
  48. 48. Trong Scrum, ai là người giao việc? 1. Không ai giao việc 2. Mà ai cũng có thể tạo/đề xuất công việc 3. Scrum là team chủ động 4. (Nhắc lại): Ai cũng có thể tạo việc, nhưng team là người nhận việc a. PO: Là người giao việc chính b. Team member: Tự phát hiện bug và fix c. ScrumMaster: Nghĩ ra việc cải tiến quy trình, áp dụng công cụ mới d. Stakeholder: Nghĩ ra việc gì đó cớ lợi cho sản phẩm, team; proxy qua PO và giao cho team làm
  49. 49. Nhóm Estimate lúc nào? 1. Với sprints a. Estimate chính vào ngày đầu tiên của sprint b. Điều chỉnh, tìm hiểu việc estimate vào (1 hoặc 2) ngày cuối của sprint c. Điều chỉnh estimate vào những ngày giữa sprint 2. Với daily meeting a. Estimate (lại) vào daily meeting 3. Dài hạn a. Estimte, plan, chiến lược 1 tháng, 3 tháng, 6 tháng
  50. 50. Planning Pokers 1. Là một cách planning 2. Cho điểm 3. Đồng thuận 100% 4. Estimate tương đối 5. Mapping/quy đổi story points và man-hour 6. Cơ sở đo đạc trên số
  51. 51. Định nghĩa Ready 1. Khi nào thì story này là sẵn sàng với team? 2. Là một lane trong kanban 3. Khi nào developers hết cẩu hỏi (ready) với một user story? 4. DoD cho user story là gì?
  52. 52. Phối hợp Kanban và Scrum thế nào? 1. Scrum + Kanban = Scrumban 2. (Scrum/Kanban) board điện tử và vật lý (giấy, bảng trắng) 3. Tính “sờ được" và đo được 4. WIP trong Kanban và Scrum 5. Tính liên tục và gián đoạn (Kanban vs. Scrum) 6. Sự đóng khung thời gian (time-boxed)
  53. 53. Scrum team bao nhiêu người? 1. Từ 3 ~ 9 người 2. Pizza rule 3. Two-pizza rule (Amazon) 4. Scaling agile: When and how? 5. Org. chart vs scrum team structure 6. Technical design maps with Scrum team org. chart
  54. 54. Velocity 1. Tốc độ nhóm “burn" (hoàn thành) số story point 2. Nếu không đo được story thì hãy đo theo số lượng task (bất kể lớn bé) 3. Velocity theo từng ngày (trong một sprint) 4. Velocity của sprint N vs. N + 1 5. Đánh giá định tính dựa trên tốc độ 6. Ra quyết định, estimate sprint N+x dựa trên velocity
  55. 55. Backlog order theo thứ tự nào? 1. Theo độ ưu tiên 2. Theo độ khẩn cấp 3. Nguyên lý 80-20 4. Scrum task board a. Task ưu tiên cao nhất ở trên, bên phải b. Thấp nhất ở bên trái dưới
  56. 56. Ai làm sprint demo 1. <Trao đổi> 2. Team? 3. PO?
  57. 57. Epic là gì? 1. Là một bộ các chức năng chia theo “chủ đề” (epic) 2. Epic quá to, dài 3. Không gói gọn trong 1 sprint 4. Mà phải chia ra nhiều sprint khác nhau (theo chủ đề/epic)
  58. 58. Agile chỉ cho software thôi à? 1. Agile = Linh hoạt 2. Agile xuất phát từ phần mềm nhưng đã/đang được áp dụng rộng a. Tài chính/budgeting b. Sản xuất c. Thiết kế d. Xuất bản
  59. 59. Agile là phương pháp luận à? 1. Agile KHÔNG phải là một phương pháp luận (methodology) 2. “The Agile movement seeks alternatives to traditional project management. Agile approaches help teams respond to unpredictability through incremental, iterative work cadences and empirical feedback. Agilists propose alternatives to waterfall, or traditional sequential development.” 3. “Agile software development describes a set of principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams”
  60. 60. Scrum đem lại gì? Scrum is a useful framework to use if: You don’t know everything about the project at the outset. There is a risk that requirements may change throughout the project. There is the potential to realise value incrementally rather than simply at the end of the delivery. You are looking to engage the creative intelligence of the team involved in building the product. Using Scrum usually results in the following benefits: Earlier realisation of value Reduced risk of delivery Reduced cost of delivery Reduced waste in the development process Greater collaboration, engagement and motivation Improved quality of the final product and greater customer satisfaction Greater responsiveness Greater alignment between IT and business departments
  61. 61. Scrum Simulation Game
  62. 62. Teamwork Game 1. Nghe 2. Nhìn 3. Viết
  63. 63. Management 3.0 Org. Chart Game <Thực hành với game xây dựng nhóm theo phương pháp quản lý mới>
  64. 64. Trait of Software and IT Projects 1. Luôn thay đổi (theo nghiệp vụ, theo doanh nghiệp, vì yếu tố khách quan) 2. Mọi người nghĩ là software dễ thay đổi 3. Software mô phỏng một nghiệp vụ nào đó 4. Kiến trúc phần mềm tương tự cơ cấu tổ chức doanh nghiệp 5. Quản lý dự án phần mềm khó hơn các ngành khác (như xây dựng, sản xuất)
  65. 65. Non-Team Roles in Scrum 1. Stakeholders 2. SME 3. Parttime Members 4. Customers
  66. 66. The Twelve Principles of Agile Software Development
  67. 67. Plan Driven vs Agile 1. Plan Driven a. Lên master plan rồi cứ thế mà làm theo b. Không cãi, không phải biện, không đổi plan c. Hướng kế hoạch d. Top-down e. Ít uyển chuyển, khó thay đổi 2. Agile a. Đặt milestone chính b. Có làm Planning activity nhưng không chú trọng master plan c. Không làm up front plan d. Luôn watch xem có sự thay đổi nào không để thay đổi plan theo e. Plan theo từng sprint f. Plan từng chút một (từng sprint) g. Hạn chế thay đổi, chèn task mới trong từng giai đoạn (sprint)
  68. 68. Team Forming Stages
  69. 69. Transition of (Traditional) Roles to Agile 1. Product Managers 2. Project Managers 3. Testers 4. Developers 5. System Designer 6. Q&A 7. Graphics Designer 8. Sysadmin
  70. 70. Servant Leadership / Management Transition
  71. 71. Toward an Agile Organization
  72. 72. Trait of Agile/Scrum Development Team
  73. 73. Who is an SM?
  74. 74. Who Owns the Product Backlog? 1. Cả team chịu trách nhiệm thêm việc vào Product backlog 2. Thường thì PO chịu trách nhiệm chính với product backlog 3. Những yêu cầu chức năng (nhiều nhất trong các loại công việc): Thường PO thêm vào 4. Một số việc khác trong backlog a. SM: Cải tiến quy trình, update team ground rules, nhật nhẹt, team building activities, training plan, seminars b. Developers: Refactor code, improve workflow, update design documents, learn CI/CD and apply 5. Lưu ý: a. Product backlog = backlog của cả sản phẩm b. Sprint backlog = công việc của TEAM trong sprint đó
  75. 75. Who Owns the Sprint Backlog? 1. The Team :) 2. Sprint backlog != Product Backlog
  76. 76. Sprint Review 1. Làm vào cuối sprint 2. Xem 10-day Scrum timeframe (Mitch Lacey) 3. Team show đã làm được gì trong sprint vừa quà 4. Team demo các features đã làm (cho PO) 5. Informal meeting 6. Ai tham gia: team, SM, PO, người liên quan, quản lý, người dự án khác 7. Sprint goal: Có hoàn thành không?
  77. 77. Sprint Retrospective 1. Nhìn lại sprint vừa qua 2. Hướng tới cải tiến 3. Tập trung vào cải tiến quy trình làm việc 4. Một số cách làm Retro a. KPT i. Keep (điểm tốt, giữ lại: cần phát huy), P: Problem (issue), T: Try thử nghiệm b. Good things, bad things, actions (for bad things). Xem lại “action list" một vài tuần một lần c. Những gì chúng ta đã làm tốt nhất? Làm sao để làm tốt hơn? (áp dụng cho matured team) d. Một số phương án khác: Đọc sách
  78. 78. 14-day Scrum Timeframe (Mitch Lacey)
  79. 79. Potentially Shippable Product 1. Sản phẩm có thể ship được 2. Một thuật ngữ đặt thù trong Scrum 3. PO quyết định ship hay không, hay bỏ một phần chức năng, hoặc làm lại 4. Ship theo lộ trình nào 5. Nhóm developers tập trung vào việc phát triển 6. PO quyết định release (hoặc không) 7. Luôn sẵn sàng ship
  80. 80. MVP: Minimum Viable Product 1. MVP = Sản phẩm tối thiếu (nhỏ nhất) có thể đưa ra thị trường 2. MVP hoàn thành trong sprint 0? hay sprint -1? 3. MVP release vào lúc nào? 4. Lộ trình tiến tới MVP (cần mấy sprints?, làm gì?) 5. Lộ trình sau MVP (product backlog: to & nhỏ, cần làm gì…)
  81. 81. Distributed Scrum
  82. 82. Issues with Distributed Scrum
  83. 83. Scaled Agile with SAFe
  84. 84. Remoted Working Scrum Team 1. Hạn chế a. Timezone b. Face-to-face meeting c. Culture/language 2. Xử lý a. Viết ra mọi thứ b. Instant messaging c. Tự động hoá (mọi thứ) d. Thỉnh thoảng họp online (skype: voice)
  85. 85. Offshoring with Scrum 1. Một số mô hình offshoring a. Việt - Nhật (tiếng Nhật) b. Việt - Mỹ (tiếng Anh) 2. Rào cản a. Ngôn ngữ, văn hoá b. Địa lý c. Timezone 3. Công cụ a. Online, collaboration tools b. Communication: Skype (voice), slack/chatwork (instant messeging) c. Task management: Jira, backlog, trello 4. Scrum events a. Daily meeting: Skype, daily report (written) b. Retrospective: Offshore and onsite teams c. Demo: Skype screen sharing, TeamViewer 5. Team structures a. Only ONE offshore developement team b. More than ONE offshore/remote development teams 6. Where are PO, SM, dev team (Where they live)
  86. 86. Spike 1. Việc có tính nghiên cứu 2. Một số người không nhận thức được sự tồn tại của spike 3. Phải time-boxed 4. Output của spike? a. Kết quả nghiên cứu b. Kết quả đánh giá c. Yes or No 5. Để làm việc A cần research tính khả thi. Đó là spike.
  87. 87. Pair Programming 1. Một thực hành của XP 2. Rất khó làm 3. Tốn thời gian 4. Cần thực hành nhiều 5. Thích hợp cho việc chuyển giao a. Kinh nghiệm b. Kiến thức 6. Một số dạng pairing a. Người mới + người mới? b. Người mới + người cũ c. Người cũ + người cũ (tham gia 2 phần module khác nhau)
  88. 88. TDD: Test Driven Development 1. Một thực hành của XP 2. Rất khó làm a. Kỹ thuật thực hành không dễ b. Con người khó thay đổi c. Cần thời gian (gấp x2, x3 so với phát triển phi TDD) 3. Thích hợp với dự án nhiều thời gian 4. Thích hợp với team thuần thục 5. Cần người có năng lực, kiên nhẫn, chịu khó thay đổi cách làm
  89. 89. XP (eXtreme Programming) Overview 1. Roles 2. Core Values 3. XP Practices 4.
  90. 90. CI: Continuous Integration 1. Tích hợp là gì? 2. Tích hợp liên tục là gì? 3. Vì sao cần tích hợp liên tục? 4. Ai làm? 5. Tích hợp cái gì? a. Source code b. Design c. Business
  91. 91. From CI to CD 1. Lịch sử CI/CD a. Jenkins b. TeamCity c. Bamboo/Atlassian 2. I/D a. Integration b. Delivery 3. CI a. Tích hợp liên tục b. “is the process of eliciting fast, automated feedback on the correctness of your application every time there is a change to the code.” 4. CD a. Deliver liên tục b. “builds upon the earlier concept by providing fast, automated feedback on the correctness and production readiness of your application every time there is a change to code, infrastructure, or configuration.”
  92. 92. Incremental (Technical) Design 1. Scrum không phủ nhận tài liệu, thiết kế 2. Chức năng khó, phức tạp: Cần design 3. Improve, tiến hoá tài liệu design từng chút một 4. Xem thêm a. Kaizen b. Lean c. Domain-Driven Design d. Thiết kế với UML
  93. 93. Source Code Refactoring 1. Công cụ = ? a. Tự động b. Thủ công c. Meeting d. Cross-review 2. IDE = (phpstorm, Eclipse IDE, IntelliJ IDEA) 3. Làm lúc nào? 4. Những ai tham gia (dev) a. Người trong, ngoài dự án 5. Review bằng git based management tool a. Jira b. Redmine (source code review plugin)
  94. 94. Refactoring Everything (=Kaizen) 1. Refactor code (cơ bản) 2. Refactor mọi thứ khác a. Thiết kế b. Mô hình kinh doanh c. Quy trình d. Tools 3. Tư tưởng Kaizen a. Từng tí một b. Chậm nhưng mà chắc
  95. 95. Time-boxed Iteration 1. Trong Scrum, interation = sprint 2. Sprint là fixed 3. Thường là 2 tuần 4. Nhịp, không (tuỳ tiện) thay đổi
  96. 96. Scrum Heartbeats
  97. 97. KPIs and Metrics in Scrum 1. Burndown 2. Burnup 3. TEAM Velocity 4. Quality Delivered to Customers = Customers' satisfaction 5. Actual Stories Completed vs. Committed Stories a. For every sprints
  98. 98. Best Communication Methods 1. Game/Gaminifcation 2. Face-to-face communication 3. Written communication
  99. 99. Tech Team Culture Based on Agile 1. Văn hoá dựa trên các nguyên tắc giá trị của Agile a. Minh bạch b. Liên chức năng 2. Văn hoá dựa trên Agile toolchain a. CI b. CD c. Pair programming d. TDD e. TiDD
  100. 100. Scrum: Low and High Quality 1. Short Term a. Slow b. But quality may not be as good as expected 2. Long Term a. Faster b. Stable c. (Stable &) better Quality d. (By the natures of Scrum)
  101. 101. Empiricism: Chủ nghĩa thực nghiệm <Trao đổi + thảo luận> Suy nghĩ từ Agile/Scrum
  102. 102. Simple Design 1. Làm hay không làm Design 2. Thế nào là design đủ (tốt)
  103. 103. Scrum Marketing <Trao đổi + thảo luận> Áp dụng Agile/Scrum/Kanban trong Marketing
  104. 104. Cone of Uncertainty
  105. 105. Ralph Stacey Certainty Matrix
  106. 106. Defined Approach (aka Waterfall) Explained & Their Hurdles <Áp dụng cho mô hình Waterfall thuần tuý> 1. Model là fixed: Requirements, Analysis, Design, Coding, Operation 2. Khách hàng, người thiết kế không hiểu được những có khăn trong tương lai khi làm tiểu quy trình đầu (như yêu cầu, phân tích, thiết kế…) 3. Khó thay đổi để đáp ứng sự thay đổi 4. Cái giá cho sự thay đổi là cao
  107. 107. Empirical Approach (Agile-ish) - How to learn - Kids learn how to ride a bicycle - Satir Change Model
  108. 108. Richness (temperature) of Communication Channel 1. Best: 2 on Whiteboard 2. Worst: Paper
  109. 109. Pareto Principles & Agile 1. Pareto/Prioritize your Product backlog 2. Prioritize your sprint backlog 3. 20% most important first, every sprint 4. Priority-driven 5. Ship when 20% is done
  110. 110. Importance of Transparency in Agile 1. Một trong 3 trụ cột của Agile 2. Chia sẻ tin xấu + tốt 3. Cộng tác với nhau
  111. 111. Case Study #1: Sprint termination <Trao đổi> Team làm được một số việc, sau 2 tuần, vứt đi, có phí hay không?
  112. 112. Case Study #2 / Workshop <Trao đổi + bài tập> UEFA Cup Champions League
  113. 113. Case Study #3 / Workshop <Trao đổi + bài tập> ChampTix - Build a Project Backlog
  114. 114. MVP 1. MVP = Minimum Marketable Feature Set 2. Sprint mấy thì tạo ra được MVP? 3. Lộ trình, kế hoạch cho tới khi tạo ra MVP 4. Sau khi có MVP thì team làm gì?
  115. 115. Levels of Planning 1. Planning thi thông tin ít 2. Plan khi nhiều thông tin 3. Cone of uncertainty 4. PO planning: Định tính 5. Developer planning a. Trong một sprint b. Deadline là trong sprint đó c. Có thể quy ra giờ d. Map theo ngày (ngày nào dự kiến xong?)
  116. 116. Planning Ownership 1. <Trao đổi> 2. Ai chịu trách nhiệm planning? a. Cả team? b. PO? c. Team members? d. SM? 3. Vào thời điểm nào thì planning? 4. Planning cái gì?
  117. 117. Reporting in Scrum 1. Daily report 2. Weekly report 3. Kanban (physical or eletronic) 4. Take a photo of kanban 5. Sprint demo/retro output
  118. 118. Project Work Types - Stories - Spikes - Taxes - Technical Debts
  119. 119. Abnormal Sprint Termination 1. Có thể dừng 2. Bỏ hết 3. Team đi làm việc khác 4. Lý do a. Khách quan/Chủ quan b. Chất lượng kém c. Thay đổi chiến lược d. Thị trường thay đổi
  120. 120. Estimate Reference Story Task 1. Estimate Reference Story Task / Story with point = 1 2. Lấy đó là story/point tiêu chuẩn 3. So sánh các story sau với story tiêu chuẩn này 4. So sánh point giữa các sprint (sprint N vs. sprint N + X) 5. So sánh point giữa dự án A và B: Có ý nghĩa không?
  121. 121. Determine Team Capacity - Per day - Per week - Per sprint & Velocity
  122. 122. Nhịp (Cadence) in Scrum 1. Nhịp theo ngày 2. Nhip theo sprint 3. Nhịp theo tuần, quý, năm 4. Timeframe của sprint 5. Sự quan trọng của nhịp (team)
  123. 123. 5 Qualities of Good/Bad Scrum Masters 5 Qualities of a Good Scrum Master 1. Servant leader 2. Coach 3. (Scrum) Framework champion 4. Problem Solver 5. Facilitator 5 Qualities of a Bad Scrum Master: 1. Boss 2. Taskmaster 3. Product Manager 4. Apathy 5. Performance Reviewer Questions: How it applies to Kanban or Lean? Do we need Scrummaster(-ish) position for Kanban or Lean?
  124. 124. Books
  125. 125. BASIC ADVANCED Scrum Framework Nguyễn Vũ Hưng 2016/12/26
  126. 126. Agile/Scrum Resources ● Scrum Alliance ● InfoQ Scrum ● Dzone Agile ● Nguyễn Vũ Hưng's blog ● Nexus Framework ● The Scrum Field Guide: Agile Advice for Your First Year and Beyond (2nd Edition) ● Scrum Alliance ● Scrum.org
  127. 127. References 1. Scrum Guide 2016 main points 2. Dương Trọng Tấn: a. Giới thiệu Scrum b. Scrum Method c. Làm việc tốt hơn với Scrum d. Agile, Scrum &? e. Scrum - a tool to achieve agility f. Agile mindset g. Nói chuyện/Giới thiệu Agile 3. Mitch Lacey 4. https://manifesto.co.uk/frequently-asked-questions-in-scrum/ 5. https://www.tutorialspoint.com/scrum/scrum_faqs.htm 6. https://dzone.com/articles/scrum-faq

×