การพัฒนาซอฟต์แวร์ Agile สามารถนำไปใช้ในโครงการที่กำหนดโดยสัญญาได้หรือไม่?


14

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

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

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

การพัฒนาซอฟต์แวร์ Agile เป็นกระบวนการที่มีความคล่องตัวมากกว่าผลิตภัณฑ์ที่มีความคล่องตัวหรือไม่?


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

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

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

@Verax: รายการ agile ถูกสร้างขึ้นเพื่อจัดการการเปลี่ยนแปลง หากโครงการของคุณไม่มีการเปลี่ยนแปลงแสดงว่าคุณไม่คล่องตัว ตอนจบของเรื่อง.
Martin Wickman

2
@Verax: คุณควรชี้แจงคำถามของคุณและเพิ่มบริบทเพิ่มเติม ความคิดเห็นของคุณแสดงให้เห็นว่ามีคำถามเพิ่มเติม นี่ก็เห็นได้อย่างชัดเจนจากการนับคะแนนในคำตอบและคำตอบที่ยอมรับนั้นไม่เกี่ยวข้องกับข้อความคำถามจริง (และแม้แต่พูดว่า "จากความคิดเห็น OPs ... ")
Martin Wickman

คำตอบ:


7

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

Agile เข้ากันไม่ได้กับการพัฒนาซอฟต์แวร์ที่กำหนดโดยสัญญา

  • สัญญาต้องยากคุณจ่าย X เราทำ Y. คุณต้องการ X + M คุณจ่ายให้เรา Y + (M * N)
  • สัญญาจะต้องเป็นที่น่าพอใจ (IE ยังไม่ได้เปิดให้บริการ) ไม่เช่นนั้นจะไม่ติดต่อทางกฎหมาย (เมื่อผู้ติดต่อมีส่วนเกี่ยวข้องคุณต้องดำเนินการผ่านกระบวนการควบคุมการเปลี่ยนแปลงที่เข้มงวด)

ร้านให้คำปรึกษาหลายแห่งเรียกร้องให้ Agile พวกเขากำลังโกหก พวกเขาบอกว่าเพราะ Agile บรรลุสถานะคำพูดของ Buzz แล้ว

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


ขณะที่ฉันเรียนรู้เพิ่มเติมเกี่ยวกับเรื่องนี้ฉันก็มาถึงข้อสรุปเดียวกัน ประโยคสุดท้ายของคุณดูเหมือนจะถูกต้องอย่างแน่นอน ฉันเคยทำงานให้กับรัฐบาลและลูกค้าของฉันคือหน่วยงานที่ฉันทำงานให้และโปรแกรมต้องได้รับการดูแลเป็นเวลาหลายปีและนานเท่าที่มีพนักงานใช้งานอยู่ ฉันเห็นการทำงานที่คล่องตัวที่นั่น ตอนนี้ฉันพัฒนาระบบฝังตัว โครงการจะสิ้นสุดลงเมื่อเครื่องทำงาน (ทั้งหมดหรือไม่มีอะไร) หากเครื่องทำงานได้บางส่วนจะไม่สามารถขายได้ - โครงการล้มเหลว
Verax

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

2
ฉันไม่เห็นด้วยกับคำตอบนี้ เหตุผลก็คือหากคุณมีสัญญาที่ไม่ได้เป็นแบบปลายเปิดหมายความว่าคุณไม่ต้องการจัดการขอบเขตการคืบ (ซึ่งมักจะเกิดขึ้น) สัญญาที่ฉันเคยเห็นเริ่มต้นด้วย: คุณจ่าย X เราทำ Y พวกเขามีประโยคที่ระบุว่าการเปลี่ยนแปลงขอบเขตใด ๆ มาพร้อมกับราคาพิเศษ ตราบใดที่คุณยังเร็วเกี่ยวกับการคืบขอบเขต notifyng (ซึ่งต้องใช้ทรัพยากรและเวลาเพิ่มเติม) จากนั้นลูกค้าก่อนหน้านี้สามารถตอบสนองต่อการเปลี่ยนแปลง (ได้รับการอนุมัติและงบประมาณจากผู้บริหารระดับสูง ฯลฯ ) จากนั้นกระบวนการจัดการเองก็คล่องตัว
Spoike

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

2
มีสัญญาที่ว่องไวดังนั้นคำตอบนี้ชัดเจนโดยคำจำกัดความ
Martin Wickman

20

หากคุณกำลังมุ่งเน้นไปที่การทำสิ่งที่สำคัญที่สุดก่อนโครงการจะสิ้นสุดเมื่อ:

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

5
1. ไม่มีเงินมากขึ้น - ลูกค้าใช้เงินทั้งหมดไปกับผลิตภัณฑ์ที่ไร้ประโยชน์ 2. ไม่มีเวลาอีกต่อไป - ลูกค้ายังคงมีผลิตภัณฑ์ที่ไร้ประโยชน์ไม่สมบูรณ์ 3. ไม่มีอะไรให้เพิ่ม - ใช่เลย! 4. ไม่คุ้มค่า - ลูกค้าเพิ่งเลิกโครงการ --- สิ่งที่ฉันหายไป? มันไม่สมเหตุสมผลสำหรับฉัน
Verax

