คำถามติดแท็ก estimation

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

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

5
คุณจะแบ่งเงินบริจาคระหว่างสมาชิกโอเพ่นซอร์สของคุณโดยพื้นฐานอย่างไร [ปิด]
ฉันเป็นผู้พัฒนาโครงการโอเพนซอร์ซซึ่งโฮสต์ใน SourceForge มันเริ่มต้นจากแอพเล็ก ๆ น้อย ๆ หลังจากที่มีการวางจำหน่ายบางอย่างมันก็ได้รับความนิยมเพิ่มมากขึ้นและมันเริ่มใช้เวลาและความรับผิดชอบมากขึ้นจากฉัน ดังนั้นฉันได้เปิดใช้งานตัวเลือกการบริจาคใน SourceForge ฉันมีความกระตือรือร้นที่จะพัฒนามันต่อไปฟรี แต่ถ้ามีเงินเข้ามาฉันจะแบ่งมันกับทีมของฉันได้อย่างไร ฉันควรแบ่งจำนวนเท่า ๆ กันระหว่างจำนวนสมาชิกในทีมหรือไม่ (50-50 เนื่องจากเป็นทีมที่สองสมาชิกแล้ว) จำนวนคลาสกระทำหรือการส่งอื่น ๆ ที่มีค่าโดยสมาชิกในทีม? ความคิดอื่น ๆ ? คุณจะทำอย่างไรในสถานการณ์เช่นนี้? กรุณาให้ความคิดเห็นของคุณ ฉันหวังว่าคำถามนี้จะเป็นประโยชน์สำหรับผู้อื่น

11
จะทำอย่างไรเมื่อการประมาณเวลาผิดพลาด
สมมติว่าคุณประเมินเวลาสำหรับกรณีเป็น 3 วัน ในวันที่สองคุณสังเกตเห็นว่าคดีนี้กำลังเติบโตและสถานการณ์ใหม่กำลังโผล่ขึ้นมาซึ่งไม่ได้ถูกนับเมื่อการประมาณเวลาเสร็จสิ้น การค้นพบใหม่นำไปสู่การเพิ่มอีก 2 วัน (รวม 5 วัน) นี่เป็นปัญหาทั่วไปที่คุณจะต้องเผชิญไม่ช้าก็เร็วในฐานะนักพัฒนาซอฟต์แวร์ กลยุทธ์ใดที่สามารถใช้เมื่อคุณจะแจ้งหัวหน้าโครงการถึงเวลาใหม่ในการจัดส่ง บ่อยครั้งที่คุณได้รับคำถามว่าทำไม คุณกระตุ้นเวลาการส่งมอบใหม่อย่างไร ความจริงก็คือโครงการจำนวนมากไม่ต้องใช้เวลามากในการวิเคราะห์และออกแบบในระหว่าง SDLC แก้ไข: ในโครงการที่ซับซ้อนมากไม่ว่าคุณจะใช้เวลาในการวิเคราะห์และออกแบบมานานเท่าไหร่ก็มีความประหลาดใจอยู่เสมอเนื่องจากกฎเกณฑ์ทางธุรกิจนั้นซับซ้อนเกินไป อย่างไรก็ตามในกรณีเช่นนี้ฉันเชื่อว่าหัวหน้าโครงการจะต้องตระหนักถึงความซับซ้อนและมีทัศนคติที่ถูกต้องเมื่อมีเรื่องประหลาดใจที่ไม่คาดคิดเกิดขึ้น คำถามคือวิธีจัดการกับผู้นำโครงการที่ไม่เข้าใจความซับซ้อน

