บทช่วยสอน SAFe (Scaled Agile Framework)

ปลอดภัย กรอบการทำงานช่วยให้ทีมงานสามารถ

• การใช้ซอฟต์แวร์และระบบ 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): ตั้งอยู่บนรากฐานของ

1. หลักการแบบ Lean-Agile
2. ค่านิยมหลัก
3. ภาวะผู้นำแบบ Lean-Agile
4. ชุดความคิดแบบ Lean-Agile
5. ชุมชนแห่งการปฏิบัติ (กลุ่มคนที่ทำงานเกี่ยวกับแนวปฏิบัติ SAFe อย่างต่อเนื่อง)
6. การดำเนินการ 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 มีสองสิ่ง:

1. บ้านปลอดภัยแห่งลีน
2. ประกาศเปรียว

บ้านปลอดภัยแห่งลีน:

SAFe มาจากหลักการและหลักปฏิบัติด้านการผลิตแบบ Lean จากปัจจัยเหล่านี้ SAFe จึงนำเสนอ "SAFe House of Lean" ได้รับแรงบันดาลใจจาก “บ้าน” ของโตโยต้าแบบลีน

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

รูปด้านล่างอธิบายเป้าหมาย เสาหลัก และ Foundation ของ “SAFe House of Lean”

ประกาศเปรียว

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

นั่นเป็นเหตุผลว่าทำไม แม้ว่ารายการทางขวาจะมีมูลค่า แต่เรากลับให้ความสำคัญกับรายการทางด้านซ้ายมากกว่า

ประกาศเปรียว

1. สิ่งที่สำคัญที่สุดคือการสร้างความพึงพอใจให้กับลูกค้าด้วยการส่งมอบซอฟต์แวร์อันทรงคุณค่าอย่างต่อเนื่องและรวดเร็วตั้งแต่เนิ่นๆ
2. ยอมรับข้อกำหนดที่เปลี่ยนแปลงไป แม้จะอยู่ในช่วงการพัฒนาล่าช้าก็ตาม กระบวนการระเบียบวิธี Agile SAFe ควบคุมการเปลี่ยนแปลงเพื่อผลประโยชน์ของลูกค้า
3. ส่งมอบซอฟต์แวร์ที่ใช้งานได้บ่อยครั้ง ตั้งแต่สองสามสัปดาห์ถึงสองสามเดือน โดยเลือกใช้ระยะเวลาที่สั้นกว่า
4. นักพัฒนาและนักธุรกิจต้องทำงานร่วมกันทุกวันตลอดทั้งโครงการ
5. สร้างโครงการเกี่ยวกับบุคคลที่มีแรงบันดาลใจ ให้การสนับสนุนและสภาพแวดล้อมที่พวกเขาต้องการ และไว้วางใจให้พวกเขาทำงานให้สำเร็จ
6. วิธีสื่อสารกับทีมพัฒนาที่มีประสิทธิภาพมากที่สุดคือการสนทนาแบบเห็นหน้ากัน
7. ซอฟต์แวร์ที่ใช้งานได้คือการวัดความก้าวหน้าเบื้องต้น
8. กระบวนการที่คล่องตัวส่งเสริมการพัฒนาที่ยั่งยืน ผู้สนับสนุน นักพัฒนา และผู้ใช้ควรจะสามารถรักษาอัตราการก้าวให้คงที่ได้อย่างไม่มีกำหนด
9. การเอาใจใส่ต่อความเป็นเลิศด้านเทคนิคและการออกแบบที่ดีอย่างต่อเนื่องจะช่วยเพิ่มความคล่องตัว
10. ความเรียบง่าย ซึ่งเป็นศิลปะในการเพิ่มปริมาณงานที่ไม่ได้ทำเสร็จเป็นสิ่งสำคัญ
11. สถาปัตยกรรม ความต้องการ และการออกแบบที่ดีที่สุดเกิดจากการจัดระเบียบทีมด้วยตนเอง
12. ในช่วงเวลาสม่ำเสมอ ทีมจะไตร่ตรองถึงวิธีที่จะมีประสิทธิภาพมากขึ้น จากนั้นจึงปรับแต่งและปรับพฤติกรรมให้เหมาะสม

