Kanban ที่มาเริ่มต้นมาจากระบบการทำงานของ Toyota ซึ่งประสบความสำเร็จอย่างมากจนทำให้สามารถผลิตรถออกมาได้ไวกว่าคู่แข่งทั่วโลกจนครองตลาดไปได้มาก สำหรับวงการ Software ได้ถูก David J. Anderson จับนำมาปรับปรุงให้เข้ากับ Software Development เพื่อการพัฒนา Software ได้อย่างรวดเร็วที่สุดด้วยเช่นกัน และสุดท้ายถูกนำไปเป็นส่วนหนึ่งของ Lean Software Development รวมไปถึงถูกจัดให้เป็น Agile อีกแบบหนึ่งนอกเหนือไปจาก Scrum อีกด้วย

Kanban มีกฎอยู่แค่ 3 ข้อ (Scrum มี 9)

1. Visualize the workflow – แสดง flow การทำงานของระบบให้ออกมาให้เห็นภาพอย่างชัดเจน สามารถบอกได้ว่าขณะนี้งานไปติดขัดที่จุดไหน อย่างไรให้ชัดเจน
2. Limit Work In Progress (WIP) – จุดหลักของ Kanban เลยคือการ limit งานต่อหนึ่งหน่วยย่อย เช่นงานสำหรับ Development ห้ามถือเกิน 2 งานเพื่อป้องกันไม่ให้งาน Overload มากเกินไป และจะทำให้สูญเสียเวลาไปมากกว่าที่ควรจะเป็น
3. Measure the lead time – วัดผลการทำงานและปรับปรุงให้ดียิ่งขึ้นไปอีก ตรงนี้จะเรียกว่า Cycle time หรือค่าเฉลี่ยที่ Card 1 อันจะอยู่บนบอร์ดตั้งแต่เริ่มต้นไปจนถึงขึ้นบน production จริง

ข้อดีของ Kanban

1. เหมาะกับการทำงานหลายๆ project พร้อมกันมากกว่า Scrum
2. เหมาะกับการทำงาน Maintain, Support ระบบแก้ bug ที่โผล่มาแบบปัจจุบันทันด่วนไปพร้อมๆ กับการพัฒนา feature มาก เพราะสามารถเปลี่ยนแปลงได้เกือบตลอดเวลา ไม่ต้องรอให้จบ sprint
3. เหมาะกับทีมงานที่มี Specialist อยู่ในทีม และต้องการการ share resource จาก specialist คนนี้พร้อมๆ กัน โดยที่ไม่ทำให้ specialist คนนี้มีงาน overload เกินไป
4. แน่นอน หากเป็นงาน backend, frontend แยกกันและไม่สามารถฝึกให้คนในทีมเขียนได้ทั้งสองอย่างพร้อมๆ กันได้ Kanban จะช่วยตรงจุดนี้ได้ในแง่การจัดการ flow เช่นงาน backend เสร็จแล้ว รอ frontend หยิบไปทำต่อ ในขณะที่ backend ก็ทำงานใหม่หลังจากส่งงานต่อให้ frontend แล้วทันที ทำให้ไม่มีการว่างงานเกิดขึ้น
5. หากงานใหญ่ไม่สามารถซอยให้เล็กลงได้แล้วจริงๆ ก็ไม่ใช่ปัญหาสำหรับ Kanban เพราะไม่มี sprint เป็นตัวจำกัดอีกแล้ว
6. เสริมสร้างความช่วยเหลือระหว่างคนในทีม เนื่องจากแค่มองบอร์ดจะรู้ทันทีว่าตอนนี้งานติดอยู่ที่ใครมากที่สุด (เป็น bottleneck ของ flow ในขณะนั้น) เพื่อนร่วมงานที่เหลือก็จะเข้าไปช่วยกัน เพื่อทำให้ bottleneck ของงานหายไปโดยเร็วที่สุด และสุดท้ายจะสามารถทำงานงาน flow ต่อไปได้ ทำให้งานโดยภาพรวมเสร็จสิ้นมากขึ้น
7. ช่วยแก้ปัญหา “ทำงานโน่นนิด นี่หน่อย เยอะมาก แต่ไม่เสร็จซักกะงาน” ได้เป็นอย่างดี ด้วย WIP

ตัวอย่าง Kanban Board

