This approach carries less risk tha

This approach carries less risk than a traditional Waterfall approach but is still far more risky and less efficient than a more Agile approaches. The focus is on delivering a sprint of work as opposed to a series of valuable/shippable features. The most commonly occurring issue in this type of scenario (in my experience) is bottle necking. For example, you deliver loads of code a little bit behind schedule (?) and you leave it until the last minute to test everything. One issue takes longer than expected to resolve, you miss your sprint deadline and you deliver nothing. Another common symptom of this type of approach is over-commitment. It’s really difficult to estimate the total effort associated with a particular User Story/Feature when approaching delivery in this phased way. You’re more or less forced to estimate each phase separately (e.g. estimate development separately to testing in this instance) – this doesn’t work as the phases are not separate, they’re totally intertwined. For example, if you find an issue with the test, you must return to development. The whole team must remain focused on delivering the end goal, not the separate phases. It’s also worth noting that velocity and burn downs are far less (if at all) useful in this type of environment – you don’t benefit from early-warning-signs as you don’t find out whether you’re on track until the end of the sprint.

ผลลัพธ์ (ไทย) 1:

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

ผลลัพธ์ (ไทย) 2:

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

ผลลัพธ์ (ไทย) 3:

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