เหตุใดกำหนดการของซอฟต์แวร์จึงยากที่จะกำหนด

ดูเหมือนว่าจากประสบการณ์ของฉันการให้วิศวกรของเราประเมินอย่างถูกต้องและกำหนดงานที่ต้องทำให้เสร็จนั้นก็เหมือนกับการถอนฟัน แทนที่จะเพียงแค่ให้การประมาณย้อยเป็นเวลา 2-3 สัปดาห์หรือ 3-6 เดือน ... วิธีที่ง่ายที่สุดในการกำหนดตารางเวลาซอฟต์แวร์คืออะไรดังนั้นพวกเขาจึงไม่เจ็บปวดที่จะกำหนด? ตัวอย่างเช่นลูกค้า A ต้องการสถานที่ภายในวันที่ 02/01/2011 คุณจะกำหนดเวลาในการใช้คุณสมบัตินี้ได้อย่างไรโดยทราบว่าอาจต้องมีการแก้ไขข้อบกพร่องอื่น ๆ ระหว่างการทำงาน

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

เหล่านี้คือเงื่อนไขที่จิตรกรผู้ติดตั้งพรม landscapers ฯลฯ ประสบการณ์เป็นประจำ แต่มันไม่เหมาะสำหรับโครงการซอฟต์แวร์ (หรือส่วนใหญ่) จำนวนมาก

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

จากประสบการณ์ส่วนตัวของฉันมันตรงกันข้ามกับที่ Pemdas พูดไว้ : จากการฝึกฝนฉันเพิ่งเข้าใจว่ามันเป็นไปไม่ได้เลยที่จะประเมินว่าต้องใช้เวลาเท่าไรในการทำงาน ในตอนต้นของอาชีพของฉันในการพัฒนาซอฟต์แวร์ฉันมักจะประมาณการเช่น "45 วัน", "ห้าสัปดาห์" ฯลฯ จากนั้นพยายามอย่างหนักเพื่อให้เสร็จทันเวลา ไม่กี่ปีหลังจากนั้นฉันเริ่มประมาณการที่แม่นยำน้อยกว่าเช่น "ประมาณหนึ่งเดือน", "ห้าถึงเจ็ดสัปดาห์" ฯลฯ ที่จริงแล้วฉันพยายามอย่างใดอย่างหนึ่งที่จะไม่ให้การประเมินใด ๆ หรือขอให้ลูกค้าประเมินด้วยตัวเธอเอง หรือกำหนดเวลาหรือฉันให้ประมาณการคร่าวๆเท่าที่จะทำได้

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

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

2. ปัญหาบางอย่างอาจเกิดขึ้น ตัวอย่างเช่นหากต้องการเริ่มงานคุณต้องติดตั้งเซิร์ฟเวอร์ SQL แฟนซีและการติดตั้งล้มเหลวและการสนับสนุนไม่มีอยู่คุณอาจต้องใช้เวลาหลายสัปดาห์ในการแก้ไขปัญหานี้

3. ความต้องการมักไม่ชัดเจนเพียงพอแต่หลังจากที่อ่านมาตั้งแต่แรกคุณคิดว่าเป็น บางครั้งคุณสามารถเข้าใจได้ว่าค่าเฉลี่ย 'A' และหลังจากเริ่มใช้งานคุณจะสังเกตเห็นว่าพวกเขาอาจหมายถึง 'B'

4. ลูกค้าต้องการเปลี่ยนความต้องการของพวกเขาเมื่อคุณเพิ่งเสร็จสิ้นส่วนที่เกี่ยวข้องและพวกเขาไม่เข้าใจว่าทำไมคุณขออีกสองสัปดาห์และ $ 2000 ทำการเปลี่ยนแปลงเล็กน้อยเพราะพวกเขาไม่เห็นว่าการเปลี่ยนแปลงเล็ก ๆนี้ต้อง เปลี่ยนสิ่งอื่น ๆ ซึ่งจำเป็นต้องเปลี่ยนผู้อื่น ฯลฯ

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