จากรูปจะเห็นว่า Selected มี (2) ต่อท้าย หมายถึงช่องนี้สามารถรับงานได้แค่ 2 งานเท่านั้น ห้ามยัดมามากกว่านี้ ส่วน Develop จะเป้น (3) ก็คือรับทำงานพร้อมกันไม่เกิน 3 งาน ส่วนของ Deploy ว่างอยู่ซึ่งสามารถดึง A (Done แล้ว) ไปทำต่อได้ และ Live! ก็คือขึ้นบน Production สำเร็จนั่นเอง 1 cycle time คือ card 1 ใบที่วิ่งผ่านตั้งแต่ selected ถึง live! ใช้เวลาทั้งหมดเท่าไรนั่นเอง

จริงๆ ยังมีรายละเอียดอีกมาก แต่ไปอ่านเพิ่มเติมได้ที่

http://www.infoq.com/minibooks/kanban-scrum-minibook

ปล. ขอบคุณพี่กรที่มาแบ่งปันเรื่อง Kanban ให้ผมและคนอื่นๆ รู้ครับ

ปล 2. Practice ต่างๆ อย่าง TDD, Pair Programming, Code Review, Retrospective, Standup Meeting ก็ยังหยิบมาใช้ได้ แค่ว่าจะไม่ fix ว่าต้องทำเมื่อไหร่ อาจ set ให้มีเฉพาะเวลาที่จำเป็นเท่านั้น ไม่ใช่ว่าห้ามทำ

• คุม Spec ให้นิ่ง Requirement ไม่เปลี่ยน (เป็นไปไม่ได้)
• กำหนดระยะเวลาเสร็จที่แน่นอนให้ได้ เพื่อจะได้เอาไปบอกลูกค้าได้ถูก (อันนี้ไม่ว่าจะ plan แบบไหนก็คือการเดาด้วยกันทั้งสิ้น)
• ถ้า Requirement เปลี่ยน ต้องแก้ให้ทันตามที่ลูกค้าต้องการ (ถ้ารับเละ ไม่ดูแรงของทีมงานก็ตายสถานเดียวครับ)

เป็นต้น ซึ่งถ้าทีมงานหรือบริษัทของคุณไม่ได้เป็นบริษัทขนาดใหญ่ (ทีม Programmer 1 ทีมใหญ่กว่า 3 คน) ก็คงไม่ค่อยเห็นภาพอะไรนัก เนื่องจากคนน้อย การบริหารจัดการก็คือการคุยกันเรื่อยๆ เป็นระยะๆ จะดีที่สุดนั่นเอง แต่แม้คนจะน้อย Agile ก็จะช่วยจัดการจัดสรรปันส่วนงานต่างๆ ให้เป็นระเบียบขึ้น ง่ายต่อการเห็นภาพรวมของ project มากขึ้น เรามาดูขั้นตอนการทำงานแบบ Agile กันดีกว่า โดยทีมงานจะแบ่งเป็นสองตำแหน่งหลักคือ Product Owner (คนที่คุยกับลูกค้า รู้ว่าลูกค้าต้องการอะไร) และ Programmer มีขั้นตอนทำงานดังนี้ (ผมจะเขียนเน้นไปทาง Practice ของ Scrum นะครับ แต่ขั้นตอนการสร้าง card จะคล้ายๆ กันหมด)

