Kanban Introduction

1. Kanban
Kulawat Wongsaroj
kulawat@proteus-agility.com
1

2. ปอม
• ทำ software มำนำน คิดว่ำเกิน 10 ปี
• อยูกบอไจล์มำ 6 ปี กว่ำ
่ ั
• ร่วมก่อตัง้ Agile66.com
• ทำมำทังบริ ษัทเล็กใหญ่ในนอก
้
• ปั จจุบน CEO & อไจล์โคช
ั
Beta in July
We are hiring!
proteus-agility.com
2

3. บุฟเฟต์อไจล์
1. เขียน User Story ไว้ ใน Backlog
2. Dev ให้ High Level Estimate กับ story
3. Product Owner เรี ยง story ใส่ Release (6w-6m) เรี ยงตำม
priority
4. Product Owner จับ story ที่เรี ยงไว้ ใส่ time-box (2w-4w)
5. จบ time-box ทีมก็ภมิใจนำเสนอ demo ให้ Product Owner
ู
6. นับ estimate ของ story ที่ทำเสร็ จใน time-box มำรวมกันได้
velocity (XP)
7. จัด retrospective มองย้ อนเพื่อ inspect & adapt
8. วนไปเรื่ อย
3

4. บุฟเฟต์อไจล์
• ส่วนใหญ่จะเป็ น Scrum กับ XP หรือผสมกัน
• Crystal, FDD, DSDM ก็มีแต่ไม่แพร่หลำยนัก
• ส่วนใหญ่ก็จะเริ่มจำกไปลงเรี ยน Certified Scrum Master
• มักจะใช้ User Story ของ XP
• Scrum ดังเดิม Sprint ละ 4 สัปดำห์ ตอนนี ้เหลือ 2
้
• ตบท้ ำย Iteration ด้ วย reflection/retrospective
session ของ Crystal/DSDM
• บำงทีมจะใช้ Story Mapping ช่วยเรื่ อง requirement
4

5. ลดขนาด
• story เล็กๆ อำนวยควำมสะดวก
– estimate ง่ำย
– plan ง่ำย ใส่ลง iteration สะดวก
– เวลำยัดไม่ลง split ออกเป็ นหลำย story ก็ได้
• story เล็กๆทำชีวิตลำบำก
– backlog เต็มไปด้ วยสิ่งเล็กๆที่เรี ยกว่ำ story ตำลำย เรี ยงยุ่ง จัดยำก
– ต้ องคิดเยอะตังแต่แรกเพรำะต้ องแตก story
้
– แตกแล้ วก็ตำมตำม track ด้ วยว่ำมำจำกไหนกันบ้ ำง
– แต่ก่อนโน้ น Kent Beck บอกว่ำ story นึงให้ 1-5 สัปดำห์ เดี๋ยวนี ้ 2-3 วัน
5

6. ลดเวลา
• time-box สันๆ อำนวย ควำมสะดวก
้
– plan ได้ เร็ ว ไม่กี่ชวโมงก็พอเพียง
ั่
– รับ feedback เร็ ว ปรับตัวเร็ ซ
• time-box สันทำชีวิตลำบำก
้
– ไม่ทนคุย requirement รู้เรื่ อง ก็ต้องลุยแล้ ว จะเตรี ยมทำก่อนยังไงก็กระทบ
ั
iteration ก่อนหน้ ำนี่อยูดี
่
– test ไม่ทนก่อนจบ iteration พอเจอ bug ช้ ำก็ไปกวนงำน iteration หน้ ำ
ั
– cycle time ล่อไปสำม iteration เพื่อทำ requirement, code และ test
& bug fix อย่ำงละ iteration
– product owner และ tester หัวปั่ นกับทังงำนเก่ำและงำนใหม่
่ ้
– เครี ยดเลย ไม่สนุกแล้ ว
6

7. เคยเจอมา @บริ ษทใหญ่แห่งหนึ่ง
ั
PRODUCT DEV DEV
MANAGER OPS/
+ INFRA
UX TEST
? ?
7

