kanban: cơ bản và nâng cao
TRANSCRIPT
Basic (and advanced) 看板/Kanban
Nguyễn Vũ HưngHà Nội, 2016/11/21
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.
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
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
Đ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)
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)
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ì?
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ì?
Đ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), Done2.Phân tích, thiết kế, lập trình, kiểm thử, triển khai3.Thiết kế, lập trình, staging, production (server)4.…
Làm Rõ Luồng Công việc/Workflow Visualization
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
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
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
Time-to-Answer
1. What is this?2. How to measure3. Actions after measuring
Time-to-Fix
1. What is this?2. How to measure3. Actions after measuring
Time-to-Production
1. What is this?2. How to measure3. Actions after measuring
Waittime (&their causes)
1. What is this?2. How to measure3. Actions after measuring
Normal Kanban Flow & WIP (&simulation)
Kanban for Cross-functional team
1. Team chúng ta hiện là cross-functional2. Và nên tiếp tục là cross-functional3. Nâng cao, đào tạo năng lực/team4. Backup được cho nhau5. “Lợi hại" hơn6. 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
Lead Time in Kanban
Urgency-Driven Kanban
1. Level of urgenciesa. TBD: Which levels?b. Name them?
2. Where to put most urgent tasks?
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
Priority-Driven Kanban
1. Where to put them?2. Order of handling prioritized tasks from top3. Rules4. Exceptions?
Problem Solving Steps by Steps
1. Define the problem2. Generate alternative solutions3. Evaluate and select an alternative4. Implement and follow up on the solution5. Bài học: “steps" chính là workflow trong kanban
Sub-Processes
1. TODOa. Bigb. Small
2. Analyzea. Doingb. Done
3. In Processa. Doingb. Done
4. Verify5. Done
Sub-Processes (Software Development)
1. Ideas2. Requirements3. Design4. Implementation5. Test
Sub-Processes (Testing)
Trao đổi/thảo luận:
1. ...2. ...3. ...4. ...5. ...
Bug/Tasks’ Life CycleVề 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
Created vs Resolved (Jira)
1. What is this?2. How to measure
a. With gitlab?
3. Actions after measuring
Kanban with Trello
1. Business based2. High-level3. With customers4. Meeting agendas based on Trello Kanban
Cumulative flow diagram (Jira)
Situation #3: Program management with Kanban
1. Program board2. Project board3. Sub-project board
Limit Mix
1. Task: 20%2. Bugs: 10%3. Change Requests: 20%4. New Features: 40%5. Contigency/Training: 10%
Kanban for Support Team
1. Inquiries2. Q&A3. Analyze
Knowledge Sharing
(off the board)
1. Wiki2. Blogs3. Meetings4. (Internal/External) seminars/meetups5. Retrospectives/Kaizen
Transparency (Tính minh bạch)
1. Là một trong những nguyên tắc cơ bản của Agile/Scrum/Kanban2. Xử lý với những task nhạy cảm ra sao?
a. Quản lý không? b. Quản lý ở đâuc. Mức độ chia sẻ thông tin thế nào?
Planning with Kanban
1. Monthly: Long-term 2. Weekly: Mid-term3. Daily: Detail
Forecasting with Kanban
1. Forecast theo ngày2. Forecast theo tuần3. Forecast theo tháng 4. Những task về sales5. 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?
Limit Team Activities
1. Avatar2. Smileys3. “I am free!”4. “I reached my limit"
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
Lean principles
1. Eliminate waste (lãng phí)2. Amplify learning3. Decide as late as possible4. Deliver as fast as possible5. Empower the team6. Build integrity in7. See the whole
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ý)
Kanban Board Simulation: kanbansim.org
1. WIP2. Cycle Time3. Lead Time4. Simulation
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ự án2. Xanh = user story3. Đỏ = effect4. Operation task = da cam5. x = vàng6. y = đỏ7. k - hồng
Kanban vs. Scrum
Scrum prescribes roles, Kanban doesn’t
1.
Scrum prescribes time-boxed iterations
1.
Scrum backlog items must fit in a sprint
1.
Both limit WIP in different ways
1.
Scrumban = Transition from Scrum to Kanban1. Iteration: Ý tưởng từ Scrum (sprint)2. On-demand planning: Khi nào cần thì lên kế hoạch3. Prioritization: Trên/dưới, trái/phải4. Bucket size planning: Tương tự big size user story estimation/planning5. Scrumkan (board): Tương tự kanban board6. Scrumban team: Không có role cụ thể
Toyota Kanban (centeral storage) (196x)
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
Personal Kanban
1. Dành cho cá nhân2. Của riêng tôi3. Kanban cho gia đình4. Kanban cho trẻ (kids)5. Bảng trắng (vật lý) hay bảng điện tử
(app)
Electronics Kanban1. Trello
Trello JIRA Agile Kanban LeanKit
Team Foundation
References
1. http://www.kanbansim.org/2. http://www.slideshare.net/GiulioRoggero/how-a-kanban-board-works3. http://labs.septeni-technology.jp/agile/kanban-next-moves-from-scrum/