1. Product Owner ไปคุยกับลูกค้า แล้วมาขายฝันให้ทีมว่าจะมีโปรเจคนี้ๆ ลูกค้าอยากได้อะไรบ้าง โดยสมมติว่าลูกค้าอยากให้เราเขียนระบบ Forum ของเว็บไซต์ของเขา
2. Product Owner เขียนสรุป Requirement ออกมาเป็น User Story ในรูปแบบ Card 1 Story ต่อ 1 Card ซึ่งมี template ของ Story คือ ”As a <role>, I want <goal/desire>” เช่น “ในฐานะ guest ต้องดู forum ได้”, “ในฐานะ member ต้องตั้งกระทู้ใหม่ได้” ซึ่งการสร้างแต่ละ Story ควรจะรู้ด้วยว่าทำไปเพื่ออะไร (ไม่งั้นก็ทำฟรี ไม่มีประโยชน์) ตรงนี้ต้องระวังว่าห้ามเขียนเป็นรูปของ Task เช่น setup database, เขียน function a() ต้องเป็น story ที่ลูกค้าอ่านเข้าใจ และถ้าเสร็จออกมาให้ทดลองใช้แล้วลูกค้าจะได้ประโยชน์อย่างชัดเจน (เช่นเขียนว่าระบบค้นหากระทู้ ไม่ใช่ function search)
3. เมื่อสรุปเสร็จทั้งหมด Product Owner ก็จะเรียงลำดับความสำคัญของ Feature ที่ลูกค้าอยากเห็นก่อน-หลัง ซึ่ง story ไหนที่เป็นฐานในการทำ Story ถัดไปควรจะมาก่อน Story ที่ต้องต่อยอดจาก story นั้นๆ รวมไปถึง Feature ที่มีโอกาสเปลี่ยนแปลงสูงก็ควรจะอยู่หลังๆ ด้วย (เผื่อลูกค้าเปลี่ยนใจจะได้เสียหายน้อยที่สุด)
4. แต่ละ Story Product Owner จะต้องเขียน Exit Criteria เพื่อสรุปว่าจากหน้าจอของผู้ใช้ที่เกี่ยวข้องกับ story นี้ เช่น คลิกปุ่มที่หนึ่งจะต้องไปหน้าไหน search ชื่อได้, search topic ได้, ถ้าไม่พิมพ์เลยต้องแสดง error เป็นต้น ทั้งหมดนี้แยกมาเป็นข้อๆ ซึ่งสำหรับโปรแกรมเมอร์แล้วจะเหมือนได้ Test Case มาโดยอัตโนมัติเอาไปทำ TDD ต่อได้ง่ายขึ้นมากเลยทีเดียว (มีคนคิดมาให้แล้วนั่นเอง) แต่ถ้า story ไหนยังไม่แน่นอน เผื่อเปลี่ยนทีหลังก็ยังไม่ต้องเขียน Exit Criteria (ในที่นี่สมมติว่า Product Owner คือ Tester ในคนเดียวกันนะครับ)
5. นำ Story Card ที่พร้อมแล้วมาวางเรียงบนโต๊ะ ประชุมร่วมกับทีม Programmer ว่าแต่ละหัวข้อควรจะให้คะแนนความยาก (Story Point) เท่าไหร่ดี โดยมีคะแนนตั้งแต่ 1,2,3,5,8,13,… เป็น Fibbonanci ซึ่งทุกคนจะโหวตแต่ละ Card พร้อมกันว่าได้เท่าไหร่ โดยอาศัยการเปรียบเทียบกันเองระหว่าง story ที่วางอยู่ด้วยกัน ซึ่งจะทำได้ง่ายกว่าประมาณด้วยเวลามาก (แต่ละคนไม่มีทางประมาณเวลาที่ใช้ทำออกมาได้ตรงกันหรอก จริงไหม? แต่ถ้าเป็นการเทียบความยากกันเอง จะได้ข้อสรุปง่ายกว่ามาก) แล้วมาดูกันว่าคะแนนต่างกันมากไหม หากแต่ละคนให้คะแนนต่างกันมากก็ต้องคุยกันว่าทำไมจึงให้แบบนั้น (เป็นสัญญาณว่าเกิดความเข้าใจไม่ตรงกันของคนในทีม รีบทำความเข้าใจให้ตรงกันซะ!) แล้วโหวตใหม่ จนกว่าจะได้คะแนนเท่ากันหมด ขั้นตอนนี้เรียกว่า Planning Poker ครับ ตรงนี้ Story Point ไม่ใช่เวลาที่จะทำเสร็จนะครับ มันคือค่าความยาก(หรือความเสี่ยง) ของงานแต่ละอย่าง ยิ่งเลขมาก จะยิ่งยากขึ้นมากตาม ซึ่งถ้าเลขเยอะมากๆ ควรจะแตก Story ออกให้เล็กลงเป็น Card 2 ใบครับ และแน่นอนว่าควรแตกเฉพาะอันที่ Requirement ไม่เปลี่ยนแน่ๆ แล้ว
6. นำ Story Point ของ Card ทั้งหมดมาบวกรวมกันก็จะได้ค่าความยากของ Project นี้ ทีนี้ละครับเราก็จะได้ Estimate ของเวลาการทำงานออกมาแล้ว โดยเทียบกับ project เก่าๆ เอาเช่น project a มี story point 30, project b มี story point 50 project b น่าจะใช้เวลาทำนานกว่าแน่ๆ และจากค่าเฉลี่ยของการทำงานที่ผ่านมา ทีมของเราทำงานได้ 5 point ต่อ 1 สัปดาห์ ดังนั้นน่าจะใช้เวลาใน project b ทั้งสิ้น 10 สัปดาห์ (ต้องไม่ลืมว่าทั้งหมดนี้คือการเดาครับ 55 แต่เป็นการเดาแบบมีหลักการมากขึ้น) ซึ่งเวลานี้ต้องไม่ลืมว่ามันคือ Speed ของทีมที่ทำทีมเดียว ไม่สามารถสรุปได้ว่าอีกทีมเข้ามาทำจะใช้เวลาในการทำเท่ากัน
7. เริ่มแบ่งงานออกเป็นรอบๆ ซึ่งถ้าเป็น Scrum จะเรียกว่า Sprint ส่วนใหญ่จะอยู่ที่ 1-2 อาทิตย์ต่อ Sprint ถ้าเป็น Agile Practice อื่นก็จะแตกต่างกันไปว่าจะแบ่งรอบการทำงานเป็นอย่างไร โดย Story ที่ลูกค้ายังเอาแน่กับชีวิตไม่ได้ เราก็ทิ้งไว้ก่อนถูกไหมครับ(แต่เราขึ้น Story ไว้แล้ว ให้คะแนนเยอะเวอร์ๆ ไปก่อน) ซึ่งเราจะแตก Story ที่มี Story Point เยอะๆ ในงานรอบแรกๆ ก่อน ยังไม่ต้องทำทุก Story เพราะ เดี๋ยว Story หลังๆ ทำไปเดี๋ยวมันก็เปลี่ยน จะทำค่อยแตก Story ทีเดียวดีกว่า
8. ทีม Programmer ลงมือทำตาม Story Card โดยใครอยากหยิบอันไหนใน Sprint นั้นๆ มาทำก่อนก็ตามใจ หรือจะคุยกันเองว่าให้ Senior ทำอันยาก Junior ทำอันง่ายก็ว่ากันไป ย้าย Card จากช่อง Backlog ไปช่อง Doing พอทำเสร็จก็ย้าย Card จากช่อง Doing ไป Done เป็นต้น
9. สำคัญมากคือต้องคุยกันในทีมว่าก่อนจะย้ายเข้า Done นั้นคือต้องทำ อะไรเสร็จแล้ว (Definition of Done) เช่น ต้อง Test เสร็จก่อนถึงจะย้ายเข้า Done ถ้ายังไม่ Test ถือว่างานยังไม่เสร็จ ห้ามย้ายเข้า Done เด็ดขาด เป็นต้น
10. เมื่อทำจบหนึ่ง Sprint ก็มาลองวิเคราะห์กันดูในทีมว่าทำได้ตามเป้าไหม เกิด Bug ที่ไม่คาดคิดหรือไม่ แล้วจะ Weight อย่างไรระหว่าง Bug ที่เกิดกับงาน Story ในรอบถัดไปที่จ่อคิวอยู่ ตรงนี้ขึ้นกับการตัดสินใจของทีมแล้วครับ ถ้าเกิด Bug นั้นต้องแก้แน่ๆ และสำคัญมาก ทำให้ต้องเลื่อนเวลาการทำงานออกไป ทีมปั่นกันไม่ไหวแน่ๆ ก็ต้องบอกลูกค้าแต่เนิ่นๆ แต่ประชุมหาทางแก้ไขกับลูกค้าเจรจาขอตัด feature หรืออะไรก็ว่าไป ไม่ใช่วันสุดท้ายพึ่งมาบอก แบบนี้ลูกค้าจะเครียดได้ครับ 55
11. วนทำข้อ 8 ไปเรื่อยๆ จนงานเสร็จครับ

