Kanban: Cơ bản và Nâng cao

5,981 views

Published on

Kanban: Cơ bản và Nâng cao

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
5,981
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Kanban: Cơ bản và Nâng cao

  1. 1. Basic(and advanced) 看板/Kanban Nguyễn Vũ Hưng Hà Nội, 2016/11/21
  2. 2. Situation #1: Kanban: Next Moves from Scrum Summary/Tổng kết Bài viết sau nói về lý do, cách tiến hành chuyển đổi khung làm việc từ Scrum sang Kanban đối với dự án phát triển sản phẩm ở thời điểm có tính quyết định: Mọi chức năng chính, có giá trị cao, bắt buộc mà khách hàng yêu cầu đã được hoàn thành (gần) hết.
  3. 3. Dự án phát triển dịch vụ S đã đi hết 9 sprint, mỗi sprint 2 tuần. Sau thời gian này, nhóm dự án, đã hoàn thành hết những chức năng (story) có giá trị cao mà khách hàng yêu cầu bắt buộc phải có. Tại thời điểm này, những story đem lại giá trị về mặt chức năng (khá lớn) đã gần như biến mất hết khỏi backlog. Cũng trong thời gian của cả 9 sprint, nhóm phát triển thực hiện Agile testing (gối đầu) và nhận được một số feedback ở dạng change request, improvement, lỗi… thường ở dạng tác vụ (task) không quá lớn hay những story bổ sung (nhỏ) được tích tụ dần trong backlog qua các buổi demo với khách hàng và kiểm thử nội bộ trong đội phát triển. Ở thời điểm này, nhóm đã đạt được độ thuần thục nhất định, có thể tự quản lý mà không cần nhiều sự giúp đỡ từ ScrumMaster hay người quản lý khác. Dự định tiếp theo được thống nhất giữa khách hàng, chủ sản phẩm và nhóm phát triển quyết định những mốc quan trọng tiếp theo của dự án: 1. Kiểm thử và hoàn thiện trong vòng 2 tới 4 tuần, 2. Sử dụng thử nghiệm quy mô nhỏ ở phía khách hàng (test driver, field test) trong vòng 2 tới 4 tuần, 3. Triển khai thực tế diện rộng ở phía khách hàng, 4. Sau đó, việc thêm mới chức năng, sửa lỗi, bảo trì sản phẩm sẽ diễn ra liên tục (cho tới khi dừng dịch vụ). Từ thời điểm này trở đi, tùy thuộc vào tình hình kinh doanh, tổ chức… nhóm dự kiến không có những thay đổi, yêu cầu lớn từ khách hàng một cách đột ngột. Nhóm quyết định sử dụng Kanban thay vì Scrum kể từ thời điểm chuyển tiếp này. Lý do và các điểm cần lưu ý được trình bày trong các phần sau. Tình huống/The Situation
  4. 4. Nhịp Phát triển/Development Cadence Nhịp phát triển mới là liên tục thay vì nhịp sprint 2 tuần. Nhịp Phát hành/Release Cycle Nhịp phát hành mới là liên tục thay vì nhịp demo/phát hành 2 tuần cuối mỗi sprint. Sự thay đổi về nhịp bắt nguồn từ nhu cầu thực tế là các tác vụ và story trong backlog đều không lớn. Một số lỗi cần sửa và đưa ngay lên máy production (quy trình xử lý hotfix) Vai Trò trong Nhóm/Team Members’ Roles Do nhóm đã tự quản tốt hơn và thuần thục hơn, chỉ cần chỉ định các vị trí “dàn hàng ngang” có tên “thành viên nhóm” có vai trò ngang nhau, tốt nhất là liên chức năng có thể bổ sung, thay thế lẫn nhau. Các vai trò chủ sản phẩm, ScrumMaster (có thể) không cần thiết, hoặc thu hẹp về dạng bán thời gian, chỉ xuất hiện hỗ trợ khi thực sự cần thiết. Chi tiết Thay đổi/Details of Changes
  5. 5. Đo Metrics/Metrics Velocity (tốc độ) – bao nhiêu điểm (point) nhóm “ăn” (burn) được trong một sprint là metric chính trong khung làm việc Scrum. Khi chuyển đổi sang Kanban, nhịp (phát hành), có thể tính bằng ngày hay thời gian thực là yếu tố đo trở nên không quá quan trọng. Với Kanban, chúng ta làm nhanh, tập trung vào làm sao cho xong việc chứ không tự bó hẹp mình trong khung thời gian của sprint (và đợi). Với Kanban, nhịp có thể chuyển thành ngày (24h) hoặc 2 ngày (48h) (khuyến nghị), hay liên tục. Quan Điểm về Quản lý Thay đổi/Change Management Approaches Kanban khuyến khích thay đổi, giống Scrum, theo triết lý Agile. Nhưng, sự thay đổi ở Kanban được hiểu là nhỏ và nhanh. Những (yêu cầu) thay đổi được khuyến khích và đưa thẳng vào hàng đợi (cột TODO) và chuyển dần sang cột DOING dựa trên sự đồng thuận về thứ tự ưu tiên giữa nhóm và khách hàng. Mỗi tác vụ đều được đăng ký bằng một ticket (issue) trên Jira. Trên bảng trắng vật lý (kanban) dán một thẻ ghi số của ticket này và mô tả ngắn gọn nếu cần. Họp Scrum/Scrum Events Các cuộc họp Scrum được giảm thiểu bằng chỉ daily standup. Các sự kiện lên kế hoạch đầu sprint, grooming giữa sprint và review, retrospective cuối sprint được hủy (nếu rất cần thiết và rất muốn, nhóm có thể thực hiện). Nhóm tổ chức họp theo mục đích cụ thể khi cần thiết. (không khuyến khích) Chi tiết Thay đổi/Details of Changes (2)
  6. 6. Giá trị, nguyên tắc chính của Kanban như sau: Giới hạn Công việc/Limit WIP Trong một thời điểm, Kanban giới hạn lượng công việc đang làm (WIP: Work in Progress) tối thiểu và tối đa một người làm. Số lượng tác vụ tối thiểu là một (cho một người): Lúc nào thành viên cũng có việc để làm. Số lượng tác vụ tối đa là ba (nhóm có 3 lập trình viên): Đừng nhiều quá, đừng ít quá. Chi tiết Thay đổi/Details of Changes (2)
  7. 7. 1. Giúp thành viên tập trung, 2. Giảm thiểu thời gian chuyển đổi giữa các việc (task switching và multi tasking), 3. Tránh trình trạng nhiều tác vụ làm đồng thời nhưng bị “treo” – không “done” (trọn vẹn), 4. Người tiếp theo (ví dụ, kiểm thử, bởi tester) không phải đợi quá lâu, không bị tồn tác vụ hay quá tải bởi đầu vào (input) từ công đoạn trước (ví dụ, việc lập trình, bởi lập trình). Limit WIP có lợi ích gì?
  8. 8. 1. TPS: Toyota Production Systems, 2. Pull/push uyển chuyển, 3. Cải tiến liên tục (continuous improvement). Hãy thử hình dung tốc độ phát triển tăng 3% (rất nhỏ) sau mỗi cycle 2 tuần. Sau 1 năm (24 cycle), tốc độ phát triển tăng với con số kỳ diệu: 200%. Tìm hiểu thêm: 1. Khái niệm pull, push trong Kanban và TPS. Triết lý phía sau Limit WIP là gì?
  9. 9. Điều này không mới với nhóm đã sử dụng Jira Agile board. Thực ra, bảng (かんばん, whiteboard) trong Kanban đơn giản (một cách có chủ đích) hơn rất nhiều so với bảng trong Scrum. Ở dạng đơn giản nhất, luồng công việc chia làm ba cột: Todo (sắp làm), Doing (đang làm) và Done (đã hoàn thành) Tùy theo nghiệp vụ và nhu cầu công việc, việc thêm cột là có thể, nhưng lưu ý không quá phức tạp. Ví dụ: 1.Todo, Doing, Verify (Kiểm tra), Done 2.Phân tích, thiết kế, lập trình, kiểm thử, triển khai 3.Thiết kế, lập trình, staging, production (server) 4.… Làm Rõ Luồng Công việc/Workflow Visualization
  10. 10. So sánh giữa Scrum, Scrumban và Kanban. Mong các bạn comment và đóng góp ý kiến. Câu hỏi Mở/Open Questions
  11. 11. 1. Scrum và Kanban đều tuyệt vời. 2. Sử dụng đúng công cụ đúng thời điểm là lựa chọn đôi khi khó. 3. Agile khuyến khích sự đơn giản và cả Scrum, Kanban đều tuân theo nguyên tắc này. Kết luận/Conclusions
  12. 12. Situation #2 Áp dụng kanban cho nhóm này ra sao các bác nhỉ? - Nhóm có 5 - 6 người (là 1 team, trong một công ty) - Có loại công việc dạng routine, hàng ngày, mỗi ngày 2 lần, đều làm việc đó (kiểm tra dữ liêu), nếu có lỗi thì báo, sửa, nếu không lỗi thì bỏ qua - Nhiều công việc dạng phát triển (phần mềm) - Nhiều công việc dạng vận hành, bảo trì (hệ thống IT, website), - Nhiều việc dạng support khách hàng - Lượng việc nhiều, loại việc nhiều - Công việc đa dạng - Team cân hết
  13. 13. Time-to-Answer 1. What is this? 2. How to measure 3. Actions after measuring
  14. 14. Time-to-Fix 1. What is this? 2. How to measure 3. Actions after measuring
  15. 15. Time-to-Production 1. What is this? 2. How to measure 3. Actions after measuring
  16. 16. Waittime (&their causes) 1. What is this? 2. How to measure 3. Actions after measuring
  17. 17. Normal Kanban Flow & WIP (&simulation)
  18. 18. Kanban for Cross-functional team 1. Team chúng ta hiện là cross-functional 2. Và nên tiếp tục là cross-functional 3. Nâng cao, đào tạo năng lực/team 4. Backup được cho nhau 5. “Lợi hại" hơn 6. Ai cũng làm được task của người khác? 7. Khi có team member ốm/nghỉ: Xử lý sao? 8. Chuyển task chéo giữa member: Nếu overload, không làm được. Mục đích: Xử lý task thật nhanh, giao nộp khách hàng
  19. 19. Lead Time in Kanban
  20. 20. Urgency-Driven Kanban 1. Level of urgencies a. TBD: Which levels? b. Name them? 2. Where to put most urgent tasks?
  21. 21. Time-Driven Kanban 1. Bao giờ phải giao hàng? 2. Cái nào trước/sau? 3. Ai làm? Lúc nào? 4. Người đó có available không? 5. Theo dõi hàng ngày/tuần
  22. 22. Priority-Driven Kanban 1. Where to put them? 2. Order of handling prioritized tasks from top 3. Rules 4. Exceptions?
  23. 23. Problem Solving Steps by Steps 1. Define the problem 2. Generate alternative solutions 3. Evaluate and select an alternative 4. Implement and follow up on the solution 5. Bài học: “steps" chính là workflow trong kanban
  24. 24. Sub-Processes 1. TODO a. Big b. Small 2. Analyze a. Doing b. Done 3. In Process a. Doing b. Done 4. Verify 5. Done
  25. 25. Sub-Processes (Software Development) 1. Ideas 2. Requirements 3. Design 4. Implementation 5. Test
  26. 26. Sub-Processes (Testing) Trao đổi/thảo luận: 1. ... 2. ... 3. ... 4. ... 5. ...
  27. 27. Bug/Tasks’ Life Cycle Về vòng đời của lỗi: - Lập trình viên *không* được close hay set progress của bug là 100% :) - Chỉ tester, test lead, team lead, project manager đặt bug progress là 100% # Thông thường, tester nào report lỗi sẽ verify đúng lỗi đó - Khi fix xong, PG *tự* verify thì sẽ set bug's progress (tối đa) là 80% - Bug life cycle + Tester report lỗi. Assign cho programmer + PG confirm lỗi. Nếu không reproducable -> return lại cho programmer + PG fix, re-assign lại issue cho tester + Tester confirm bug đã fixed và close. Nếu không, return lại cho programmer
  28. 28. Created vs Resolved (Jira) 1. What is this? 2. How to measure a. With gitlab? 3. Actions after measuring
  29. 29. Kanban with Trello 1. Business based 2. High-level 3. With customers 4. Meeting agendas based on Trello Kanban
  30. 30. Cumulative flow diagram (Jira)
  31. 31. Situation #3: Program management with Kanban 1. Program board 2. Project board 3. Sub-project board
  32. 32. Limit Mix 1. Task: 20% 2. Bugs: 10% 3. Change Requests: 20% 4. New Features: 40% 5. Contigency/Training: 10%
  33. 33. Kanban for Support Team 1. Inquiries 2. Q&A 3. Analyze
  34. 34. Knowledge Sharing (off the board) 1. Wiki 2. Blogs 3. Meetings 4. (Internal/External) seminars/meetups 5. Retrospectives/Kaizen
  35. 35. Transparency (Tính minh bạch) 1. Là một trong những nguyên tắc cơ bản của Agile/Scrum/Kanban 2. Xử lý với những task nhạy cảm ra sao? a. Quản lý không? b. Quản lý ở đâu c. Mức độ chia sẻ thông tin thế nào?
  36. 36. Planning with Kanban 1. Monthly: Long-term 2. Weekly: Mid-term 3. Daily: Detail
  37. 37. Forecasting with Kanban 1. Forecast theo ngày 2. Forecast theo tuần 3. Forecast theo tháng 4. Những task về sales 5. Tuần/tháng tới: Liệu có dự án nào về 6. Nhân sự/task: Đủ không? Có ai overload không?
  38. 38. Limit Team Activities 1. Avatar 2. Smileys 3. “I am free!” 4. “I reached my limit"
  39. 39. Issue Management with Kanban 1. “I have a problem" 2. “I’ve been stuck for 3 days" 3. A lane for “issues" or 4. Issues as tickets
  40. 40. Lean principles 1. Eliminate waste (lãng phí) 2. Amplify learning 3. Decide as late as possible 4. Deliver as fast as possible 5. Empower the team 6. Build integrity in 7. See the whole
  41. 41. Waste (lãng phí) 1. Partially done work (làm dở dang) 2. Extra processes (quy trình thừa) 3. Extra features (chức năng thừa) 4. Task switching (không tập trung) 5. Waiting (đợi) 6. Motion (di chuyển) 7. Defects (lỗi) 8. Management activities (việc quản lý)
  42. 42. Kanban Board Simulation: kanbansim.org 1. WIP 2. Cycle Time 3. Lead Time 4. Simulation
  43. 43. Coloring Kanban Phân loại công việc theo màu của ticket 1. Một màu cho một dự án 2. Xanh = user story 3. Đỏ = effect 4. Operation task = da cam 5. x = vàng 6. y = đỏ 7. k - hồng
  44. 44. Kanban vs. Scrum
  45. 45. Scrum prescribes roles, Kanban doesn’t 1.
  46. 46. Scrum prescribes time-boxed iterations 1.
  47. 47. Scrum backlog items must fit in a sprint 1.
  48. 48. Both limit WIP in different ways 1.
  49. 49. Scrumban = Transition from Scrum to Kanban 1. Iteration: Ý tưởng từ Scrum (sprint) 2. On-demand planning: Khi nào cần thì lên kế hoạch 3. Prioritization: Trên/dưới, trái/phải 4. Bucket size planning: Tương tự big size user story estimation/planning 5. Scrumkan (board): Tương tự kanban board 6. Scrumban team: Không có role cụ thể
  50. 50. Toyota Kanban (centeral storage) (196x)
  51. 51. Toyota Production Lines 1. Giống, khác nhau gì? 2. Liên hệ với Kanban? 3. Quy trình; tự động hoá; tiêu quy trình
  52. 52. Personal Kanban 1. Dành cho cá nhân 2. Của riêng tôi 3. Kanban cho gia đình 4. Kanban cho trẻ (kids) 5. Bảng trắng (vật lý) hay bảng điện tử (app)
  53. 53. Electronics Kanban Trello JIRA Agile Kanban LeanKit Team Foundation
  54. 54. References 1. http://www.kanbansim.org/ 2. http://www.slideshare.net/GiulioRoggero/how-a-kanban-board-works 3. http://labs.septeni-technology.jp/agile/kanban-next-moves-from-scrum/

×