พิมพ์เขียวการจัดการโครงการ ตอนที่ 2: การเปรียบเทียบน้ำตก DAD ปลอดภัย LeSS และ Scrum@Scale อย่างครอบคลุม

ภาพรวม

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

ในส่วนที่ 2 เราจะเจาะลึกถึงวิธีที่ผู้จัดการโครงการใช้วิธีการแบบน้ำตก ซึ่งเป็นกรอบงานทั่วไปที่สุดสำหรับการพัฒนาซอฟต์แวร์ในบริษัทแบบดั้งเดิม เมื่อพิจารณาจากสิ่งนี้ เราจะกล่าวถึงเฟรมเวิร์กยอดนิยมที่พยายามรวมหลักการที่คล่องตัวในระดับต่างๆ เช่น Disciplined Agile Delivery (DAD), Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS) และ Scrum@Scale

น้ำตก

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

วงจรชีวิตหกช่วงของแบบจำลองน้ำตกดั้งเดิมคือ:

1. ข้อกำหนด: ในระยะนี้ ความคาดหวังและเป้าหมายของโครงการได้รับการกำหนดไว้ และข้อกำหนดจะได้รับการวิเคราะห์และจัดทำเป็นเอกสารอย่างกว้างขวาง ซึ่งมักจะโดยนักวิเคราะห์ธุรกิจ ข้อกำหนดจะได้รับการตรวจสอบและอนุมัติก่อนออกจากระยะนี้
2. การออกแบบ: หลังจากที่ข้อกำหนดได้รับการอนุมัติแล้ว งานจะเริ่มเกี่ยวกับการออกแบบสถาปัตยกรรมและการออกแบบผลิตภัณฑ์เพื่อให้เป็นไปตามข้อกำหนดที่ได้รับอนุมัติ สถาปัตยกรรมทางกายภาพ สถาปัตยกรรมส่วนประกอบ การออกแบบฐานข้อมูล องค์ประกอบโดยละเอียด การออกแบบโมดูล และด้านอื่นๆ ของการออกแบบได้รับการจัดทำเป็นเอกสารโดยสถาปนิกหรือนักออกแบบซอฟต์แวร์ จากนั้นจะมีการทบทวนและอนุมัติก่อนเริ่มดำเนินการ
3. การใช้งาน: หลังจากที่การออกแบบได้รับการอนุมัติ การใช้งานหรือการเข้ารหัสของซอฟต์แวร์ตามข้อกำหนดและการออกแบบจะทำโดยนักพัฒนาซอฟต์แวร์
4. การ ตรวจสอบความถูกต้อง: หลังจากการใช้งานเสร็จสิ้น ซอฟต์แวร์จะได้รับการทดสอบโดยทีมทดสอบหรือทีม QA เพื่อให้แน่ใจว่าตรงตามข้อกำหนดและการออกแบบและบรรลุระดับคุณภาพที่ต้องการ พบข้อบกพร่อง บันทึก คัดแยก และแก้ไขในหลายกรณี
5. การนำ ออกใช้และการบำรุงรักษา: หลังจากการทดสอบและการดีบักเสร็จสิ้น ผลิตภัณฑ์จะถูกนำออกใช้กับไคลเอ็นต์และติดตั้ง บ่อยครั้ง การทดสอบหนึ่งรอบเกิดขึ้นเพื่อให้แน่ใจว่าการติดตั้งสำเร็จ หลังจากจัดส่งผลิตภัณฑ์แล้ว จะมีการบำรุงรักษาและการสนับสนุนอย่างต่อเนื่องเพื่อให้แน่ใจว่าผลิตภัณฑ์จะทำงานต่อไปตามที่ออกแบบไว้

ข้อดีของน้ำตก

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

หากนำไปใช้กับประเภทโครงการที่เหมาะสม ข้อดีบางประการของแบบจำลองน้ำตก:

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

ข้อเสียของน้ำตก

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

ข้อเสียของแบบจำลองน้ำตกซึ่งส่วนใหญ่เน้นที่ความสามารถในการปรับตัวต่อการเปลี่ยนแปลงไม่ได้ ได้แก่:

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

วินัย เปรียว เดลิเวอรี่ (DAD)

การส่งมอบแบบคล่องตัว (DAD) แบบมีระเบียบวินัย (DAD) ได้รับการทำให้เป็นทางการโดย Scott Ambler จาก IBM และ Mark Lines และขยายไปตามเฟรมเวิร์กที่คล่องแคล่วและว่องไว โดยตระหนักว่าส่วนที่ไม่คล่องตัวขององค์กรมักจะเกี่ยวข้องกับความสามารถบางอย่างในการนำเสนอโครงการซอฟต์แวร์ เฟรมเวิร์กนี้รวมกิจกรรมจากการดำเนินงานด้านไอที สถาปัตยกรรมองค์กร การจัดการพอร์ตโฟลิโอ การเงิน และการจัดซื้อไว้อย่างชัดเจนในวงจรการจัดส่งแบบสมบูรณ์ DAD ตั้งเป้าที่จะเพิ่มความคล่องตัวทางธุรกิจโดยรวมในทางปฏิบัติ

