การพัฒนา S / W แบบปรับได้ - คู่มือฉบับย่อ

Agile คืออะไร?

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

ในการพัฒนาซอฟต์แวร์คำว่า "คล่องตัว" ถูกปรับให้หมายถึง "ความสามารถในการตอบสนองต่อการเปลี่ยนแปลง - การเปลี่ยนแปลงจากข้อกำหนดเทคโนโลยีและผู้คน"

ประกาศ Agile

Agile Manifesto ได้รับการเผยแพร่โดยทีมนักพัฒนาซอฟต์แวร์ในปี 2544 โดยเน้นถึงความสำคัญของทีมพัฒนารองรับความต้องการที่เปลี่ยนแปลงและการมีส่วนร่วมของลูกค้า

แถลงการณ์เปรียวคือ -

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

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

นั่นคือในขณะที่มีค่าในรายการทางด้านขวาเราให้ความสำคัญกับรายการทางด้านซ้ายมากขึ้น

ลักษณะของความคล่องตัว

ต่อไปนี้เป็นลักษณะของ Agility -

• ความคล่องตัวในการพัฒนาซอฟต์แวร์แบบ Agile มุ่งเน้นไปที่วัฒนธรรมของทั้งทีมด้วยทีมที่มีระเบียบวินัยหลากหลายสายงานที่ได้รับการเสริมพลังและจัดระเบียบตนเอง

• ส่งเสริมความรับผิดชอบร่วมกันและความรับผิดชอบ

• อำนวยความสะดวกในการสื่อสารที่มีประสิทธิภาพและการทำงานร่วมกันอย่างต่อเนื่อง

• วิธีการทั้งทีมหลีกเลี่ยงความล่าช้าและเวลารอ

• การส่งมอบบ่อยครั้งและต่อเนื่องช่วยให้แน่ใจว่าได้รับการตอบกลับอย่างรวดเร็วซึ่งจะช่วยให้ทีมสอดคล้องกับข้อกำหนด

• การทำงานร่วมกันช่วยอำนวยความสะดวกในการผสมผสานมุมมองที่แตกต่างกันอย่างทันท่วงทีในการนำไปใช้แก้ไขข้อบกพร่องและรองรับการเปลี่ยนแปลง

• ความก้าวหน้าคงที่ยั่งยืนและคาดเดาได้โดยเน้นความโปร่งใส

วิธีการแบบ Agile

การนำวิธี Agile มาใช้ในช่วงแรก ได้แก่ Rational Unified Process, Scrum, Crystal Clear, Extreme Programming, Adaptive Software Development, Feature Driven Development และ Dynamic Systems Development Method (DSDM) ปัจจุบันสิ่งเหล่านี้เรียกรวมกันว่าวิธีการแบบ Agile หลังจากที่ Agile manifesto เผยแพร่ในปี 2544

ในบทช่วยสอนนี้เราจะได้เรียนรู้เกี่ยวกับ Agile Methodology - Adaptive Software Development.

Adaptive Software Development คืออะไร?

การพัฒนาซอฟต์แวร์ที่ปรับเปลี่ยนได้คือการก้าวไปสู่แนวทางปฏิบัติที่ปรับเปลี่ยนได้โดยทิ้งแนวปฏิบัติที่กำหนดไว้ในบริบทของระบบที่ซับซ้อนและสภาพแวดล้อมที่ซับซ้อน Adaptive Software Development มุ่งเน้นไปที่การทำงานร่วมกันและการเรียนรู้เป็นเทคนิคในการสร้างระบบที่ซับซ้อน พัฒนามาจากแนวทางปฏิบัติที่ดีที่สุดของ Rapid Application Development (RAD) และ Evolutionary Life Cycles จากนั้นการพัฒนาซอฟต์แวร์แบบปรับตัวได้รับการขยายเพื่อรวมแนวทางการปรับตัวสำหรับการจัดการโดยมีการคาดเดาเข้ามาแทนที่การวางแผน

Jim Highsmith ตีพิมพ์หนังสือเรื่อง Adaptive Software Development ในปี 2000 ในคำพูดของ Highsmith -

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

แบบจำลองวงจรชีวิตการพัฒนาซอฟต์แวร์ (SDLC) เป็นกรอบงานที่อธิบายกิจกรรมที่ดำเนินการในแต่ละขั้นตอนของโครงการพัฒนาซอฟต์แวร์

ในวงจรชีวิตของการพัฒนาซอฟต์แวร์กิจกรรมจะดำเนินการในห้าขั้นตอน -

• Requirements Gathering- มีการรวบรวมข้อกำหนดสำหรับซอฟต์แวร์ที่จะพัฒนา ข้อกำหนดเหล่านี้จะเป็นภาษาที่ลูกค้า / ผู้ใช้เข้าใจ แนะนำให้ใช้คำศัพท์เฉพาะโดเมน

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

• Design - ขั้นตอนนี้เกี่ยวข้องกับการมาถึงสถาปัตยกรรมซอฟต์แวร์และข้อมูลจำเพาะการใช้งานตามเทคโนโลยีที่เลือกสำหรับการพัฒนา

• Construction - ในขั้นตอนนี้โค้ดจะได้รับการพัฒนาทดสอบหน่วยบูรณาการทดสอบการรวมและการสร้าง

• Testing- การทดสอบการทำงานของซอฟต์แวร์ที่สร้างขึ้นเสร็จสิ้นในขั้นตอนนี้ นอกจากนี้ยังรวมถึงการทดสอบข้อกำหนดที่ไม่สามารถใช้งานได้

มีสองวิธีในการดำเนินกิจกรรมเหล่านี้ -

• Prescriptive - แบบจำลอง SDLC ที่จะให้วิธีการดำเนินกิจกรรมในลักษณะที่กำหนดตามที่กำหนดโดยกรอบงาน

• Adaptive- โมเดล SDLC ที่จะช่วยให้คุณมีความยืดหยุ่นในการดำเนินกิจกรรมพร้อมกฎบางประการที่ต้องปฏิบัติตาม วิธีการที่คล่องตัวส่วนใหญ่เป็นไปตามแนวทางนี้โดยแต่ละวิธีมีกฎเกณฑ์ อย่างไรก็ตามการปฏิบัติตามแนวทางปรับตัวหรือคล่องตัวไม่ได้หมายความว่าซอฟต์แวร์ได้รับการพัฒนาโดยไม่ปฏิบัติตามระเบียบวินัยใด ๆ ซึ่งจะนำไปสู่ความสับสนวุ่นวาย

คุณต้องเข้าใจว่าเราไม่สามารถบอกได้ว่าโมเดล SDLC เฉพาะนั้นดีหรือไม่ดี แต่ละคนมีจุดแข็งและจุดอ่อนของตัวเองดังนั้นจึงมีความเหมาะสมในบางบริบท

เมื่อคุณเลือกโมเดล SDLC สำหรับโครงการของคุณคุณต้องเข้าใจ -

• บริบทองค์กรของคุณ
• บริบทเทคโนโลยีของคุณ
• องค์ประกอบทีมของคุณ
• บริบทลูกค้าของคุณ