10
วิธีเพิ่มนักพัฒนาใหม่ให้กับทีม
ฉันเป็น บริษัท เล็ก ๆ ที่ประกอบไปด้วยนักพัฒนาเพียง 2 คน เรากำลังสร้างแอปพลิเคชันขนาดใหญ่มากสำหรับลูกค้าของเรา การพัฒนาในโครงการนี้ดำเนินต่อไปเป็นเวลา 1.5 ปี ตอนนี้ลูกค้ารายนี้มีหลักประกันสปอนเซอร์ที่สำคัญและพวกเขากำลังจัดกิจกรรมที่เกี่ยวข้องกับโครงการนี้ ดังนั้นตอนนี้เรามีกำหนดส่งภายใน 2 เดือนและเราไม่ควรพลาด เรากำลังคิดที่จะเพิ่มนักพัฒนาใหม่ให้กับทีมและฉันสงสัยว่าเราสามารถทำอะไรได้บ้างเพื่อช่วยให้เขาทำงานร่วมกัน นี่คือสถานการณ์: เรากำลังเข้าใกล้เกณฑ์ของกฎหมายของ Brooks - จุดที่เพิ่มนักพัฒนาใหม่จะเป็นการต่อต้าน แอปพลิเคชันค่อนข้างออกแบบมาอย่างดี แต่การใช้งานนั้นไม่เป็นระเบียบในบางจุด (โดยเฉพาะโค้ดที่เก่ากว่า) มีการทดสอบหน่วยสำหรับรหัสล่าสุดเท่านั้น เมื่อโครงการนี้เริ่มต้นเราไม่ได้ทำการทดสอบเป็นประจำ เอกสารและความคิดเห็นไม่สมบูรณ์ แอปพลิเคชั่นมีทั้งขนาดใหญ่และซับซ้อน ลูกค้าเขียนรายละเอียดเกี่ยวกับโครงการของเขาเกือบทุกอย่างอย่างชัดเจนและ "เป็นมิตรกับโปรแกรมเมอร์" เป็นความคิดที่ดีที่จะเพิ่มคนตอนนี้หรือไม่? ถ้าเป็นเช่นนั้นเราจะทำอะไรได้บ้างเพื่อช่วยให้นักพัฒนาใหม่รวมเข้ากับทีม? แก้ไข: สปอนเซอร์กำลังจัดการแข่งขันกีฬาทางอินเทอร์เน็ตสำหรับฤดูใบไม้ผลิหน้า มันจะต้องเริ่มในวันที่เฉพาะเจาะจงของปี เราไม่สามารถเปลี่ยนได้ สิ่งที่นักพัฒนาของเรา (ฉันเป็นหนึ่งในสองคน) ต้องทำคือ: กรอกใบสมัครที่มีอยู่ให้เสร็จ (ประมาณ 25% ของงานที่ต้องทำ) การสร้างโมดูลใหม่ที่จำเป็นสำหรับองค์กรของเหตุการณ์นี้ (ประมาณ 75% ของงานที่ต้องทำ) โมดูลใหม่นี้ไม่สามารถพัฒนาโดยไม่เข้าใจ API ของโปรแกรมหลัก …

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

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