หลักการและส่วนประกอบหลัก

บทบาท

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

บทบาทหลัก:

1. ผู้มีส่วนได้ส่วนเสีย: คนที่ขึ้นอยู่กับทีมของคุณที่ทำโครงการให้เสร็จ: ลูกค้า ผู้ใช้ปลายทาง หรือเพื่อนร่วมงานภายใน
2. สมาชิกในทีม: บุคคลในทีมที่ทำงานตามแผนจริง: นักพัฒนา นักออกแบบ ผู้ทดสอบ ฯลฯ
3. หัวหน้าทีม: คล้ายกับ scrum master หัวหน้าทีมทำงานเป็นผู้นำรับใช้ให้กับทีมโดยการขจัดสิ่งกีดขวาง อำนวยความสะดวกในการทำงานร่วมกันในทีม และกระจายค่าที่คล่องตัว
4. เจ้าของผลิตภัณฑ์: บางครั้งเรียกว่า "เสียงของลูกค้า" เจ้าของผลิตภัณฑ์เป็นตัวแทนของผู้มีส่วนได้ส่วนเสียและรักษารายการลำดับความสำคัญของงานที่ต้องทำ
5. เจ้าของสถาปัตยกรรม: รับผิดชอบในการลดความเสี่ยงด้านสถาปัตยกรรมตามขนาด บทบาทนี้มักจะเต็มไปด้วยนักพัฒนาอาวุโสในทีม เนื่องจากต้องใช้พื้นฐานทางเทคนิคที่ลึกซึ้งและความรู้ด้านโดเมนธุรกิจที่มั่นคง

บทบาทรอง:

1. ผู้เชี่ยวชาญ: ผู้ที่เข้าร่วมทีมชั่วคราวเพื่อช่วยในบทบาทเฉพาะทาง ตัวอย่างเช่น นักวิเคราะห์ข้อมูลอาจเข้าร่วมเพื่อให้ความสามารถในการวิจัยในระยะแรกของโครงการ
2. ผู้เชี่ยวชาญด้านโดเมน: ที่ปรึกษาด้านภาษี ที่ปรึกษากฎหมาย และบุคคลอื่นๆ ที่มีความเชี่ยวชาญด้านโดเมนและช่วยเหลือทีมเกี่ยวกับความท้าทายที่เกี่ยวข้อง
3. ผู้เชี่ยวชาญด้านเทคนิค: ผู้ดูแลระบบฐานข้อมูล ผู้เชี่ยวชาญด้านความปลอดภัยในการสร้างต้นแบบ ฯลฯ คนเหล่านี้ช่วยเหลือสมาชิกในทีมที่เข้าใจได้ทั่วถึงในประเด็นสำคัญในวงจรชีวิต
4. ผู้ทดสอบอิสระ: แม้ว่าผู้ทดสอบมักจะเป็นส่วนหนึ่งของทีมหลัก แต่ในบางกรณี ข้อกำหนดด้านกฎระเบียบด้านชีวิตหรือระบบที่ซับซ้อนมาก ผู้ทดสอบอิสระจะทำงานควบคู่ไปกับการตรวจสอบการส่งมอบงาน
5. ผู้ รวมระบบ: โดยรวมแล้ว ทีมต่างๆ กำลังทำงานในส่วนต่างๆ ของทั้งระบบ ผู้รวมระบบช่วยให้ทีมรวมส่วนของตนกับทั้งระบบและจัดการการพึ่งพาได้

การสนับสนุนวงจรชีวิต

DAD ส่งเสริมวงจรชีวิตการจัดส่งแบบสมบูรณ์ ไม่ใช่แค่เพียงส่วนการเขียนโปรแกรมและส่วนการวางจำหน่ายที่ครอบคลุมโดย Agile/scrum แต่ยังรวมถึงระยะการเริ่มต้นซึ่งกำหนดและอนุมัติวิสัยทัศน์ของโครงการ ตลอดจนระยะการสนับสนุนและการเลิกใช้ภายหลังการปล่อย ปัจจุบัน DAD รองรับ 6 วงจรชีวิตที่แตกต่างกัน:

• วัฏจักร Agile: วงจรชีวิตโครงการตาม Scrum
• วงจรชีวิตแบบลีน: วงจรชีวิตโครงการตาม Kanban
• การส่งมอบอย่างต่อเนื่อง: Agile Lifecycle
• การส่งมอบอย่างต่อเนื่อง: วงจรชีวิตแบบลีน
• วงจรชีวิตการสำรวจ (Lean Startup)
• วงจรชีวิตของโปรแกรมสำหรับทีมของทีม

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

เป้าหมายกระบวนการ

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