ตัวอย่างเช่นหากการพัฒนาซอฟต์แวร์สามารถคาดเดาได้คุณสามารถใช้ Prescriptive approach ในทางกลับกันหากการพัฒนาซอฟต์แวร์ไม่สามารถคาดเดาได้นั่นคือความต้องการไม่เป็นที่ทราบแน่ชัดหรือทีมพัฒนาไม่มีการเปิดรับโดเมนหรือเทคโนโลยีปัจจุบันมาก่อนเป็นต้นดังนั้นวิธีการปรับเปลี่ยนจึงเป็นทางเลือกที่ดีที่สุด

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

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

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

แบบจำลองน้ำตก - จุดแข็ง

จุดแข็งของแบบจำลองน้ำตกคือ -

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

แบบจำลองน้ำตก - จุดอ่อน

จุดอ่อนหรือข้อเสียของแบบจำลอง Waterfall คือ -

• เหมาะ - ไม่ตรงกับความเป็นจริง

• ไม่สมจริง - ไม่สามารถคาดหวังความต้องการที่ถูกต้องได้ในช่วงต้นโครงการ

• ไม่ได้สะท้อนถึงลักษณะซ้ำ ๆ ของการพัฒนาเชิงสำรวจที่พบมากขึ้น

• ยากและแพงในการเปลี่ยนแปลง

• ซอฟต์แวร์จะถูกส่งมอบเมื่อสิ้นสุดโครงการเท่านั้น เนื่องจากสิ่งนี้ -

  • ชะลอการค้นพบข้อบกพร่องร้ายแรง

  • ความเป็นไปได้ในการส่งมอบข้อกำหนดที่ล้าสมัย

• ค่าใช้จ่ายในการจัดการที่สำคัญซึ่งอาจมีค่าใช้จ่ายสูงสำหรับทีมและโครงการขนาดเล็ก

• ต้องใช้ทรัพยากรที่มีประสบการณ์ในทุกขั้นตอน - นักวิเคราะห์นักออกแบบนักพัฒนานักทดสอบ

• การทดสอบจะเริ่มต้นหลังจากการพัฒนาเสร็จสมบูรณ์เท่านั้นและผู้ทดสอบจะไม่เกี่ยวข้องกับขั้นตอนก่อนหน้านี้

• ไม่มีการแบ่งปันความเชี่ยวชาญของทีมข้ามสายงานเนื่องจากแต่ละขั้นตอนดำเนินการในไซโล

ควรใช้ Waterfall Model เมื่อใด

คุณสามารถใช้แบบจำลองน้ำตกได้หาก -

• ข้อกำหนดเป็นที่รู้จักกันดี

• คำจำกัดความของผลิตภัณฑ์มีเสถียรภาพ

• เทคโนโลยีเป็นที่เข้าใจกันดี

• เวอร์ชันใหม่ของผลิตภัณฑ์ที่มีอยู่

• การโอนย้ายผลิตภัณฑ์ที่มีอยู่ไปยังแพลตฟอร์มใหม่

• องค์กรขนาดใหญ่ที่มีทีมข้ามสายงานที่มีโครงสร้าง

• ช่องทางการสื่อสารได้รับการจัดตั้งขึ้นอย่างดีภายในองค์กรและกับลูกค้าเช่นกัน

แบบจำลองการสร้างต้นแบบเชิงวิวัฒนาการ

ในการพัฒนาซอฟต์แวร์โดยใช้แบบจำลอง Evolutionary Prototyping นักพัฒนาจะสร้างต้นแบบในช่วงข้อกำหนด จากนั้นผู้ใช้ปลายทางจะประเมินต้นแบบและให้ข้อเสนอแนะ ข้อเสนอแนะสามารถแก้ไขต้นแบบหรือฟังก์ชันเพิ่มเติมได้ จากข้อเสนอแนะผู้พัฒนาได้ปรับแต่งต้นแบบเพิ่มเติม

ดังนั้นผลิตภัณฑ์จึงพัฒนาไปตาม Prototype → Feedback → Refined Prototype Cycles และด้วยเหตุนี้ชื่อ Evolutionary Prototyping เมื่อผู้ใช้พอใจกับฟังก์ชันการทำงานและการทำงานของผลิตภัณฑ์โค้ดต้นแบบจะถูกนำไปใช้ตามมาตรฐานที่กำหนดสำหรับการส่งมอบผลิตภัณฑ์ขั้นสุดท้าย

แบบจำลองการสร้างต้นแบบเชิงวิวัฒนาการ - จุดแข็ง

จุดแข็งหรือข้อดีของแบบจำลองการสร้างต้นแบบวิวัฒนาการคือ -

• ลูกค้า / ผู้ใช้ปลายทางสามารถเห็นภาพความต้องการของระบบเมื่อพวกเขารวมตัวกันเพื่อดูต้นแบบ

• นักพัฒนาเรียนรู้จากลูกค้าและด้วยเหตุนี้จึงไม่มีความคลุมเครือเกี่ยวกับโดเมนหรือสภาพแวดล้อมการผลิต

• ช่วยให้สามารถออกแบบและพัฒนาได้อย่างยืดหยุ่น

• การโต้ตอบกับต้นแบบช่วยกระตุ้นการรับรู้ถึงฟังก์ชันการทำงานที่จำเป็นเพิ่มเติม

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

• มีการสร้างสัญญาณความก้าวหน้าที่มั่นคงและมองเห็นได้

• การส่งมอบผลิตภัณฑ์ขั้นสุดท้ายที่ถูกต้องและบำรุงรักษาได้

แบบจำลองการสร้างต้นแบบเชิงวิวัฒนาการ - จุดอ่อน

จุดอ่อนหรือข้อเสียของ Evolutionary Prototyping model มีดังนี้ -

• มีแนวโน้มที่จะละทิ้งการพัฒนาแบบมีโครงสร้างในการพัฒนาโค้ดแอนด์ฟิกซ์แม้ว่าจะไม่ใช่สิ่งที่โมเดลกำหนด

• โมเดลนี้ได้รับชื่อเสียงที่ไม่ดีสำหรับวิธีการที่รวดเร็วและสกปรก

• ความสามารถในการบำรุงรักษาโดยรวมอาจถูกมองข้ามไป

• ลูกค้าอาจขอให้ส่งมอบต้นแบบเป็นขั้นสุดท้ายโดยไม่เปิดโอกาสให้นักพัฒนาดำเนินการขั้นตอนสุดท้ายนั่นคือการกำหนดมาตรฐานของผลิตภัณฑ์ขั้นสุดท้าย

• โครงการสามารถดำเนินต่อไปได้ตลอดไป (โดยมีขอบเขตต่อเนื่อง) และผู้บริหารอาจไม่เห็นคุณค่า

เมื่อใดควรใช้แบบจำลองการสร้างต้นแบบเชิงวิวัฒนาการ

คุณสามารถใช้โมเดล Evolutionary Prototyping -

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

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

แบบจำลองส่วนเพิ่มซ้ำ - จุดแข็ง

ข้อดีหรือจุดแข็งของ Iterative Incremental model คือ -

• คุณสามารถพัฒนาข้อกำหนดที่จัดลำดับความสำคัญก่อน