ระดับต่างๆ ใน ​​SAFE

การใช้งาน SAFe มีสองประเภทที่แตกต่างกัน:

1. การใช้งาน SAFe 4.0
2. การใช้งาน SAFe 3.0

• ในการใช้งาน SAFe 4.0 เรามี 4 ระดับ: ผลงาน กระแสคุณค่า โปรแกรม และทีม
• ในการใช้งาน SAFe 3.0 เรามี 3 ระดับ: ผลงาน โปรแกรม และทีมงาน
• SAFe 3 ระดับมีไว้สำหรับการใช้งานขนาดเล็กที่มีคนไม่เกิน 100 คน โปรแกรมที่ไม่ต้องการความร่วมมือที่สำคัญ
• SAFe 4 ระดับมีไว้สำหรับโซลูชันที่โดยทั่วไปต้องใช้ผู้ปฏิบัติงานหลายร้อยคนในการพัฒนาปรับใช้และบำรุงรักษาซอฟต์แวร์

ระดับทีม

บทบาท/ทีม		งานอีเว้นท์		ศิลปวัตถุ
* ทีมเปรียว		* Sprint การวางแผน		* ทีมที่ค้างอยู่
* เจ้าของผลิตภัณฑ์		* การกรูมมิ่ง Backlog		* ข้อกำหนดที่ไม่สามารถใช้งานได้
* สครัมมาสเตอร์		* ยืนขึ้นทุกวัน		* วัตถุประสงค์ PI ของทีม
		* การดำเนินการ		* การวนซ้ำ
		* Sprint ทดลอง		* เรื่องราว (ซอฟต์แวร์ทำงาน)
		* Sprint มีผลย้อนหลัง		* Sprint เป้าหมาย
		* ไอพี Sprints		* คุณภาพในตัว
				* เดือย
				* ทีมคัมบัง

• ทีม 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 (การเพิ่มโปรแกรม) การวางแผน		* วิสัยทัศน์
* ทีมงานระบบ		* การสาธิตระบบ		* แผนงาน
* การจัดการการเปิดตัว		* ตรวจสอบและยอมรับการประชุมเชิงปฏิบัติการ		* ตัวชี้วัด
* การจัดการผลิตภัณฑ์		* Archiรันเวย์รันเวย์		* เหตุการณ์สำคัญ
* UEX ArchiTect		* ปล่อยได้ตลอดเวลา		* เผยแพร่
* วิศวกรรถไฟปล่อย (RTE)		* รถไฟปล่อยเปรียว		* โปรแกรมมหากาพย์
* ระบบ Archiเทค/วิศวกร		* ปล่อย		* โปรแกรมคัมบัง
* เจ้าของธุรกิจ				* โปรแกรมค้าง
* ผู้นำแบบ Lean-Agile				* ข้อกำหนดที่ไม่สามารถใช้งานได้
* ชุมชนแห่งการปฏิบัติ				* งานที่สั้นที่สุดแบบถ่วงน้ำหนักก่อน (WSJF)
* บริการที่ใช้ร่วมกัน				* วัตถุประสงค์ของโปรแกรม PI
* ลูกค้า				* คุณสมบัติ
				* เปิดใช้งาน
				* สารละลาย
				* การประสานงานสายธารคุณค่า

• ในระดับโปรแกรม คุณค่าของ 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		* การวางแผนการลงทุนเชิงกลยุทธ์		* ธีมเชิงกลยุทธ์
* การจัดการพอร์ตโฟลิโอโปรแกรม		* การวางแผนผลงาน Kanban (Epic)		* องค์กร
* เจ้าของมหากาพย์				* ผลงานที่ค้างอยู่
				* ผลงานคัมบัง
				* ข้อกำหนดที่ไม่สามารถใช้งานได้
				* มหากาพย์และตัวเปิดใช้งาน
				* กระแสคุณค่า
				* งบประมาณ (CapEx และ OpEx)

