ภาพรวม

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

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

น้ำตก

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

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

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

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

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

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

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

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

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

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

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

การจัดส่งแบบคล่องตัวอย่างมีวินัย (DAD)

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

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

บทบาท

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

บทบาทหลัก:

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

บทบาทรอง:

วิธีใช้แอพ invision

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

การสนับสนุนตลอดอายุการใช้งาน

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SAFe

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

จุดเริ่มต้นของ SAFe เป็นหนังสือของ Dean Leffingwell“ การปรับขนาดความคล่องตัวของซอฟต์แวร์: แนวทางปฏิบัติที่ดีที่สุดสำหรับองค์กรขนาดใหญ่ ,” เผยแพร่ในปี 2550 ปัจจุบัน Leffingwell เป็นหัวหน้าวิธีการของ SAFe แต่คนอื่น ๆ ก็มีส่วนร่วมในกรอบนี้เช่นกัน ปัจจุบันในเวอร์ชัน 4.6 เฟรมเวิร์กนี้มีลักษณะคล้ายกับผลิตภัณฑ์ซอฟต์แวร์ที่มีการกำหนดเวอร์ชันความเข้ากันได้แบบย้อนกลับและส่วนประกอบต่างๆ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ค่านิยมหลักของ 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 แบบดั้งเดิมส่วนใหญ่นำไปใช้โดยที่ทีมทำงานในการทำซ้ำเพื่อส่งมอบระบบการทำงาน บทบาทของผู้เชี่ยวชาญด้านการต่อสู้เจ้าของผลิตภัณฑ์และสมาชิกในทีมถูกใช้ใน SAFe เช่นเดียวกับกิจกรรมการต่อสู้และสิ่งประดิษฐ์ส่วนใหญ่ นอกจากนี้ทีมยังได้รับการสนับสนุนโดยบทบาทระดับโปรแกรมเช่น Product Management, System Architect และบริการที่แชร์อื่น ๆ Kanban ใช้เพื่อช่วยให้เห็นภาพการไหลของคุณสมบัติผ่านวงจรชีวิตการจัดส่งและการโต้ตอบและการส่งมอบระหว่างทีม

DevOps และ Release on Demand Competency / Program Level

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

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

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

• Agile release Trains (ARTs) เป็นทีมของทีมที่มีความคล่องตัวซึ่งจัดขึ้นเพื่อส่งมอบคุณค่าตามความต้องการผ่านทางท่อส่งแบบต่อเนื่อง

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

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

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

โซลูชันทางธุรกิจและความสามารถทางวิศวกรรมระบบแบบลีน อธิบายถึง“ วิธีการนำหลักการและแนวปฏิบัติ Lean-Agile ไปใช้กับข้อกำหนดการพัฒนาการปรับใช้และวิวัฒนาการของแอปพลิเคชันซอฟต์แวร์ขนาดใหญ่ที่ซับซ้อนและระบบทางกายภาพในโลกไซเบอร์”

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

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

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

• แก้ไขข้อกังวลด้านการปฏิบัติตามกฎระเบียบอย่างต่อเนื่อง

• สถาปนิกสำหรับขนาดโมดูลาร์ความเกี่ยวข้องและความสามารถในการให้บริการ

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

ระดับพอร์ตการลงทุน / ความสามารถในการจัดการพอร์ตการลงทุนแบบลีน

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

Lean Portfolio Management มุ่งเน้นในด้านต่อไปนี้:

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

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

3. การกำกับดูแลแบบลีน: คาดการณ์งบประมาณวัดผลการดำเนินงานและบังคับใช้การปฏิบัติตาม

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

LeSS

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

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

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

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

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

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

4. มากขึ้นด้วยน้อยลง

5. โฟกัสทั้งผลิตภัณฑ์

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

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

8. การคิดเชิงระบบ

9. ความคิดแบบลีน

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

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

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

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

การวางแผน Sprint

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

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

การปรับแต่งสินค้าค้างส่ง

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

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

สิ้นสุด Sprint

ในตอนท้ายของการวิ่งแต่ละครั้งมีสามสิ่งเกิดขึ้น:

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

[ป้องกันอีเมล]

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

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

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

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

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

Scrum Master Cycle

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

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

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

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

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

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

กำลังดำเนินการ [ป้องกันอีเมล]

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

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

สรุป

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

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

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

ทำความเข้าใจพื้นฐาน

ความแตกต่างระหว่าง Waterfall และ Agile methodologies คืออะไร?

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

สามารถใช้น้ำตกและเปรียวร่วมกันได้หรือไม่?

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

วิธีการแบบผสมผสานคืออะไร?

วิธีการแบบผสมผสานหมายความว่ามีการใช้ส่วนประกอบบางอย่างของ Waterfall และ Agile ในโครงการเดียวกันหรือใน บริษัท เดียวกัน เป็นแนวทางทั่วไปสำหรับ บริษัท ที่เปลี่ยนจากน้ำตกไปสู่ความคล่องตัว