• การจัดส่งสินค้าครั้งแรกเร็วกว่า

• ลูกค้าจะได้รับฟังก์ชันที่สำคัญก่อนใคร

• ลดต้นทุนการจัดส่งเริ่มต้น

• การเปิดตัวแต่ละครั้งเป็นการเพิ่มผลิตภัณฑ์เพื่อให้ลูกค้ามีผลิตภัณฑ์ที่ใช้งานได้ตลอดเวลา

• ลูกค้าสามารถให้ข้อเสนอแนะเกี่ยวกับการเพิ่มขึ้นของแต่ละผลิตภัณฑ์ได้ดังนั้นจึงหลีกเลี่ยงความประหลาดใจเมื่อสิ้นสุดการพัฒนา

• การเปลี่ยนแปลงข้อกำหนดสามารถรองรับได้อย่างง่ายดาย

แบบจำลองที่เพิ่มขึ้นซ้ำ ๆ - จุดอ่อน

ข้อเสียของแบบจำลองส่วนเพิ่มแบบวนซ้ำคือ -

• ต้องมีการวางแผนการทำซ้ำอย่างมีประสิทธิภาพ

• ต้องการการออกแบบที่มีประสิทธิภาพเพื่อให้แน่ใจว่ามีการรวมฟังก์ชันการทำงานที่จำเป็นและการจัดเตรียมสำหรับการเปลี่ยนแปลงในภายหลัง

• ต้องการคำจำกัดความของระบบที่สมบูรณ์และใช้งานได้ตั้งแต่เนิ่นๆเพื่อให้สามารถกำหนดค่าส่วนเพิ่มได้

• จำเป็นต้องมีอินเทอร์เฟซโมดูลที่กำหนดไว้อย่างดีเนื่องจากบางส่วนได้รับการพัฒนามานานก่อนที่จะมีการพัฒนาอื่น ๆ

• ต้นทุนรวมของระบบทั้งหมดไม่ต่ำกว่า

เมื่อใดควรใช้แบบจำลองส่วนเพิ่มแบบวนซ้ำ

Iterative Incremental Model สามารถใช้ได้เมื่อ -

• ข้อกำหนดส่วนใหญ่เป็นที่ทราบล่วงหน้า แต่คาดว่าจะพัฒนาไปตามกาลเวลา

• ข้อกำหนดมีการจัดลำดับความสำคัญ

• จำเป็นต้องได้รับฟังก์ชันพื้นฐานที่ส่งมอบอย่างรวดเร็ว

• โครงการมีกำหนดการพัฒนาที่ยาวนาน

• โครงการมีเทคโนโลยีใหม่

• โดเมนเป็นของใหม่สำหรับทีม

โมเดล Rapid Application Development (RAD) มีขั้นตอนดังต่อไปนี้ -

• Requirements Planning phase - ในขั้นตอนการวางแผนข้อกำหนดจำเป็นต้องดำเนินการ aworkshop เพื่อหารือเกี่ยวกับปัญหาทางธุรกิจอย่างมีแบบแผน

• User Description phase - ในขั้นตอนคำอธิบายผู้ใช้เครื่องมืออัตโนมัติจะใช้เพื่อรวบรวมข้อมูลจากผู้ใช้

• Construction phase - ในขั้นตอนการก่อสร้างเครื่องมือเพิ่มประสิทธิภาพเช่นเครื่องกำเนิดโค้ดเครื่องกำเนิดหน้าจอ ฯลฯ จะถูกใช้ภายในกล่องเวลาโดยใช้วิธีการ“ ทำจนกว่าจะเสร็จสิ้น”

• Cut Over phase - ในเฟส Cut over การติดตั้งระบบจะดำเนินการทดสอบการยอมรับของผู้ใช้และการฝึกอบรมผู้ใช้

รูปแบบการพัฒนาแอปพลิเคชันอย่างรวดเร็ว - จุดแข็ง

ข้อดีหรือจุดแข็งของรูปแบบ Rapid Application Development มีดังนี้ -

• ลดเวลาในการทำงานและเพิ่มประสิทธิภาพการทำงานโดยมีสมาชิกในทีมน้อยลงจะหมายถึงต้นทุนที่ลดลง

• การมีส่วนร่วมของลูกค้าตลอดวงจรที่สมบูรณ์ช่วยลดความเสี่ยงที่จะไม่บรรลุความพึงพอใจของลูกค้าและคุณค่าทางธุรกิจ

• โฟกัสจะย้ายไปที่โค้ดในโหมด what-you-see-is-what-you-get (WYSIWYG) สิ่งนี้ทำให้เกิดความชัดเจนว่าสิ่งที่กำลังสร้างคือสิ่งที่ถูกต้อง

• ใช้แนวคิดการสร้างแบบจำลองเพื่อรวบรวมข้อมูลเกี่ยวกับธุรกิจข้อมูลและกระบวนการ

รูปแบบการพัฒนาแอปพลิเคชันอย่างรวดเร็ว - จุดอ่อน

ข้อเสียหรือจุดแข็งของ Rapid Application Development model มีดังนี้ -

• กระบวนการพัฒนาแบบเร่งจะต้องตอบสนองผู้ใช้อย่างรวดเร็ว

• เสี่ยงต่อการไม่บรรลุการปิด

• ยากที่จะใช้กับระบบเดิม

• นักพัฒนาและลูกค้าจะต้องมุ่งมั่นที่จะทำกิจกรรมที่เกิดขึ้นอย่างรวดเร็วในช่วงเวลาสั้น ๆ

เมื่อใดควรใช้โมเดลการพัฒนาแอปพลิเคชันอย่างรวดเร็ว

Rapid Application Development model สามารถใช้ได้เมื่อ -

• ผู้ใช้สามารถมีส่วนร่วมตลอดวงจรชีวิต
• โครงการสามารถกำหนดเวลาได้
• สามารถส่งมอบฟังก์ชันได้ทีละน้อย

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

Spiral model เพิ่มการวิเคราะห์ความเสี่ยงและการสร้างต้นแบบ RAD ให้กับแบบจำลอง Waterfall แต่ละรอบมีลำดับขั้นตอนเดียวกันกับแบบจำลองน้ำตก

แบบจำลองเกลียวมีสี่ส่วน ให้เราคุยรายละเอียด

Quadrant 1 - กำหนดวัตถุประสงค์ทางเลือกและข้อ จำกัด

• Objectives - ฟังก์ชันการทำงานประสิทธิภาพอินเทอร์เฟซฮาร์ดแวร์ / ซอฟต์แวร์ปัจจัยแห่งความสำเร็จที่สำคัญ ฯลฯ

• Alternatives - สร้างใช้ซ้ำซื้อสัญญาย่อย ฯลฯ

• Constraints - ค่าใช้จ่ายกำหนดการอินเทอร์เฟซ ฯลฯ

Quadrant 2 - ประเมินทางเลือกระบุและแก้ไขความเสี่ยง

• ศึกษาทางเลือกอื่นที่สัมพันธ์กับวัตถุประสงค์และข้อ จำกัด ที่กำหนด