• ระดับความสนใจ/ข้อกังวล/การมีส่วนร่วม/ใน SAFe ระดับสูงสุดคือ ผลงานที่ปลอดภัย
• พอร์ตโฟลิโอจัดเตรียมบล็อกพื้นฐานสำหรับจัดระเบียบกระแสคุณค่าขององค์กรแบบ Lean-Agile ผ่านทาง Value Stream หนึ่งรายการขึ้นไป
• พอร์ตโฟลิโอช่วยในการพัฒนาระบบและโซลูชันซึ่งอธิบายไว้ในธีมเชิงกลยุทธ์ (เชื่อมโยงพอร์ตโฟลิโอ SAFe กับกลยุทธ์ทางธุรกิจที่เปลี่ยนแปลงไปขององค์กร)
• เพื่อให้บรรลุวัตถุประสงค์เชิงกลยุทธ์ ระดับพอร์ตโฟลิโอจึงสรุปองค์ประกอบเหล่านี้ โดยจัดให้มีการจัดทำงบประมาณขั้นพื้นฐานและกลไกการกำกับดูแลอื่นๆ วิธีนี้ช่วยให้มั่นใจได้ว่าการลงทุนในกระแสคุณค่าจะให้ผลตอบแทนที่จำเป็นสำหรับองค์กร
• พอร์ตโฟลิโอเชื่อมโยงกับธุรกิจแบบสองทิศทาง:
  • เพื่อเป็นแนวทางให้พอร์ตโฟลิโอบรรลุวัตถุประสงค์ทางธุรกิจที่เปลี่ยนแปลงไปในวงกว้าง จึงจัดให้มีธีมเชิงกลยุทธ์
  • อีกทิศทางหนึ่งบ่งบอกถึงการไหลอย่างต่อเนื่องของมูลค่าพอร์ตโฟลิโอ
• การจัดการพอร์ตโฟลิโอของโปรแกรมทำหน้าที่เป็นผู้มีส่วนได้ส่วนเสีย และมีความรับผิดชอบต่อการส่งมอบผลลัพธ์ทางธุรกิจ
• SAFe Portfolio Level ประกอบด้วยบุคลากร กระบวนการ และระบบการสร้างและโซลูชันที่จำเป็นซึ่งองค์กรต้องการเพื่อให้บรรลุวัตถุประสงค์เชิงกลยุทธ์
• กระแสคุณค่าเป็นวัตถุประสงค์หลักในพอร์ตโฟลิโอ โดยให้เงินทุนสำหรับบุคลากรและทรัพยากรอื่นๆ ที่จำเป็นในการสร้างโซลูชัน
• แนวคิดหลักที่สำคัญที่ใช้ที่นี่คือ:
  • การเชื่อมต่อกับองค์กร
  • การจัดการพอร์ตโฟลิโอโปรแกรม
  • การจัดการโฟลว์ของ Portfolio Epics

ระดับกระแสคุณค่า

บทบาท/ทีม		งานอีเว้นท์		ศิลปวัตถุ
* DevOps		* การวางแผน PI ก่อนและหลัง (การเพิ่มโปรแกรม)		* วิสัยทัศน์
* ทีมงานระบบ		* การสาธิตโซลูชัน		* แผนงาน
* การจัดการการเปิดตัว		* ตรวจสอบและยอมรับการประชุมเชิงปฏิบัติการ		* ตัวชี้วัด
* การจัดการโซลูชัน		* รถไฟปล่อยเปรียว		* เหตุการณ์สำคัญ
* UEX ArchiTect				* เผยแพร่
* วิศวกรสายธารคุณค่า (RTE)				* มหากาพย์สตรีมคุณค่า
* สารละลาย Archiเทค/วิศวกร				* สตรีมค่าคัมบัง
* บริการที่ใช้ร่วมกัน				* กระแสมูลค่าที่ค้างอยู่
* ลูกค้า				* ข้อกำหนดที่ไม่ใช่หน้าที่
* ผู้จัดหา				* งานที่สั้นที่สุดแบบถ่วงน้ำหนักก่อน (WSJF)
				* วัตถุประสงค์ PI กระแสคุณค่า
				* ความสามารถ
				* เปิดใช้งาน
				* บริบทของโซลูชัน
				* การประสานงานสายธารคุณค่า
				* กรอบเศรษฐกิจ
				* ความตั้งใจในการแก้ปัญหา
				* MBSE
				* กำหนดตาม
				* เปรียว Archiเทคเจอร์