กระบวนการทั้งหมดนี้มีการบันทึกจุดการตัดสินใจที่จะต้องให้ทีมตัดสินใจว่าจะจัดโครงสร้างกระบวนการนั้นอย่างไร จุดตัดสินใจแต่ละจุดมีเทคนิคหรือแนวทางปฏิบัติที่แนะนำซึ่งสามารถนำไปใช้ในการตัดสินใจได้ คุณสามารถดูตัวอย่างนี้ได้ในภาพด้านล่าง กระบวนการ “Develop Common Vision” มีการตัดสินใจ 6 ข้อที่ควรทำ การตัดสินใจแต่ละครั้งมีแนวทางปฏิบัติที่แนะนำ 2 ถึง 5 ข้อ ลูกศรระบุว่าผู้เขียน DAD ได้จัดลำดับรายการโดยรายการบนสุดเป็นแนวปฏิบัติที่ดีที่สุด และรายการล่างสุดคือแนวปฏิบัติที่แย่ที่สุดในรายการนี้ ข้อความ _ ตัวหนา ตัวเอียง_ หมายถึงจุดเริ่มต้นที่ดีสำหรับทีมใหม่ ซึ่งเพิ่งเริ่มต้นกับ DAD

มาตราส่วนของ DAD

แนวทางการจัดส่งแบบ Agile ที่มีระเบียบวินัยในการปรับมาตราส่วนจากสองมุมที่ต่างกัน:

• ความคล่องตัวทางยุทธวิธีในระดับ

• ความคล่องตัวเชิงกลยุทธ์ในวงกว้าง

ความคล่องตัวทางยุทธวิธีพยายามที่จะจัดการกับปัจจัยในการปรับสเกลแต่ละทีม เช่น ขนาด การกระจายทางภูมิศาสตร์ ความซับซ้อนของโครงการ ฯลฯ ผ่านการประยุกต์ใช้เป้าหมายของกระบวนการตามสถานการณ์และแนวทางปฏิบัติที่แนะนำ

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

• DevOps ที่มีระเบียบวินัย: ครอบคลุมการใช้ DevOps เพื่อให้ผลลัพธ์ที่มีประสิทธิภาพมากขึ้นแก่องค์กร

• Disciplined Agile IT (DAIT): ครอบคลุมถึงวิธีการใช้กลยุทธ์ที่คล่องตัวและลีนกับไอทีทุกด้าน

• องค์กร Agile ที่มีวินัย:. ครอบคลุมถึงวิธีการใช้แบบลีนและคล่องตัวทั่วทั้งองค์กร

ปลอดภัย

Scaled Agile Framework (SAFe) เป็นที่นิยมมากที่สุด เช่นเดียวกับเฟรมเวิร์ก Agile ที่ปรับขนาดที่ซับซ้อนและครอบคลุมที่สุดในขณะนี้ 29% ของผู้ตอบแบบสอบถามในรายงานประจำปีของ Agile อ้างว่าใช้กรอบการทำงานนี้ในองค์กรของตน ในทางกลับกัน มีผู้จัดการโครงการ SAFe จำนวนมากในตลาด

จุดเริ่มต้นของ SAFe คือหนังสือ "Scaling Software Agility: Best Practices for Large Enterprises" ของ Dean Leffingwell ซึ่งตีพิมพ์ในปี 2550 ปัจจุบัน Leffingwell เป็นหัวหน้าระเบียบวิธีวิจัยของ SAFe แต่ยังมีคนอื่นๆ อีกจำนวนมากที่มีส่วนร่วมในกรอบการทำงานนี้ ในปัจจุบัน ในเวอร์ชัน 4.6 เฟรมเวิร์กนี้คล้ายกับผลิตภัณฑ์ซอฟต์แวร์ที่มีการกำหนดเวอร์ชัน ความเข้ากันได้แบบย้อนหลัง และส่วนประกอบต่างๆ

หลักการและส่วนประกอบหลัก

เป้าหมายหลักของ SAFe คือการอำนวยความสะดวกในการสร้างและการเติบโตของ Lean Enterprise เนื่องจากตระหนักดีว่าบริษัทประเภทต่างๆ หลายประเภท เป็นส่วนหนึ่งของบริษัทซอฟต์แวร์ที่ต้องการสร้างมูลค่าอย่างต่อเนื่องในระยะเวลาที่สั้นที่สุดและยั่งยืน

SAFe for Lean Enterprises พยายามสร้าง Lean Enterprise โดยการจัดหาฐานความรู้เกี่ยวกับหลักการ ความสามารถ และแนวทางปฏิบัติที่ดีที่สุดที่ได้รับการพิสูจน์แล้ว

SAFe 4.6 กำหนดความสามารถหลักห้าประการขององค์กรแบบลีน ความสามารถแต่ละอย่างเป็นชุดของความรู้ ทักษะ และพฤติกรรมที่เกี่ยวข้อง ซึ่งช่วยให้องค์กรต่างๆ เก่ง:

1. ความเป็นผู้นำแบบ Lean-Agile : อธิบายว่าผู้นำขับเคลื่อนและรักษาการเปลี่ยนแปลงขององค์กรผ่านการเรียนรู้ การสอน และการนำแนวความคิดแบบ Lean-Agile ของ SAFe ไปใช้ได้อย่างไร

2. ความคล่องตัวของทีมและเทคนิค : อธิบายทักษะ หลักการ และแนวทางปฏิบัติที่จำเป็นในการสร้างทีม Agile ที่มีประสิทธิภาพสูง

3. DevOps และ release on Demand : อธิบายว่าการนำ DevOps ไปใช้งานและไปป์ไลน์การส่งมอบอย่างต่อเนื่องช่วยให้องค์กรมีความสามารถในการปล่อยผลิตภัณฑ์ที่เพิ่มขึ้นเมื่อใดก็ได้ที่จำเป็นเพื่อตอบสนองความต้องการ

4. โซลูชันทางธุรกิจและวิศวกรรมระบบแบบลีน : อธิบายวิธีการใช้หลักการและแนวทางปฏิบัติแบบลีน-คล่องกับข้อกำหนด การพัฒนา การปรับใช้ และวิวัฒนาการของแอปพลิเคชันซอฟต์แวร์ขนาดใหญ่และซับซ้อน

5. การจัดการพอร์ตโฟลิโอแบบลี น: ปรับกลยุทธ์และการดำเนินการโดยใช้วิธีการคิดแบบลีนและระบบกับกลยุทธ์และการระดมทุน การดำเนินงานพอร์ตโฟลิโอที่คล่องตัว และการกำกับดูแล

สมรรถนะหลักแต่ละรายการจะจับคู่โดยตรงกับระดับที่เกี่ยวข้องในไดอะแกรมกระบวนการ SAFe ยกเว้นภาวะผู้นำแบบ Lean-Agile ซึ่งครอบคลุมกระบวนการทั้งหมด

ความสามารถในการเป็นผู้นำแบบ Lean-Agile

เป้าหมายหลักของความสามารถในการเป็นผู้นำแบบ Lean-Agile คือการช่วยเปลี่ยนองค์กรให้เป็นองค์กรแบบ Lean-Agile ซึ่งทำได้โดยการเรียนรู้ ฝึกฝน และสอนแนวความคิด ค่านิยม หลักการ และแนวทางปฏิบัติแบบ Lean-Agile ของ SAFe

ค่านิยมหลักของ SAFe เป็นแนวทางในการเปลี่ยนแปลงไปสู่องค์กรแบบลีน ในทุกโอกาส พฤติกรรมของผู้นำมีบทบาทสำคัญในการส่งเสริมพวกเขา ค่านิยมหลักคือ:

1. Alignment : สื่อสารพันธกิจ กลยุทธ์พอร์ตโฟลิโอ และวิสัยทัศน์ของโซลูชัน ดำเนินการบรรยายสรุปที่เกี่ยวข้อง และเข้าร่วมในการวางแผนเพิ่มโปรแกรม (PI) และการบำรุงรักษางานในมือ

2. ความโปร่งใส : เห็นภาพงานที่เกี่ยวข้องทั้งหมด

3. คุณภาพในตัว : มีส่วนร่วมในการปฏิบัติเพื่อส่งมอบคุณภาพตลอดวงจรชีวิต ปฏิเสธที่จะรับงานคุณภาพต่ำ สนับสนุนการลงทุนในการบำรุงรักษาและลดหนี้ทางเทคนิค

4. การดำเนินการโปรแกรม : เข้าร่วมเป็นเจ้าของธุรกิจในการดำเนินการ PI และสร้างมูลค่าทางธุรกิจ ตรวจสอบให้แน่ใจว่าขอบเขตสอดคล้องกับความต้องการและความสามารถ ขจัดสิ่งกีดขวางและ demotivators อย่างก้าวร้าว

ค่านิยมหลักของ SAFe ได้รับการสนับสนุนโดยโอบรับ Lean-Agile Mindset และใช้หลักการ SAFe:

1. มองเศรษฐกิจ

2. ใช้การคิดอย่างเป็นระบบ

3. สมมติความแปรปรวน; รักษาตัวเลือก

4. สร้างทีละน้อยด้วยวงจรการเรียนรู้ที่รวดเร็วและบูรณาการ

5. เหตุการณ์สำคัญบนพื้นฐานของการประเมินวัตถุประสงค์ของระบบการทำงาน

   

6. เห็นภาพและจำกัด WIP ลดขนาดแบทช์ และจัดการความยาวของคิว

7. ใช้จังหวะ ประสานกับการวางแผนข้ามโดเมน

8. ปลดล็อกแรงจูงใจที่แท้จริงของผู้ปฏิบัติงานความรู้