• ระบุความเสี่ยงเช่นการขาดประสบการณ์เทคโนโลยีใหม่ตารางงานที่แน่น ฯลฯ

• แก้ไขความเสี่ยงที่ระบุโดยประเมินผลกระทบที่มีต่อโครงการระบุแผนบรรเทาทุกข์และแผนฉุกเฉินที่จำเป็นและนำไปปฏิบัติ ต้องมีการติดตามความเสี่ยงอยู่เสมอ

Quadrant 3 - พัฒนาผลิตภัณฑ์ระดับถัดไป

กิจกรรมทั่วไป ได้แก่ -

• สร้างการออกแบบ
• ทบทวนการออกแบบ
• พัฒนาโค้ด
• ตรวจสอบรหัส
• ทดสอบผลิตภัณฑ์

Quadrant 4 - วางแผนระยะต่อไป

กิจกรรมทั่วไป ได้แก่ -

• จัดทำแผนโครงการ
• พัฒนาแผนการจัดการการกำหนดค่า
• พัฒนาแผนการทดสอบ
• จัดทำแผนการติดตั้ง

Spiral Model - จุดแข็ง

ข้อดีหรือจุดแข็งของวิธี Spiral คือ -

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

Spiral Model - จุดอ่อน

ข้อเสียหรือจุดอ่อนของวิธี Spiral คือ -

• อาจเป็นการยากที่จะกำหนดวัตถุประสงค์เหตุการณ์สำคัญที่ตรวจสอบได้ซึ่งบ่งบอกถึงความพร้อมที่จะดำเนินการผ่านการทำซ้ำครั้งต่อไป

• เวลาที่ใช้ในการวางแผนการรีเซ็ตวัตถุประสงค์การวิเคราะห์ความเสี่ยงและการสร้างต้นแบบอาจเป็นค่าใช้จ่าย

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

• แบบจำลอง Spiral มีความซับซ้อนในการทำความเข้าใจสำหรับสมาชิกในทีมใหม่

• ต้องมีความเชี่ยวชาญในการประเมินความเสี่ยง

• Spiral อาจดำเนินต่อไปอย่างไม่มีกำหนด

• นักพัฒนาจะต้องได้รับการมอบหมายใหม่ในระหว่างกิจกรรมที่ไม่อยู่ระหว่างการพัฒนา

เมื่อใดควรใช้ Spiral Model

Spiral model สามารถใช้ได้เมื่อ -

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

Agile Methods ขึ้นอยู่กับ Agile manifesto และปรับเปลี่ยนได้ตามธรรมชาติ วิธีการเปรียวช่วยให้มั่นใจ -

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

มีวิธีการแบบ Agile หลายวิธีที่ส่งเสริมการพัฒนาซ้ำ ๆ และเพิ่มขึ้นด้วยการทำซ้ำตามเวลา แม้ว่าวิธีการแบบ Agile จะปรับเปลี่ยนได้ แต่กฎของวิธีการเฉพาะนั้นไม่สามารถผ่านได้และด้วยเหตุนี้จึงต้องมีการนำไปใช้อย่างมีวินัย

Agile Methods - จุดแข็ง

ข้อดีหรือจุดแข็งของวิธี Agile คือ -

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

วิธีการที่คล่องตัว - จุดอ่อน

ข้อเสียหรือจุดอ่อนของวิธี Spiral คือ -

• ความพร้อมของลูกค้าอาจไม่สามารถทำได้

• ทีมควรมีประสบการณ์ในการปฏิบัติตามกฎของวิธีการ

• จำเป็นต้องมีการวางแผนที่เหมาะสมเพื่อตัดสินใจอย่างรวดเร็วเกี่ยวกับฟังก์ชันการทำงานที่ต้องจัดส่งในการทำซ้ำ

• ทีมคาดว่าจะมีทักษะในการประมาณและทักษะการเจรจาต่อรอง

• ทีมควรมีทักษะการสื่อสารที่มีประสิทธิภาพ

• ทีมใหม่อาจจัดกันเองไม่ได้

• ต้องมีวินัยในการพัฒนาและส่งมอบในการทำซ้ำตามเวลา

• การออกแบบจะต้องเรียบง่ายและบำรุงรักษาได้จึงต้องใช้ทักษะการออกแบบที่มีประสิทธิภาพ

เมื่อใดควรใช้วิธี Agile

สามารถใช้วิธี Agile เมื่อ -

• แอปพลิเคชันมีความสำคัญต่อเวลา

• ขอบเขตมี จำกัด และเป็นทางการน้อยลง (การปรับขนาดวิธีการแบบ Agile ไปยังโครงการขนาดใหญ่กำลังดำเนินการโดยมีการขยายบางส่วนไปยังวิธีการแบบ Agile)

• องค์กรใช้วิธีการที่มีระเบียบวินัย

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

Adaptive Software Development (ASD) ได้พัฒนาขึ้นเพื่อแก้ไขปัญหาเหล่านี้ โดยมุ่งเน้นที่การเกิดขึ้นเป็นปัจจัยที่สำคัญที่สุดจากมุมมองของผู้บริหารเพื่อเพิ่มความสามารถในการจัดการการพัฒนาผลิตภัณฑ์

ในคำพูดของ Jim Highsmith“ กรอบการพัฒนาซอฟต์แวร์แบบปรับเปลี่ยนได้ขึ้นอยู่กับประสบการณ์หลายปีกับวิธีการพัฒนาซอฟต์แวร์แบบดั้งเดิมการให้คำปรึกษาการฝึกปฏิบัติและการเขียนเกี่ยวกับเทคนิค Rapid Application Development (RAD) และการทำงานร่วมกับ บริษัท ซอฟต์แวร์เทคโนโลยีชั้นสูงในการจัดการการพัฒนาผลิตภัณฑ์ของตน แนวทางปฏิบัติ”.

แบบจำลองน้ำตกพบว่ามีลักษณะเป็นเส้นตรงและความสามารถในการคาดเดาได้โดยมีข้อเสนอแนะน้อย สามารถดูเป็นลำดับของPlan → Build → Implement.

แบบจำลองวัฏจักรของวิวัฒนาการเช่นแบบจำลอง Spiral ได้ย้ายแนวทางการกำหนดไปสู่ ​​Adaptive one โดยมี Plan → Build → Revise Cycles.

อย่างไรก็ตามความคิดของผู้ปฏิบัติงานยังคงมุ่งมั่นโดยมีความสามารถในการคาดการณ์ในระยะยาวเปลี่ยนเป็นการคาดการณ์ในระยะสั้น การปฏิบัติของแบบจำลองวัฏจักรวิวัฒนาการเช่น RAD พบว่ามีความมุ่งมั่นน้อยกว่า

วงจรชีวิตแบบปรับตัว

โมเดล Adaptive สร้างขึ้นจากมุมมองที่แตกต่างกัน แม้ว่าวัฏจักรจะเหมือนกับแบบจำลองวิวัฒนาการ แต่ชื่อของเฟสก็สะท้อนให้เห็นถึงลักษณะที่ไม่สามารถคาดเดาได้ของระบบที่ซับซ้อนมากขึ้น

