การพัฒนาซอฟต์แวร์ Agile: คุณมีปฏิกิริยาอย่างไรด้านการเงินต่อการเปลี่ยนแปลงข้อกำหนดของผู้ใช้

มีสิ่งหนึ่งที่ฉันสงสัยอยู่เสมอเมื่ออ่านเกี่ยวกับสิ่งที่ "การพัฒนาแบบคล่องตัว" ที่นี่ใน SE และไซต์อื่น ๆ :

ในวิศวกรรมซอฟต์แวร์ "ดั้งเดิม" คุณ

1. รวบรวมความต้องการของผู้ใช้
2. เขียนข้อมูลจำเพาะตามข้อกำหนดเหล่านี้
3. มอบให้ลูกค้าและเรียกเก็บเงินจากเขาสำหรับงานที่ทำไปแล้ว
4. ทำการออกแบบทางเทคนิค (หยาบ) เพื่อให้คุณสามารถประเมินค่าใช้จ่ายในการใช้งาน
5. ให้ผู้ใช้เสนอราคาสำหรับการติดตั้ง
6. รอให้ลูกค้าลงนามในข้อกำหนดและยอมรับข้อเสนอ
7. ออกแบบดำเนินการทดสอบ
8. บิล.

หากในระหว่างกระบวนการความต้องการเปลี่ยนแปลงคุณส่งข้อเสนอ (ราคา) สำหรับการเปลี่ยนแปลงที่ต้องการ (หรือทำฟรีหากการเปลี่ยนแปลงมีขนาดเล็กคุณชอบลูกค้าและลูกค้าไม่ได้ทำบ่อยเกินไป) .

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

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

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

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

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

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

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

แต่ถ้าคุณอธิบาย บริษัท ได้ดีพอทุกคนเป็นผู้ชนะ

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

การต่อสู้โดยเฉพาะอย่างยิ่งเหมาะสำหรับบริษัท ซอฟต์แวร์ผลิตภัณฑ์และใช้ใน บริษัท ผู้ให้บริการน้อยกว่า

คุณสามารถใช้ความว่องไวบางอย่างในโครงการของคุณเช่นการทำซ้ำ stand-ups รายวัน burndorn ฯลฯ แต่ฉันรับรองได้ว่าถ้าคุณเสนอสิ่งต่าง ๆ ในราคาและส่งมอบน้อยกว่าที่อยู่ในสัญญา คุณจะมีปัญหา

กรุณาอย่าตอบสนองความว่องไวà toutes les ซอส เราต้องใช้วิธีการแก้ไขที่เหมาะสมกับปัญหาที่กำหนด

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

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

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

สำหรับลูกค้ารายอื่นวิธีการทำงานที่ดีมีดังต่อไปนี้:

• เมื่อลงนามข้อเสนอแรกให้ระบุต้นทุนโดยประมาณและต้นทุนสูงสุด ค่าใช้จ่ายโดยประมาณไม่ได้มีความหมายใด ๆ ตามกฎหมาย: เป็นเพียงการประมาณการ ค่าใช้จ่ายสูงสุดมีมูลค่าตามกฎหมาย: ถ้าคุณบอกว่าผลิตภัณฑ์จะมีค่าใช้จ่าย $ 3,000 ให้กับลูกค้าของคุณและในที่สุดก็มีค่าใช้จ่าย $ 3,157.24 ลูกค้าจะยังคงต้องจ่าย $ 3,000 ในทางปฏิบัติในกรณีส่วนใหญ่ค่าใช้จ่ายจริงจะน้อยกว่าค่าสูงสุดที่กำหนดและใกล้เคียงกับค่าประมาณของคุณ

• เมื่อลูกค้าขอให้เปลี่ยนข้อกำหนดให้ประเมินต้นทุนที่มีและเปรียบเทียบกับค่าใช้จ่ายและรัฐจริง หากคุณใกล้จะเสร็จสิ้นผลิตภัณฑ์และค่าใช้จ่ายจริงคือ $ 2,108.36 และค่าใช้จ่ายในการเปลี่ยนแปลงจะอยู่ที่ประมาณ $ 150 เพียงแค่ดำเนินการ หากในอีกด้านหนึ่งมีความเสี่ยงที่จะถึงระดับสูงสุดให้บอกลูกค้าของคุณว่าคุณต้องประเมินต้นทุนโดยรวมใหม่ด้วยกัน

Agile และ 'เขียนข้อเสนอ' ดูเหมือนเป็นสิ่งที่ตรงกันข้าม :) - อันหลังไม่ใช่วิศวกรรมซอฟต์แวร์ที่มีประสิทธิผล: D

เอาล่ะตอนนี้เรามีเรื่องตลกออกไป - กลับสู่ความเป็นจริง

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

สิ่งนี้หมายความว่า? หมายความว่าสัญญามีการระบุว่าเรา (ลูกค้า) แก้ไขประมาณการเบื้องต้นของต้นทุนและ +/- ความแปรปรวน% ที่เราสามารถจัดการได้เช่นการเสนอราคา $ 100K แต่ฉันยินดีที่จะไปถึง $ 120K (อาจไม่ใช่ ส่วนหนึ่งของสัญญา แต่ในใจของลูกค้า)

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

คุณต้องการกลับไปหาลูกค้าด้วยการเงินหรือไม่? NO ไม่จำเป็น. คุณจะมีลูกค้าจัดลำดับความสำคัญเหล่านี้และใส่ไว้ในตำแหน่งที่ถูกต้องในงานในมือ ตอนนี้คุณรู้ขนาดของงานในมือ (คุณควรทำถ้ายังไม่ได้ทำ) และขึ้นอยู่กับการเงิน (ราคาต่อประเด็น) คุณรู้ว่าข้อกำหนดลำดับความสำคัญต่ำอาจไม่สามารถทำได้กับงบประมาณที่กำหนด แสดง backlog ที่ได้รับการอนุมัติใหม่โดยมีการประเมินคุณสมบัติที่สามารถทำได้ตามสัญญา $$ จากนั้นให้พวกเขาตัดสินใจว่าพวกเขายินดีจ่ายมากขึ้นเพื่อรับมากขึ้นถ้า / เมื่อคุณ / พวกเขาไปถึงที่นั่น หากพวกเขาต้องการมันฟรี ... คุณยืนหยัดและบอกพวกเขาว่ามันจะมีค่าใช้จ่ายมากขึ้น

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

หวังว่านี่จะช่วยได้!

ประสบการณ์ของคนอื่นอาจแตกต่างกันไป แต่วิธีหนึ่งที่ฉันเห็นมันทำส่วนใหญ่เหมือนกับ "ดั้งเดิม" ของคุณที่มีสิ่งต่าง ๆ ให้สังเกต:

1. สร้างในบางค่าใช้จ่ายสำหรับการเปลี่ยนแปลง (ตัวอย่างเช่น 10%)
2. ประเมินและเรียกเก็บเงินแยกต่างหากสำหรับการเปลี่ยนแปลงขนาดใหญ่หรือการรวมและการเปลี่ยนแปลงการเรียกเก็บเงินเกินกว่าค่าใช้จ่ายในตัว (ที่ดีแม้ว่าจะไม่ใช่การเขียนโปรแกรมตัวอย่างคืองานออกแบบซึ่งมักจะมีค่าใช้จ่ายเริ่มต้น เสริม)

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

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