9
คุณคิดอย่างไรกับ“ การวางแผนโป๊กเกอร์”? [ปิด]
ตามที่เป็นอยู่ในปัจจุบันคำถามนี้ไม่เหมาะสำหรับรูปแบบคำถาม & คำตอบของเรา เราคาดหวังคำตอบที่จะได้รับการสนับสนุนจากข้อเท็จจริงการอ้างอิงหรือความเชี่ยวชาญ แต่คำถามนี้อาจเรียกร้องให้มีการถกเถียงอภิปรายโต้แย้งหรือการอภิปรายเพิ่มเติม หากคุณรู้สึกว่าคำถามนี้สามารถปรับปรุงและเปิดใหม่ได้โปรดไปที่ศูนย์ช่วยเหลือเพื่อขอคำแนะนำ ปิดให้บริการใน7 ปีที่ผ่านมา วางแผนโป๊กเกอร์ สรุปในกรณีที่คุณไม่ต้องการอ่านบทความ wiki: รับรายการงานที่คุณต้องการทำสำหรับการทำซ้ำที่จะเกิดขึ้น สำหรับแต่ละงาน: 2.1 พูดคุยกับกลุ่มสิ่งที่เกี่ยวข้อง 2.2 ทุกคนเขียน / เลือกการประเมินว่าจำเป็นต้องใช้ความพยายามมากแค่ไหนสำหรับงาน 2.3 ทุกคนเปิดเผยการประมาณ 2.4 ค่าสูงสุดและค่าต่ำสุดอธิบายการใช้เหตุผล 2.5 ทำซ้ำจนกว่าจะถึงฉันทามติ โดยทั่วไปแล้วสิ่งที่คล้ายกับตัวเลขจากลำดับฟีโบนักชีเช่น 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 เป็นค่าที่อนุญาตดังนั้นคุณจึงไม่ได้รับข้อโต้แย้งที่ยาวนานกว่าค่าปิดเช่น 23 vs 27 นอกจากนี้ตัวเลขยังแสดงถึงค่าความพยายามน้อยกว่าหน่วยซึ่งค่าจะถูกกำหนดโดยงานพื้นฐานที่ทุกคนเห็นด้วยเท่ากับ 1 และทุกสิ่งทุกอย่างสัมพันธ์กับสิ่งนั้น ในท้ายที่สุดเป้าหมายคือการได้รับความรู้สึกที่ดีสำหรับ "ความเร็ว" ของทีมที่กำหนดซึ่งเป็นจำนวนคะแนนเหล่านี้ที่สามารถทำให้เสร็จในการวนซ้ำที่กำหนด ด้วยสิ่งนี้จึงเป็นไปได้ที่จะทำการประมาณการอย่างแม่นยำอย่างสมเหตุสมผลว่าจะใช้คุณลักษณะใดนานเท่าใด เราทำสิ่งนี้ในการวางแผนการประชุมซ้ำที่ บริษัท …

12
มันมีค่าใช้จ่ายมากในการแก้ไขจุดบกพร่องในตอนท้ายของโครงการหรือไม่?
ในการโพสต์บล็อกโดย Andrew Hayความจริงดังต่อไปนี้ถูกโพสต์ : มีค่าใช้จ่ายมากขึ้นในการแก้ไขข้อบกพร่องในตอนท้ายของโครงการที่ทำเพื่อแก้ไขข้อผิดพลาดเดียวกันก่อนหน้านี้ในโครงการ อย่างไรก็ตามสิ่งนี้ดูเหมือนจะไม่แน่นอนโดยเฉพาะหลังจากอ่านโพสต์บล็อกบน Less Wrong ที่ไม่ถูกต้องและข้อมูลที่ฉันเห็นเพื่อสำรองนั้นเก่ามาก วันนี้ยังคงเป็นความจริงที่ถูกต้องหรือไม่

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

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

4
วิธีกำหนดจำนวนโปรแกรมเมอร์ที่จำเป็นสำหรับโครงการ
คุณจะรู้ได้อย่างไรว่าโปรแกรมเมอร์แต่ละคนต้องการโครงการที่ประสบความสำเร็จมากแค่ไหน? บริษัท ที่ฉันทำงานเพื่อตอบสนองคำสั่งซื้อสำหรับ บริษัท ลูกค้า เราได้เขียนระบบการจัดการคลังสินค้าภายในที่จัดการการจัดการสินค้าคงคลังตามสถานที่ตั้งการประมวลผลคำสั่งการสร้างใบแจ้งหนี้การออกใบแจ้งหนี้การตรวจสอบการขนส่งสินค้าและการรายงาน (อาจมีรายงาน 50 ฉบับ) นอกจากนี้ยังมีฟังก์ชั่นการสแกนบาร์โค้ดและพอร์ทัลไคลเอ็นต์พร้อมกับคุณสมบัติอื่น ๆ อีกมากมาย นอกจากนี้ยังมีไทม์ล็อคของพนักงานเต็ม มันทำงานร่วมกับ Quickbooks, UPS และ FedEx มันทำงานกับลูกค้าอย่างน้อย 50 รายซึ่งแตกต่างกันเล็กน้อยในการทำงานของพวกเขา ตัวอย่างเช่นเรานำเข้าคำสั่งซื้อจากไฟล์ที่ลูกค้าส่ง แต่ลูกค้าแต่ละรายส่งรูปแบบไฟล์ที่แตกต่างกัน (csv, excel, ไฟล์แฟลตและบริการเว็บ) ดังนั้นเราจึงมีวิธีการแปลงชุดคำสั่งซื้อเป็นโหล การส่งออกเป็นเรื่องเดียวกัน โครงการมีความซับซ้อนและเพิ่มความซับซ้อนทุกวันด้วยรหัสมากกว่าหนึ่งล้านบรรทัด มันคือรหัส VB.NET ประมาณ 250,000 บรรทัด, รหัส Ruby 6,200 สายและบางที 5,000 บรรทัดของ PHP นอกจากนี้ยังมีฐานข้อมูล MySQL ที่มีประมาณ 200 ตาราง เนื่องจากความต้องการที่เปลี่ยนแปลงตลอดเวลาและความต้องการที่แตกต่างกันของลูกค้าหลายสิบคนรหัสจึงแตกต่างกันอย่างมากในด้านคุณภาพจากรหัสที่แย่มากไปจนถึงค่อนข้างดี ปัจจุบันโครงการนี้มีโปรแกรมเมอร์เพียงคนเดียวเท่านั้นเอง ขณะนี้ฉันยังให้การสนับสนุนผลิตภัณฑ์ทั้งหมดสำหรับ บริษัท …

