บทช่วยสอน SAFe (Scaled Agile Framework)
โธมัส แฮมิลตัน
⚡ สรุปอย่างชาญฉลาด
Scaled Agile Framework (SAFe) คือฐานความรู้สำหรับการประยุกต์ใช้แนวทางปฏิบัติแบบ Lean-Agile ในระดับองค์กร โดยจัดระเบียบตามระดับทีม โปรแกรม พอร์ตโฟลิโอ และกระแสคุณค่า เพื่อช่วยให้องค์กรขนาดใหญ่สามารถวางแผน จัดทำงบประมาณ และส่งมอบคุณค่าได้อย่างสอดคล้องและมีคุณภาพในตัว
SAFe (Scaled Agile Framework) คืออะไร
กรอบงาน Agile ที่ปรับขนาดได้ (SAFe) เป็นฐานความรู้ออนไลน์ที่มีให้ใช้งานฟรี ซึ่งช่วยให้คุณสามารถใช้หลักปฏิบัติแบบ Lean-Agile ในระดับองค์กรได้ มอบประสบการณ์ที่เรียบง่ายและมีน้ำหนักเบาสำหรับการพัฒนาซอฟต์แวร์ เป็นชุดขององค์กรและรูปแบบเวิร์กโฟลว์ที่มีจุดมุ่งหมายเพื่อเป็นแนวทางแก่องค์กรในการขยายแนวทางปฏิบัติแบบ Lean และ Agile แบ่งออกเป็น 3 ส่วน ได้แก่ ทีม โปรแกรม และพอร์ตโฟลิโอ
ปลอดภัย กรอบการทำงานช่วยให้ทีมงานสามารถ
- การใช้ซอฟต์แวร์และระบบ Lean-Agile ในระดับองค์กร
- มันเป็นไปตามหลักการแบบ Lean และ Agile
- โดยให้คำแนะนำโดยละเอียดสำหรับงานในพอร์ตโฟลิโอขององค์กร กระแสคุณค่า โปรแกรม และทีม
- ได้รับการออกแบบมาเพื่อตอบสนองความต้องการของผู้มีส่วนได้ส่วนเสียทั้งหมดภายในองค์กร
SAFe ได้รับการพัฒนาครั้งแรกในภาคสนามและมีรายละเอียดเพิ่มเติมใน ดีน เลฟฟิงเวลล์'หนังสือและบล็อก เวอร์ชัน 1.0 เป็นเวอร์ชันอย่างเป็นทางการครั้งแรกในปี 2011 เวอร์ชันล่าสุดคือ 4.6 ซึ่งเผยแพร่ในเดือนตุลาคม 2018 โดยให้คำแนะนำในการทำงานในระดับพอร์ตโฟลิโอขององค์กร, Value Stream, โปรแกรม และทีม
เหตุใดจึงต้องใช้ SAFe Agile Framework
เป็นกรอบงานที่เรียบง่ายและมีน้ำหนักเบา แต่สามารถรองรับความต้องการของกระแสคุณค่าขนาดใหญ่และการพัฒนาระบบที่ซับซ้อนได้ โดยการนำกรอบงาน SAFe agile มาใช้ คุณจะได้รับประโยชน์ดังต่อไปนี้:
- ผลผลิตเพิ่มขึ้น by 20 -% 50
- คุณภาพ เพิ่มขึ้นมากกว่า 50%
- เวลาไปตลาด เร็วกว่า % 30-75
- เพิ่มขึ้น การมีส่วนร่วมของพนักงาน และ พึงพอใจในงาน.
แผนภาพกรอบรายละเอียดมีอยู่ใน เว็บไซต์- โดยแสดงบทบาทหลัก กิจกรรม สิ่งที่ส่งมอบ และโฟลว์ทั้งหมด นอกจากนี้ยังทำหน้าที่เป็นเครื่องช่วยนำทางไปยังส่วนที่เหลือของไซต์ด้วย
รูปภาพด้านล่างอธิบายวิธีการทำงานของกระบวนการแบบ Agile Epics เป็นงานชิ้นใหญ่ ซึ่งแบ่งออกเป็นเรื่องราวเล็กๆ น้อยๆ หรือเรื่องราวย่อยๆ อีกหลายเรื่อง มหากาพย์ย่อยเหล่านี้ได้รับการจัดสรรให้กับทีมเป็นเรื่องราว แต่ละทีมจะทำงานกับเรื่องราวหรือฟีเจอร์ซอฟต์แวร์เหล่านี้ตามลำดับ
เมื่อใดจึงควรใช้ Scaled Agile Framework
- เมื่อทีมสนใจที่จะใช้แนวทางที่คล่องตัวกับโปรแกรมและพอร์ตโฟลิโอที่ใหญ่กว่าแบบหลายทีม
- เมื่อหลายทีมดำเนินการตามแนวทาง Agile ของตนเอง แต่ต้องเผชิญกับอุปสรรค ความล่าช้า และความล้มเหลวอยู่เป็นประจำ
- เมื่อทีมต้องการทำงานอย่างอิสระ
- เมื่อคุณต้องการปรับขนาด Agile ทั่วทั้งองค์กร แต่ไม่แน่ใจว่าอาจจำเป็นต้องมีบทบาทใหม่อะไรบ้าง หรือบทบาทที่มีอยู่ (เช่น การจัดการ) จำเป็นต้องเปลี่ยนแปลงอย่างไร และอย่างไร
- เมื่อคุณพยายามที่จะปรับขนาด Agile ทั่วทั้งองค์กรของคุณ แต่ประสบปัญหาในการจัดตำแหน่งเพื่อให้บรรลุกลยุทธ์ที่สม่ำเสมอหรือสม่ำเสมอทั่วทั้งแผนกธุรกิจ ตั้งแต่พอร์ตโฟลิโอไปจนถึงระดับโปรแกรมและทีม
- เมื่อองค์กรต้องการปรับปรุงระยะเวลารอคอยในการพัฒนาผลิตภัณฑ์ และต้องการทราบว่าบริษัทอื่นๆ ประสบความสำเร็จในการปรับขนาด Agile ด้วย SAFe ได้อย่างไร
แตกต่างจากแนวทางปฏิบัติแบบ Agile อื่นๆ อย่างไร
ในบทช่วยสอน Scaled Agile Framework นี้ เรามาดูกันว่าเฟรมเวิร์ก Scaled Agile แตกต่างจากแนวทางปฏิบัติแบบ Agile อื่นๆ อย่างไร
- เปิดเผยต่อสาธารณะและใช้งานได้ฟรี
- มีจำหน่ายในรูปแบบที่เข้าถึงได้ง่ายและใช้งานได้จริง
- เป็นผลิตภัณฑ์น้ำหนักเบา พิสูจน์ได้จริงและเฉพาะเจาะจงตามระดับ
- มันปรับเปลี่ยน/รักษาแนวทางปฏิบัติแบบ Agile ที่ใช้บ่อยที่สุดอย่างต่อเนื่อง/สม่ำเสมอ
- นำเสนอส่วนขยายที่เป็นประโยชน์สำหรับแนวทางปฏิบัติทั่วไปที่คล่องตัว
- ถือเป็นแนวทางปฏิบัติที่คล่องตัวในบริบทขององค์กร
- นำเสนอภาพรวมการพัฒนาซอฟต์แวร์ที่สมบูรณ์
- การมองเห็นหรือความโปร่งใสมีมากขึ้นในทุกระดับ
- อย่างต่อเนื่องหรือข้อเสนอแนะเกี่ยวกับคุณภาพและการปรับปรุงอย่างสม่ำเสมอ
Foundationของ Scaled Agile Framework
Scaled Agile Framework (SAFe): ตั้งอยู่บนรากฐานของ
- หลักการแบบ Lean-Agile
- ค่านิยมหลัก
- ภาวะผู้นำแบบ Lean-Agile
- ชุดความคิดแบบ Lean-Agile
- กลุ่มผู้ปฏิบัติงาน (กลุ่มคนที่ทำงานเกี่ยวกับแนวทางปฏิบัติของ SAFe อย่างต่อเนื่อง)
- การดำเนินการ 1-2-3
หลักการแบบ Lean-Agile ที่ปลอดภัย
หลักการและค่านิยม SAFe Agile พื้นฐานสำหรับ SAFe เหล่านี้ต้องได้รับการทำความเข้าใจ จัดแสดง และดำเนินการต่อเพื่อให้ได้ผลลัพธ์ที่ต้องการ
- ใช้มุมมองทางเศรษฐกิจ
- ใช้การคิดอย่างเป็นระบบ
- สมมติความแปรปรวน รักษาตัวเลือกไว้
- สร้างแบบค่อยเป็นค่อยไปด้วยวงจรการเรียนรู้แบบบูรณาการที่รวดเร็ว
- เหตุการณ์สำคัญฐานในการประเมินตามวัตถุประสงค์ของระบบการทำงาน
- แสดงภาพและจำกัด WIP ลดขนาดแบทช์ และจัดการความยาวของคิว
- ใช้จังหวะและซิงโครไนซ์กับการวางแผนข้ามโดเมน
- ปลดล็อกแรงจูงใจภายในของผู้ปฏิบัติงานที่มีความรู้
- กระจายอำนาจการตัดสินใจ
ค่านิยมหลัก SAFe Agile
วิธีการ SAFe Agile อิงตามค่าสี่ค่าเหล่านี้
การจัดข้อความ:
- SAFe รองรับการจัดตำแหน่ง
- การจัดตำแหน่งเริ่มต้นที่
- ธีมเชิงกลยุทธ์ใน Portfolio Backlog และ
- เลื่อนลงไปที่ Vision and Roadmap ของ Program Backlogs จากนั้น
- ย้ายไปที่ Backlogs ของทีม
คุณภาพในตัว:
- ช่วยให้มั่นใจได้ว่าการส่งมอบที่เพิ่มขึ้นทุกครั้งจะสะท้อนถึงมาตรฐานคุณภาพ
- คุณภาพไม่ได้อยู่ที่ “เพิ่มภายหลัง” แต่สร้างไว้
- คุณภาพในตัวเป็นข้อกำหนดเบื้องต้นของ Lean และข้อบังคับ
โปร่งใส:
- ความโปร่งใสคือปัจจัยที่ทำให้เกิดความไว้วางใจ
- SAFe ช่วยให้องค์กรบรรลุความโปร่งใสในทุกระดับ - ผู้บริหาร ผู้จัดการพอร์ตโฟลิโอ และผู้มีส่วนได้ส่วนเสียอื่น ๆ
- ทุกคนสามารถดูผลงานในมือ/Kanban, โปรแกรมในมือ/Kanban และทีม Backlog/Kanban
- แต่ละระดับมีความเข้าใจเป้าหมาย PI อย่างชัดเจน
- โปรแกรมการฝึกอบรมจะมองเห็นรายการงานค้างของทีม รวมถึงรายการงานค้างอื่นๆ ของโปรแกรม
- ทีมงานและโปรแกรมต่างๆ สามารถมองเห็นภาพรวมของธุรกิจและสถาปัตยกรรม Epics ได้ พวกเขาสามารถมองเห็นสิ่งที่กำลังจะเกิดขึ้นในอนาคต
การทำงานของโปรแกรม:
- SAFe ให้ความสำคัญอย่างยิ่งกับระบบการทำงานและผลลัพธ์ทางธุรกิจที่ตามมา
- SAFe จะไม่มีประโยชน์หากทีมไม่สามารถดำเนินการและส่งมอบคุณค่าได้อย่างต่อเนื่อง
ผู้นำแบบ Lean Agile
ผู้นำแบบ Lean-Agile คือผู้เรียนรู้และเป็นครูตลอดชีวิต ช่วยให้ทีมสร้างระบบที่ดีขึ้นผ่านการทำความเข้าใจและจัดแสดงหลักการ SAFe แบบ Lean-Agile
ในฐานะผู้สนับสนุนทีม ความรับผิดชอบสูงสุดคือการนำไปใช้ ความสำเร็จ และการปรับปรุงการพัฒนาแบบ Lean-Agile อย่างต่อเนื่อง เพื่อการเปลี่ยนแปลงและการปรับปรุงอย่างต่อเนื่อง ผู้นำต้องได้รับการฝึกอบรม
ผู้นำจำเป็นต้องนำรูปแบบการเป็นผู้นำแบบใหม่มาใช้ สิ่งหนึ่งที่เสริมศักยภาพและมีส่วนร่วมกับบุคคลและทีมอย่างแท้จริงเพื่อบรรลุศักยภาพสูงสุดของพวกเขา
หลักการของผู้นำแบบ Lean-Agile เหล่านี้
- เป็นผู้นำการเปลี่ยนแปลง
- รู้ทาง; เน้นการเรียนรู้ตลอดชีวิต
- พัฒนาคน
- สร้างแรงบันดาลใจและสอดคล้องกับพันธกิจ ลดข้อจำกัดให้เหลือน้อยที่สุด
- กระจายอำนาจการตัดสินใจ
- ปลดล็อกแรงจูงใจภายในของผู้ปฏิบัติงานที่มีความรู้
ชุดความคิดแบบ Lean Agile
กรอบความคิดแบบ Lean-Agile มีสองสิ่ง:
- บ้านปลอดภัยแห่งลีน
- ประกาศเปรียว
SAFe House of Lean:
SAFe มาจากหลักการและหลักปฏิบัติด้านการผลิตแบบ Lean จากปัจจัยเหล่านี้ SAFe จึงนำเสนอ "SAFe House of Lean" ได้รับแรงบันดาลใจจาก “บ้าน” ของโตโยต้าแบบลีน
เป้าหมายของการผลิตแบบลีนนั้นไม่มีใครเทียบได้: เพื่อส่งมอบมูลค่าสูงสุดให้กับลูกค้าโดยใช้เวลารอคอยสินค้าที่สั้นที่สุดและมีคุณภาพสูงสุดเท่าที่จะเป็นไปได้ให้กับลูกค้า
รูปด้านล่างอธิบายเป้าหมาย เสาหลัก และ Foundation ของ “SAFe House of Lean”
ประกาศเปรียว
เรากำลังค้นหาวิธีการพัฒนาที่ดีกว่าเดิมping ซอฟต์แวร์โดยการลงมือทำและช่วยเหลือping คนอื่นก็ทำเช่นกัน จากการทำงานนี้ เราได้เรียนรู้คุณค่าของสิ่งต่อไปนี้:
นั่นเป็นเหตุผลว่าทำไม แม้ว่ารายการทางขวาจะมีมูลค่า แต่เรากลับให้ความสำคัญกับรายการทางด้านซ้ายมากกว่า
ประกาศเปรียว
- สิ่งที่สำคัญที่สุดคือการสร้างความพึงพอใจให้กับลูกค้าด้วยการส่งมอบซอฟต์แวร์อันทรงคุณค่าอย่างต่อเนื่องและรวดเร็วตั้งแต่เนิ่นๆ
- ยอมรับข้อกำหนดที่เปลี่ยนแปลงไป แม้จะอยู่ในช่วงการพัฒนาล่าช้าก็ตาม กระบวนการระเบียบวิธี Agile SAFe ควบคุมการเปลี่ยนแปลงเพื่อผลประโยชน์ของลูกค้า
- ส่งมอบซอฟต์แวร์ที่ใช้งานได้บ่อยครั้ง ตั้งแต่สองสามสัปดาห์ถึงสองสามเดือน โดยเลือกใช้ระยะเวลาที่สั้นกว่า
- นักพัฒนาและนักธุรกิจต้องทำงานร่วมกันทุกวันตลอดทั้งโครงการ
- สร้างโครงการเกี่ยวกับบุคคลที่มีแรงบันดาลใจ ให้การสนับสนุนและสภาพแวดล้อมที่พวกเขาต้องการ และไว้วางใจให้พวกเขาทำงานให้สำเร็จ
- วิธีสื่อสารกับทีมพัฒนาที่มีประสิทธิภาพมากที่สุดคือการสนทนาแบบเห็นหน้ากัน
- ซอฟต์แวร์ที่ใช้งานได้คือการวัดความก้าวหน้าเบื้องต้น
- กระบวนการที่คล่องตัวส่งเสริมการพัฒนาที่ยั่งยืน ผู้สนับสนุน นักพัฒนา และผู้ใช้ควรจะสามารถรักษาอัตราการก้าวให้คงที่ได้อย่างไม่มีกำหนด
- การเอาใจใส่ต่อความเป็นเลิศด้านเทคนิคและการออกแบบที่ดีอย่างต่อเนื่องจะช่วยเพิ่มความคล่องตัว
- ความเรียบง่าย ซึ่งเป็นศิลปะในการเพิ่มปริมาณงานที่ไม่ได้ทำเสร็จเป็นสิ่งสำคัญ
- สถาปัตยกรรม ความต้องการ และการออกแบบที่ดีที่สุดเกิดจากการจัดระเบียบทีมด้วยตนเอง
- ในช่วงเวลาสม่ำเสมอ ทีมจะไตร่ตรองถึงวิธีที่จะมีประสิทธิภาพมากขึ้น จากนั้นจึงปรับแต่งและปรับพฤติกรรมให้เหมาะสม
ระดับต่างๆ ใน SAFE
การใช้งาน SAFe มีสองประเภทที่แตกต่างกัน:
- การใช้งาน SAFe 4.0
- การใช้งาน SAFe 3.0
- ในการใช้งาน SAFe 4.0 เรามี 4 ระดับ: ผลงาน กระแสคุณค่า โปรแกรม และทีม
- ในการใช้งาน SAFe 3.0 เรามี 3 ระดับ: ผลงาน โปรแกรม และทีมงาน
- SAFe 3 ระดับมีไว้สำหรับการใช้งานขนาดเล็กที่มีคนไม่เกิน 100 คน โปรแกรมที่ไม่ต้องการความร่วมมือที่สำคัญ
- SAFe 4 ระดับมีไว้สำหรับโซลูชันที่โดยทั่วไปต้องใช้ผู้ปฏิบัติงานหลายร้อยคนในการพัฒนาปรับใช้และบำรุงรักษาซอฟต์แวร์
ระดับทีม
| บทบาท/ทีม | อีเวนต์ | ศิลปวัตถุ |
|---|---|---|
| ทีม Agile | Sprint การวางแผน | รายการงานค้างของทีม |
| เจ้าของสินค้า | แบ็คล็อก การดูแล | ข้อกำหนดที่ไม่ใช่หน้าที่ |
| การต่อสู้โท | การประชุมประจำวัน | วัตถุประสงค์ของทีม PI |
| การกระทำ | การทำซ้ำ | |
| Sprint ทดลอง | เรื่องราว (ซอฟต์แวร์ที่ใช้งานได้จริง) | |
| Sprint มีผลย้อนหลัง | Sprint เป้าหมาย | |
| IP Sprints | คุณภาพในตัว | |
| spikes | ||
| ทีมคันบัน |
- ทีม SAFe ทั้งหมดเป็นส่วนหนึ่งของ Agile Release Train (ART) หนึ่งหรือทีมอื่นๆ
- ทีม SAFe ได้รับการเสริมศักยภาพ จัดระเบียบตนเอง จัดการตนเอง และทำงานข้ามสายงาน
- แต่ละทีมมีหน้าที่รับผิดชอบเท่าเทียมกันในการกำหนด สร้าง และทดสอบเรื่องราวจาก Team Backlog ในรูปแบบ Iteration ที่มีความยาวคงที่
- ทีมงานวางแผนและดำเนินการตามระยะเวลาที่กำหนดสองสัปดาห์ตามเป้าหมายการทำซ้ำที่ตกลงกันไว้
- ทีมจะใช้รูทีน ScrumXP/Team Kanban เพื่อส่งมอบระบบคุณภาพสูงเพื่อสร้าง System Demo ทุกๆ สองสัปดาห์
- ทีมงานที่แตกต่างกันทั้งหมดใน ART (Agile Release Trains) จะสร้างระบบที่บูรณาการและทดสอบแล้ว ผู้มีส่วนได้ส่วนเสียจะประเมินและตอบกลับพร้อมข้อเสนอแนะที่รวดเร็ว
- พวกเขาใช้แนวทางปฏิบัติด้านคุณภาพที่มีอยู่แล้วภายใน
- ทีม ScrumXP แต่ละทีมจะมีสมาชิกในทีม 5-9 คน ซึ่งรวมถึงบทบาททั้งหมดที่จำเป็นในการสร้างมูลค่าเพิ่มด้านคุณภาพในแต่ละ Iteration
- บทบาท ScrumXP ประกอบด้วย:
- ทีม (นักพัฒนา + ผู้ทดสอบคุณภาพ)
- การต่อสู้โท
- เจ้าของผลิตภัณฑ์. ฯลฯ..
- SAFe แบ่งไทม์ไลน์การพัฒนาออกเป็นชุดของการวนซ้ำภายใน PI (การเพิ่มระดับโปรแกรม)
- ระยะเวลา PI อยู่ระหว่าง 8 -12 สัปดาห์
- ทีมงานจะใช้เรื่องราวเพื่อส่งมอบคุณค่า เจ้าของผลิตภัณฑ์จะมีอำนาจด้านเนื้อหาในการสร้างและยอมรับเรื่องราวของตน
- เรื่องราวประกอบด้วยความต้องการของลูกค้า
- Team Backlog รวมถึงเรื่องราวของผู้ใช้และตัวเปิดใช้งาน ซึ่งได้รับการระบุในระหว่างการวางแผน PI เมื่อฝ่ายบริหารผลิตภัณฑ์นำเสนอ Roadmap วิสัยทัศน์ และ Program Backlog
- การระบุ อธิบายรายละเอียด จัดลำดับความสำคัญ กำหนดเวลา นำไปใช้ ทดสอบ และยอมรับเรื่องราวเป็นข้อกำหนดหลักของงานฝ่ายบริหารในระดับทีม
- การวนซ้ำแต่ละครั้งจะมี:
- การเพิ่มฟังก์ชันใหม่อันทรงคุณค่า
- สำเร็จด้วยรูปแบบการทำซ้ำอย่างต่อเนื่อง
- วางแผนการทำซ้ำ
- มุ่งมั่นกับฟังก์ชันบางอย่าง
- ดำเนินการวนซ้ำโดยการสร้างและทดสอบเรื่องราว
- สาธิตฟังก์ชั่นใหม่
- มีผลย้อนหลัง
- ทำซ้ำสำหรับการวนซ้ำครั้งต่อไป
- ทีมยังสนับสนุนการสาธิตระบบเมื่อสิ้นสุดการทำซ้ำแต่ละครั้ง ซึ่งเป็นจุดบูรณาการที่สำคัญสำหรับ ART
- สตรีมค่าที่มากขึ้นจะมี ART หลายรายการ
- การทำซ้ำด้านนวัตกรรมและการวางแผน (IP) ช่วยให้ทีมงานมีโอกาสในการริเริ่มนวัตกรรมและการสำรวจ
ระดับโปรแกรม
| บทบาท/ทีม | อีเวนต์ | ศิลปวัตถุ |
|---|---|---|
| DevOps | การวางแผน PI (Program Increment) | วิสัยทัศน์: |
| ทีมระบบ | การสาธิตระบบ | แผนงาน |
| การจัดการการปล่อย | การประชุมเชิงปฏิบัติการตรวจสอบและรับรอง | ตัวชี้วัด |
| การจัดการผลิตภัณฑ์ | Archiรันเวย์รันเวย์ | เหตุการณ์สำคัญ |
| ยูเอ็กซ์ ArchiTect | ปล่อยได้ทุกเมื่อ | สัมพันธ์ |
| วิศวกรกระบวนการปล่อยผลิตภัณฑ์ (Release Train Engineer - RTE) | Agile Release Train | โปรแกรม Epics |
| System Archiเทค/วิศวกร | ปล่อย | โปรแกรม Kanban |
| เจ้าของธุรกิจ | รายการค้างของโปรแกรม | |
| ผู้นำแบบลีน-อะจิล | ข้อกำหนดที่ไม่ใช่หน้าที่ | |
| ชุมชนแห่งการปฏิบัติ | การจัดลำดับงานโดยใช้เกณฑ์ถ่วงน้ำหนักแบบ Shortest Job First (WSJF) | |
| บริการที่ใช้ร่วมกัน | วัตถุประสงค์ของโครงการ PI | |
| ลูกค้า | คุณสมบัติ (Feature) | |
| Enabler | ||
| Solution | ||
| การประสานงานกระแสคุณค่า |
- ในระดับโปรแกรม คุณค่าของ SAFe จะถูกส่งโดย Agile Release Trains (ART) ที่มีอายุการใช้งานยาวนาน การวนซ้ำมีไว้สำหรับทีมและการฝึกฝนมีไว้สำหรับโปรแกรม
- Agile Release Trains (ART) เป็นเครื่องมือหลักในการส่งมอบคุณค่าในระดับโปรแกรม มันส่งมอบกระแสคุณค่าให้กับองค์กร
- ระยะเวลาการเพิ่มโปรแกรม (PI) คือ 8 ถึง 12 สัปดาห์
- ART ประกอบด้วยทีม Agile 5 – 12 ทีม (~ 50 – 125+ คน) ซึ่งรวมถึงบทบาทและโครงสร้างพื้นฐานทั้งหมดที่จำเป็นในการส่งมอบซอฟต์แวร์ระดับระบบที่ผ่านการทดสอบและใช้งานได้อย่างสมบูรณ์
- PI แต่ละตัวจะเป็นกล่องเวลาที่มีการทำซ้ำหลายครั้ง ซึ่งในระหว่างนี้ จะมีการพัฒนาและส่งมอบส่วนเพิ่มที่สำคัญและมีคุณค่าของระบบ
- ในแต่ละ PI เซสชัน "สาธิต" และ "ตรวจสอบและปรับเปลี่ยน" จะเกิดขึ้น และการวางแผนจะเริ่มต้นสำหรับ PSI ถัดไป
- ในระดับโปรแกรม SAFe เน้นหลักการการจัดตำแหน่ง เนื่องจากมีการบูรณาการความพยายามของทีมที่คล่องตัวหลายอย่างเพื่อสร้างมูลค่าให้กับลูกค้า
- ลำดับชั้นของสิ่งประดิษฐ์ SAFe คือ Epics->คุณสมบัติ->เรื่องราวของผู้ใช้.
- ในระดับโปรแกรม ผู้จัดการผลิตภัณฑ์/ผู้จัดการโปรแกรมมีสิทธิ์ด้านเนื้อหา เขากำหนดและจัดลำดับความสำคัญของงานที่ค้างอยู่ของโปรแกรม
- Backlog ของโปรแกรมคือรายการคุณสมบัติที่จัดลำดับความสำคัญ
- ในระดับโปรแกรม คุณลักษณะต่างๆ สามารถเกิดขึ้นได้ หรืออาจมาจากมหากาพย์ที่กำหนดไว้ในระดับพอร์ตโฟลิโอก็ได้
- ฟีเจอร์จะแยกย่อยตามเรื่องราวของผู้ใช้และไหลไปสู่งานค้างระดับทีม
- ผู้จัดการผลิตภัณฑ์หรือบทบาทวิศวกรฝึกอบรมการวางจำหน่ายสามารถจัดการโดยผู้จัดการโครงการ/ผู้จัดการโครงการอาวุโส
- System Archiบทบาทที่รับผิดชอบในระดับโปรแกรมคือการทำงานร่วมกันในแต่ละวันกับทีมงาน เพื่อให้แน่ใจว่าได้ปฏิบัติตามข้อกำหนดที่ไม่เกี่ยวกับฟังก์ชัน นอกจากนี้ พวกเขายังทำงานร่วมกับสถาปนิกองค์กรในระดับพอร์ตโฟลิโอเพื่อให้แน่ใจว่ามีสถาปัตยกรรมที่เพียงพอเพื่อรองรับความต้องการของผู้ใช้และธุรกิจในอนาคต
- การออกแบบอินเทอร์เฟซ แนวทางประสบการณ์ผู้ใช้ และองค์ประกอบการออกแบบสำหรับทีมจัดทำโดยนักออกแบบ UX
- บทบาท Chief-Scrum Master ดำเนินการโดย 'Release Train Engineer'
- ทีมงานต่างๆ (ตั้งแต่ฝ่ายการตลาด การพัฒนา คุณภาพ การดำเนินงาน และการปรับใช้) จัดตั้ง 'ทีมจัดการการเผยแพร่' พวกเขาจะอนุมัติการเผยแพร่โซลูชันคุณภาพเป็นประจำให้กับลูกค้า
- การปรับใช้ซอฟต์แวร์ในสภาพแวดล้อมของลูกค้าและการส่งมอบที่ประสบความสำเร็จได้รับการดูแลโดยทีมงาน DevOps
ระดับพอร์ตโฟลิโอ
| บทบาท/ทีม | อีเวนต์ | ศิลปวัตถุ |
|---|---|---|
| Enterprise Architect | การวางแผนการลงทุนเชิงกลยุทธ์ | หัวข้อเชิงกลยุทธ์ |
| การจัดการพอร์ตโฟลิโอโปรแกรม | การวางแผนพอร์ตโฟลิโอแบบคันบัน (Epic) | Enterprise |
| เจ้าของ Epic | รายการงานค้างในพอร์ตโฟลิโอ | |
| ผลงานคัมบัง | ||
| ข้อกำหนดที่ไม่ใช่หน้าที่ | ||
| มหากาพย์และผู้สนับสนุน | ||
| สายธารแห่งคุณค่า | ||
| งบประมาณ (งบประมาณลงทุนและงบประมาณดำเนินงาน) |
- ระดับความสนใจ/ข้อกังวล/การมีส่วนร่วม/ใน SAFe ระดับสูงสุดคือ ผลงานที่ปลอดภัย
- พอร์ตโฟลิโอจัดเตรียมบล็อกพื้นฐานสำหรับจัดระเบียบกระแสคุณค่าขององค์กรแบบ Lean-Agile ผ่านทาง Value Stream หนึ่งรายการขึ้นไป
- พอร์ตโฟลิโอช่วยในการพัฒนาระบบและโซลูชันซึ่งอธิบายไว้ในธีมเชิงกลยุทธ์ (เชื่อมโยงพอร์ตโฟลิโอ SAFe กับกลยุทธ์ทางธุรกิจที่เปลี่ยนแปลงไปขององค์กร)
- เพื่อให้บรรลุวัตถุประสงค์เชิงกลยุทธ์ ระดับพอร์ตโฟลิโอจึงสรุปองค์ประกอบเหล่านี้ โดยจัดให้มีการจัดทำงบประมาณขั้นพื้นฐานและกลไกการกำกับดูแลอื่นๆ วิธีนี้ช่วยให้มั่นใจได้ว่าการลงทุนในกระแสคุณค่าจะให้ผลตอบแทนที่จำเป็นสำหรับองค์กร
- พอร์ตโฟลิโอเชื่อมโยงกับธุรกิจแบบสองทิศทาง:
- เพื่อเป็นแนวทางให้พอร์ตโฟลิโอบรรลุวัตถุประสงค์ทางธุรกิจที่เปลี่ยนแปลงไปในวงกว้าง จึงจัดให้มีธีมเชิงกลยุทธ์
- อีกทิศทางหนึ่งบ่งบอกถึงการไหลอย่างต่อเนื่องของมูลค่าพอร์ตโฟลิโอ
- การจัดการพอร์ตโฟลิโอของโปรแกรมทำหน้าที่เป็นผู้มีส่วนได้ส่วนเสีย และมีความรับผิดชอบต่อการส่งมอบผลลัพธ์ทางธุรกิจ
- SAFe Portfolio Level ประกอบด้วยบุคลากร กระบวนการ และระบบการสร้างและโซลูชันที่จำเป็นซึ่งองค์กรต้องการเพื่อให้บรรลุวัตถุประสงค์เชิงกลยุทธ์
- กระแสคุณค่าเป็นวัตถุประสงค์หลักในพอร์ตโฟลิโอ โดยให้เงินทุนสำหรับบุคลากรและทรัพยากรอื่นๆ ที่จำเป็นในการสร้างโซลูชัน
- แนวคิดหลักที่สำคัญที่ใช้ที่นี่คือ:
- การเชื่อมต่อกับองค์กร
- การจัดการพอร์ตโฟลิโอโปรแกรม
- การจัดการโฟลว์ของ Portfolio Epics
ระดับกระแสคุณค่า
| บทบาท/ทีม | อีเวนต์ | ศิลปวัตถุ |
|---|---|---|
| DevOps | การวางแผนก่อนและหลัง PI (Program Increment) | วิสัยทัศน์: |
| ทีมระบบ | การสาธิตโซลูชัน | แผนงาน |
| การจัดการการปล่อย | การประชุมเชิงปฏิบัติการตรวจสอบและรับรอง | ตัวชี้วัด |
| การจัดการโซลูชั่น | Agile Release Train | เหตุการณ์สำคัญ |
| ยูเอ็กซ์ ArchiTect | สัมพันธ์ | |
| วิศวกรกระบวนการสร้างมูลค่า (RTE) | มหากาพย์กระแสคุณค่า | |
| Solution Archiเทค/วิศวกร | คันบันกระแสคุณค่า | |
| บริการที่ใช้ร่วมกัน | รายการค้างของกระบวนการสร้างมูลค่า | |
| ลูกค้า | ข้อกำหนดที่ไม่ใช่หน้าที่ | |
| ผู้ผลิต | การจัดลำดับงานโดยใช้เกณฑ์ถ่วงน้ำหนักแบบ Shortest Job First (WSJF) | |
| วัตถุประสงค์ของการปรับปรุงกระบวนการทำงาน (PI) ของกระแสคุณค่า | ||
| ความสามารถ | ||
| Enabler | ||
| บริบทของโซลูชัน | ||
| การประสานงานกระแสคุณค่า | ||
| กรอบเศรษฐกิจ | ||
| เจตนาของโซลูชัน | ||
| เอ็มบีเอสอี | ||
| ตั้งค่าตาม | ||
| คล่องแคล่ว Archiเทคเจอร์ |
- ระดับสตรีมค่าเป็นทางเลือกใน SAFe
- Value Stream Level เป็นฟีเจอร์ใหม่ใน SAFe 4.0
- ระดับกระแสคุณค่ามีไว้สำหรับ/ออกแบบมาสำหรับองค์กร/ผู้สร้าง/องค์กรที่:
- ขนาดใหญ่
- อิสระ
- มีโซลูชันที่ซับซ้อน
- โดยทั่วไปแล้วโซลูชันของพวกเขาต้องใช้ ART หลายรายการ
- พวกเขามีส่วนสนับสนุนซัพพลายเออร์
- พวกเขาเผชิญกับความท้าทายด้านระบบที่ใหญ่ที่สุด
- สำหรับระบบไซเบอร์กายภาพ
- สำหรับซอฟต์แวร์ ฮาร์ดแวร์ ไฟฟ้าและอิเล็กทรอนิกส์ อุปกรณ์ออปติก กลไก ของไหล และอื่นๆ อีกมากมาย
- การสร้างระบบประเภทนี้มักจะต้องใช้ผู้ปฏิบัติงานหลายร้อยหรือหลายพันคน ตลอดจนซัพพลายเออร์ทั้งภายนอกและภายใน
- หากระบบมีภารกิจสำคัญ ความล้มเหลวของโซลูชัน หรือแม้แต่ระบบย่อย มีผลกระทบทางเศรษฐกิจและสังคมที่ยอมรับไม่ได้
- ถ้าวิสาหกิจสามารถสร้างได้ด้วยผู้ฝึกไม่กี่ร้อยคน ก็อาจไม่จำเป็นต้องมีการก่อสร้างระดับนี้ ในกรณีนี้พวกเขาสามารถใช้จาก 'มุมมองยุบ' ซึ่งเป็นระบบ SAFe 3 ระดับ
- การสร้างโซลูชันกระแสคุณค่าในรูปแบบ Lean-Agile ต้องใช้สิ่งประดิษฐ์ การประสานงาน และโครงสร้างเพิ่มเติม ดังนั้นระดับนี้จึงมีกรอบการทำงานทางเศรษฐกิจเพื่อกำหนดขอบเขตทางการเงินสำหรับ Value Stream
- รองรับจังหวะและการซิงโครไนซ์สำหรับ ART และซัพพลายเออร์หลายราย รวมถึงการประชุมวางแผนก่อนและหลัง PI และการสาธิตโซลูชัน
- โดยให้บทบาทเพิ่มเติม ได้แก่: Value Stream Engineer, Solution Archiเทค/วิศวกรรม และการจัดการโซลูชัน