การพัฒนาแบบปรับตัวก้าวไปไกลกว่ามรดกทางวิวัฒนาการในสองแนวทางหลัก -

• มันแทนที่ความมุ่งมั่นอย่างชัดเจนด้วย Emergence

• นอกเหนือจากการเปลี่ยนแปลงในวงจรชีวิตไปสู่การเปลี่ยนแปลงรูปแบบการจัดการที่ลึกซึ้งยิ่งขึ้น

สามขั้นตอนในวงจรการพัฒนาซอฟต์แวร์แบบปรับตัว ได้แก่ -

• Speculate - Speculate แทนที่การวางแผนคำที่กำหนดไว้การวางแผนข้อกำหนดของผลิตภัณฑ์หรือการวางแผนงานการจัดการโครงการ

• Collaborate - การทำงานร่วมกันแสดงถึงการสร้างสมดุลระหว่าง

  • การจัดการในแง่การบริหารโครงการแบบดั้งเดิมและ

  • การสร้างและรักษาสภาพแวดล้อมการทำงานร่วมกันที่จำเป็นสำหรับการเกิดขึ้น

กิจกรรมความร่วมมือสร้างผลิตภัณฑ์ให้ทันต่อการเปลี่ยนแปลงของสิ่งแวดล้อม

• Learn - เรียนรู้จุดมุ่งหมายทั้งผู้พัฒนาและลูกค้าเพื่อใช้ผลลัพธ์ของแต่ละรอบการพัฒนาเพื่อเรียนรู้ทิศทางต่อไป

ในบทนี้เราจะทำความเข้าใจเกี่ยวกับแนวคิดต่างๆของการพัฒนาซอฟต์แวร์ที่ปรับเปลี่ยนได้

ทฤษฎี Complex Adaptive Systems (CAS)

Brian Arthur และเพื่อนร่วมงานของเขาที่สถาบัน Santa Fe ใช้ทฤษฎี Complex Adaptive Systems (CAS) เพื่อปฏิวัติความเข้าใจเกี่ยวกับฟิสิกส์ชีววิทยาวิวัฒนาการและเศรษฐศาสตร์

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

โลกทั้งสองแตกต่างกันทั้งพฤติกรรมรูปแบบและวัฒนธรรม พวกเขาเรียกร้องให้ -

• เทคนิคการจัดการที่แตกต่างกัน
• กลยุทธ์ที่แตกต่างกัน
• ความเข้าใจที่แตกต่างกัน

การพัฒนาซอฟต์แวร์ที่ซับซ้อน

เนื่องจากขอบเขตของแอปพลิเคชั่นซอฟต์แวร์ถูกขยายออกไปแม้แต่องค์กรพัฒนาซอฟต์แวร์ก็มีความขัดแย้งที่คล้ายคลึงกันดังที่ได้กล่าวไว้ข้างต้น

• โลกใบหนึ่งแสดงโดยการพัฒนาที่มุ่งมั่นซึ่งมาจากแนวทางการจัดการที่มีรากฐานมาจากพื้นฐานของความมั่นคงและความสามารถในการคาดการณ์ (ซึ่งในแง่ของอาเธอร์หมายถึงผลตอบแทนที่ลดลง)

• Second World เป็นตัวแทนของอุตสาหกรรมที่เปลี่ยนจากการลดลงไปสู่สภาพแวดล้อมที่ส่งคืนที่เพิ่มขึ้นซึ่งไม่สามารถคาดเดาได้ไม่เป็นเชิงเส้นและรวดเร็ว

เพื่อแก้ไขปัญหาของโลกที่สองนี้ Jig Highsmith ได้เสนอกรอบการทำงานการพัฒนาซอฟต์แวร์แบบปรับตัวที่แตกต่างจากการพัฒนาซอฟต์แวร์ที่มุ่งมั่น

การพัฒนาซอฟต์แวร์ Adaptive มุ่งเน้นไปที่การจัดการกับระบบที่ซับซ้อน -

• Adaptive Software Development สำหรับวงจรชีวิตของการพัฒนา

• เทคนิคการจัดการแบบปรับตัวเรียกร้องให้มีความคิดที่แตกต่างจากแนวทางการจัดการโครงการแบบเดิม

ในบทช่วยสอนนี้คุณสามารถเข้าใจการใช้งานทั้งสองนี้

Adaptive Software Development (ASD) ขึ้นอยู่กับสองมุมมอง -

• มุมมองแนวคิดตามทฤษฎี Complex Adaptive Systems (CAS) ตามที่ระบุในส่วนแรกของบทนี้

• มุมมองเชิงปฏิบัติตาม

  • ประสบการณ์หลายปีกับวิธีการพัฒนาซอฟต์แวร์ที่มุ่งมั่น

  • ให้คำปรึกษาฝึกฝนและเขียนเกี่ยวกับเทคนิค Rapid Application Development (RAD) และทำงานร่วมกับ บริษัท ซอฟต์แวร์เทคโนโลยีชั้นสูงในการจัดการการพัฒนาผลิตภัณฑ์ของตน

ในบทนี้คุณจะเข้าใจมุมมองแนวความคิดของ Adaptive Software Development

แนวคิด Complex Adaptive Systems (CAS)

ทฤษฎี Complex Adaptive Systems (CAS) มีหลายแนวคิด การพัฒนาซอฟต์แวร์แบบปรับเปลี่ยนได้ขึ้นอยู่กับสองแนวคิดเหล่านี้ -

• Emergence
• Complexity

การเกิดขึ้น

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

สิ่งนี้สามารถเกิดขึ้นได้โดย Emergence ดังที่แสดงไว้ในทฤษฎี Complex Adaptive Systems (CAS) สามารถเข้าใจได้จากตัวอย่างง่ายๆเช่นพฤติกรรมการแห่ของนก

เมื่อคุณสังเกตฝูงนกคุณสังเกตเห็นว่า -

• นกแต่ละตัวพยายามที่จะ

  • รักษาระยะห่างขั้นต่ำจากวัตถุอื่น ๆ ในสิ่งแวดล้อมรวมทั้งนกอื่น ๆ

  • จับคู่ความเร็วกับนกในละแวกนั้น

  • มุ่งหน้าไปยังจุดศูนย์กลางของมวลนกในละแวกนั้น

• ไม่มีกฎเกณฑ์ของพฤติกรรมสำหรับกลุ่ม กฎเดียวคือเกี่ยวกับพฤติกรรมของนกแต่ละตัว

• อย่างไรก็ตามมีพฤติกรรมที่เกิดขึ้นใหม่คือฝูงนก เมื่อนกหลงทางวิ่งไล่ตามฝูงนกก็แยกย้ายไปรอบ ๆ สิ่งกีดขวางและการปฏิรูปในอีกด้านหนึ่ง

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

นอกเหนือจากการพัฒนาแล้วการเกิดขึ้นเป็นแนวคิดที่สำคัญที่สุดจากมุมมองของผู้บริหารด้วย

ความซับซ้อน

ในบริบทการพัฒนาซอฟต์แวร์ความซับซ้อนเป็นเรื่อง -

• บุคคลของทีมเช่นนักพัฒนาลูกค้าผู้ขายคู่แข่งและผู้ถือหุ้นจำนวนและความเร็วของพวกเขา