อันนี้จริงๆ แล้วถ้าเป็นการวางแผนทั่วๆ ไป คนมักจะวางแผนง่ายๆ ด้วยการ “เผื่อเวลาความไม่แน่นอน” เอาไว้ถูกไหมครับ ซึ่งมักจะเผื่อไว้ครั้งแรกครั้งเดียว แล้วก็มารู้ตัวอีกทีตอนใกล้จะปิดโปรเจคแล้วก็ปั่นไฟลนก้นกันสุดๆ ถ้าทำตามขั้นตอน Agile พวกนี้จะช่วยให้เราประเมินสถานการณ์บนพื้นฐานของความจริงอยู่ตลอดครับ หากเห็นว่าสถานการณ์กำลังแย่ ทำไม่ทันแน่ๆ เราก็จะได้หาทางวางแผนแก้ไขให้ทันท่วงที และเนื่องจากเราทำงานไล่ทำเป็น Story อยู่แล้ว หาก Story ท้ายๆ ไม่มีปัญญาปั่นให้เสร็จจริงๆ อย่างน้อยมันก็คือ Story ที่สำคัญน้อยที่สุดแล้ว ถูกไหมครับ (เราเรียงลำดับความสำคัญไว้แล้วนี่) ความเสียหายที่เกิดจะน้อยที่สุดครับ ดีกว่าทำไอนู่นเสร็จนิด ไอ้นี่เสร็จหน่อย แล้วประกอบออกมาเป็นโปรแกรมไม่สมประกอบ ใช้งานไม่ได้ซักอย่าง นั่นคือหายนะของ Project ที่ไม่ได้วางแผนครับ โชคดีกับการวางแผนการทำงานนะครับทุกคน

