สถิติที่น่าสนใจ
Kanban ให้เมตริกหลักสองรายการเพื่อวัดประสิทธิภาพของทีมอย่างเป็นกลาง: เวลานำและรอบเวลา
เวลาดำเนินการคือเวลาจากช่วงเวลาที่งานเข้าสู่ช่วงเริ่มต้นจนถึงช่วงเวลาที่ออกจากช่วงสิ้นสุด เช่น ในตัวอย่างของเรา เป็นเวลาเดลต้าจากช่วงเวลาที่งานถูกป้อนในคอลัมน์งานระหว่างดำเนินการจนกระทั่ง ย้ายไปยังคอลัมน์ เสร็จสิ้น
การใช้ Kanban เพื่อปรับปรุงประสิทธิภาพการออกแบบด้านไอที ยังต้องจัดการเวลาดำเนินการเพื่อให้แน่ใจว่าคุณสมบัติจะถูกส่งตรงเวลา ทีมสามารถเพิ่มประสิทธิภาพระยะเวลารอคอยด้วยวิธีใดวิธีหนึ่งต่อไปนี้
แบ่งขั้นตอนออกเป็นขั้นตอนย่อยๆ
รวมขั้นตอนเล็ก ๆ หลาย ๆ ขั้นตอนเป็นหนึ่งเดียว
การทำงานอัตโนมัติผ่านสคริปต์
การเพิ่มแหล่งข้อมูลเพิ่มเติม เช่น โครงสร้างพื้นฐานด้านคอมพิวเตอร์
รอบการทดสอบ/ทบทวนเพิ่มเติมเพื่อจำกัดกิจกรรมของเสียในขั้นตอนต่อๆ ไป
ปัญหาหลักของการพัฒนาผลิตภัณฑ์ซอฟต์แวร์คือคุณลักษณะเดียวกันอาจซับซ้อนกว่าในด้านอื่น ตัวอย่างเช่น คุณลักษณะบางอย่างอาจนำไปใช้ได้ยากกว่าการทดสอบ และในทางกลับกัน สามารถควบคุมเวลาดำเนินการของฟังก์ชันดังกล่าวได้โดยแบ่งงานออกเป็นโดเมนที่เกี่ยวข้อง เมื่อดำเนินการดังกล่าว คุณต้องรวมจุดสิ้นสุดการรวมเพื่อให้แน่ใจว่าเมื่อดำเนินการฟังก์ชัน จะมีการรวมแต่ละโดเมนเข้ากับฟังก์ชันเต็มรูปแบบ
เมตริกอื่นคือรอบเวลา ซึ่งจะวัดว่างานนั้นเริ่มต้นจริงเมื่อใดและเสร็จสิ้นเมื่อใด นี่ไม่ใช่การวัดความพยายาม แต่เป็นการวัดระยะเวลาของวงจรในระบบ รอบเวลาคือเวลาที่ฟังก์ชันใช้ในการเดินทางจากจุดเริ่มต้นไปยังจุดสิ้นสุดของกระบวนการของคุณ ในขณะที่เวลาดำเนินการคือเวลาระหว่างเวลาที่ฟังก์ชันเข้าและออกจากกระบวนการของคุณ การคำนวณระยะเวลารอคอยสินค้าโดยเฉลี่ยและรอบเวลาช่วยให้คุณทราบขั้นตอนการทำงานของคุณ การเปรียบเทียบเวลางานโดยเฉลี่ยในขั้นตอนต่างๆ สามารถให้หลักฐานเชิงประจักษ์ว่ากระบวนการกำลังปรับปรุง
เมื่อรวบรวมชุดข้อมูลเชิงประจักษ์ที่เชื่อถือได้เกี่ยวกับเวลานำและรอบเวลาแล้ว ควรใช้กฎของ Little เพื่อคำนวณปริมาณงานของทีม: จำนวนลูกค้าเฉลี่ยระยะยาวในระบบที่เสถียร (L) เท่ากับค่าเฉลี่ยระยะยาว ความถี่การมาถึงที่มีประสิทธิภาพ (λ) คูณด้วยค่าเฉลี่ยของเวลาที่ลูกค้าใช้ในระบบ (W)
เรามาแสดงความคิดนี้ในเชิงพีชคณิตกัน:
L = λW
หรือในแง่ Kanban:
รอบเวลาเฉลี่ย = เวลางานเฉลี่ย / ปริมาณงานเฉลี่ย
เมื่อกระบวนการผ่านขั้นตอนการปรับแต่ง ปริมาณงานควรระบุว่าการเปลี่ยนแปลงนั้นปรับปรุงขั้นตอนการทำงานหรือไม่
การใช้หลักปฏิบัติและเมตริกที่อธิบายไว้ ทีมสามารถมองเห็นปัญหาต่อไปนี้ในเวิร์กโฟลว์ของตนได้:
ระบุปัญหาคอขวด
ระบุพื้นที่ "เบรก" ของเวิร์กโฟลว์
ระบุพื้นที่สำหรับการปรับปรุงการไหล
กฎการควบคุมโฟลว์ขึ้นอยู่กับข้อเท็จจริงที่ว่ากระบวนการทั้งหมดต้องได้รับการทบทวนอย่างต่อเนื่องเพื่อหาวิธีทำให้ทีมของคุณมีประสิทธิภาพและประสิทธิผลมากขึ้น กล่าวอีกนัยหนึ่ง กุญแจสำคัญคือการค้นหาและกำจัดกิจกรรมที่สิ้นเปลืองในกระบวนการของคุณ
สำหรับทีมพัฒนา ขอแนะนำว่าก่อนที่จะเริ่มกระบวนการ Kanban ในโครงการ ผู้เข้าร่วมโครงการทุกคนมีแนวคิดที่ชัดเจนเกี่ยวกับภาพรวมของโครงการ พื้นที่ความรู้ด้านการออกแบบควรประกอบด้วยชุดของคุณลักษณะลำดับความสำคัญที่จะนำไปใช้ และวิสัยทัศน์ทางสถาปัตยกรรมเบื้องต้นว่าคุณลักษณะทั้งหมดจะทำงานร่วมกันอย่างไร เพื่อให้ชัดเจน มุมมองทางสถาปัตยกรรมนี้ควรครอบคลุมทุกส่วนของระบบ รวมถึงแต่ไม่จำกัดเฉพาะการออกแบบ การทดสอบ การออกแบบทางกายภาพ และซอฟต์แวร์ ตามความเหมาะสม ด้วยข้อมูลเชิงลึกนี้ ในขณะที่โครงการพัฒนาขึ้น ทีมสามารถให้คำแนะนำเกี่ยวกับวิธีการพัฒนาคุณลักษณะที่พึ่งพาซึ่งกันและกันได้ สิ่งนี้ช่วยลดโอกาสในการทำงานซ้ำเนื่องจากการประกอบที่ไม่ถูกต้อง
การออกแบบไอทีและ Kanban เน้นการขจัดความสูญเสีย
องค์ประกอบสำคัญของการผลิตแบบ Kanban และ Lean คือการมุ่งเน้นที่การกำจัดของเสีย ในสภาพแวดล้อมการออกแบบ ของเสียมักเกิดจากกิจกรรมที่สิ้นเปลือง เช่น
1) ทำเกินความจำเป็น
ตำแหน่ง "คุณสมบัตินี้จะมีประโยชน์ในสักวันหนึ่ง มาเพิ่มกันเถอะ" เป็นสิ่งที่ยอมรับไม่ได้ในโครงการไอที ทีมควรโฟกัสเฉพาะสิ่งที่จำเป็นในตอนนี้ นั่นคือ การปฏิบัติงานด้วยวิธีที่เหมาะสมที่สุด นี่ไม่ได้หมายความว่างานที่มีค่ามากในการพัฒนาโมดูล/คลาสเพื่อจัดเก็บฟังก์ชันการทำงานในอนาคตควรถูกกำจัดออกไป แต่ความเข้าใจที่ว่าควรพิจารณาเฉพาะงานที่เพิ่มมูลค่าเท่านั้นที่อยู่ในระดับแนวหน้า
2) ทำในสิ่งที่จำเป็นต้องทำด้วยวิธีย่อยๆ
คุณควรสร้างเฉพาะสิ่งที่จำเป็นอย่างยิ่งเพื่อให้งานสำเร็จ การทำงานที่ไม่ได้มีส่วนช่วยในการแก้ปัญหานั้นเป็นความพยายามที่สูญเปล่า โดยเฉพาะอย่างยิ่งเนื่องจากโครงการขนาดใหญ่ในด้านการพัฒนาไอทีเป็นโครงการที่ต้องใช้ความรู้สูงและมีค่าใช้จ่ายสูง ดังนั้น ควรตัดงานที่ไม่จำเป็นหรือไร้ประโยชน์ออกไป และทุกคนในทีมควรตระหนักในเรื่องนี้
3) การทำงานหลายอย่างพร้อมกัน
การทำงานหลายอย่างพร้อมกันจะเพิ่มค่าใช้จ่ายเสมอ เนื่องจากค่าใช้จ่ายของสวิตช์บริบทอาจสูง ขีดจำกัด WIP กำหนดขอบเขตของ "การยืด" ความพยายามของทีม
4) การดำเนินการไม่สมบูรณ์ / ไม่สมบูรณ์
Kanban ส่งเสริมแนวคิดในการกำหนดอย่างชัดเจนว่างานถึงกำหนดเมื่อใดด้วยเกณฑ์การเข้าและออกสำหรับแต่ละคอลัมน์
5) กำลังรอ / ไม่ได้ใช้งาน
ข้อกล่าวอ้าง "ฉันไม่สามารถเริ่มงานนี้ได้จนกว่าจะได้รับจาก..." ใช้ไม่ได้ใน Kanban กระดานภาพและการประชุมรายวันสร้างโอกาสในการระบุงานการบล็อก ตัวอย่างทั่วไปของโครงการ IT คือเมื่อโครงการกำลังรอสภาพแวดล้อมการตรวจสอบความถูกต้อง Kanban สามารถช่วยในเรื่องนี้ได้โดยแยกงานการตรวจสอบออกเป็นการสร้างสภาพแวดล้อมการตรวจสอบความสมบูรณ์ของระบบอย่างง่าย จากนั้นจึงเพิ่มงานที่ทำให้สภาพแวดล้อมการตรวจสอบมีความซับซ้อนมากขึ้น
6) ข้อผิดพลาดในการเลือกทรัพยากร / งาน
ข้อกล่าวอ้าง "ขอให้ Vova ทำสิ่งนี้ในขณะที่เขาไม่ว่าง" ใช้ไม่ได้ในระบบ Kanban
การมอบหมายให้คนที่พร้อมแต่ไม่มีความสามารถเพียงพอมักจะจบลงด้วยงานคุณภาพต่ำที่ใช้เวลานานกว่าที่ต้องการและจำเป็นต้องทำใหม่ในภายหลังอย่างหลีกเลี่ยงไม่ได้ การแก้ไขใด ๆ เป็นการเสียเวลา แม้ว่า Kanban จะไม่ให้กลไกใดๆ ในการแยกปัญหานี้ แต่จะช่วยระบุว่าเป็นปัญหาที่ต้องแก้ไข เนื่องจากงานที่สนับสนุนโดยทรัพยากรที่มอบหมายไม่ถูกต้องมักจะใช้เวลานานกว่าปกติ
การรวมวิธีการ Kanban
ด้านล่างนี้คุณจะพบคำแนะนำเกี่ยวกับวิธีที่ทีมพัฒนาสามารถรวมแนวทาง Kanban เข้ากับเวิร์กโฟลว์ปัจจุบันของพวกเขา คำแนะนำเหล่านี้ส่วนหนึ่งมาจากประสบการณ์จริงและแนวทางปฏิบัติที่ดีที่สุดในชุมชนการพัฒนาซอฟต์แวร์
Kanban เมื่อเทียบกับวิธี Agile อื่นๆ แล้ว เป็นวิธีการที่ง่ายมากโดยมีค่าใช้จ่ายต่ำมากและกฎง่ายๆ ที่สามารถนำมาใช้ได้อย่างง่ายดาย ความจริงที่ว่ามันไม่ขัดจังหวะขั้นตอนที่กำลังดำเนินการอยู่คือจุดแข็งของมัน เพราะมันสามารถและแม้กระทั่งจำเป็นต้องรวมเข้ากับเวิร์กโฟลว์ที่มีอยู่แล้ว เพื่อให้ทีมสามารถจัดระเบียบตนเองได้ และหากจำเป็น ปรับปรุงเวิร์กโฟลว์ต่อไป
ดังนั้นคุณจะทำอย่างไรเพื่อค่อยๆ แนะนำ Kanban เข้าสู่โฟลว์ของคุณ มีคำศัพท์ภาษาญี่ปุ่นสามคำที่ใช้อธิบายการเปลี่ยนแปลงของทีม Kanban จากสถานะเริ่มต้นเป็นสถานะหลัก
SHU - สถานที่ที่เราศึกษาพื้นฐานของเทคโนโลยีหรือระเบียบวิธี
Ha - การทำความเข้าใจพื้นฐานและการแนะนำอย่างค่อยเป็นค่อยไปและการปรับวิธีการใหม่
RI - เชี่ยวชาญในเทคโนโลยี ใช้ข้อมูลขั้นสูงและสร้างสรรค์สิ่งใหม่ๆ
ลองพิจารณารายละเอียดขั้นตอนเหล่านี้
1. SHU - ความรู้เบื้องต้นเกี่ยวกับ Kanban
เราขอเสนอขั้นตอนในการแนะนำ Kanban เข้าสู่ทีม
ระยะที่ 1 - การเรียนรู้: จ้างมืออาชีพเพื่อเรียนรู้เพิ่มเติมเกี่ยวกับ Kanban
ระยะที่ 2 – การแสดงภาพตามขั้นตอน: จดบันทึกกระบวนการปัจจุบันโดยใช้กระดานไวท์บอร์ด เริ่มต้นที่ทีมอยู่ในขณะนี้ การแสดงภาพไม่ใช่ภาพของวิธีที่คุณต้องการทำงาน แต่เป็นการเน้นไปที่วิธีการทำงานจริง ดี กล่าวคือ การแสดงข้อมูลที่ให้ข้อมูลและถูกต้องเป็นการเริ่มต้นที่ดีสำหรับผู้ที่ใช้ Kanban ขั้นตอนต่อไปคือการทำให้แน่ใจว่าทีมเข้าใจเกณฑ์การเข้าและออกสำหรับแต่ละขั้น
ระยะที่ 3 - เพิ่มขีดจำกัด WIP การเพิ่มขีดจำกัด WIP ควรเป็นไปตามความเป็นจริง ตัวเลือกที่ดีคือการเริ่มต้นด้วยการคำนวณ WIP เป็นจำนวนวิศวกร/ผู้เชี่ยวชาญ คูณด้วยจำนวนงานโดยเฉลี่ยที่สมเหตุสมผลที่แต่ละงานดำเนินการในแต่ละครั้ง Kanban แนะนำให้เริ่มต้นเพียงเล็กน้อยและค่อยๆ เพิ่ม WIP ผ่านประสบการณ์ เช่น เมื่อสล็อตฟรียังคงเปิดนานเกินไปหรือรอบเวลานานเกินไป สิ่งนี้เริ่มที่จะระบุคอขวดและข้อจำกัดของทรัพยากร
ขั้นตอนที่ 4 - การทบทวน สามารถดำเนินการตรวจสอบได้ในทุกขั้นตอน เป้าหมายคือเพื่อหารือเกี่ยวกับความคืบหน้าของกระบวนการและขจัดปัญหาคอขวด ตลอดจนปรับปรุงสิ่งที่ (และวิธี) กำลังดำเนินการอยู่
2. HA - การใช้ Kanban
เมื่อทักษะ Kanban พื้นฐานถูกสร้างขึ้นแล้ว คุณสามารถเริ่มนำวิธีการไปใช้ได้
ขั้นตอนที่ 1 - การรวบรวมตัวบ่งชี้ เริ่มรวบรวมตัวชี้วัดที่มีอยู่ สิ่งนี้จะให้ข้อมูลวัตถุประสงค์บนพื้นฐานของการเปลี่ยนแปลงเชิงปฏิบัติที่สามารถดำเนินการได้ นอกจากนี้ การรวบรวมข้อมูลยังเป็นพื้นฐานสำหรับการกำหนดวัตถุประสงค์ว่าการเปลี่ยนแปลงกระบวนการใดๆ ช่วยปรับปรุงประสิทธิภาพของทีมได้จริงหรือไม่
ขั้นตอนที่ 2 - คือการใช้เมตริก เมตริกที่รวบรวมระหว่างการสนทนาใดๆ จะใช้เพื่อปรับปรุงการประเมินงาน/กิจกรรม และเพื่อวางแผนปริมาณงานที่ทีมสามารถจัดการได้อย่างสมเหตุสมผล
3. RI - การเรียนรู้ Kanban
ณ จุดนี้ ทีมมีความเชี่ยวชาญอย่างเต็มที่ในการใช้ Kanban เมื่อใช้ข้อมูลที่รวบรวมได้ ตอนนี้คุณสามารถรวมไว้ในเซสชันการวางแผนในอนาคตของคุณเพื่อประมาณระยะเวลาของชุดงานที่อยู่ข้างหน้าคุณ ตอนนี้การวางแผนของคุณขึ้นอยู่กับข้อมูลเชิงประจักษ์ ไม่ใช่สมมติฐานที่ลวงตา เนื่องจากการประมาณการขึ้นอยู่กับข้อมูลเชิงประจักษ์ คุณจึงมั่นใจในความถูกต้องได้
โดยสรุป เราทราบว่าการเปลี่ยนแปลงใดๆ นั้นยาก ก่อกวน และอาจทำให้หลายคนในทีมไม่สบายใจ ขอแนะนำอย่างยิ่งให้ปรับ Kanban (หรือกระบวนการใหม่ใดๆ) เป็นขั้นๆ โดยคำนึงถึงปัญหาที่สำคัญของผู้ที่ได้รับผลกระทบโดยตรงจากการแนะนำเทคโนโลยีใหม่
ไม่มีอะไรทำให้ผู้คนหวาดกลัวได้มากไปกว่าสิ่งที่ไม่รู้จัก หากไม่เข้าใจการเปลี่ยนแปลงและเป้าหมายอย่างถ่องแท้ ในกรณีส่วนใหญ่ผู้คนจะมีปฏิกิริยาเชิงลบต่อการเปลี่ยนแปลง โอกาสของความสำเร็จจะเพิ่มขึ้นหากการเรียนรู้และการใช้งาน Kanban ค่อยๆ เสร็จสิ้น
สุดท้าย โปรดทราบว่าการสนทนาเกี่ยวกับ Kanban ที่นำเสนอนี้มีไว้สำหรับการเริ่มต้นเท่านั้น แม้ว่า Kanban เองจะค่อนข้างเรียบง่าย แต่เหตุผลในการใช้งานและบริบทที่พัฒนาอาจต้องมีการชี้แจงเพิ่มเติม หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับ Kanban และวิธีการนำไปใช้กับการผลิตแบบลีนและการพัฒนาผลิตภัณฑ์ คุณควรอ้างอิงเอกสารเฉพาะทาง
