Kanban ในการออกแบบด้านไอที แนวทางปฏิบัติ

• แสดงภาพขั้นตอนการทำงานของคุณ

• ขีดจำกัด WIP

• การควบคุมความคืบหน้า

• มั่นใจได้ถึงความโปร่งใสของนโยบาย

• การปรับปรุงร่วมกัน การพัฒนา การทดลอง

เมื่อเปรียบเทียบกับเฟรมเวิร์กการจัดการโครงการแบบ Agile แบบดั้งเดิมแล้ว Kanban นั้นเข้าใจง่ายมาก ความเรียบง่ายนี้เป็นจุดแข็งหลัก ดังนั้นการใช้คัมบังจึงสามารถเป็นตัวเร่งให้เกิดการเปลี่ยนแปลงในวิธีการจัดระเบียบงานได้

Kanban ในการออกแบบด้านไอที แนวทางปฏิบัติ

แสดงภาพขั้นตอนการทำงานของคุณ

Kanban ยึดตามแนวคิดที่ว่าทีมควรเห็นขั้นตอนการทำงานของพวกเขา ผู้จัดการโครงการสามารถค้นหาศักยภาพในการปรับปรุงได้โดยใช้การแสดงภาพเวิร์กโฟลว์

กิจกรรมของนักพัฒนาทั้งหมดได้รับการวางแผน ติดตาม และนำเสนอเป็นภาพบนกระดาน Kanban มีโอกาสอย่างสม่ำเสมอและต่อเนื่องสำหรับการสนทนาในทีมเกี่ยวกับวิธีตรวจสอบให้แน่ใจว่าทีมมีสมาธิและทำงานที่สำคัญที่สุด การดำเนินการที่เร็วขึ้น เช่น การแก้ไขจุดบกพร่อง สามารถแสดงเป็นภาพด้วยสีอื่นได้

อีกทางเลือกหนึ่ง บอร์ด Kanban สำหรับนักพัฒนาด้าน IT สามารถมีขั้นตอนเวิร์กโฟลว์ได้หลายขั้นตอน

• งานค้าง: ฟังก์ชัน/การดำเนินการทั้งหมดที่ต้องดำเนินการ

• การวิเคราะห์: ความหย่อนที่จำเป็นในการทำความเข้าใจและวิเคราะห์ปัญหา จับข้อกำหนด กำหนดเกณฑ์ทางออกหรือเสร็จสิ้น และพิจารณาแนวทางสถาปัตยกรรมที่แตกต่างกัน

• การออกแบบ: วิศวกรรมการออกแบบเบื้องต้น

• การดำเนินการ: การดำเนินการแก้ปัญหา

• การตรวจสอบความถูกต้อง: การดีบักและ/หรือการตรวจสอบความถูกต้องของการนำไปใช้และการปฏิบัติตามเกณฑ์ที่กำหนดไว้ในขั้นตอนการวิเคราะห์

• เสร็จสิ้น: งาน/การดำเนินการตรงกับเกณฑ์การออก

บอร์ดดังกล่าวอาจมีเวิร์กโฟลว์เร่งด่วนแยกต่างหากที่สร้างความสามารถสำหรับรายการที่หลีกเลี่ยงไม่ได้ซึ่งจำเป็นต้องเร่งดำเนินการ แน่นอนว่า "แบนด์" นี้ควรใช้ไม่บ่อยนัก

มุมมองภาพของบอร์ด Kanban สนับสนุนการอภิปรายภายในทีมเกี่ยวกับวิธีการปรับกระบวนการและวิธีการของทีมให้เหมาะสมเพื่อลดการเสียเวลาในกระบวนการทำงานของทีม

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

ขีดจำกัด WIP

วิธีการแบบคลาสสิกในการที่ทีมมีส่วนร่วมในงานออกแบบคือการให้งาน/คุณสมบัติหลายอย่างแก่พวกเขาเพื่อดำเนินการในเวลาเดียวกัน เช่นเดียวกับการมีการประชุมอย่างต่อเนื่องเพื่อคิดวิเคราะห์เกี่ยวกับข้อบกพร่องและกำหนดงานที่ "รวดเร็ว" ในปัจจุบัน ต้องทำให้เสร็จในเวลาที่สั้นที่สุด ข้อกำหนด เห็นได้ชัดว่าสิ่งนี้นำไปสู่ความไร้ประสิทธิภาพเนื่องจากจำเป็นต้องสลับระหว่างงานต่างๆ วิธีแก้ไขที่มีประสิทธิภาพมากกว่าคือการทำให้แน่ใจว่าแต่ละคนโฟกัสกับงานน้อยลงและปล่อยให้ทำงานจนจบ วัตถุประสงค์ของแนวทางปฏิบัตินี้คือการจำกัดงานระหว่างดำเนินการ