7
สำหรับ 1 และ 2: หากคุณทำสิ่งที่สำคัญที่สุดก่อนจากนั้นเมื่อคุณไม่มีเงินคุณจะได้สิ่งที่สำคัญที่สุดที่คุณจะได้รับจากเงิน คล้ายกันกับเวลา ฉันยอมรับว่า 3 หายาก สำหรับ 4: การหยุดไม่ได้หมายความว่าลูกค้าจะยอมแพ้ อาจหมายความว่าพวกเขามีสิ่งที่สำคัญที่สุดที่พวกเขาต้องการจากนี้และตอนนี้อยากจะทำสิ่งอื่น ๆ ด้วยเงินของพวกเขา คุณตัดสินใจได้อย่างไรว่าจะสิ้นสุดโครงการอื่นเมื่อใด ไม่ว่าคุณจะใช้เกณฑ์ใดในขณะนี้ก็ยังมีอยู่ในโครงการที่คล่องตัว
Dale Emery

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

5
@ Verax: ไม่มีสิ่งใดเป็นผลิตภัณฑ์ที่ต้องใช้ "all or nothing" มีคุณสมบัติที่มักจะเป็น "ดีที่มี" และข้อบกพร่องที่เป็นเครื่องสำอางมากกว่าการใช้งาน โครงการต้นทุนคงที่ประสบความสำเร็จหากโครงการเหล่านั้นเหลืออยู่เมื่อเงินหมด วิธีการแบบเปรียวพยายามที่จะเพิ่มโอกาสในการที่
Michael Borgwardt

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

14

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

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


5

ไม่เคยและนั่นคือความงามของมัน

โครงการไม่เคยเสร็จ คุณมาถึงรีลีสอื่นเป็นอีกก้าวสำคัญ แต่ตราบใดที่เงินไหลออกมามีอีกหนึ่งฟีเจอร์ที่จะเพิ่มอีกหนึ่งส่วนที่จะทำให้ดีขึ้นอีกหนึ่งบั๊กที่ต้องแก้ไข โครงการจะตายเมื่อไม่ต้องการอีกต่อไป แต่จะไม่เสร็จ ตรงข้ามกับรุ่น Waterfall ที่มีความต้องการ -> project-> product-> end นี่คือลูปที่สามารถหมุนได้ตลอดไปตราบใดที่คุณได้รับเงิน

ไม่ใช่คุณลักษณะทางธุรกิจที่กล่าวถึงบ่อยครั้งของเทคโนโลยีนี้ใช่ไหม


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

4

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

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

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

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

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


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

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

2
เกิดอะไรขึ้นถ้าลูกค้าทำสัญญาบ้าน แต่เงินหมดก่อนที่หลังคาจะวาง? ค่ายว่องไวจะยังคงเรียกว่าความสำเร็จ ไม่มีใครอื่นจะ; โดยเฉพาะลูกค้า
Dunk

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

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

1

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

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

ราคาคงที่ส่วนที่ 1 มีอะไรเลวร้ายมาก

ราคาคงที่ส่วนที่ 2 แก้ไขได้ด้วยความคล่องตัว!


เป็นการยากที่จะทราบว่าเมื่อแก้ไขข้อบกพร่องทั้งหมดแล้ว
Martin Wickman

อาจจะ "เมื่อข้อบกพร่องที่รู้จักทั้งหมดที่มีค่าการแก้ไขได้รับการแก้ไข"?
Dan Ray

@ CharithJ ลิงก์ของคุณเสีย พวกเขายังคงมีอยู่ที่ไหน? ขอบคุณ
TwainJ

1

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

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


1
ผู้เสนอเปรียวสร้างข้อสันนิษฐานผิด ๆ ว่าในโลกของน้ำตกนักพัฒนาหายไปหลังจากเซ็นสัญญาและไม่เคยได้ยินอีกเลยจนกว่าผลิตภัณฑ์จะปรากฏออกมานอกประตู วิธีการทำงานในชีวิตจริงคือมีจำนวนจุดตรวจและจำนวนมากที่ลูกค้าสามารถมีส่วนร่วมได้มากเท่าที่พวกเขาต้องการ หากพวกเขาไม่ชอบทิศทางหรือการตัดสินใจพวกเขาสามารถร้องขอการเปลี่ยนแปลง เมื่อถึงเวลาส่งมอบผลิตภัณฑ์ควรเป็นสิ่งที่ลูกค้าต้องการเท่าที่ลูกค้าเลือกที่จะมีส่วนร่วม Agile ไม่ได้ปรับปรุงสิ่งนี้สำหรับหลาย ๆ โครงการ
Dunk
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.