9. กระจายอำนาจการตัดสินใจ

หลักการเหล่านี้คล้ายกับหลักการแบบ Lean และ Agile ในที่สุด การเปลี่ยนแปลงองค์กรก็ทำได้สำเร็จโดยปฏิบัติตามแผนงานการดำเนินการของ SAFe

ความสามารถของทีมและความคล่องตัวทางเทคนิค/ระดับทีม

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

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

• ความคล่องตัวทางเทคนิค : ทีมงานใช้แนวทางปฏิบัติทางเทคนิคแบบ Agile เพื่อให้แน่ใจว่าโค้ดและคุณภาพของส่วนประกอบ และความสามารถในการบำรุงรักษาโค้ดที่พวกเขาผลิต\ Quality เป็นจุดสนใจหลักในทีมและความสามารถด้านความคล่องตัวทางเทคนิค เพื่อให้บรรลุสิ่งนี้ เทคนิคทางวิศวกรรมที่คล่องตัว เช่น Behavior Driven Development (BDD) และ Test-driven development (TDD) ถูกนำมาใช้เพื่อเพิ่มคุณภาพและการไหล การไหลที่รวดเร็วขึ้นอยู่กับคุณภาพของอาคารทั่วทั้งระบบ เนื่องจากข้อผิดพลาดอาจส่งผลกระทบอย่างรุนแรงต่อการไหลและปล่อยล่าช้า

ระดับทีมของไดอะแกรม SAFe อธิบายวิธีการทำงานของทีม Agile แต่ละทีม ทุกทีมเป็นส่วนหนึ่งของ Agile Release Train ซึ่งทำงานเพื่อส่งมอบ Product Increment โฟลว์แบบ Agile/scrum แบบดั้งเดิมส่วนใหญ่จะนำไปใช้ โดยที่ทีมทำงานซ้ำๆ เพื่อส่งมอบระบบการทำงาน บทบาทของ scrum master เจ้าของผลิตภัณฑ์ และสมาชิกในทีมถูกใช้ใน SAFe เช่นเดียวกับกิจกรรม scrum และสิ่งประดิษฐ์ส่วนใหญ่ ทีมยังได้รับการสนับสนุนโดยบทบาทระดับโปรแกรม เช่น การจัดการผลิตภัณฑ์ สถาปนิกระบบ และบริการที่ใช้ร่วมกันอื่นๆ Kanban ใช้เพื่อช่วยให้เห็นภาพการไหลของคุณลักษณะต่างๆ ผ่านวงจรการจัดส่งและการโต้ตอบและแฮนด์ออฟระหว่างทีม

DevOps และ Release on Demand Competency/ระดับโปรแกรม

DevOps และ Release on Demand Competency อธิบายว่า "การนำ DevOps ไปใช้และไปป์ไลน์การจัดส่งแบบต่อเนื่องช่วยให้องค์กรมีความสามารถในการปล่อยมูลค่าทั้งหมดหรือบางส่วนได้ตลอดเวลาที่จำเป็นเพื่อตอบสนองความต้องการของตลาดและลูกค้า"

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

• DevOps นำเสนอแนวทางการเพาะเลี้ยง ระบบอัตโนมัติ การไหลแบบลีน การวัด และการกู้คืน (CALMR) ที่ช่วยให้สามารถส่งมอบและปล่อยตามความต้องการได้อย่างต่อเนื่อง

• Agile release train (ARTs) คือทีมจากทีม agile ที่ได้รับการจัดระเบียบเพื่อส่งมอบมูลค่าตามต้องการผ่านท่อส่งที่ต่อเนื่อง

ระดับโปรแกรมของไดอะแกรมอธิบายบทบาทและกิจกรรมที่จำเป็นในการนำเสนออย่างต่อเนื่องผ่าน Agile Release Train (ART) ระดับนี้ทำงานในลักษณะวนซ้ำที่คล้ายกับระดับทีม แต่รวมทีมที่คล่องตัวหลายทีมและรวมรอบเพิ่มเติม ART เป็นทีมที่คล่องตัวซึ่งประกอบด้วย 5 ถึง 12 ทีม (50 ถึง 125 คน) รวมถึงบทบาทเปรียวแบบดั้งเดิมตลอดจนบทบาทสำคัญของโปรแกรม เช่น Release Train Engineer (RTE) และการจัดการผลิตภัณฑ์ ART ส่งมอบ โปรแกรมเพิ่ม (PI) ใน 8-12 สัปดาห์ ซึ่งวางแผนผ่าน การวางแผน PI และนำโดย ผู้จัดการผลิตภัณฑ์