• ขนาดและความซับซ้อนทางเทคโนโลยี

แนวทางปฏิบัติในการพัฒนาซอฟต์แวร์ที่ปรับเปลี่ยนได้

Adaptive Software Development นำเสนอมุมมองที่แตกต่างเกี่ยวกับแนวทางการจัดการซอฟต์แวร์ ในส่วนด้านล่างนี้คุณจะเข้าใจแนวทางปฏิบัติที่สำคัญ 2 ข้อนั่นคือคุณภาพและ RAD ซึ่งทั้งสองอย่างนี้มีการแบ่งส่วนเพื่อรวบรวมข้อกำหนด

คุณสามารถดูรายละเอียดของแนวทางปฏิบัติทั้งหมดได้ในบทแนวทางการพัฒนาซอฟต์แวร์แบบปรับเปลี่ยนได้ในบทช่วยสอนนี้

คุณภาพ

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

แนวทางปฏิบัติของ RAD

แนวทางปฏิบัติของ RAD โดยทั่วไปจะเกี่ยวข้องกับสิ่งต่อไปนี้ -

• วัฏจักรของวิวัฒนาการ
• กลุ่มโฟกัสลูกค้าเซสชัน JAD บทวิจารณ์ด้านเทคนิค
• การจัดการโครงการแบบกำหนดเวลา
• วิศวกรรมซอฟต์แวร์ต่อเนื่อง
• ทีมเฉพาะพร้อมห้องสงคราม

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

แนวทางปฏิบัติของ RAD และกระบวนการของ Microsoft เป็นตัวอย่างของการพัฒนาแบบปรับตัวในการดำเนินการ การให้ป้ายกำกับ (เช่นการพัฒนาแบบปรับตัว) และตระหนักว่ามีองค์ความรู้ทางวิทยาศาสตร์เพิ่มมากขึ้น (เช่นทฤษฎี CAS) อธิบายว่าเหตุใดจึงทำงานได้ สิ่งนี้ควรเป็นพื้นฐานสำหรับการใช้แนวปฏิบัติเหล่านี้อย่างครอบคลุมมากขึ้น

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

Jim Highsmith เผยแพร่ Adaptive Software Development ในปี 2000

แนวทางปฏิบัติในการพัฒนาซอฟต์แวร์แบบปรับได้ให้ความสามารถในการรองรับการเปลี่ยนแปลงและสามารถปรับเปลี่ยนได้ในสภาพแวดล้อมที่ปั่นป่วนด้วยผลิตภัณฑ์ที่พัฒนาโดยมีการวางแผนและการเรียนรู้เพียงเล็กน้อย

ขั้นตอนของวงจรชีวิต ASD

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

• Speculate
• Collaborate
• Learn

ทั้งสามขั้นตอนนี้สะท้อนให้เห็นถึงลักษณะไดนามิกของการพัฒนาซอฟต์แวร์แบบปรับตัว การพัฒนาแบบปรับตัวได้แทนที่ความมุ่งมั่นอย่างชัดเจนด้วยภาวะฉุกเฉิน นอกเหนือไปจากการเปลี่ยนแปลงเพียงอย่างเดียวในวงจรชีวิตไปสู่การเปลี่ยนแปลงรูปแบบการจัดการที่ลึกซึ้งยิ่งขึ้น Adaptive Software Development มีวงจรชีวิต Speculate-Collaborate-Learn แบบไดนามิก

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

เก็งกำไร

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

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

ร่วมมือ

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

การทำงานร่วมกันจะต้องใช้ความสามารถในการทำงานร่วมกันเพื่อสร้างผลลัพธ์แบ่งปันความรู้หรือตัดสินใจ

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

เรียนรู้

ส่วนเรียนรู้ของวงจรชีวิตมีความสำคัญต่อความสำเร็จของโครงการ ทีมต้องเพิ่มพูนความรู้อย่างต่อเนื่องโดยใช้แนวทางปฏิบัติเช่น -

• บทวิจารณ์ทางเทคนิค
• Retrospectives โครงการ
• กลุ่มโฟกัสลูกค้า

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

• เกี่ยวกับการเปลี่ยนแปลงผลิตภัณฑ์

• การเปลี่ยนแปลงพื้นฐานเพิ่มเติมในสมมติฐานพื้นฐานเกี่ยวกับวิธีการพัฒนาผลิตภัณฑ์

การทำซ้ำจะต้องสั้นเพื่อให้ทีมสามารถเรียนรู้จากข้อผิดพลาดเล็ก ๆ แทนที่จะเป็นข้อผิดพลาดใหญ่

เก็งกำไร - ทำงานร่วมกัน - เรียนรู้วงจรโดยรวม

ดังที่คุณสังเกตจากวงจร Speculate-Collaborate-Learn ที่ระบุไว้ข้างต้นจะเห็นได้ชัดว่าทั้งสามขั้นตอนไม่เป็นเชิงเส้นและทับซ้อนกัน

เราสังเกตสิ่งต่อไปนี้จาก Adaptive framework

• เป็นการยากที่จะทำงานร่วมกันโดยไม่ต้องเรียนรู้หรือเรียนรู้โดยไม่ต้องร่วมมือกัน

• เป็นการยากที่จะเก็งกำไรโดยไม่ต้องเรียนรู้หรือเรียนรู้โดยไม่เก็งกำไร

• เป็นการยากที่จะเก็งกำไรโดยไม่ต้องทำงานร่วมกันหรือร่วมมือกันโดยไม่ต้องคาดเดา

วงจรการพัฒนาซอฟต์แวร์แบบปรับตัวมีลักษณะพื้นฐานหกประการ -

• เน้นภารกิจ
• ตามคุณลักษณะ
• Iterative
• Time-boxed
• ขับเคลื่อนด้วยความเสี่ยง
• เปลี่ยนความอดทน

ในบทนี้คุณจะเข้าใจลักษณะทั้ง 6 ประการของการพัฒนาซอฟต์แวร์แบบปรับเปลี่ยนได้

เน้นภารกิจ

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

หากไม่มีภารกิจที่ชัดเจนและการฝึกฝนการปรับแต่งภารกิจอย่างสม่ำเสมอวงจรชีวิตแบบวนซ้ำจะกลายเป็นวงจรชีวิตที่แกว่งไปมาแกว่งไปมาโดยไม่มีความคืบหน้าในการพัฒนา

ตามคุณลักษณะ

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

คุณลักษณะสามารถพัฒนาได้จากการทำซ้ำหลายครั้งเมื่อลูกค้าให้ข้อเสนอแนะ

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

ซ้ำ

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

ไทม์บ็อกซ์

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

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

ขับเคลื่อนด้วยความเสี่ยง

ใน Adaptive Software Development การทำซ้ำจะขับเคลื่อนโดยการระบุและประเมินความเสี่ยงที่สำคัญ

ยอมรับการเปลี่ยนแปลง

การพัฒนาซอฟต์แวร์แบบปรับเปลี่ยนสามารถยอมรับการเปลี่ยนแปลงได้โดยมองว่าการเปลี่ยนแปลงเป็นความสามารถในการเพิ่มความได้เปรียบในการแข่งขัน แต่ไม่ใช่ปัญหาสำหรับการพัฒนา

