การตัดสินใจเลือกวันวางจำหน่ายก่อนรวบรวมความต้องการทั้งหมดไม่คล่องตัวหรือไม่?


10

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

คำตอบ:


19

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

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


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

1
@DavidArno ฉันขอยืนยันว่า "คุณภาพ" เป็นส่วนหนึ่งของคำจำกัดความของเสร็จซึ่งเป็นส่วนหนึ่งของทุกความต้องการ และ "ทรัพยากร" อย่างแน่นอนสามารถมีผลกระทบอย่างมีนัยสำคัญในการส่งมอบถ้าคุณใช้ทรัพยากรออกไปจากโครงการ
Philip Kendall

1
@ChristianHackl: ฉันคิดว่าไม่ว่าวิธีการพัฒนาซอฟต์แวร์ต้องใช้เวลาและเงินจำนวนมากถ้าคุณต้องการคุณภาพ
Bryan Oakley

2
@BryanOakley: นั่นเป็นเรื่องจริง ฉันแค่หวังว่าผู้สอนศาสนาที่คล่องแคล่วจะตระหนักว่าวิธีการของพวกเขานั้นไม่พิเศษในเรื่องนี้ เมื่อคุณทิ้งสมมติฐานที่ผิดพลาดไว้ว่าว่องไวให้คุณมีเค้กและกินมันคุณสามารถออกแบบกระบวนการพัฒนาที่ถูกต้องสำหรับโครงการของคุณโดยเลือกว่าควรมี "ความคล่องตัว" เท่าใด
Christian Hackl

1
@ChristianHackl ไม่มีวิธีการใดที่เป็น bullet เงิน แต่ประเด็นหลักของ "ว่องไว" (คำกว้าง) ไม่ใช่ว่ามันจะทำให้การส่งมอบที่ประสบความสำเร็จถูกลง / เร็วขึ้น แต่มันทำให้ต้นทุนของความล้มเหลว (หลีกเลี่ยงไม่ได้) ลดลง
Guran

3

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

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

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

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


คุณสัญญากับคนจริงๆเหรอ? หากคุณผิดและวิธีการอื่นจะตรงตามกำหนดเวลาด้วยมื้ออาหารที่ดียิ่งขึ้น?
Christian Hackl

1
ข้อโต้แย้งที่คล้ายคลึงกันเกี่ยวกับ Agile และกำหนดส่งที่นี่
Eric King

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

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

@Daniel: อืมฉันแค่คัดค้านความคิดที่ว่าผลลัพธ์ที่ดีเยี่ยมสำหรับลูกค้าเพียงเพราะคุณเชื่อว่าคุณใช้วิธีการที่ดีที่สุด นั่นไม่ใช่ความจริง
Christian Hackl

2

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


2

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

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

ตอนนี้เจ้านายของคุณอาจไม่ชัดเจนว่าคุณควรวางแผนวันวางจำหน่ายครั้งที่สองด้วยคุณสมบัติเพิ่มเติมที่ใช้งานจริง

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