5 Agile Scaling Framework ที่เปรียบเทียบ: คุณควรใช้อันไหน?

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

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

กรอบงานที่เหมาะสมที่สุดสำหรับทีมของคุณจะแตกต่างกันไป ขึ้นอยู่กับปัจจัยต่างๆ เช่น เงินทุนที่มีอยู่ วิธีการขององค์กร และความซับซ้อนของผลิตภัณฑ์

คุณควรปรับขนาดเมื่อใด

มีเกณฑ์สำคัญหลายประการที่คุณต้องปฏิบัติตามก่อนที่คุณจะพิจารณาการปรับขนาด:

คุณสามารถจัดการการพัฒนาด้วยทีมเดียวได้หรือไม่?

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

ทีมงานของคุณคล่องตัวหรือไม่?

บางทีเกณฑ์ที่สำคัญที่สุดก็คือความสามารถของทีมของคุณในแนวทาง Agile หากทีมของคุณไม่มีประสบการณ์ใน Agile การปรับขนาดจะสร้างปัญหามากขึ้น

แนวทางปฏิบัติในการพัฒนาทีมของคุณต้องได้รับการปรับปรุงหรือไม่?

หากแนวทางปฏิบัติด้านวิศวกรรมของทีมคุณไม่ได้ผล การปรับขนาดอาจไม่ให้ผลลัพธ์ที่ต้องการ แนวทางปฏิบัติ เช่น การนำ DevOps ไปใช้อย่างเหมาะสมและไปป์ไลน์ CI/CD มีความสำคัญต่อความสอดคล้องกันระหว่างทีม นอกจากนี้ หากไม่มีการประกันคุณภาพที่เป็นมาตรฐาน การทดสอบคุณสมบัติใหม่อาจเป็นเรื่องยาก

ทีมของคุณมีการเพิ่มแบบบูรณาการหรือไม่?

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

การเลือกกรอบการปรับขนาด

มีเฟรมเวิร์กการปรับขนาด Agile มากมายให้เลือก แต่เราจะเน้นที่โซลูชันที่ใช้กันอย่างแพร่หลายมากที่สุด 5 แบบ ได้แก่ Scaled Agile Framework (SAFe), Nexus, Large-Scale Scrum (LeSS), Scrum@Scale และ Disciplined Agile (DA) . ฉันพบว่าสิ่งเหล่านี้เป็นเฟรมเวิร์กที่มีประสิทธิภาพมากที่สุด และสามารถนำไปใช้กับสถานการณ์และองค์กรต่างๆ ได้ ส่วนต่อไปนี้จะจัดเตรียมข้อมูลที่คุณต้องการเพื่อเป็นทางเลือกที่ดีที่สุดสำหรับบริบทการปรับขนาดเฉพาะของคุณ

1. Scaled Agile Framework (SAFe)

SAFe เป็นเฟรมเวิร์กยอดนิยมสำหรับการปรับขนาดแบบ Agile จากการสำรวจในปี 2564 พบว่า 37% ของผู้ปฏิบัติงานแบบ Agile ใช้งาน โดยส่วนใหญ่เกิดจากการกำหนดค่าที่หลากหลาย ซึ่งทั้งหมดเน้นที่สายธารคุณค่า และมีแนวทางและขั้นตอนที่ชัดเจน

เนื่องจาก SAFe ใช้เพื่อส่งมอบโซลูชันที่ซับซ้อนซึ่งต้องใช้บุคลากรมากกว่า 50 คน จึงจัดทีมเป็นขบวนปล่อยที่คล่องตัว (ARTs) ในการซิงโครไนซ์ทีมใน ART นั้น SAFe จะใช้การวนซ้ำของโปรแกรม—คล้ายกับ Scrum sprints— และโดยทั่วไปการวนซ้ำแต่ละครั้งจะกินเวลาแปดถึง 12 สัปดาห์ แนวทางนี้ช่วยให้ผู้จัดการผลิตภัณฑ์จดจ่อกับเป้าหมายโดยรวมและดูแลแผนงานผลิตภัณฑ์ที่ซับซ้อนได้อย่างมีประสิทธิภาพโดยไม่ต้องทำการเปลี่ยนแปลงมากเกินไป

SAFe อิงตามเฟรมเวิร์ก Scrum แต่มีข้อแตกต่างที่สำคัญสองประการ: การนำ SAFe ไปใช้เกิดขึ้นที่ระดับองค์กรมากกว่าระดับทีม และในขณะที่ Scrum ให้สิทธิ์แก่เจ้าของผลิตภัณฑ์ในการจัดลำดับความสำคัญ แต่ SAFe สนับสนุนแนวทางที่เป็นประชาธิปไตยมากขึ้น

SAFe มีการดำเนินการสี่ระดับ:

ความปลอดภัยที่จำเป็น

Essential SAFe เป็นรากฐานของ SAFe และต้องได้รับการฝึกฝนก่อนที่จะไปยังการกำหนดค่าใดๆ ที่ตามมา มันใช้บทบาท Scrum ที่จัดตั้งขึ้น เช่น Scrum master ผู้จัดการผลิตภัณฑ์ และเจ้าของผลิตภัณฑ์ และยังแนะนำบทบาทใหม่: วิศวกรฝึกอบรมการเปิดตัว บุคคลนี้ทำหน้าที่เป็นผู้นำคนรับใช้และโค้ช ART นำทางทีมเพื่อวางเป้าหมาย ART สามารถมีได้ระหว่าง 5 ถึง 12 ทีม โดย ART แต่ละทีมสามารถนำเสนอโซลูชันที่สมบูรณ์ได้

โซลูชั่นขนาดใหญ่