ความคืบหน้าของฟีเจอร์ PI, มหากาพย์ และอื่นๆ มีการติดตามและจัดการผ่านบอร์ด Program Kanban RTE ทำหน้าที่เป็น Scrum Master บน ART การประชุมการซิงโครไนซ์รายวันรวมถึงทีม Daily Standups, Scrum-of-Scrums (RTE & Scrum Masters), PO Sync (การจัดการผลิตภัณฑ์ & เจ้าของผลิตภัณฑ์) และ ART Sync (Scrum-of-Scrums และ PO Sync ร่วมกัน) PI แต่ละรายการมีการสาธิตระบบและย้อนหลัง

โซลูชันทางธุรกิจและความสามารถด้านวิศวกรรมระบบแบบลีน/ระดับโซลูชันขนาดใหญ่

Business Solutions and Lean Systems Engineering Competency อธิบายว่า "วิธีการใช้หลักการและแนวทางปฏิบัติแบบ Lean-Agile กับข้อกำหนด การพัฒนา การปรับใช้ และวิวัฒนาการของแอปพลิเคชันซอฟต์แวร์ขนาดใหญ่ที่ซับซ้อน และระบบกายภาพไซเบอร์"

นอกจากหลักการ SAFe แล้ว การใช้หลักการ 8 ประการต่อไปนี้เมื่อทำงานกับโซลูชันขนาดใหญ่เป็นกุญแจสำคัญในความสามารถนี้:

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

• จัดการการรวมบ่อยๆ

• จัดการกับข้อกังวลด้านการปฏิบัติตามข้อกำหนดอย่างต่อเนื่อง

• สถาปนิกสำหรับขนาด แบบแยกส่วน การปล่อยออกได้ และความสามารถในการให้บริการ

การจัดการโซลูชัน ควบคุมเนื้อหาของ โซลูชันและวิศวกรฝึกอบรมโซลูชัน (STE) จะแนะนำงาน สถาปนิกโซลูชัน มีหน้าที่รับผิดชอบในการรักษาสถาปัตยกรรมที่ดีสำหรับ ART ทั้งหมดในโซลูชัน การวางแผนก่อนและหลัง PI ใช้เพื่อวางแผนโซลูชันที่จัดส่งผ่านการเพิ่มทีละโปรแกรม Solution Backlog มี ความสามารถ และ Solution Epics และติดตามผ่านบอร์ด Solution Kanban

Portfolio Level/Lean Portfolio Management Competency

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

Lean Portfolio Management มุ่งเน้นไปที่พื้นที่ต่อไปนี้:

1. เงินทุนเชิงกลยุทธ์และการลงทุน: เชื่อมต่อพอร์ตโฟลิโอกับกลยุทธ์องค์กร แหล่งเงินทุนจากแหล่งเงินทุน และสร้างกระแสพอร์ต

2. การดำเนินงานพอร์ตโฟลิโอที่คล่องตัว: ประสานกระแสคุณค่า สนับสนุนการทำงานของโปรแกรม และความเป็นเลิศในการปฏิบัติงาน

3. การกำกับดูแลแบบลีน: คาดการณ์งบประมาณ วัดประสิทธิภาพพอร์ตโฟลิโอ และบังคับใช้การปฏิบัติตามข้อกำหนด

ระดับพอร์ตโฟลิโอประกอบด้วยหลักการ แนวทางปฏิบัติ และบทบาทที่จำเป็นในการเริ่มต้นและควบคุมชุดของ Value Streams ในการพัฒนา Portfolio Backlog ประกอบด้วย Business Epics และ Enabler Epics และติดตามผ่าน บอร์ด Portfolio Kanban* **Lean Portfolio Management (LPM) ตัดสินใจเกี่ยวกับกระแสคุณค่าที่อยู่ในพอร์ตโฟลิโอและรวมถึงผู้มีอำนาจตัดสินใจสูงสุดในองค์กร Enterprise Architect จะแนะนำงานและประสานงานใน Value Streams

น้อย

กรอบงานการต่อสู้ขนาดใหญ่ (LeSS) สร้างขึ้นโดย Craig Larman และ Bas Vodde ซึ่งใช้ประสบการณ์ในอุตสาหกรรมการเงินและโทรคมนาคม ตามชื่อของมัน LeSS ส่งเสริมให้มีกระบวนการและขั้นตอนน้อยที่สุดเท่าที่จะเป็นไปได้เพื่อให้ทีม Scrum จำนวนมากทำงานร่วมกัน การปรับขนาดเป็นเรื่องยากเพราะผู้คนทำให้มันซับซ้อน ดังนั้นเป้าหมายที่นี่คือการทำให้ง่ายที่สุด

หลักการและส่วนประกอบหลัก

“LeSS is Scrum ใช้ได้กับหลายทีม ทำงานร่วมกันในผลิตภัณฑ์เดียว” LeSS อิงตามหลักการ 10 ประการซึ่งดูเหมือนคุ้นเคยกับทุกคนที่คุ้นเคยกับหลักการแบบ Lean-Agile:

1. Scrum ขนาดใหญ่คือ Scrum

2. การควบคุมกระบวนการเชิงประจักษ์

3. ความโปร่งใส

4. มากแต่น้อย