• ระดับสตรีมค่าเป็นทางเลือกใน SAFe
• Value Stream Level เป็นฟีเจอร์ใหม่ใน SAFe 4.0
• ระดับกระแสคุณค่ามีไว้สำหรับ/ออกแบบมาสำหรับองค์กร/ผู้สร้าง/องค์กรที่:

1. ขนาดใหญ่
2. อิสระ
3. มีโซลูชันที่ซับซ้อน
4. โดยทั่วไปแล้วโซลูชันของพวกเขาต้องใช้ ART หลายรายการ
5. พวกเขามีส่วนสนับสนุนซัพพลายเออร์
6. พวกเขาเผชิญกับความท้าทายด้านระบบที่ใหญ่ที่สุด
7. สำหรับระบบไซเบอร์กายภาพ
8. สำหรับซอฟต์แวร์ ฮาร์ดแวร์ ไฟฟ้าและอิเล็กทรอนิกส์ อุปกรณ์ออปติก กลไก ของไหล และอื่นๆ อีกมากมาย

• การสร้างระบบประเภทนี้มักจะต้องใช้ผู้ปฏิบัติงานหลายร้อยหรือหลายพันคน ตลอดจนซัพพลายเออร์ทั้งภายนอกและภายใน
• หากระบบมีภารกิจสำคัญ ความล้มเหลวของโซลูชัน หรือแม้แต่ระบบย่อย มีผลกระทบทางเศรษฐกิจและสังคมที่ยอมรับไม่ได้
• ถ้าวิสาหกิจสามารถสร้างได้ด้วยผู้ฝึกไม่กี่ร้อยคน ก็อาจไม่จำเป็นต้องมีการก่อสร้างระดับนี้ ในกรณีนี้พวกเขาสามารถใช้จาก 'มุมมองยุบ' ซึ่งเป็นระบบ SAFe 3 ระดับ
• การสร้างโซลูชันกระแสคุณค่าในรูปแบบ Lean-Agile ต้องใช้สิ่งประดิษฐ์ การประสานงาน และโครงสร้างเพิ่มเติม ดังนั้นระดับนี้จึงมีกรอบการทำงานทางเศรษฐกิจเพื่อกำหนดขอบเขตทางการเงินสำหรับ Value Stream
• รองรับจังหวะและการซิงโครไนซ์สำหรับ ART และซัพพลายเออร์หลายราย รวมถึงการประชุมวางแผนก่อนและหลัง PI และการสาธิตโซลูชัน
• โดยให้บทบาทเพิ่มเติม ได้แก่: Value Stream Engineer, Solution Archiเทค/วิศวกรรม และการจัดการโซลูชัน

สรุป

• SAFe เป็นวิธีการที่ได้รับการพิสูจน์แล้วในอุตสาหกรรมและมุ่งเน้นคุณค่าในการขยายขนาด Agile ในระดับองค์กร
• ตอบคำถามเช่น “เราจะวางแผนอย่างไร” “เราจะจัดงบประมาณอย่างไร” และ “เราจะทำงานข้ามฟังก์ชันในงานสถาปัตยกรรมได้อย่างไร” นักพัฒนาซอฟต์แวร์?"
• กรอบงาน SAFe Agile ช่วยให้ทีมองค์กรขนาดใหญ่บรรลุเป้าหมายเชิงกลยุทธ์ขององค์กร ไม่ใช่แค่เป้าหมายโครงการแต่ละโครงการ
• กรอบการทำงานนำเสนอความสามารถในการรักษาและสร้างกลยุทธ์แบบรวมศูนย์เพื่อส่งมอบคุณค่า
• โมเดล SAFe มีสามหรือสี่ระดับที่รวมศูนย์ธีมเชิงกลยุทธ์ขององค์กร
• กลยุทธ์แบบรวมศูนย์ ผสมผสานกับการดำเนินการพัฒนาแบบกระจายอำนาจแบบกระจายอำนาจ

อ้างอิง:

SAFe สำหรับองค์กรแบบ Lean 5.0:

http://www.scaledagileframework.com