6. กลายเป็นสิ่งที่เลวร้ายจริงๆเมื่อประมาณการของคุณขึ้นอยู่กับคนอื่น ตัวอย่างเช่นในโครงการหนึ่งเดือนฉันต้องรอให้นักออกแบบทำผลงานของเขาเองจนเสร็จ นักออกแบบนี้ใช้เวลา 3 เดือนก่อนส่งเศษอึที่ใช้ไม่ได้ แน่นอนโครงการก็สาย

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

คุณทำอะไรได้บ้าง?

1. กำหนดเวลาให้ใหญ่ขึ้น หากคุณคิดว่าคุณสามารถทำงานได้ภายในสองสัปดาห์พูดว่าคุณจะส่งงานให้ภายในหนึ่งเดือน

2. ชัดเจน หากคุณพึ่งพานักออกแบบผู้พัฒนารายอื่น ฯลฯ ให้พูด แทนที่จะบอกว่า "ฉันจะส่งมอบผลิตภัณฑ์ภายในสามเดือน" ให้พูดว่า "ฉันจะส่งมอบผลิตภัณฑ์ภายในสองเดือนหลังจากที่ผู้ออกแบบจะให้ไฟล์ PSD แก่ฉัน"

3. อธิบายว่าหากความต้องการเปลี่ยนแปลงไปทุกวันโครงการจะถูกส่งไม่ทัน

4. Slice ตารางเวลาของคุณ การส่งมอบชิ้นส่วนของโครงการขนาดใหญ่ตรงเวลานั้นง่ายขึ้น

5. อย่าคาดคะเนเมื่อคุณใช้ผลิตภัณฑ์ที่คุณไม่รู้จักดีหรือโดยเฉพาะอย่างยิ่งเมื่อคุณจะทำงานกับซอร์สโค้ดของคนอื่น: คุณไม่สามารถทำนายได้ว่าซอร์สโค้ดที่เสแสร้งสามารถทำได้และเวลาที่คุณใช้ไป ทำความเข้าใจและคัดลอกไปที่ The Daily WTF

คำถามที่คล้ายกันมากคือ "ใช้เวลานานแค่ไหนในการไขปริศนาไขว้นี้?"

คุณไม่สามารถตอบได้จนกว่าคุณจะได้เห็นมันเพื่อดูสิ่งต่าง ๆ มากมายเช่น:

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

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

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

เหตุผลที่ชัดเจนที่สุดว่าทำไมวิศวกรคุณไม่สามารถให้คุณประมาณการที่ถูกต้องก็คือว่ามันเป็นไปไม่ได้

แน่นอนคุณสามารถประมาณเวลา + -2 นาทีที่จะใช้เวลาจากบ้านของคุณไปทำงาน คุณรู้วิธีขับรถคุณสามารถประเมินการจราจรและปัจจัยภายนอกอื่น ๆ

บอกฉันว่าต้องใช้เวลาเท่าไหร่ในการขับรถจากลอนดอนไปบาร์เซโลนา ไม่มีเครื่องมือการวางแผน GPS ขั้นสูงแน่นอน ใช้วิธีการแบบเก่าที่ดีอย่างที่เราทำในการประมาณค่าซอฟต์แวร์ การประมาณค่าเชิงประจักษ์และการคาดการณ์

ในซอฟต์แวร์มันแย่กว่า:

1. การประมาณการมักจะกลายเป็นข้อผูกพันดังนั้นการตัดสินใจของเราจึงได้รับการแก้ไข
2. อาจมีความแตกต่างอย่างมากระหว่างการประมาณค่าของ Bob และ Karl สำหรับงานเดียวกัน
3. ความไม่แน่นอนเป็นเรื่องธรรมดามากที่เราติดอยู่กับข้อผิดพลาดโง่หรือฮาร์ดไดรฟ์ผิดพลาดทำลายการประมาณที่ดีใด ๆ ที่ชัดเจน
4. เรามักจะลืมเกี่ยวกับงานอื่น ๆ ทั้งหมดนอกเหนือจากการเขียนโปรแกรมรวมถึงการประชุมการโทรติดต่อการช่วยเหลือ coleague ของเราเป็นต้น
5. สมองของมนุษย์จะถูก จำกัด ไม่ได้ถูกออกแบบมาเพื่อประเมินงานที่ต้องใช้เวลานาน