9
ควรรวมเวลาของผู้ทดสอบเมื่อประเมินตั๋วหรือไม่
เมื่อสร้างการประมาณเวลาสำหรับตั๋วควรรวมเวลาที่ใช้สำหรับผู้ทดสอบ (QAs) ไว้ในการประมาณตั๋วหรือไม่ ก่อนหน้านี้เราได้ประเมินไว้เสมอโดยไม่มีเวลาทดสอบ แต่เรากำลังพูดถึงรวมถึงมันเสมอ มันสมเหตุสมผลแล้วสำหรับการวิ่งในปัจจุบันของเราล่าสุดก่อนการเปิดตัวเนื่องจากเราจำเป็นต้องรู้ว่าเวลาทั้งหมดจะใช้เวลาหนึ่งสัปดาห์ ฉันเข้าใจเสมอว่าการประเมินนั้นใช้สำหรับนักพัฒนาเท่านั้นเพราะมันมีแนวโน้มว่าจะเป็นทรัพยากรที่ จำกัด ในทีม เพื่อนร่วมงานคนหนึ่งบอกว่าไม่ว่าพวกเขาจะทำงานที่ไหนมาก่อนเวลาทดสอบ เพื่อความชัดเจนนี่เป็นกระบวนการที่นักพัฒนากำลังเขียนหน่วยการรวมและการทดสอบ UI ที่มีความครอบคลุมที่ดี
17 agile  scrum  estimation  qa 

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

7
ทีมกำลังประเมินแต้มเรื่องราวธุรกิจต้องการเวลาที่แท้จริง
ฉันแน่ใจว่านี่ไม่ใช่เรื่องแปลก เรามีทีมการต่อสู้สองทีมที่ทำงานได้ดีในการประเมินเรื่องราวของผู้ใช้โดยใช้จุดเรื่องราว (กลุ่มดาวในทีมปัจจุบันมีอายุประมาณ 8 เดือนเท่านั้นแม้ว่าสมาชิกในทีมจะมีประสบการณ์การต่อสู้หลายปี) แต่มันยากสำหรับส่วนธุรกิจของ บริษัท ที่เกี่ยวข้องกับเรื่องราวของผู้ใช้ พวกเขาต้องการหน่วยเวลาจริง (หรือ "สูตรในการแปลงคะแนนเรื่องราวเป็นชั่วโมง") เพื่อให้พวกเขาสามารถวางแผนได้ว่าเมื่อใดที่สิ่งต่างๆจะพร้อม ( "เราจำเป็นต้องรู้เมื่อเราสามารถบอกลูกค้าได้ว่า Feature X จะอยู่ในการผลิต " ) ฉันและผู้นำการต่อสู้ของฉันได้อธิบายว่า "ไม่มีความสัมพันธ์ที่ชัดเจนระหว่างจุดเรื่องราวและเวลาที่เกิดขึ้นจริง" และ "จุดเรื่องราวใช้เพื่อกำหนดจำนวนทีมที่สามารถวิ่งได้" และฉัน คุณสามารถเดาได้ว่าพวกเขาพึงพอใจแค่ไหนกับคำตอบนั้น พวกเขายังต้องการทราบตามเวลาในปฏิทินเมื่อเราจะไปที่เรื่องราวผู้ใช้ครั้งที่ 27 ใน Backlog ไม่ว่าในกรณีใดฉันได้รวบรวมสถิติบางส่วนและการประเมิน SP ของเราแปลเป็นผลลัพธ์ที่ใช้เวลาจริงที่แตกต่างกันอย่างดุเดือด (วัดโดยซอฟต์แวร์ scrum board ของเราซึ่งติดตามจำนวนตั๋วที่ใช้ในคอลัมน์ "กำลังทำงาน" ) สำหรับเรื่องราวของผู้ใช้ 1-SP นั้นแน่นอนว่ามีอคติอย่างหนักในช่วงเวลาสั้น ๆ (โดยมีการระเบิดขึ้นเป็นครั้งคราว) แต่โดยเฉพาะอย่างยิ่งสำหรับเรื่องราว 2-SP พวกเขาอยู่ทั่วทุกที่: มีปัจจัย 20 ระหว่างความสำเร็จ "เร็วที่สุด" …
15 scrum  estimation 