ทุกโครงการมีขีดจำกัด: คน พลังการประมวลผล ใบอนุญาต วันหยุดที่วางแผนไว้ ฯลฯ ขีดจำกัดเหล่านี้จำเป็นต้องได้รับการกำหนดอย่างชัดเจนและบันทึกไว้ในกระดานคัมบัง ซึ่งทำได้โดยการกำหนดขีดจำกัดของงานระหว่างทำ (WIP) ให้กับแต่ละคอลัมน์บนกระดาน Kanban ที่แสดงถึงขีดจำกัด ตัวอย่างเช่น สมมติว่าเราต้องการกำหนดขีดจำกัดของงานระหว่างดำเนินการให้กับขั้นตอนการดำเนินการ หากเรามีนักพัฒนาสี่รายและเราตั้งสมมติฐานว่านักพัฒนาสามารถทำงานได้ไม่เกินสองงานต่อครั้ง ขีดจำกัด WIP ที่ได้คือ 8 (= นักพัฒนา 4 คน * 2 งานต่อนักพัฒนา 1 คน) สิ่งนี้กำหนดจำนวนสูงสุดของงาน/กิจกรรมที่สามารถเกิดขึ้นได้ในขั้นตอนนี้ของกระบวนการ

ประเด็นสำคัญอยู่ที่ Kanban ใช้สิ่งที่เรียกว่าระบบดึง หากผู้จัดการโครงการเชื่อว่าขีดจำกัด WIP เป็นตัวกำหนดจำนวนช่องว่างที่พร้อมใช้งานสำหรับแต่ละคอลัมน์ เขาจะสามารถย้ายงานไปยังคอลัมน์ได้ก็ต่อเมื่อมีช่องว่างว่างเท่านั้น ตัวอย่างเช่น

• ทีมไม่สามารถเริ่มรายการใหม่จากงานในมือได้ หากขั้นตอนการวิเคราะห์ถึงขีดจำกัด WIP

• อย่างไรก็ตาม ทันทีที่องค์ประกอบใดๆ ในขั้นตอนการวิเคราะห์เสร็จสิ้น จะสามารถย้ายไปยังขั้นตอนการออกแบบได้ทันทีหากมีช่องว่างว่างหนึ่งช่อง

• ไม่มีขีดจำกัดสำหรับคอลัมน์เสร็จสิ้น

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

ประเด็นสำคัญเกี่ยวกับการย้ายจากงานในมือไปยังขั้นตอนการวิเคราะห์คือการให้โอกาสในการตัดสินใจว่างานหรือหน้าที่ใดมีค่ามากที่สุดในปัจจุบัน เนื่องจากลำดับความสำคัญมักจะเปลี่ยนแปลงตลอดทั้งโครงการเนื่องจากข้อมูลใหม่หรือปัญหาทางเทคนิค ความสามารถในการพิจารณาใหม่ว่าอะไรควรดำเนินการให้เร็วที่สุดหรือช้าที่สุดเท่าที่จะเป็นไปได้คือค่าสำคัญในการใช้ระบบต่อเนื่องเช่น Kanban

เมื่อมีข้อจำกัดของ WIP แล้ว จะเห็นได้ชัดว่ามีจุดคอขวดอยู่ที่ใดในกระบวนการ เนื่องจากองค์ประกอบหนึ่งหรือหลายองค์ประกอบสร้างแรงกดดันย้อนกลับต่อกิจกรรมต้นน้ำ การเพิ่มขีดจำกัด WIP มักจะหมายความว่างานค้างอยู่ในคอลัมน์นานเกินไป และงานถูกลากยาวเกินไป

เมื่อกำหนดขีดจำกัด WIP ชุดเริ่มต้นแล้ว มีแนวโน้มว่าจะต้องมีการปรับเปลี่ยนเมื่อโครงการดำเนินไป นี่เป็นเรื่องธรรมชาติและเป็นเรื่องที่คาดหวังได้ วิธีหนึ่งคือการสังเกตความราบรื่นของงานที่ไหลผ่านบอร์ดคัมบัง และทดลองค้นหา WIP ที่เหมาะสมที่สุดโดยการเพิ่มและลดขีดจำกัด WIP เพื่อทำให้โฟลว์ราบรื่น

การควบคุมความคืบหน้า

เป้าหมายขององค์กรที่สำคัญประการหนึ่งของโครงการคือการใช้ทรัพยากรของทีมอย่างมีประสิทธิภาพสูงสุดเพื่อแก้ปัญหางานของโครงการ มุมมองด้านภาพและขีดจำกัดของงานระหว่างดำเนินการที่กล่าวถึงในส่วนก่อนหน้านี้ช่วยระบุปัญหาคอขวดและช่วยทีมปรับเวิร์กโฟลว์ให้เหมาะสมตั้งแต่ต้นจนจบ

มั่นใจได้ถึงความโปร่งใสของนโยบาย

ดังสุภาษิตที่ว่า “ยาฆ่าเชื้อที่ดีที่สุดคือแสงแดด” ซึ่งหมายความว่าเฉพาะเมื่อนโยบายมีความชัดเจนเท่านั้นจึงจะมองเห็นปัญหาได้

จุดประสงค์ของแนวทางปฏิบัติหลักนี้คือเพื่ออธิบายนโยบายพื้นฐานใดๆ ในเวิร์กโฟลว์ให้ชัดเจน เช่น วิธีดำเนินการจริง เมื่อจัดทำขึ้นแล้ว ข้อมูลเหล่านี้จะกลายเป็น "ข้อเท็จจริง" สำหรับโครงการ และลดภาระการวิเคราะห์เชิงอัตนัยหรือภาระทางอารมณ์ที่เกี่ยวข้องกับกระบวนการพัฒนา

