ขอบเขตคงที่ + กำหนดเวลาตายตัว + สัญญาราคาคงที่ที่เคยทำเพื่อทำงานกับ“ เปรียว” หรือไม่?


32

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


17
ขอบเขตคงที่ + กำหนดเวลาตายตัว + สัญญาราคาคงที่ที่เคยทำงาน
Carson63000

4
นี่ไม่ใช่วิธีการใช้ถ้อยคำใหม่: "เร็วดีหรือถูกเลือกสอง"
Matthieu M.

3
ไม่ได้แก้ไข antonym ของเปรียวหรือไม่
แมตต์เอลเลน

คำตอบ:


10

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

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


71

ฉันต้องการถามคำถามแบบตอบโต้:

สามารถคงขอบเขต + เส้นตายคง + การแก้ไขสัญญาราคาเคยได้รับการสร้างขึ้นมาเพื่อการทำงานระยะเวลา ?

คำว่า "ดี / เร็ว / ถูก - เลือกสอง" ไม่ได้เป็นเพียงเรื่องตลกทางวิศวกรรมที่ไร้สาระ ผู้จัดการโครงการทุกคนที่มีค่าควรรู้เกี่ยวกับสามเหลี่ยมการบริหารโครงการ :

สามเหลี่ยมการบริหารโครงการ

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

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

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

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

  • สลิปกำหนดการ ปัญหาที่คาดเดาไม่ได้เกิดขึ้น องค์ประกอบการสร้างแผนภูมิที่คุณใช้มา 5 ปีติดต่อกันไม่สามารถใช้งานได้กับ Windows 95 ซึ่งลูกค้าของคุณยังคงใช้งานอยู่ จุดบกพร่องที่คลุมเครือใน Windows 64 บิตทำให้เกิดข้อบกพร่องของ UI อย่างรุนแรงและคุณใช้เวลาเกือบหนึ่งสัปดาห์ในการติดตามและพัฒนาวิธีแก้ปัญหา (นี่เกิดขึ้นกับฉันจริงๆ) นักพัฒนาอาวุโสของคุณโดนรถบัสและคุณต้องไปรับสมัครและฝึกอบรมคนใหม่ วันที่จัดส่งโดยประมาณของคุณผิดเสมอ เสมอ.

    ดูกฎหมายของ Hofstadter :

    กฎของ Hofstadter: มันใช้เวลานานกว่าที่คุณคาดไว้เสมอถึงแม้คุณจะคำนึงถึงกฎหมายของ Hofstadter

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

นี้จะทำให้รู้สึกไม่กับโครงการที่เป็น (หรือเรียกร้องจะ) ทั้งขอบเขตคงที่หรือเวลาที่คงที่

หากมีการแก้ไขแอตทริบิวต์โครงการหนึ่งรายการ (ราคา / ขอบเขต / ตารางเวลา) ฉันจะบอกคุณว่าอาจไม่เหมาะกับวิธีการแบบเปรียว

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

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

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


4
+1 สำหรับกฎหมาย Hofstadters ฉันจะเสนอราคาในเซสชั่นการประเมินต่อไป
Chris Buckett

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

2
ฉันสงสัยว่าเป็นวิธีการจัดการที่ได้ทำงานกับลูกค้า
Chris Buckett

3
โครงการกำหนดเวลา / ขอบเขต / ราคาคงที่สามารถทำงานได้ (ฉันได้ทำไปแล้ว) พวกเขาต้องการเพียงความต้องการที่มั่นคงจริง ๆ การประเมินที่ดีมากและเมื่อคุณพูดว่าสิ่งเหล่านี้ยากมากในความเป็นจริง +1 สำหรับคำอธิบายที่ชัดเจนว่า Agile นั้นขัดแย้งกับกลไกราคาคงที่อย่างไรแม้ว่าจะเป็นเรื่องเกี่ยวกับ (smart) การแลกเปลี่ยนและอื่น ๆ ก็ขัดขวางความเป็นไปได้ที่จะซื้อขายอะไรก็ตาม
Jon Hopkins

3
เพียงจำนวน upvote ของคำตอบนี้แสดงจำนวนของ toiling ใน Agile + ระเบียบราคาคงที่
ผู้ถือแหวน

18

ฉันรักคำพูดนี้:

“ การแย่งชิงนั้นยอดเยี่ยมสำหรับขอบเขตของตัวแปรวันที่คงที่หรือ“ ขอบเขตคงที่” (ซึ่งเติบโตตลอดเวลา) ตัวแปรวันที่ หากคุณกำลังทำขอบเขตคงที่ฉันขอแนะนำ Waterfall หรือ RUP ซึ่งจะซื้อหาคุณสองสามเดือนเพื่อหางานใหม่” ~ Michael James


6

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

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

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


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

0

ราคาคงที่ / กำหนดเวลาตายตัว / ขอบเขตคงที่สามารถทำได้อย่างน้อยก็คล่องแคล่วเช่นเดียวกับในน้ำตก

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

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

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


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

0

ฉันเห็นด้วยกับบรูซในระดับหนึ่ง แม้ว่าฉันจะไม่คุ้นเคยกับน้ำตกหรือโฟโต้มากนักและก็ไม่สามารถออกความเห็นได้

สิ่งที่ฉันอ่านเมื่อเร็ว ๆ นี้และฉันคิดว่าพูดได้ดีจริงๆคือแม้ใน Agile เราก็ละเลยการวางแผน เซสชั่นการวางแผนอย่างละเอียดเมื่อทำซ้ำดีมาก - ไม่จำเป็น - แต่เพื่อวางแผนตลอดการทำซ้ำ

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

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


2
หากคุณกำลังวางแผนอย่างต่อเนื่อง Scrum นั้นไม่เหมาะสำหรับคุณ Kanban อาจเหมาะกว่าที่จะลอง แต่สิ่งที่คุณพูดเกี่ยวกับ Agile เป็นเกี่ยวกับเป็นจุด
gbjbaanb
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.