แถมท้ายเว็บดีๆ ที่ช่วยในการทำ Story Card ได้อย่างดีเยี่ยมครับ

http://www.trello.com

1. Driver – Navigator : เป็นการจับคู่โดยมี Driver เป็นผู้ลงมือ coding และ Navigator เป็นผู้ Review code และ planning สิ่งที่จะต้องทำต่อไป
2. Mouse-Keyboard : เป็นการจับคู่โดยมีคนหนึ่งจับ Mouse อีกคนจับ Keyboard เพื่อเป็นการเตือนสติว่า “อีกคนยังทำงานอยู่”
3. Ping-Pong : เป็นการจับคู่โดยมี Driver เป็นผู้ลงมือ coding และ Navigator เป็นผู้ Review code + ทำ Unit Test ของ code ส่วนนั้น

ประโยชน์

1. ช่วยเร่ง productivity ขึ้นเป็นประมาณ 1.6-1.8 เท่า (ไม่ถึง 2 เท่า) ในเวลาเท่าเดิม
2. ช่วยลดเปอร์เซ็นต์การเกิด bug ที่จะต้องตามแก้ทีหลัง(โดยเฉพาะอย่างยิ่ง bug โง่) ลงได้เป็นอย่างมาก
3. สร้างเสริมความสัมพันธ์ ความสามัคคีในองค์กร (Team work)
4. ลดเวลาการ training Novice ลงเนื่องจากใช้ในการทำงานจริงเลย
5. Novice จะมีความภาคภูมิใจที่ได้เป็นส่วนหนึ่งของการทำงานจริง และ code ของตัวเองได้ถูกนำไปใช้จริง ช่วยสร้างความฮึกเหิมและความมั่นใจได้ดี เพื่อส่งผลต่อการทำงาน และทัศนคติที่ดี ลดความกลัวที่จะทำพลาดลงในอนาคต
6. เป็นเจ้าของ code ทั้งคู่ ทำให้เมื่อต้องเปลี่ยนแปลงแก้ไขในอนาคต ให้ 1 ใน 2 คน ใครก็ได้เป็นคนแก้ (ถึงจะหายตัวไปคนก็ไม่เป็นไร)
7. ลดการ interrupt เช่นเล่น MSN, เล่นเกม ระหว่างการทำงาน ลงได้ เพราะต้องเกรงใจ partner ด้วย
8. ป้องกันการหลับของ partner ได้ง่าย (ใครหลับ อีกคนก็ตบหัวให้ตื่นได้)

หลักปฏิบัติทั่วไป

1. ควรสลับหน้าที่ระหว่าง Driver และ Navigator ทุกๆ 1 ชั่วโมงเพื่อไม่ให้ซ้ำซาก จำเจ เบื่อ แต่อาจสลับทุก 6-8 ชั่วโมงก็ได้ตามแต่ความเหมาะสม
2. ควรเปลี่ยน partner (คนที่จับคู่ทำ Pair) ทุกๆ iteration (ในงาน ผู้พูดกล่าวว่า 1 iteration ของที่รอยเตอร์มีความยาว 2 อาทิตย์)
3. เน้นการ Communication มากๆ ระหว่างคู่ จะต้องไม่มี Ego ต่อกัน ควรทำความตกลงเรื่องนิสัยส่วนตัวของแต่ละคนในขณะทำงาน ก่อนเริ่มใช้จริง เพื่อจะได้ไม่เกิดปัญหาภายหลัง
4. หาก Expert คู่กับ Novice ควรเลือก feature ที่ง่ายๆ มาทำ และ Expert จะต้องไม่ข่ม Novice โดยระหว่างที่ Novice เป็นคน code Expert ก็แนะนำสิ่งที่จะต้องทำทั่วไป แต่ระหว่างที่ Expert เป็นคน code Novice จะต้องคอยถาม Expert อยู่ตลอดว่าตรงนี้ทำเพื่ออะไร หรือตรงนั้นอ่าน code แล้วไม่เข้าใจ อ่านยาก Expert จะต้องไม่มี Ego และต้องยอมปรับ code แบ่งสัดส่วนให้ Novice อ่านรู้เรื่อง เพื่อเป็นการบ่งบอกว่า “code ส่วนนั้น อ่านง่ายสำหรับคนทั่วไป ไม่ซับซ้อน”
5. การจับคู่ทำงานใน 3-4 ครั้งแรกจะค่อนข้างทำงานได้ช้ากว่าแยกกันทำพอสมควร หลังจากนั้นไปแล้วจึงจะเห็นผลจากการจับคู่การทำงาน