สิ่งสำคัญคือต้องสร้างโอกาสในการทบทวนกระบวนการผ่านหลักฐานวัตถุประสงค์ที่รวบรวมหรือข้อเท็จจริงแต่ละรายการ โอกาสเหล่านี้สามารถใช้เพื่อสร้างแนวคิดในการปรับปรุงซึ่งทุกคนเห็นพ้องต้องกันเนื่องจากการอภิปรายอิงจากข้อเท็จจริงจริง ตามหลักการแล้ว ข้อเสนอแนะนี้ควรเกิดขึ้นเมื่อใดก็ตามที่มีหลักฐานเพียงพอของปัญหา ประเด็นนี้จะต้องได้รับการอภิปรายอย่างมีความหมาย ซึ่งบางครั้งอาจกินเวลานานหลายสัปดาห์หรือเป็นเดือน

การเกิดขึ้นของคอขวดยังเป็นโอกาสในการหารือเกี่ยวกับแนวคิด แนวคิดหลังการอภิปรายสามารถวางลงในงานในมือ (หรืองาน) เพื่อจัดลำดับความสำคัญและเพิ่มเมื่อช่องว่างถัดไปว่าง

การประชุมรายวันเป็นโอกาสในการหารือเกี่ยวกับปัญหาอย่างเป็นกลาง

กระดาน Kanban เป็นองค์ประกอบทางกายภาพ ช่วยให้ผู้คนสามารถพูดคุยเกี่ยวกับ "กระดาน" แทนที่จะเป็น "บุคคล" ด้วยการเลื่อนการสนทนาไปที่ช่อง "งาน" (“อะไรที่ทำให้งาน A หยุดไม่คืบหน้า”) ผู้จัดการสามารถขจัดปัญหาทั่วไป เช่น การเริ่มเรื่องส่วนตัว (“ทำไมการแก้ปัญหางาน A จึงใช้เวลานานมาก”)

การปรับปรุงร่วมกัน การพัฒนา การทดลอง

ในบริบทของการดำเนินโครงการด้านไอที Kanban นำเสนอเมตริกที่สำคัญ (เช่น แผนภูมิลำดับงาน CFD แบบสะสม) ที่สามารถให้ข้อมูลเชิงลึกที่เป็นจริงเกี่ยวกับ:

• สถานะปัจจุบันของโครงการไอที

• ความคิดบางอย่างเกี่ยวกับกำหนดการที่คาดการณ์ไว้สำหรับอนาคต

• ข้อมูลสำคัญบางอย่างที่จำเป็นสำหรับการวางแผนล่วงหน้า

ข้อมูลทั้งหมดนี้เชื่อมโยงกับโครงสร้างการรายงานการจัดการที่มีอยู่ และสามารถให้มุมมองที่สมจริงยิ่งขึ้นเกี่ยวกับสถานะที่แท้จริงของโครงการมากกว่าแผนภูมิ Gantt

เนื่องจาก Kanban เป็นโฟลว์ที่ต่อเนื่อง จึงเป็นไปได้และจำเป็นต้องหารือถึงการเปลี่ยนแปลงรายการเวิร์กโฟลว์เมื่อใดก็ได้ ตามกฎแล้วนี่เป็นเพราะสถานะเรื้อรังของขั้นตอนกระบวนการซึ่งกลายเป็น "คอขวด" สิ่งนี้ต้องการให้ทีมค้นหาวิธีแก้ไขปัญหาเพื่อกำจัดคอขวดหรือปรับปรุงการไหล ตามหลักการแล้ว โซลูชันดังกล่าวพบบนพื้นฐานของข้อมูลเชิงประจักษ์ที่น่าเชื่อถือ ซึ่งแสดงให้เห็นการเกิดขึ้นอย่างต่อเนื่องของปัญหาคอขวดในระยะนี้

เมื่อมีการตัดสินใจเกี่ยวกับตัวเลือกการปรับปรุงแล้ว ควรกำหนดเวลาเช่นเดียวกับงานอื่นๆ โดยเพิ่มเข้าไปในขั้นตอนเริ่มต้น ในกรณีของเรา นี่คืองานในมือและดำเนินการตามนั้น ในขณะที่การรวบรวมเมตริกดำเนินต่อไป ทีมจะสามารถระบุได้อย่างเป็นกลางว่าแนวคิดนั้นทำให้ประสิทธิภาพของทีมดีขึ้นหรือแย่ลง

ทฤษฎีที่อยู่เบื้องหลังหลักปฏิบัติ Kanban หลักนี้คือการระบุปัญหาจากมุมมองระยะยาว การเปลี่ยนแปลงตามข้อเท็จจริงจะถูกทำขึ้น และจากนั้นผลลัพธ์จะถูกบันทึกเพื่อตรวจหาปัญหา ดังนั้นการปรับปรุงจึงเป็นวัฏจักรอย่างต่อเนื่อง