แนวทางปฏิบัติในการพัฒนาซอฟต์แวร์แบบปรับเปลี่ยนได้รับแรงหนุนจากความเชื่อในการปรับตัวอย่างต่อเนื่องโดยมีวงจรชีวิตพร้อมที่จะยอมรับการเปลี่ยนแปลงอย่างต่อเนื่องเป็นบรรทัดฐาน

Adaptive Software Development Lifecycle ทุ่มเทให้กับ -

• การเรียนรู้อย่างต่อเนื่อง
• เปลี่ยนการวางแนว
• Re-evaluation
• มองไปสู่อนาคตที่ไม่แน่นอน
• การทำงานร่วมกันอย่างเข้มข้นระหว่างนักพัฒนาการจัดการและลูกค้า

SDLC ที่ปรับเปลี่ยนได้

การพัฒนาซอฟต์แวร์แบบปรับเปลี่ยนได้รวม RAD เข้ากับแนวทางปฏิบัติที่ดีที่สุดทางวิศวกรรมซอฟต์แวร์เช่น -

• การเริ่มต้นโครงการ
• การวางแผนวงจรการปรับตัว
• วิศวกรรมส่วนประกอบพร้อมกัน
• การตรวจสอบคุณภาพ
• QA ขั้นสุดท้ายและการเปิดตัว

แนวทางปฏิบัติในการพัฒนาซอฟต์แวร์แบบปรับเปลี่ยนสามารถแสดงได้ดังนี้ -

ดังที่แสดงไว้ข้างต้นแนวปฏิบัติด้านการพัฒนาซอฟต์แวร์แบบปรับเปลี่ยนได้แบ่งออกเป็นสามขั้นตอนดังนี้ -

• เก็งกำไร - การเริ่มต้นและการวางแผน

  • การริเริ่มโครงการ

  • การสร้างกล่องเวลาสำหรับโครงการทั้งหมด

  • ตัดสินใจเกี่ยวกับจำนวนการทำซ้ำและกำหนดช่องเวลาให้กับแต่ละรายการ

  • พัฒนาธีมหรือวัตถุประสงค์สำหรับการทำซ้ำแต่ละครั้ง

  • กำหนดคุณสมบัติให้กับการทำซ้ำแต่ละครั้ง

• Collaborate - การพัฒนาคุณสมบัติพร้อมกัน

  • การทำงานร่วมกันสำหรับทีมแบบกระจาย

  • การทำงานร่วมกันสำหรับโครงการขนาดเล็ก

  • การทำงานร่วมกันสำหรับโครงการขนาดใหญ่

• Learn - การตรวจสอบคุณภาพ

  • คุณภาพผลลัพธ์จากมุมมองของลูกค้า

  • คุณภาพของผลลัพธ์จากมุมมองทางเทคนิค

  • การทำงานของทีมส่งมอบและสมาชิกในทีมปฏิบัติกำลังใช้ประโยชน์

  • สถานะโครงการ

เก็งกำไร - การเริ่มต้นและการวางแผน

ในการพัฒนาซอฟต์แวร์แบบปรับเปลี่ยนขั้นตอนการเก็งกำไรมีสองกิจกรรม -

• Initiation
• Planning

เก็งกำไรมีแนวทางปฏิบัติห้าประการที่สามารถดำเนินการซ้ำ ๆ ในระหว่างขั้นตอนการเริ่มต้นและการวางแผน พวกเขาคือ -

• การเริ่มต้นโครงการ
• การสร้างกล่องเวลาสำหรับโครงการทั้งหมด
• ตัดสินใจเกี่ยวกับจำนวนการทำซ้ำและกำหนดช่องเวลาให้กับแต่ละรายการ
• พัฒนาธีมหรือวัตถุประสงค์สำหรับการทำซ้ำแต่ละครั้ง
• กำหนดคุณสมบัติให้กับการทำซ้ำแต่ละครั้ง

การริเริ่มโครงการ

การริเริ่มโครงการเกี่ยวข้องกับ -

• การกำหนดภารกิจและวัตถุประสงค์ของโครงการ
• การทำความเข้าใจข้อ จำกัด
• การจัดตั้งองค์กรโครงการ
• การระบุและสรุปข้อกำหนด
• ทำการประมาณขนาดและขอบเขตเบื้องต้น
• การระบุความเสี่ยงที่สำคัญของโครงการ

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

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

การสร้างกล่องเวลาสำหรับทั้งโครงการ

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

ดังที่คุณทราบแล้วการเก็งกำไรไม่ได้ละทิ้งการประมาณค่า แต่หมายถึงการยอมรับว่าการประมาณการอาจผิดพลาดได้

การทำซ้ำและกล่องเวลา

ตัดสินใจเกี่ยวกับจำนวนการทำซ้ำและระยะเวลาในการทำซ้ำแต่ละครั้งโดยพิจารณาจากขอบเขตของโครงการโดยรวมและระดับความไม่แน่นอน

สำหรับแอปพลิเคชันขนาดเล็กถึงขนาดกลาง -

• การทำซ้ำมักจะแตกต่างกันไปตั้งแต่สี่ถึงแปดสัปดาห์
• บางโครงการทำงานได้ดีที่สุดเมื่อทำซ้ำสองสัปดาห์
• บางโครงการอาจต้องใช้เวลามากกว่าแปดสัปดาห์

เลือกเวลาตามสิ่งที่เหมาะกับคุณ เมื่อคุณตัดสินใจเกี่ยวกับจำนวนการทำซ้ำและความยาวของการทำซ้ำแต่ละครั้งแล้วให้กำหนดตารางเวลาสำหรับการทำซ้ำแต่ละครั้ง

พัฒนาธีมหรือวัตถุประสงค์

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

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

กำหนดคุณสมบัติ

นักพัฒนาและลูกค้าควรร่วมกันกำหนดคุณลักษณะให้กับการทำซ้ำแต่ละครั้ง เกณฑ์ที่สำคัญที่สุดสำหรับการกำหนดคุณลักษณะนี้คือการทำซ้ำทุกครั้งจะต้องส่งมอบชุดคุณลักษณะที่มองเห็นได้พร้อมฟังก์ชันการทำงานที่สำคัญให้กับลูกค้า

ระหว่างการกำหนดคุณสมบัติให้กับการทำซ้ำ -

• ทีมพัฒนาควรจัดทำประมาณการคุณลักษณะความเสี่ยงและการอ้างอิงและให้ข้อมูลแก่ลูกค้า

• ลูกค้าควรตัดสินใจเกี่ยวกับการจัดลำดับความสำคัญของคุณลักษณะโดยใช้ข้อมูลที่ทีมพัฒนาให้มา

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

ร่วมมือกัน─การพัฒนาคุณสมบัติพร้อมกัน

ในระหว่างขั้นตอนการทำงานร่วมกันโฟกัสอยู่ที่การพัฒนา ขั้นตอนการทำงานร่วมกันมีสองกิจกรรม -

• ทีมพัฒนาทำงานร่วมกันและส่งมอบซอฟต์แวร์ที่ใช้งานได้

