ช่วงนี้เก๋ค่อนข้างสนใจเกี่ยวกับ agile แขนงอื่นๆ เช่น kanban เนื่องจากได้คำถามจากน้อง developer ที่ tarad.com มาด้วย น้องเค้าถามว่าที่เก๋พูดมาทั้งหมดนี้ต่างกับ kanban อย่างไร เก๋เลยเอาสิ่งที่เคยฟัง podcast ของ agile university และมีเรื่อง scrum vs. kanban ไปตอบน้องเค้าคร่าวๆ เท่าที่ทราบ จึงเริ่มอยากศึกษามากขึ้นละ
อันนี้สรุปมาจาก podcast นะคะ
| Scrum | Kanban |
| fixed time boxes– มีการกำหนดช่วงเวลาใน iteration ที่แน่นอน และมีการกำหนด/แบ่งแยก planning meeting และ demo and review meeting เห็นชัดเจน | no fixed time boxes–ไม่มีการกำหนดช่วงเวลาในแต่ละ iteration ใช้วิธีการแบบ increment boundaries จึงไม่มี fixed planning meeting หรือ fixed demo and review meeting |
| tasks & estimates–ดูว่ามีงานอะไรบ้าง และ estimate ออมาเพื่อดูสิ่งที่ต้องทำให้เสร็จภายใน time box ที่กำหนด | no tasks & estimates–หยิบงานมาเริ่มทำเลย |
| มีการ track velocity–เพื่อดูว่าในแต่ละ box เราควรจะทำงานได้เยอะแค่ไหน | มีการ track flow–เพื่อดู queues (มีอะไรรออยู่บ้าง), work in process(ทำอะไรอยู่) และ cycle time (ใช้เวลาทำนานเท่าไหร่) |
| scrum master เป็นเจ้าของ process–ทีมฟัง direction มาจาก scrum master เป็นหลัก | team เป็นเจ้าของ process–ไม่มีการกำหนด process ที่แน่นอน แต่ทีมมีการประเมินงานใน queue/WIP/cycle time แล้วค่อยดูว่าควรจะปรับปรุงและทำงานอย่างไรต่อไป |
| จะ delivery increment อย่างไร?? | จะ delivery flow ของ minimal marketable features อย่างไร?? |
ส่วนตัวไม่เคยทำ kanban เลย (ได้ข่าววงในว่าคุณ @korn4D ชำนาญมาก กำลังรออ่าน blog เหมือนกัน 
) และอยากจะเข้าใจด้วยว่ามันทำงานยังงัย และต่างกับ scrum อย่างไร และผลที่เห็นชัดในการใช้งาน kanban เป็นอย่างไร ใครมีอะไรมาช่วยแชร์กันหน่อยนะคะ จะได้ร่วมกันแบ่งปันความรู้ จะเขียนเป็น blog ใหม่ก็ได้แต่รบกวนลิงค์กลับมาแถวนี้ด้วยนะคะ คนที่มาอ่านใหม่จะได้ตามถูก 
ถ้าเขียนอะไรผิดไป ทักท้วงติติงส่งเสริมได้เลยนะคะ รออ่านอยู่ค่ะ
ต้องขอแก้ไว้ก่อน เพราะ เดี๋ยวคนอ่านหลายคนจะเข้าใจผิด
1. Kanban (อ่านว่า คัมบัง) ไม่ใช่ agile และเกิดก่อน agile หลายสิบปี (1948)
2. เรื่องที่เล่ามานั้น เป็นแนวคิดเรื่อง Agile-Kanban ซึ่งผมไม่เห็นด้วยเพราะ Kanban เป็นแค่เครื่องมือ ไม่ใช่ตัวเนื้อหา การเอามาใช้แต่เปลือกจะทำให้ เสียหายได้ (Individuals and interactions over processes and tools)
3. ที่ว่า ไม่มี time box นั้นไม่ถูก Kanban เองไม่มี time box เพราะ เป็นแค่เครื่องมือ ใน TPS ซึ่งเป็นตัวโปรเซส มี time box (และโหดมากด้วย อยากรู้ละเอียด ถ้ามีเพื่อนทำงานโรงงานโตโยต้า ลองถามว่า “เก็ตซึโดะ” คืออะไร จะรู้ชัด)
4. ไม่มี estimate อันนี้ไปคนละโลก TPS มีวิธีการวางแผนและวัดผลที่ ละเอียดมากกว่า agile หลายเท่านัก
5. เป้าหมายของ TPS อยู่ที่การสร้าง flow ก็จริง แต่ flow เป็นผลไม่ใช่เหตุ จึงไม่มีการ track flow เพราะไม่ช่วย TPS จะดูเรื่องของ Takt time เป็นหลัก ไม่พูดละเอียดดีกว่า เดี๋ยวสับสนไปกันใหญ่
ุ6. TPS ยึดหลักการ PDCA ของ Deming กระบวนการทุกชนิดต้องเขียนเป็นขั้นตอนอย่างละเอียด การที่บอกว่าไม่มีการกำหนด process เป็นการบิดเบือนอย่างที่สุด
แนะนำว่าจะศึกษาเรื่องนี้อย่าอ่านหนังสือฝรั่งครับ เพราะฝรั่งตามหลังเราอยู่ คนไทยทำงานกับญี่ปุ่นมานานกว่าฝรั่ง และรู้เรื่องนี้ดีกว่า แต่ไม่ใช่สายซอฟแวร์เท่านั้นเอง หาอ่านเกี่ยวกับ TPS ก่อน ค่อยเข้าเรื่อง Kaizen Kanban เป็นแค่เปลือกครับ อยากเห็นของจริง ถ้าขับ toyota หรือ honda เวลาเอารถเข้าศูนย์ ลองนั่งสังเกตดูจะเห็น Kanban ของจริงครับ แต่อย่าไปถามนะ คนทำเค้าไม่รู้หรอก ว่าใช้โปรเซสระดับโลกอยู่ เค้ารู้แต่หน้าที่ตัวเองเท่านั้นเอง
เริ่มต้นอ่านเล่มนี้ก่อนก็ได้ อ่านสนุกเหมือนนิทาน
http://publishing.eisquare.com/index.php?page=shop.product_details&flypage=shop.flypage&product_id=298&category_id=10&option=com_virtuemart&Itemid=37&lang=en
ถ้าจะเอาแบบวิชาการต้องของ ดร. วิทยา ครับ ออกมาจะครบทุกเล่มแล้ว เริ่มอ่านอันนี้ครับ
http://www.prachasan.com/toyotaschool/toyotaway.html
อ่านแล้วจะรู้ว่า Agile ไม่ใช่ของใหม่เค้าคิดกันมาได้ตั้งแต่ก่อนสงครามโลกแล้ว ความจริง ถ้าจะนับย้อนไปได้ถึงสมัยพุทธกาลนั่นแหละ ถ้าตามงานเขียนของผมมาอย่าต่อเนื่องจะพอนึกออกว่าทำไม “พระพุทธเจ้าท่านใช้แนวทางของ Agile ในการเผยแผ่พุทธศาสนา” ไงล่ะ
ดังนั้นรบกวนอธิบายการทำงานของพี่ได้หรือเปล่าคะ นี่คือสิ่งที่อยากรู้ เพราะตอนนี้เป็นเหมือนกับรู้ว่าต่างกัน แต่ไม่ได้มองเห็นภาพเลยว่าต่างกันอย่างไร และยิ่งพี่บอกว่ามันมีแค่เปลือก ยิ่งอยากรู้มากยิ่งขึ้นค่ะ เพราะเก๋ฟังมาจาก podcast เก๋ก็เชื่อเค้าประมาณนึงเพราะเป็น agile university บอกมา ซึ่งเค้าเปรียบเทียบมาอย่างนั้นจริงๆ เก๋ก็เข้าใจจากในนั้นว่ามันคือ agile อีกแขนงหนึ่ง เท่าที่ดูใน agile66 ก็มีแต่คนมาบอก practice ของ scrum ทั้งนั้น ว่าทำงานจริงได้อย่างไร เก๋อยากเห็นของ kanban บ้างค่ะ รบกวนด้วยนะคะ
ระวังเรื่องการศึกษาให้ดี อ่านเรื่องนี้ละกัน
http://korn4d.wordpress.com/2010/06/09/dont-assume-just-ask
อย่ายึดติด กับระบบและโปรเซส ไม่งั้นอาจจะหลงทางได้ (ฺำเบ็นบอกว่า Agile เป็นทาง[ทางหนึ่งในหลายทาง] ไม่ใช่จุดหมายใช่หรือไม่)
Kanban เหมือนการนั่งสมาธิ มีพระบางองค์นั่งสมาธิแล้วบรรลุธรรม แต่การนั่งสมาธิไม่ใช่เหตุที่ท่านบรรลุธรรม เป็นแค่วิธิการปฏิบัติเท่านั้น เนื้อแท้อยู่ข้างในไม่ใช่ข้างนอก ท่านบรรลุเพราะเห็นธรรม ไม่ใช่เพราะนั่งสมาธิ
Scrum เหมือน ศีล 10; Lean เหมือนพระวินัย (ศีล 227) Scrum ยังไม่ถ่องแท้ ข้ามขั้นไปไม่ช่วยอะไร มีแต่สับสนไม่เข้าใจเท่านั้น ถ้ายังไม่ถึงจุดที่เข้าใจทั้งจุดดีและด้อยทั้งหมดของ Scrum อย่าไปไหนต่อ อยู่ที่นั่นก่อนเอาให้ลึกสุดแล้วค่อยเดินต่อ
ลองอ่าน สองเล่มข้างบนก่อน แล้วตอบให้ตัวเองให้ได้ว่า มันลบจุดอ่อนของ scrum ได้อย่างไร จึงค่อยเดินต่อ อย่างที่เคยบอกไปแล้ว ในตอนก่อนๆ Agile มาจาก Lean ซึ่งมาจาก Zen ซึ่งเป็นพุทธ
พุทธเน้นที่การ ปฏิับัติ ไม่ใช่ ความรู้ อย่าหาความรู้ เพราะมันไม่ใช่พุทธ รู้เท่าที่จำเป็นเพื่อการปฏิบัติก็พอ อย่าติดรู้ เพราะไม่ใช่ทาง
อธิบายเยอะเพราะคิดว่า น้องเก๋น่าจะหาทางเข้าใจมันได้ หลายคนผมอธิบายอย่างนี้ไม่ได้เพราะเขายังไม่พร้อม
เด๋วจะลองไปอ่านดูนะคะ ขอบคุณสำหรับลิงค์ที่ให้มาค่ะ
อ่อ พี่จะผิดหวังไหมถ้าเก๋บอกว่า ที่พี่อธิบายเก๋ก็ยังไม่ค่อยเข้าใจเพราะไม่มีความรู้เรื่องศีลต่างๆ ที่กล่าวมา เลยอ่ะค่ะ เลยคิดว่าเด๋วตามไปอ่านลิงค์ที่ให้มาก็ได้ค่ะ
เริ่มมีการนำ Kanban มาเปรียบเทียบกับ Scrum มากขึ้นเรื่อยๆใน context ของ “Tool” ใน Agile Community เพราะว่า Kanban นั้นแรง
ไปเจอหนังสือเล่มหนึ่งที่พูดถึงเรื่องนี้ได้อย่างดีเขียนโดย คำนำเขียนโดย Lean ตัวแม่ Mary Poppendieck และ Kanban ตัวพ่อ David Anderson (@agilemanager) และที่สำคัญคือโหลดได้ฟรีที่ http://www.infoq.com/minibooks/kanban-scrum-minibook
ยาวเหมือนกันแต่อ่านง่าย ผมก็อ่านไปได้แค่บทแรกๆ แต่รู้สึกได้ว่าคนเขียนกับ Korn4D พูดไว้คล้ายๆกันเลยอยากเอามาแนะนำ ลองดูนะครับ ผมขออนุญาติขี้เกียจไม่มาสรุปอะไรตรงนี้เพราะคิดว่ายังไม่ถ่องแท้พอ อยากเขียน blog อยู่เหมือนกันแต่มันยังไม่ตกผลึกพอ
คนเขียนคือ Henrik Kniberg & Mattias Skarin ครับ
ป้ากับลุงเขียน Forwards ให้แค่นั้นครับ
ขออภัยที่ไม่ได้เอ่ยชื่อคนเขียน มัวแต่อ้างคนเขียนคำนำ
ไม่แนะนำให้อ่านสำหรับ คนที่ยังไม่รู้จัก TPS อ่านแล้วเหมือน ส่งดาบให้โดยยังไม่เป็นกังฟู มันจะบาดมือเอาเท่านั้น อย่างที่บอก Kanban เป็น tool Scrum เป็น Process เอามา compare อย่างนี้มัน เหมือน compare ส้มกับแอปเปิล มัีนเทียบกันไม่ได้ กลายเป็นว่า ถ้าคุณควบคุมตัวเอง ใน iteration ไม่ได้ เพราะอะไรก็ตาม เอา Kanban มาใช้ดีกว่า เล่นเกมส์ turn base ยังคิดไม่ทันบอกให้เล่น real-time strategy ตายกันพอดี
ควรศึกษา TPS ให้เข้าใจ ต้องรู้จัก Just In Time และ Jidoka ให้เข้าใจก่อนว่า เป็นเสาหลักอย่างไร สามเอ็ม(Muri, Mura, Muda) มาจากไหน และทำให้เกิด ความสูญเปล่าทั้งเจ็ด ได้อย่างไร แล้วค่อยเริ่มปรับปรุงการทำงาน ด้วย Kaizen อาศัย สร้าง Respect และ Teamwork ด้วย หลัก Nemawashi หาต้นตอของปัญหาด้วย Genchi Genbutsu ทำอย่างต่อเนื่องไม่หยุดจนถึงระดับ Hansei ทั้งหมดต้องมาจากหลักปรัชญาทั้ง 14
ทั้งหมดไม่ต้องใช้ Kanban ซึ่งเป็นแค่ tool ตัวหนึ่งในระบบ Visual Control คือ ป้องกันไม่ให้ปัญหาหลบซ่อนอยู่ได้ ซึ่งนอกจาก Kanban ก็จะมี Andon, Poka-yoke (Autonomation), Supermarket เป็นต้น
โอยเหนือย!
เล่าให้ฟังอีกเรื่องหนึ่ง เมื่อตอนที่ รถญี่ปุ่นบุกตลาดอเมริกาจนเอาชนะ 3 ยักษ์แห่งดีทรอยต์ได้ ฝรั่งตกใจขอไปดูงาน แล้วเห็น Kanban นี่แหละ แล้วก็คิดว่า ญี่ปุ่นชนะเพราะ Kanban กลับบ้านไปตั้งหน้าตั้งตา copy ทำเป็น ระบบ คอมพิวเตอร์เลย เร็วกว่า ดีกว่า ต้องชนะ แน่ๆ แต่สุดท้ายก็เหลว เพราะไป copy ผิดจุด DNA ของ Lean ไม่ได้อยู่ที่กระดาน แต่อยู่ที่คน 555
ผมไม่คิดว่ามันร้ายแรงขนาดจะฟันมือตัวเองนะ อยู่ที่ว่าท่านจอมยุทธมีกำลังภายในในการทำความเข้าใจกับดาบที่ได้แค่ไหน ถ้ามีพื้น TPS แน่นก็จะแล่นปรื้ดแต่ถ้าไม่มีผมกลับคิดว่าอ่านแล้วอาจทำให้อยากไปศึกษา TPS ก็ได้ อ่านแล้วอาจจะนำบางอย่างมาปรับใช้กับ process ที่ทำอยู่ก็ได้ ถ้าเอาแต่ copy โดยไม่มีความเข้าใจก็คงจะฟันตัวเองแน่นอนแหล่ะ
เพิ่งไปซื้อมาอ่านครับ (the toyota way) ยังอ่านไม่จบ ติดใจที่ช่วงแรกการผลิตเป็นงานฝีมือ
ใช้คนที่มีความชำนาญสูงกลุ่มเล็กๆ แล้วสามารถเปลี่ยนเป็นการผลิตเชิงอุตสาหกรรม ที่สามารถจ้างใครมาประกอบก็ได้
ตอนนี้เรามองว่าการผลิตซอฟแวร์เป็นงานฝีมือ อาจเป็นเพราะแสดงว่าเราล้าหลังเค้า เพราะเรายังไม่มีกระบวนการที่ดีพอ
หรือมันอาจเป็นอย่างนี้จริงๆ ก็ได้ ซื่งถ้าเป็นเช่นนี้ก็คงยากที่เราจะหากระบวนการผลิตที่เชื่อถือได้แบบการผลิตรถยนต์
คงต้องรอใครซักคนมาปฏิวัติ
ปล. link อันนี้ก็โอนะ http://www.lib13.net/c-lean/
อย่าสับสนครับ สิ่งที่เกิดคือ ในช่วง 70-80 มีการถดถอยของเศรษฐกิจ สามยักษ์แห่งดีทรอยต์ lay off คนงานหลายหมื่นคน Toyota ลดเงินเดือนทุกคนเหลือหนึ่งในสาม โดยให้ผลัดกันนอนอยู่บ้าน เพราะมีงานไม่พอกับจำนวนคน ฝ่ายบริหารทำงานฟรีไม่เอาเงินเดือน พอหลังจากนั้นพอเศรษฐกิจเริ่มฟื้นตัว Toyota มีคนพร้อมไม่ต้องจ้างแล้วมาฝึกงานกันใหม่ กลับสู่ตลาดได้เร็วกว่าเจ้าอื่นถึง 6 เดือน แสดงให้เห็นว่าการผลิตก็เป็นงานฝีมือเหมือนกัน
สิ่งที่เหนือกว่านั้นแล้วก็หาศึกษายาก คือ วิชาที่เขาไม่ส่งออก ชื่อว่า TPDS “Toyota Product Development system” เขาเอามาให้เราแต่ภาคผลิต ภาคการออกแบบเขาเก็บไว้บ้านตัวเอง
จากประสบการณ์ทำระบบอีอาร์พีและได้เข้าไปคลุกคลีกับโรงงานผลิตหุ่นยนต์ แล้วได้มีโอกาศเข้าไปคุยกับผู้บริหาร หลังจากที่งานเฟสแรกเสร็จแบบไ่สนุกนักท่านแนะนำให้ไปอ่าน TPS เหมือนกันท่านบอกว่าสามารถนำมาประยุกต์กับการทำงานพัฒนาซอฟต์แวร์ได้ดีเลยทีเดียวเลยจริงๆผมไม่เคยศึกษา TPS เห็นแต่หนังสือ Toyota way พอมาเจอกระทู้นี้ ตรงเลยครับกับที่ผู้บริหารท่านอธิบายให้ฟังแรกๆไอ้เราก็ไม่ค่อยเข้าใจเท่าไหร่
กำลังจะทำ kanban แล้วมา search google เจอ blog ตัวเอง ตลกดี
อ่าน comment อีกครั้งแล้วแอบคันไม้คันมือ เลยขอ comment ด้วยซะหน่อย
ลองอ่านใหม่ที่เขียนไป จริงๆ เก๋ก็ยังมองความตั้งใจของตัวเอง เป็นพื้นฐานของ scrum vs. kanban นะคะ ไม่ได้ bias แต่อย่างใด (เก๋ไม่ได้เกลียด kanban นะคะขอออกตัว) และสิ่งที่เขียน ก็แค่ตัองการแชร์สิ่งที่ไปฟังมา เท่านั้นเองจริงๆ ค่ะ เพราะแหล่งที่ฟังมาก็น่าเชื่อถือ
ตอนนี้สิ่งแรกที่เพิ่งเริ่มทำไปก็คือ iteration ที่ไม่ได้เป็น fixed-time เพราะมันขึ้นกับสถานการณ์ ณ ตอนนั้น แต่ ณ เวลาตัวเก๋ยังไม่รู้ว่าเมื่อไหร่เราควรจะ extend iteration เมื่อไหร่ควรจะเริ่ม iteration ใหม่ เพราะเหมือนมันมาจากการตัดสินใจของคนให้ requirement และลูกค้า และยังไม่มีความรู้เกี่ยวกับการ pull งาน การวางแผน ว่าจะทำอย่างไรให้ effective จึงยังไม่เห็นอะไรชัดเจน แต่คาดว่าคงได้มีอะไรมาเล่าแน่ๆ
อย่าเพิ่ง panic กันนะคะ สิ่งที่เก๋เพิ่งพูดไปอาจจะยังไม่ใช่ kanban ที่ถูกต้อง บอกแล้วว่าเพิ่งเริ่มต้น และกำลังพยายาม เด๋วคนใหม่ๆ จะตกใจกลัวไปซะก่อน
สนับสนุน positive thinking นะคะ อยากให้มาแชร์กันมากกว่าเพื่อถกหาความรู้ ดีกว่าที่จะคิดกลัวว่าจะฟันมือตัวเอง หรือฟันมือคนอื่น 
เพราะผู้อ่านสื่อเองก็ควรมีวิจารณญาณในการอ่านด้วยเช่นกัน ไม่ควรตั้งใจจะเชื่อเพียงอย่างเดียว
หลงทางเข้ามา อ่านแล้วน่าสนใจดีครับ
ความคิดเห็นส่วนตัว
ถ้าเรื่องพัฒนาซอร์ฟแวร์ คิดว่า ไม่ควรเอาระบบคัมบังมาใช้หรอกครับ Pull System และ Concept ของ TPS หละก็ น่าจะใช้ได้ แต่คัมบัง ส่วนตัวแล้ว ใช้ไม่ได้
ใครทำซอร์ฟแวร์แล้วเอาคัมบังมาใช้ก็แย่เต็มทน
ลองอ่านเรื่องเกี่ยวกับ TPS Lean Servier ที่ไม่ใช่ Lean Manufacturing แล้วลองเทียบกับระบบเน็ตเวิร์ค เรื่อง Synchronous / Asynchronous เปรียบเทียบการไหลของงานกับการไหลของข้อมูล น่าจะช่วยได้นะครับ
ทีมที่บริษัท หากทำ maintenance ก็ใช้ Kanban หมดนะคะ ไม่ได้แย่เลย เหมาะสมด้วย
“ใครทำซอร์ฟแวร์แล้วเอาคัมบังมาใช้ก็แย่เต็มทน”
โลกแคบไปไหมครับ http://www.infoq.com/presentations/kanban-for-software