5. เน้นทั้งผลิตภัณฑ์

6. ลูกค้าเป็นศูนย์กลาง

7. พัฒนาอย่างต่อเนื่องสู่ความสมบูรณ์แบบ

8. การคิดอย่างเป็นระบบ

9. คิดน้อย

10. ทฤษฎีการจัดคิว

LeSS มีบทบาทหลักเพียงสองบทบาท ซึ่งทั้งสองบทบาทถูกยืมมาจาก Scrum:

1. เจ้าของผลิตภัณฑ์: ทำงานร่วมกับ 2-8 ทีม
2. Scrum master: ทำงานร่วมกับ 1-3 ทีม

ทุกทีมทำงานกับ Backlog ของผลิตภัณฑ์ เดียวกันในระยะเวลา 1-4 สัปดาห์ ทีมทำงานคู่ขนานกัน หมายความว่าพวกเขาเริ่มต้นและสิ้นสุดการวิ่งพร้อมกัน เมื่อสิ้นสุดการวิ่ง ทีมงานจะร่วมกันส่งมอบ ผลิตภัณฑ์ที่เพิ่มขึ้น แทบจะเป็นไปไม่ได้เลยที่เจ้าของผลิตภัณฑ์หนึ่งรายจะทำงานร่วมกับ 8 ทีมได้ LeSS ส่งเสริมการย้ายความรับผิดชอบของการชี้แจงรายการค้างของผลิตภัณฑ์ไปยังทีมงาน ในทางกลับกัน ทีมงานจะต้องทำงานข้ามสายงานและไม่ได้มีเพียงการเขียนโค้ด การออกแบบ และการทดสอบความสามารถเท่านั้น แต่ยังรวมถึงความรู้ด้านโดเมนธุรกิจด้วย ที่สำคัญกว่านั้น ทีมงานต้องได้รับอำนาจเพื่อเข้าถึงลูกค้าได้

การวางแผนการวิ่ง

การวางแผนแบ่งออกเป็นสองส่วน:

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

การปรับแต่ง Backlog ของผลิตภัณฑ์

การปรับแต่ง Backlog ของผลิตภัณฑ์ (PBR) เสร็จสิ้นในระหว่าง sprint เพื่อเตรียมรายการ backlog ของผลิตภัณฑ์สำหรับการวางแผน sprint LeSS ไม่ได้เสนอกฎเกณฑ์เกี่ยวกับวิธีการทำ PBR และปล่อยให้บริษัทต่างๆ เป็นผู้พิจารณากระบวนการที่มีประสิทธิภาพสูงสุดด้วยตนเอง PBR เกี่ยวข้องกับกิจกรรมหลักสามประการ:

1. แยกรายการใหญ่.
2. ลงรายละเอียดจนกว่าจะพร้อม
3. การประมาณการ

สิ้นสุด Sprint

เมื่อสิ้นสุดการวิ่งแต่ละครั้ง สามสิ่งจะเกิดขึ้น:

1. Sprint Review: การสาธิต Sprint ที่แชร์ซึ่งทีมและลูกค้าสำรวจสิ่งที่ทำระหว่าง Sprint และสิ่งที่ควรทำต่อไป
2. ย้อนหลัง: แต่ละทีมมีมุมมองย้อนหลังของตนเองเพื่อปรับปรุงกระบวนการของตน
3. ภาพ รวมย้อนหลัง: ทีม เจ้าของผลิตภัณฑ์ และผู้เชี่ยวชาญการต่อสู้ร่วมกันเพื่อตรวจสอบและปรับวิธีปฏิบัติขององค์กรให้มีประสิทธิภาพมากขึ้น

Scrum@Scale

Scrum at Scale และ Scrum@Scale ใช้แทนกันได้ วิธีการนี้ได้รับการแนะนำโดย Jeff Sutherland ในปี 2014 ซึ่งเป็นผู้สร้างระเบียบวิธี Scrum และเป็นหนึ่งในผู้ลงนามใน Agile Manifesto

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

หลักการและส่วนประกอบหลัก

Scrum@Scale เป็นเฟรมเวิร์กที่ทำให้การปรับขนาดง่ายขึ้นอย่างมากโดยใช้ Scrum เพื่อปรับขนาด Scrum ใน Scrum "อะไร" (เจ้าของผลิตภัณฑ์) แยกออกจาก "อย่างไร" (scrum master) อย่างชัดเจน ใช้กลยุทธ์เดียวกันนี้ใน Scrum@Scale เพื่อให้เข้าใจถึงเขตอำนาจศาลและความรับผิดชอบ ขจัดความสูญเปล่าและความขัดแย้ง

Scrum@Scale มีสองรอบในการแยกเขตอำนาจศาลอย่างชัดเจน: รอบ Scrum Master และวงจร เจ้าของผลิตภัณฑ์ ที่มีจุดติดต่อสองจุด: กระบวนการระดับทีมและคำติชมการเปิดตัวผลิตภัณฑ์