นั่นเป็นเหตุผลที่เป็นไปไม่ได้ที่จะบอกลูกค้าของคุณว่าคุณจะสามารถจัดส่งสินค้าในวันที่ 02/01/2011 ด้วยความแม่นยำที่ถูกต้องและลืมเกี่ยวกับวันที่ 03/01/2011

เพื่อแก้ไขปัญหาเหล่านั้นฉันขอแนะนำให้คุณใช้เทคนิคการประเมินขั้นสูงเช่นPlanning Poker (ข้อจำกัดความรับผิดชอบ: นี่คือหนึ่งในเว็บไซต์ของฉัน) และการพัฒนาซ้ำพร้อมการคำนวณVelocity

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

การพัฒนาซอฟต์แวร์โดยนิยาม - การค้นพบและการประดิษฐ์ มันจะต้องเกี่ยวข้องกับสิ่งที่ไม่รู้จักเสมอ

เวลาเท่านั้นที่ทุกอย่างที่เกี่ยวข้องกับการพัฒนาซอฟต์แวร์เป็นที่รู้จักคือเมื่อซอฟต์แวร์เสร็จสมบูรณ์

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

เหตุผลที่เราเขียนซอฟต์แวร์ใหม่เพราะเรามีคุณสมบัติใหม่หรือเทคโนโลยีใหม่หรือทั้งสองอย่าง ใหม่หมายถึงใหม่ - ไม่ทราบ - ไม่แน่นอน

เนื่องจากการพัฒนาซอฟต์แวร์ต้องเกี่ยวข้องกับความแปลกใหม่ความพยายามในการพัฒนาจึงไม่สามารถคาดการณ์ได้

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

มันไม่ง่ายเลย คุณแค่พยายามทำให้ดีขึ้น

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

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

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

เพราะเราทำตารางเร็วเกินไป ดูบทความของ Construxเกี่ยวกับการทำคร่าวๆเบื้องต้นจากนั้นดีกว่าทีหลัง นอกจากนี้หากคุณไม่ได้ติดตามว่าคุณทำตามการประมาณการก่อนหน้านี้เป็นการยากที่จะทำให้ดีขึ้น FogBugz ทำเช่นนั้น [ลูกค้าของพวกเขาฟรีไม่มีความขัดแย้งทางผลประโยชน์อื่น ๆ ]

ฉันได้เรียนรู้มากมายจากหนังสือเล่มนี้:

การประมาณค่าซอฟต์แวร์: ทำให้เข้าใจถึงศาสตร์มืด

ในระยะสั้นเพื่อรับผลลัพธ์การประมาณที่ดีกว่าเราดำเนินการดังนี้

1. ทั้งหมด แต่งานเล็ก ๆ น้อย ๆ คาดว่ามากกว่าหนึ่งคน (สองในกรณีของเรา)
2. เราแบ่งงานออกเป็นงานย่อย ๆ ยิ่งคุณมีโอกาสมากที่การประเมินของคุณจะดีขึ้น - กฎหมายของคนจำนวนมากถ้าฉันจำได้อย่างถูกต้องจากฮาป่า
3. เราประเมินสถานการณ์ที่เลวร้ายที่สุดดีที่สุดและเป็นไปได้มากที่สุด บางครั้งเราแต่ละคนประเมินสถานการณ์ต้นไม้เหล่านั้นแตกต่างกันโดยสิ้นเชิง นั่นหมายความว่าเราต้องพูดคุยและโดยปกติแล้วปรากฎว่าพวกเราคนหนึ่งไม่เข้าใจงาน หากว่ามีคนคนหนึ่งประเมินงานคนเดียวมันจะประเมินผิด
4. เราใส่ตัวเลข 3 ตัวจากจุดด้านบนลงในสมการและรับการประมาณ (ยอดเยี่ยม) k

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