5
ประสิทธิภาพค่าใช้จ่ายสัมพัทธ์ของการทดสอบขับเคลื่อน (ยอมรับ)
ฉันต้องการทราบว่าผลกระทบโดยรวมของการวางแผนทรัพยากรในโครงการซอฟต์แวร์คืออะไรซึ่งความต้องการและการออกแบบของโครงการนั้นเกิดจากการทดสอบการยอมรับอัตโนมัติและการทดสอบหน่วยในทางตรงกันข้ามกับแนวทางการพัฒนาซอฟต์แวร์แบบดั้งเดิม จากประสบการณ์ของคุณผลกระทบโดยรวมต่อความต้องการทรัพยากรสำหรับการทำโครงการซอฟต์แวร์ภายใต้ TDD นั้นตรงข้ามกับวิธีการพัฒนาแบบ "ดั้งเดิม" มากกว่านี้หรือไม่? ดูเหมือนว่าฉันจะเห็นได้ชัดว่าคุณภาพจะเพิ่มขึ้นและปริมาณของความไม่แน่นอนลดลงเนื่องจากการทดสอบเสร็จสิ้นก่อนหน้านี้ แต่การทดสอบที่ต้องดำเนินการล่วงหน้าดูเหมือนว่าจะต้องใช้เวลานักพัฒนามากขึ้น ความพยายามในการพัฒนาเพิ่มขึ้นเท่าใดหรือลดลงจริงหรือไม่เนื่องจากการกำจัดข้อบกพร่องล่วงหน้า ต้องใช้ความพยายามมากแค่ไหนจากลูกค้า? พวกเขาต้องเปลี่ยนวิธีการที่เกี่ยวข้องกับโครงการโดยเฉพาะอย่างยิ่งหากพวกเขาคุ้นเคยกับการออกแบบที่ยิ่งใหญ่หรือไม่? จำนวนชั่วโมงที่ต้องการโดยรวมของลูกค้าเพิ่มขึ้นหรือลดลงจริงหรือไม่ ฉันคิดว่าการประมาณเวลาจะคลุมเครือมากในกระบวนการ TDD วนซ้ำเมื่อเริ่มต้นโครงการ TDD (เนื่องจากไม่มีแผนพัฒนาซอฟต์แวร์) มีจุดพูด 20% ในโครงการที่ความเชื่อมั่นเพิ่มขึ้นเพียงพอที่จะให้เวลาและเงินที่แน่นอนมากขึ้นหรือน้อยลงสำหรับลูกค้า หมายเหตุ: ฉันไม่ได้มองหาความคิดเห็นส่วนตัวหรือทฤษฎีที่นี่ดังนั้นโปรดอย่าคาดเดา ฉันกำลังมองหาประสบการณ์การใช้งานจริงใน TDD มากขึ้น
15 tdd  estimation 

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