การกำหนดค่านี้ตั้งอยู่บน Essential SAFe และแนะนำแนวคิดที่เรียกว่า "solution train" ใช้ในการสร้างโซลูชันขนาดใหญ่และซับซ้อนที่ต้องการการประสานงานของ ART หลายตัว ซึ่งอาจเป็นหลายร้อยหรือหลายพันคน ซึ่งทำงานบนกระแสคุณค่าเดียวกัน ตัวอย่างเช่น ถ้าคุณทำงานที่ Microsoft และมีทีมสามทีมที่เขียนโปรแกรม Excel, Word และ PowerPoint แยกกัน พวกเขาทั้งหมดมีส่วนทำให้เกิดกระแสคุณค่าเดียวกัน: Microsoft Office

ผลงาน

ผลงานประกอบด้วย ART หลายรายการที่ทำงานบนกระแสคุณค่าที่แตกต่างกัน ต่อด้วยตัวอย่าง Microsoft: แยกทีมที่ทำงานในผลิตภัณฑ์ Office, Skype หรือ Xbox ของบริษัท

ปลอดภัยเต็มรูปแบบ

การกำหนดค่านี้รวมเลเยอร์ทั้งหมด—Essential, Large Solution และ Portfolio—เพื่อประสานงานการจัดการทีมทั่วทั้งองค์กร

2. Nexus

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

ในระหว่างการวิ่ง ทีมจะมีส่วนร่วมในช่วงการปรับแต่งเพื่อจัดลำดับความสำคัญและประเมินงานในมือ เนื่องจากความซับซ้อนของการจัดการงานในมือเพิ่มขึ้นตามจำนวนทีม Nexus จึงกำหนดช่วงการปรับแต่ง ทีมประชุมกันเพื่อทบทวนและทบทวนหลังการวิ่งแต่ละครั้ง

3. Scrum ขนาดใหญ่ (LeSS)

LeSS เกือบจะเหมือนกับ Nexus แต่มีความแตกต่างเล็กน้อย เช่น แบบแผนการตั้งชื่อและเซสชันการวางแผนการวิ่งแบบเฉพาะทีมเพิ่มเติม นอกจากนี้ยังมีความสามารถในการขยายที่แตกต่างกันด้วยการกำหนดค่าที่สอง LeSS Huge ซึ่งสนับสนุนการทำงานร่วมกันของทีมมากกว่าแปดทีม

LeSS Huge ใช้แนวทางที่ยึดลูกค้าเป็นศูนย์กลางในการจัดระเบียบการพัฒนา ในการจัดการงานอย่างมีประสิทธิภาพ เจ้าของผลิตภัณฑ์จำเป็นต้องแยกงานในมือในระดับสูงออกเป็น "งานในมือ" ที่มีขนาดเล็กลงของสินค้าที่ละเอียดยิ่งขึ้น จากนั้นจึงแยกประเภทเพิ่มเติม - ตามพื้นที่ความต้องการ

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

4. Scrum@Scale

Scrum@Scale เป็นส่วนขยายของ Scrum และน่าจะเป็นเฟรมเวิร์กที่ง่ายที่สุดในการเรียนรู้และทำความเข้าใจ มันขยายจากทีมหนึ่งไปยังอีกทีมหนึ่ง

องค์ประกอบหลักของเฟรมเวิร์กคือ Scrum of Scrums (SoS) แต่ละทีมจะเลือกบุคคลเพื่อเป็นตัวแทนของพวกเขาในการประชุม SoS ซึ่งมักจะเกิดขึ้นทุกวันหลังจากที่แต่ละทีมยืนขึ้น จุดมุ่งหมายของการประชุม SoS ในแต่ละวันคือการช่วยประสานงานและการสื่อสารระหว่างทีม และอำนวยความสะดวกในการจัดการการพึ่งพาหรือการทับซ้อนกันที่ง่ายดาย

บทบาทเฉพาะภายในเฟรมเวิร์กนี้ ได้แก่ ต้นแบบ SoS ซึ่งเป็นเวอร์ชันที่ปรับขนาดของต้นแบบ Scrum และเจ้าของผลิตภัณฑ์ระดับหัวหน้า ซึ่งทำงานร่วมกับเจ้าของผลิตภัณฑ์ของทีมเพื่อสร้างงานในมือร่วมกันสำหรับ SoS

Scrum@Scale มีการกำหนดน้อยกว่าเฟรมเวิร์กอื่นๆ ทำให้องค์กรสามารถปรับขนาดได้ตามต้องการ หากจำนวนทีมยังคงเติบโตและการประชุม SoS มีขนาดใหญ่เกินไป องค์กรสามารถขยายกรอบงานเป็น Scrum of Scrum of Scrums (SoSoS)

5. มีระเบียบวินัยเปรียว (DA)

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

สามารถใช้ได้ในระดับทีมพัฒนาซอฟต์แวร์หรือทั่วทั้งองค์กร สำหรับส่วนหลัง ชุดเครื่องมือ DA จะระบุว่าหน้าที่ทางธุรกิจต่างๆ เช่น การเงิน การดำเนินงานด้านไอที และการจัดการผู้ขาย ควรระบุและนำเสนอตัวเลือกต่างๆ สำหรับการทำเช่นนั้น

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

สามารถใช้ DA ร่วมกับเฟรมเวิร์กอื่นๆ เพื่อขยายเพิ่มเติมได้

เลือกอย่างระมัดระวังและปรับขนาดอย่างช้าๆ

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

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

คุณได้ใช้กรอบเหล่านี้ในกิจกรรมการปรับขนาดของคุณหรือไม่? บอกเราเกี่ยวกับประสบการณ์ของคุณในส่วนความคิดเห็น