• ผู้จัดการโครงการอำนวยความสะดวกในการทำงานร่วมกันและกิจกรรมการพัฒนาที่เกิดขึ้นพร้อมกัน

การทำงานร่วมกันคือการสร้างสรรค์ร่วมกันซึ่งครอบคลุมทีมพัฒนาลูกค้าและผู้จัดการ การสร้างร่วมกันได้รับการสนับสนุนโดยความไว้วางใจและความเคารพ

ทีมควรร่วมมือกัน -

• ปัญหาทางเทคนิค
• ข้อกำหนดทางธุรกิจ
• การตัดสินใจอย่างรวดเร็ว

ต่อไปนี้เป็นแนวทางปฏิบัติที่เกี่ยวข้องกับขั้นตอนการทำงานร่วมกันใน Adaptive Software Development -

• การทำงานร่วมกันสำหรับทีมแบบกระจาย
• การทำงานร่วมกันสำหรับโครงการขนาดเล็ก
• การทำงานร่วมกันสำหรับโครงการขนาดใหญ่

การทำงานร่วมกันสำหรับทีมแบบกระจาย

ในโครงการที่เกี่ยวข้องกับทีมแบบกระจายควรพิจารณาสิ่งต่อไปนี้ -

• พันธมิตรที่แตกต่างกัน
• ความรู้เชิงกว้าง
• วิธีที่ผู้คนโต้ตอบ
• วิธีที่พวกเขาจัดการการพึ่งพาระหว่างกัน

การทำงานร่วมกันสำหรับโครงการขนาดเล็ก

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

การทำงานร่วมกันสำหรับโครงการขนาดใหญ่

โครงการขนาดใหญ่จำเป็นต้องมีการปฏิบัติเพิ่มเติมเครื่องมือการทำงานร่วมกันและการโต้ตอบของผู้จัดการโครงการและควรจัดเรียงตามบริบท

เรียนรู้ - การตรวจสอบคุณภาพ

Adaptive Software Development สนับสนุนแนวคิดของ 'Experiment and Learn'

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

• หาข้อผิดพลาด
• เรียนรู้จากพวกเขา
• ลดการทำงานซ้ำโดยค้นหาปัญหาเล็ก ๆ ก่อนที่จะกลายเป็นปัญหาใหญ่

ในตอนท้ายของการทำซ้ำการพัฒนาแต่ละครั้งมีสิ่งที่ต้องเรียนรู้ทั่วไปสี่ประเภท -

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

คุณภาพผลลัพธ์จากมุมมองของลูกค้า

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

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

คุณภาพของผลลัพธ์จากมุมมองทางเทคนิค

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

ในโครงการ Adaptive Software Development ทีมงานควรตรวจสอบประสิทธิภาพของตนเองเป็นระยะ Retrospectives ส่งเสริมให้ทีมเรียนรู้เกี่ยวกับตัวเองและงานของพวกเขาร่วมกันเป็นทีม

การทบทวนย้อนหลังแบบวนซ้ำช่วยให้สามารถทบทวนประสิทธิภาพของทีมได้เป็นระยะเช่น -

• ตรวจสอบสิ่งที่ไม่ได้ผล
• สิ่งที่ทีมต้องทำเพิ่มเติม
• สิ่งที่ทีมต้องทำน้อยลง

สถานะโครงการ

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

การตรวจสอบสถานะโครงการควรประกอบด้วย -

• โครงการอยู่ที่ไหน
• โครงการกับแผนอยู่ที่ไหน?
• โครงการควรอยู่ที่ไหน?

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

ผังงานของการจัดการซอฟต์แวร์แบบดั้งเดิมแสดงอยู่ด้านล่าง

การจัดการซอฟต์แวร์แบบดั้งเดิมมีลักษณะเฉพาะด้วยคำสั่งควบคุม

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

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

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

การจัดการแบบปรับตัว

การจัดการแบบปรับตัวได้พิสูจน์แล้วว่าประสบความสำเร็จในสภาพแวดล้อมที่ผู้จัดการทรัพยากรทำงานร่วมกันกับผู้มีส่วนได้ส่วนเสียและนักวิทยาศาสตร์เป็นทีมโดยมีเป้าหมายดังต่อไปนี้ -

• เพื่อเรียนรู้ว่าระบบที่ถูกจัดการตอบสนองต่อการแทรกแซงของมนุษย์อย่างไร

• เพื่อปรับปรุงนโยบายและแนวปฏิบัติด้านทรัพยากรในอนาคต

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

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

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

การจัดการแบบปรับตัวช่วยในการเปลี่ยนแปลงการตัดสินใจโดยทำให้ชัดเจนว่า -

• การตัดสินใจเป็นเรื่องชั่วคราว
• การตัดสินใจของผู้บริหารไม่จำเป็นต้องถูกเสมอไป
• คาดว่าจะมีการปรับเปลี่ยน

แนวทางการจัดการแบบปรับตัวมีสองประเภท -

• Passive Adaptive Management
• Active Adaptive Management

Passive Adaptive Management

การจัดการแบบปรับตัวมีจุดมุ่งหมายเพื่อเพิ่มพูนความรู้ทางวิทยาศาสตร์และจึงช่วยลดความไม่แน่นอน

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

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

Active Adaptive Management

แนวทางการจัดการแบบ Active Adaptive จะตรวจสอบข้อมูลก่อนที่จะดำเนินการจัดการ

จากนั้นจึงมีการพัฒนาแบบจำลองระบบทางเลือกของระบบนิเวศที่แข่งขันกันและการตอบสนองที่เกี่ยวข้อง (เช่นการเปลี่ยนแปลงทางประชากรการใช้เพื่อการพักผ่อนหย่อนใจ) แทนที่จะเป็นแบบจำลองเดียว ตัวเลือกการจัดการจะถูกเลือกตามการประเมินของโมเดลทางเลือกเหล่านี้

การจัดการความเป็นผู้นำ - การทำงานร่วมกัน

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

ในการพัฒนาซอฟต์แวร์ผู้นำมักจะรับผิดชอบเหล่านี้ เราต้องการผู้นำมากกว่าแม่ทัพ ผู้นำคือผู้ทำงานร่วมกันและทำงานร่วมกับทีม Collaborative-Leadership เป็นแนวทางปฏิบัติที่เป็นที่ต้องการมากที่สุดในการพัฒนาแบบปรับตัว

ผู้นำมีคุณสมบัติดังนี้ -

• เข้าใจและกำหนดทิศทาง

• มีอิทธิพลต่อผู้ที่เกี่ยวข้องและให้คำแนะนำ

• ทำงานร่วมกันอำนวยความสะดวกและจัดการทีมในระดับมหภาค

• ให้ทิศทาง

• สร้างสภาพแวดล้อมที่ผู้มีความสามารถสามารถเป็นนวัตกรรมสร้างสรรค์และตัดสินใจได้อย่างมีประสิทธิภาพ

• เข้าใจว่าบางครั้งพวกเขาจำเป็นต้องสั่งการ แต่นั่นไม่ใช่สไตล์ที่โดดเด่นของพวกเขา