เนื้อหา
- ทำไมต้อง Agile IT
- วิธีการเปรียวรับมือกับปัญหาของตัวแบบน้ำตกได้อย่างไร
- Agile ส่งผลกระทบต่ออุตสาหกรรมไอทีอย่างไร
- ไม่มีข้อบกพร่องไม่มีความเครียด - คู่มือแบบเป็นขั้นตอนเพื่อสร้างซอฟต์แวร์ที่เปลี่ยนแปลงชีวิตโดยไม่ทำลายชีวิตของคุณ
- เหตุผลที่เปลี่ยนเป็นวิธีปฏิบัติที่คล่องตัว
- การจัดการความต้องการแย่
- การออกแบบซอฟต์แวร์ไม่ดี
- ข้อ จำกัด ในการพัฒนา
- BT ทำอะไรเพื่อแก้ไขปัญหาข้างต้น
- ข้อสรุป
ที่มา: Darkovujic / Dreamstime.com
Takeaway:
สำหรับหลาย ๆ คนโมเดลการพัฒนาซอฟต์แวร์ของน้ำตกเป็นมาตรฐานมานานหลายทศวรรษ แต่ตอนนี้ถูกแทนที่ด้วยวิธีการที่คล่องตัวกว่า
วิธีการ Agile สำหรับการพัฒนาซอฟต์แวร์สามารถส่งผลกระทบเชิงบวกต่ออุตสาหกรรมไอที ผลลัพธ์ของการยอมรับวิธีการแบบ Agile นั้นสามารถวัดได้หลายวิธี ตอบสนองได้เร็วขึ้นของการร้องขอการเปลี่ยนแปลงซอฟต์แวร์ข้อบกพร่องที่น้อยลงการวัดเชิงปริมาณของประสิทธิภาพของทีมและปัญหาคอขวดล้วนเป็นภาพสะท้อนของการดำเนินงานที่ประสบความสำเร็จของ Agile ในการวัดผลกระทบของ Agile ได้สำเร็จองค์กรต้องเปรียบเทียบตัวชี้วัดต่าง ๆ ที่เกี่ยวข้องกับการพัฒนา pre-Agile และ post-Agile ผลกระทบที่แท้จริงของ Agile นั้นไม่สามารถวัดได้จากการเพิ่มขึ้นของรายได้หรือจากจำนวนของบั๊กที่เพิ่มขึ้น ต้องพิจารณาพารามิเตอร์ภายในหลายอย่างเพื่อทำความเข้าใจกับผลกระทบที่แท้จริง (สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการพัฒนาแบบ Agile ดูการพัฒนาซอฟต์แวร์แบบ Agile 101)
ทำไมต้อง Agile IT
อุตสาหกรรมไอทีได้รับการโน้มน้าวให้ปฏิบัติ Agile ส่วนใหญ่เนื่องจากข้อ จำกัด ของรูปแบบน้ำตกของการพัฒนาซอฟต์แวร์ โดยทั่วไปจะพบว่า บริษัท ไอทีไม่สามารถตอบสนองต่อการเปลี่ยนแปลงความต้องการของลูกค้าหรือสถานการณ์ตลาดหรือลดต้นทุนด้วยโมเดลการพัฒนาซอฟต์แวร์ แม้ว่าเราจะถ่วงดุลเอียงไปทางระเบียบวิธี Agile และพิจารณาความตื่นเต้นที่จะเป็นเพียงแค่โฆษณา แต่ก็มีข้อเสนอแนะเชิงประจักษ์มากมายต่อโมเดลน้ำตก
พูดง่ายๆก็คือโมเดลฟอลส์เป็นรูปแบบการพัฒนาซอฟต์แวร์ที่ใช้งานได้อย่างต่อเนื่อง - หนึ่งเฟสหลังจากนั้นอีกหนึ่งเฟส โมเดลนี้มีห้าขั้นตอน: ข้อกำหนดการออกแบบการนำไปใช้การตรวจสอบและการบำรุงรักษา โดยปกติหลังจากเสร็จสิ้นขั้นตอนเดียวจะเป็นการยากถ้าไม่เป็นไปไม่ได้ที่จะทำการเปลี่ยนแปลงในช่วงก่อนหน้า ดังนั้นสมมติฐานคือข้อกำหนดมีการแก้ไขค่อนข้างมาก ความแตกต่างที่สำคัญกับโมเดล Agile นั้นอยู่ในสมมติฐานที่ว่าจะไม่มีการเปลี่ยนแปลงข้อกำหนด Agile สันนิษฐานว่าสถานการณ์ทางธุรกิจจะเปลี่ยนแปลงและข้อกำหนดอื่น ๆ ดังนั้นซอฟต์แวร์จะถูกส่งเป็นชิ้นเล็ก ๆ มากกว่า ss ในขณะที่ในโมเดลน้ำตกการส่งหรือปล่อยครั้งแรกจะเกิดขึ้นหลังจากเวลานาน (สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการพัฒนาดูที่ Apache Spark ช่วยพัฒนาแอปพลิเคชันอย่างรวดเร็ว)
การวิจารณ์ที่น่าสังเกตมากที่สุดต่อโมเดลน้ำตกเป็นข้อสันนิษฐานว่าจะไม่มีการเปลี่ยนแปลงข้อกำหนดใด ๆ ข้อสันนิษฐานนั้นมีข้อบกพร่องและไม่สมจริง ตัวอย่างเช่นในปีพ. ศ. 2544 การศึกษาโครงการด้านไอที 1,027 รายการในสหราชอาณาจักรแสดงให้เห็นว่าข้อสันนิษฐานนี้เป็นสาเหตุที่ใหญ่ที่สุดเพียงข้อเดียวของความล้มเหลวของโครงการด้านไอที
ในอีกตัวอย่างหนึ่ง Craig Larman ผู้แต่งหนังสือ "Agile and Iterative Development: A Manager's Guide" ได้ชี้ให้เห็นว่าโครงการจำนวนหนึ่งดำเนินการโดยกระทรวงกลาโหม (DoD) โดยใช้โมเดลน้ำตกในสหรัฐอเมริกาล้มเหลวในการ บรรลุวัตถุประสงค์ของพวกเขา ตลอดทศวรรษที่ 1980 และปี 1990 กระทรวงฯ จำเป็นต้องใช้โมเดลน้ำตกสำหรับโครงการพัฒนาซอฟต์แวร์ตามมาตรฐานที่ตีพิมพ์ในกระทรวงมาตรฐานฉบับที่ 2167 สถิติที่น่าตกใจเปิดเผยว่า 75% ของโครงการซอฟต์แวร์เหล่านี้ไม่เคยใช้ จากรายงานนี้คณะทำงานได้เปิดตัวภายใต้ Dr. Frederick Brooks ผู้เชี่ยวชาญด้านวิศวกรรมซอฟต์แวร์ที่มีชื่อเสียง กองเรือรบออกมาพร้อมกับรายงานที่ให้ความเห็นว่า "กระทรวงกลาโหมที่ 2167 ต้องการการยกเครื่องครั้งใหญ่เพื่อสะท้อนให้เห็นถึงแนวปฏิบัติที่ดีที่สุดในปัจจุบัน การพัฒนาเชิงวิวัฒนาการนั้นดีที่สุดในทางเทคนิคมันช่วยประหยัดเวลาและเงิน "
สมมติฐานสี่ข้อต่อไปนี้ของโมเดลน้ำตกล้มเหลวในสถานการณ์จริง:
- ข้อกำหนดที่ให้ไว้มีการกำหนดไว้อย่างสมเหตุสมผลและจะไม่เปลี่ยนแปลงอย่างมีนัยสำคัญ
- แม้ว่าความต้องการจะเปลี่ยนแปลงไปในระหว่างขั้นตอนการพัฒนา แต่ก็จะมีขนาดเล็กพอที่จะรองรับได้ในวงจรการพัฒนา
- การรวมระบบซึ่งเกิดขึ้นหลังจากการส่งมอบซอฟต์แวร์จะเป็นไปตามแผน
- นวัตกรรมซอฟต์แวร์และความพยายามที่จำเป็นในการคิดค้นจะเป็นไปตามกำหนดการและคาดการณ์ได้
วิธีการเปรียวรับมือกับปัญหาของตัวแบบน้ำตกได้อย่างไร
วิธีการเปรียวพื้นฐานแตกต่างจากแบบจำลองน้ำตกและที่ชัดเจนจากสมมติฐาน:
- ไม่มีใครแม้แต่ลูกค้าก็สามารถรู้หรือเข้าใจข้อกำหนดได้อย่างสมบูรณ์ ไม่มีการรับประกันว่าข้อกำหนดจะไม่เปลี่ยนแปลง
- การเปลี่ยนแปลงความต้องการอาจไม่เล็กและสามารถจัดการได้ ในความเป็นจริงพวกเขาจะมาในขนาดต่าง ๆ และจะมาต่อ ดังนั้นซอฟต์แวร์จะถูกส่งมอบทีละน้อยเพื่อติดตามการเปลี่ยนแปลง
Agile ส่งผลกระทบต่ออุตสาหกรรมไอทีอย่างไร
Agile ถูกนำไปใช้ในหลาย ๆ ที่ในขณะที่ บริษัท จำนวนมากกำลังวางแผนที่จะใช้ Agile แม้ว่า Agile ได้ทำการเปลี่ยนแปลงพื้นฐานในอุตสาหกรรมไอทีอย่างแน่นอน แต่ข้อเท็จจริงและตัวเลขยังคงยากที่จะได้รับ แต่ผลกระทบของ Agile สามารถเข้าใจได้ด้วยกรณีศึกษาของ British Telecom (BT) ที่ระบุด้านล่าง
ไม่มีข้อบกพร่องไม่มีความเครียด - คู่มือแบบเป็นขั้นตอนเพื่อสร้างซอฟต์แวร์ที่เปลี่ยนแปลงชีวิตโดยไม่ทำลายชีวิตของคุณ
คุณไม่สามารถพัฒนาทักษะการเขียนโปรแกรมของคุณเมื่อไม่มีใครใส่ใจคุณภาพของซอฟต์แวร์
เหตุผลที่เปลี่ยนเป็นวิธีปฏิบัติที่คล่องตัว
บีทีเริ่มประสบปัญหาจำนวนมากกับแนวทางการพัฒนาซอฟต์แวร์ในปี 2547 บีทีได้พัฒนาโครงการซอฟต์แวร์จำนวนมากทั้งที่เรียบง่ายและซับซ้อน โครงการซอฟต์แวร์จำนวนมากไม่สามารถพัฒนาผลผลิตที่มีคุณภาพภายในระยะเวลาที่ตกลงกัน BT พบว่าปัญหาที่เกิดขึ้นเป็นรากฐานของรูปแบบน้ำตก ดังนั้นการเสริมรูปแบบน้ำตกจึงไม่ช่วย สาเหตุหลักของปัญหาระบุไว้ด้านล่าง:
การจัดการความต้องการแย่
- มีการให้ข้อกำหนดจำนวนมากเกินไปเพื่อให้บรรลุผลภายในเวลาที่ จำกัด เกินไป
- ข้อกำหนดจำนวนมากไม่เกี่ยวข้องกับความต้องการทางธุรกิจ
- เกือบทั้งหมดหากไม่ใช่ข้อกำหนดทั้งหมดจะถูกกำหนดสถานะเป็นลำดับความสำคัญสูง
- ความต้องการแสดงถึงความต้องการทางธุรกิจในปัจจุบันโดยไม่ต้องรอดูสถานการณ์ในอนาคต สิ่งนี้ทิ้งไว้ซึ่งความเป็นไปได้ที่จะเกิดการเปลี่ยนแปลงซอฟต์แวร์ในอนาคต
การออกแบบซอฟต์แวร์ไม่ดี
- ด้วยข้อกำหนดจำนวนมากนักออกแบบใช้เวลามากเกินไปเพียงพยายามคิดว่าความต้องการนั้นมีความหมายอย่างไร เหลือเวลาอีกเล็กน้อยสำหรับการออกแบบที่แท้จริง
- นักวิเคราะห์ความต้องการได้ย้ายไปทำงานที่ได้รับมอบหมายอื่น
- ปัจจัยสองข้อข้างต้นส่งผลให้การออกแบบไม่ดี นักออกแบบจะต้องส่งมอบตามระยะเวลาเดิม
ข้อ จำกัด ในการพัฒนา
การเขียนโค้ดนั้นเร่งรีบและมีคุณภาพไม่ดีเนื่องจากการออกแบบซอฟต์แวร์มีข้อบกพร่อง นักพัฒนาจะตระหนักว่าการออกแบบซอฟต์แวร์ที่ไม่ดีจะส่งผลให้เกิดรหัสที่ไม่ดี แต่อย่างไรก็ตามจะต้องส่งมอบตามระยะเวลาที่ตกลงกันไว้ ข้อบกพร่องจำนวนมากจะถูกรายงานระหว่างการรวมกันเพราะการทดสอบหน่วยและการทดสอบการถดถอยไม่ได้ทำงาน
ตามเวลาที่มีการใช้งานซอฟต์แวร์ลูกค้าบันทึกว่าข้อกำหนดได้เปลี่ยนแปลงไปแล้วดังนั้นจึงมีภาพจำลองทางธุรกิจ ซอฟต์แวร์ยังมีปัญหามากมาย อย่างมีประสิทธิภาพความพยายามทั้งหมดของการพัฒนาซอฟต์แวร์ขณะนี้ถือว่าเป็นการสิ้นเปลือง
BT ทำอะไรเพื่อแก้ไขปัญหาข้างต้น
BT ตระหนักว่าการเสริมโมเดลน้ำตกไม่ใช่คำตอบของปัญหา มันต้องการแนวทางใหม่ ดังนั้นจึงตัดสินใจใช้วิธีการแบบเปรียว ภายใต้วิธีการใหม่สิ่งต่าง ๆ ที่ได้รับการตัดสินใจ:
- แทนที่จะเป็นวงจรการพัฒนา 12 เดือนตอนนี้ BT จะส่งมอบซอฟต์แวร์ที่ทำงานได้ในรอบ 90 วัน แนวคิดคือการมุ่งเน้นไปที่ปัญหาทางธุรกิจหนึ่งหรือสองและเป้าหมายเพื่อส่งมอบโซลูชันซอฟต์แวร์ภายใน 90 วัน จุดเริ่มต้นของวัฏจักรนี้ถูกทำเครื่องหมายโดยการสนทนาที่เข้มข้นระหว่างผู้มีส่วนได้ส่วนเสียที่แตกต่างกันเพื่อให้มีการระบุวิเคราะห์และจัดลำดับความสำคัญอย่างชัดเจน
- เป้าหมายคือการมอบคุณค่าทางธุรกิจที่ชัดเจนและเป็นรูปธรรม ลูกค้าภายในอยู่ภายใต้แรงกดดันเพื่อให้มีข้อกำหนดที่ชัดเจน ดังนั้นแทนที่จะเป็นเป้าหมายที่คลุมเครือเรื่องราวของผู้ใช้จะได้รับตามเกณฑ์การยอมรับที่ชัดเจน
- ซอฟต์แวร์ที่จะส่งมอบจะถูกทดสอบและจัดทำเอกสารอย่างสมบูรณ์ ซอฟต์แวร์จะต้องผ่านการทดสอบการรวมบ่อยครั้งเพื่อระบุปัญหาล่วงหน้า
ด้วยวิธี Agile นั้น BT สามารถปรับให้เข้ากับความต้องการที่เปลี่ยนแปลงหรือสถานการณ์ทางธุรกิจได้ง่ายขึ้น ปรับปรุงคุณภาพของรหัสและแก้ไขข้อบกพร่องพื้นฐานในนาทีสุดท้าย
ข้อสรุป
Agile สำหรับข้อดีและ hype รอบ ๆ มันยังอยู่ในช่วงที่ศักยภาพของมันไม่ได้รับการรับรู้อย่างเต็มที่ นี่เป็นเพราะองค์กรจำนวนมากกำลังปรับวิธีการในขอบเขตของการปรับเปลี่ยนหลักการเดิม เป็นผลให้รูปแบบน้ำตกกำลังกลับมาในบางกรณี ในขณะที่การปรับแต่งจะดำเนินต่อไปสิ่งสำคัญคือการรักษาหลักการพื้นฐานของ Agiles หลายองค์กรอ้างว่าเป็น Agile อย่างเต็มที่ แต่พวกเขายังมีวิธีที่จะไปเพื่อที่จะกลายเป็น บริษัท Agile อย่างแท้จริง