8. ผูรู้ Agile หลายท่านเริ่ มนา Lean มาใช้
้
• นำร่องโดยศำสดำ Tom & Mary Poppendieck กับ Lean
Software Development
• แพร่หลำยในวงกว้ ำงจำก Kanban ของ David Anderson
– kan (คัม) แปลว่ำ สัญญำณ
– ban (บัง) แปลว่ำ ปำย
้
– kanban เป็ นเครื่ องมือใน Toyota Product System (TPS)
– Kanban (k ตัวใหญ่) เป็ น software process ที่นำเอำหลักกำรของ
Lean มำใช้ ในกำรทำ software โดยใช้ kanban (k ตัวเล็ก) pull
system, visualization และอื่นๆ
8

9. ความเข้าใจที่คลาดเคลื่อนเกี่ยวกับ Kanban
• Kanban เอำมำเทียบกับ Scrum ไม่ได้ คนละเรื่ อง เพรำะ
Scrum เป็ น process แต่ Kanban เป็ นแค่ board ?
– kanban board เป็ น board ใช่ แต่นนไม่ใช่ Kanban
ั่
• Kanban เหมำะกับ Software Maintenance เท่ำนัน
้
– Kanban เหมำะกับ maintenance มำก แต่ Kanban ตอนนี ้ได้ รับ
กำรนำไปใช้ ใน software project ขนำดใหญ่ ทำ product ใหม่ๆ
อย่ำงกว้ ำงขวำง
9

10. Toyota Production System (TPS)
• สมมุติวำคุณเป็ นคนติดตังประตู Prius มีประตูกองอยู่ 10 กว่ำบำน
่ ้
• ติดไป กองก็เตี ้ยลง พอเหลือ 5 บำน ก็เจอกระดำษ (kanban) แปะอยูเ่ ขียนว่ำ
“สังประตูเพิ่ม 10 บำน”
่
• คุณหยิบกระดำษนันไปส่งให้ ช่ำงทำประตู ซึงรอคุณอยูแล้ ว
้ ่ ่
• เขำไม่ได้ รอคุณอยูเ่ ฉยๆ เขำทำอย่ำงอื่นไปด้ วย (อำจจะเป็ นประตู Camry) แต่สิ่ง
สำคัญคือ เขำไม่ได้ ทำประตู Prius
• จนกระทังเขำได้ ใบสังนี ้จำกคุณ เขำจึงเริ่ มทำประตู Prius
่ ่
• คุณกลับไปประจำที่และเริ่ มติดตังประตูตอ
้ ่
• ในจังหวะที่ประตูในกองของคุณกำลังจะหมด ช่ำงทำประตูก็เอำประตูใหม่ 10 บำน
มำให้ คณ เท่ าที่จาเป็ น ในเวลาที่จาเป็ น (Just In Time)
ุ
• ทุกอย่ำงลื่ นไหลไปอย่ำงรำบรื่ นอย่ำงอัศจรรย์
10

11. Toyota Production System (TPS)
• บัตร Kanban นี ้ทำหน้ ำที่จำกัดไม่ให้ Toyota ผลิตประตู Prius
มำเก็บไว้ ใน inventory โดยไม่จำเป็ น ทำให้ ไม่เกิด waste
• ในตัวอย่ำงสมมุตินี ้ ประตูจะไม่กองสูงเกิน 15 บำน
• Lean เรี ยกงำนที่อยู่ระหว่ำงกำรผลิต Work-In-Progress
(WIP)
• Story ที่ยงอยู่ระหว่ำงกำร develop ก็คือ WIP ใน Kanban
ั
• Kanban เน้ นให้ จำกัด WIP ไม่ให้ มำกเกินไป ให้ เกิดควำมลื่นไหล
อย่ำงอัศจรรย์
11

12. Kanban ดูเหมือนไม่ใช่ Agile?
• Kanban ไม่มี time-box development
• story ใหญ่กว่ำและมีน้อยกว่ำ
• estimate มีก็ได้ ไม่มีก็ได้
• velocity ไม่ใช้ มำดู cycle time แทน
มีข้อไหนขัดกับ Agile Manifesto?
12

13. Visualize Workflow
13