Scrum Master Cycle

scrum master cycle มีหน้าที่รับผิดชอบในการสร้างสิ่งต่าง ๆ ที่วงจรเจ้าของผลิตภัณฑ์ระบุไว้ ใน Scrum@Scale ทีม Scrum แต่ละทีมจะมีบทบาท สิ่งประดิษฐ์ กิจกรรม และพิธีการเหมือนกันกับ Scrum แบบดั้งเดิม

ทีม Scrum ถูกจัดกลุ่มเป็น Scrum of Scrums (SoS) ซึ่งรับผิดชอบร่วมกันในการผลิตผลิตภัณฑ์ที่เพิ่มขึ้นร่วมกัน พวกเขามีส่วนร่วมในการดูแลและจัดลำดับความสำคัญของงานในมือ เก็บข้อมูลย้อนหลัง รักษาอุปสรรคที่ค้างอยู่ และพวกเขาจัด Scaled Daily Scrum (SDS) (คล้ายกับรูปแบบการต่อสู้รายวัน) เพื่อประสานงานทีมและขจัดสิ่งกีดขวางบนถนน SDS มีตัวแทนอย่างน้อยหนึ่งคน (โดยปกติคือ scrum master ของทีม) ของแต่ละทีมที่เข้าร่วม และนำโดย Scrum of Scrums master (SoSM) ซึ่งมีหน้าที่รับผิดชอบในการประสานงานกับทีม scrum และเจ้าของผลิตภัณฑ์

หากต้องการปรับขนาดเพิ่มเติม จะมี scrum of scrum of scrums (SoSoS) ที่ สร้างขึ้นจาก SoS หลายตัว ซึ่งจะตอบสนองทุกวัน เป็นต้น ผู้นำโดยรวมคือ Executive Action Team (EAT) ซึ่งมีหน้าที่ส่งเสริม Agile ในองค์กร ประสานงานทีม Scrum ตามความจำเป็น และเป็นจุดสุดท้ายในการขจัดสิ่งกีดขวาง

วงจรเจ้าของผลิตภัณฑ์

Product Owner Cycle มีหน้าที่รับผิดชอบในการสร้างผลิตภัณฑ์หรือบริการ และกิจกรรมทั้งหมดที่จำเป็นเพื่อสนับสนุนสิ่งนั้น เจ้าของผลิตภัณฑ์ได้รับมอบหมายให้ดูแลทีม Scrum และดำเนินกิจกรรมทั้งหมดในบทบาทของตนตามที่กำหนดไว้ใน Scrum เจ้าของผลิตภัณฑ์จะถูกจัดกลุ่มเป็นกลุ่ม เจ้าของผลิตภัณฑ์ ซึ่งจับคู่กับทีม SoS Product Owner Teams พบปะกันทุกวันที่ Meta Scrum เพื่อหารือเกี่ยวกับกลยุทธ์ระดับสูงสำหรับทีม และประสานงานตามความจำเป็นกับ SoSM ที่เกี่ยวข้อง รวมถึงเจ้าของผลิตภัณฑ์และผู้มีส่วนได้ส่วนเสียอื่นๆ Meta Scrums นำโดย Chief Product Owner (CPO)

Product Owner ปรับขนาดในลักษณะเดียวกันกับ scrum master ขึ้นอยู่กับขนาดขององค์กรและสิ้นสุดใน Executive Meta Scrum (EMT) ซึ่งรับผิดชอบการตั้งค่าลำดับความสำคัญทั่วทั้งบริษัท

การใช้ Scrum@Scale

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

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

บทสรุป

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

เมื่อบริษัทต่างๆ เผชิญกับโครงการที่ใหญ่กว่าและซับซ้อนกว่าซึ่งมีข้อกำหนดหรือเป้าหมายที่เปลี่ยนแปลงอยู่ตลอดเวลา พวกเขาจึงมองหาแนวทางแบบ Agile มากขึ้น เนื่องจากเดิม Agile มีไว้สำหรับทีมเล็กๆ 5-9 คน ผู้ปฏิบัติงาน Agile หลายคนจึงมีวิธีหลากหลายในการขยายขนาด Agile จากทีมเดียว ไปเป็นหลายทีม ไปจนถึงทั้งองค์กร ในบทความนี้ เราได้กล่าวถึง Disciplined Agile Delivery (DAD), Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS) และ Scrum@Scale

ในส่วนสุดท้ายของพิมพ์เขียวการจัดการโครงการ เราจะกล่าวถึงกรอบงานเฉพาะสำหรับการจัดการโครงการบางประเภท เช่น PMP (PMBOK) และ PRINCE2 นอกจากนี้ เราจะพูดถึงกระบวนการและกรอบการทำงานด้านนวัตกรรม เช่น "งานที่ต้องทำ" (JTBD) และ "การคิดเชิงออกแบบ"