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

Basic(and advanced) 看板/Kanban
Nguyễn Vũ Hưng
Hà 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), 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

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 measure
3. Actions after measuring

Time-to-Fix
1. What is this?
2. How to measure

Time-to-Production
1. What is this?
2. How to measure

Waittime (&their causes)
1. What is this?
2. How to measure

Normal Kanban Flow & WIP (&simulation)

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

Urgency-Driven Kanban
1. Level of urgencies
a. 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 top
3. Rules
4. Exceptions?

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

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

Sub-Processes (Software Development)
1. Ideas
2. Requirements
3. Design
4. Implementation
5. Test

Sub-Processes (Testing)
Trao đổi/thảo luận:
1. ...
2. ...
3. ...
4. ...
5. ...

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

Created vs Resolved (Jira)
1. What is this?
2. How to measure
a. With gitlab?

Kanban with Trello
1. Business based
2. High-level
3. With customers
4. Meeting agendas based on Trello Kanban

Cumulative flow diagram (Jira)

Situation #3: Program management with Kanban
1. Program board
2. Project board
3. 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. Inquiries
2. Q&A
3. Analyze

Knowledge Sharing
(off the board)
1. Wiki
2. Blogs
3. Meetings
4. (Internal/External) seminars/meetups
5. 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/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?

Planning with Kanban
1. Monthly: Long-term
2. Weekly: Mid-term
3. Daily: Detail

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?

Limit Team Activities
1. Avatar
2. Smileys
3. “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 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

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. WIP
2. Cycle Time
3. Lead Time
4. 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ự án
2. Xanh = user story
3. Đỏ = effect
4. Operation task = da cam
5. x = vàng
6. y = đỏ
7. k - hồng

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 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ể

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â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)

Electronics Kanban
Trello JIRA Agile Kanban LeanKit
Team Foundation

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/

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

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Kanban: Cơ bản và Nâng cao (20)

More from Vu Hung Nguyen (20)

Recently uploaded (20)

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