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/