หมายเหตุ: สิ่งนี้ใช้ได้กับโครงการที่คุณเรียกเก็บเงินเป็นรายชั่วโมงเปรียบเทียบกับอัตราคงที่ / แบบคงที่

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

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

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

ผู้พัฒนารายต่อไปลืมที่จะประเมินงานที่ไม่ใช่การพัฒนาทั้งหมดเช่นการประชุมและอีเมลที่เกี่ยวข้องกับโครงการการปรับใช้การสนับสนุน QA การสนับสนุน UAT การทดสอบหน่วยการเขียนการวิจัยเอกสาร ฯลฯ เมื่อเราเพิ่มงานประเภทนี้ลงในสเปรดชีตประมาณของเรา การประมาณการมีวิธีที่ดีกว่า

เมื่อมาถึงการประเมินเวลาสำหรับงานซึ่งอาจใช้เวลานานกว่านั้นสองสามชั่วโมงฉันพยายามอย่างดีที่สุดเพื่อใช้กฎนี้:

1. ไม่เคยพยายามที่จะทำนายเมื่อคนอื่น ๆ จะเสร็จสิ้นการงานของพวกเขาหากเกิดขึ้นจะขึ้นอยู่กับมัน พูดด้วยตัวคุณเองเท่านั้น
2. ก่อนวิเคราะห์งานจากนั้นประมาณ โดยการวิเคราะห์ฉันหมายถึงอย่างน้อยเขียน (และไม่พยายามเก็บทุกอย่างไว้ในหัวของคุณ!) รายการงานย่อยที่มีการประเมินสำหรับแต่ละงาน
3. หากงานมีความซับซ้อนเพียงพอให้ประเมินเวลาสำหรับการวิเคราะห์ด้วยตนเอง ให้การประเมินเป็นกระบวนการแยกต่างหาก คุณอาจทำให้แน่ใจว่าเจ้านายของคุณรู้เรื่องนั้นด้วย
4. อย่าประเมินภายใต้ความกดดัน ทำให้ชัดเจนว่าต้องใช้เวลาในการประมาณค่าที่เหมาะสมและบอกสิ่งที่พวกเขาเช่น "ฉันจะตั้งชื่อวันพรุ่งนี้ในเวลา 11:00 น. เมื่อฉันจะวิเคราะห์งานให้เสร็จ" ฉันรู้ว่าลูกค้า / ผู้จัดการบางคนสามารถกดยาก แต่พวกเขาจะไม่ผ่าน ใส่ใบหน้าที่วุ่นวายของคุณและเรียกร้องเวลาของคุณ!
5. ขอเวลามากกว่าที่คุณคิดเพราะคุณอาจลืมเพิ่มเวลาพักดื่มกาแฟ (และการรบกวนอื่น ๆ ) ในการประมาณของคุณ
6. สำหรับงานใหญ่ถามมากกว่านี้ - อาจจะมีร้านกาแฟมากกว่าหนึ่งแห่ง
7. หากคุณไม่สามารถประมาณการได้ (งานนั้นยากเกินไป / ไม่คุ้นเคย) หรือไม่แน่ใจจริงๆ - ขอความช่วยเหลือจากบุคคลที่มีความสามารถในการวิเคราะห์ของคุณ

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

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

มี"unknowns unknown" และ "unknown unknowns" :-)

1. การคาดการณ์มักจะกลายเป็นกำหนดเวลา

   • ไม่มีใครอยากพลาดกำหนดและกลายเป็นหัวข้อ!

2. การเปลี่ยนแปลงข้อกำหนด (มักจะสมเหตุสมผล) และโปรแกรมเมอร์ไม่สามารถยับยั้งมันได้

3. โปรแกรมเมอร์ทำ / อาจไม่มีการควบคุมปัจจัยเช่น

   • ความพร้อมใช้งานของรหัสเธอขึ้นอยู่กับ
   • คุณภาพของรหัสเธอขึ้นอยู่กับ
   • สถาปัตยกรรมโดยรวมและการออกแบบระบบ
   • API เพื่อเข้าถึงส่วนอื่น ๆ ของระบบ