14. Explicit Policy - ทาข้อตกลงให้โจ๋ งครึ่ ม
“จะย้ ำย card จำก In Dev ไป Read To
Test ได้ ก่อต่อเมื่อ unit test ผ่ำนหมด,
test coverage ไม่ลดลงจำกเดิม และ
check in เข้ ำ branch แล้ วเท่ำนัน”้
14

15. Minimal Marketable Feature
• story ต้ องเป็ น MMF
• ให้ ตงคำถำมว่ำจะประกำศ feature นี ้ หน้ ำเวปของ product
ั้
หรื อไม่
15

16. Limit WIP
• WIP ของระบบ = ทุกคน / 2
• Column WIP = ทุกคนใน column / 2
– บังคับให้ ทำงำนร่วมกัน
– อำจปรับเป็ น / 1.5
• ลองดูแล้ วปรับไป
• Limit จะทำให้ เห็น คอขวด
16

17. การจากัดงานทาให้ได้งานเพิ่มขึ้น!
ถนนมีรถวิ่ง 30% ถนนมีรถวิ่ง 60% ถนนมีรถวิ่ง 95%
• ควำมเร็วเฉลี่ย 100 กม/ชม • ควำมเร็วเฉลี่ย 100 กม/ชม • ควำมเร็วเฉลี่ย 30 กม/ชม
• รถวิงผ่ำน 40 คัน/ชม
่ • รถวิงผ่ำน 80 คัน/ชม
่ • รถวิงผ่ำน 70 คัน/ชม
่
ไม่ได้ เผื่อควำมไม่แน่นอน เช่น รถเสีย รถวิ่งช้ ำ รถเปลี่ยนเลน ตำรวจตังด่ำน
้
ไม่ได้ เผื่อควำมไม่แน่นอน เช่น ลูกค้ ำเปลี่ยนใจ เวอร์ ชนใหม่ไม่รองรับ หลุด!
ั่
http://agileconsulting.blogspot.com/2011/07/explaining-why-limiting-wip-is-so.html
17

18. Limit WIP
http://agileconsulting.blogspot.com/2011/07/explaining-why-limiting-wip-is-so.html
18

19. วัด Cycle Time
Estimate ไม่ใช่สิ่งจำเป็ นอีกต่อไป!
19

20. ไร้ iteration ไม่ไร้ Rhythm
• Daily Stand-Up – กำร์ ดไหนจะย้ ำยไปไหน คอขวดเป็ นไงบ้ ำง
• Retro – สำมอำทิตย์ที หรือแล้ วแต่ -> ปรับปรุงระบบอยู่ตลอด
• Demo – สองอำทิตย์หน หรื อแล้ วแต่
• Prioritization - เป็ นพักๆ
20

21. ลดแรงต้านการเปลี่ยนแปลง
Kanban เน้ นให้ เริ่ มจำกกำรเปลี่ ยนแปลงน้ อยที่สุดจำกสิ่งที่มีอยู่แล้ ว
อำจเริ่มเพียง
• ทำให้ เห็นภำพกำรไหลของงำน – Visualize Workflow
• จำกัดงำนที่กำลังทำ – Limit WIP
• ทำข้ อตกลงให้ โจ๋งครึ่ม – Make Policy Explicit
• ช่วยกันปรับปรุง – Improve Collaboratively
21

22. Kanban ห่อ Scrum
PRODUCT
MANAGER OPS/
+ INFRA
UX
22

23. Scrum vs Kanban War
@Alshalloway
• Interesting thing about the Scrum vs Kanban is
many people had trouble with scrum found
kanban to work. Not other way. Some like to
ignore this.
• Other thing is that those in the scrum camp who
diss kanban have not done it, let alone be
newbies. Most KB leaders are experts in scrum.
• When an expert in two methods tells you 1 works
in some situations another doesn’t, the right
question is WHY, not don’t compare
http://www.theagilerevolution.com/episode-18-scrum-vs-kanban-war
23

24. References
• เกือบทังหมดเอำมำจำก
้
http://www.agileproductdesign.com/blog/200
9/kanban_over_simplified.html
• อยำกลอง Kanban จริง ควรอ่ำนเล่มนี ้ก่อน
24