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

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

652 project-management  development-process  estimation  time-management 

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

132 agile  scrum  estimation  user-story 

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

120 communication  estimation  release-management 

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

113 project-management  contract  estimation 

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

86 estimation  legacy-code 

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

83 design  project-management  estimation  technical-debt 

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

63 architecture  project-management  estimation 

นักพัฒนาซอฟต์แวร์เกือบทุกคนต้องตอบคำถามจากฝ่ายธุรกิจเช่น: เหตุใดจึงต้องใช้เวลา 2 วันในการเพิ่มแบบฟอร์มติดต่ออย่างง่ายนี้ เมื่อนักพัฒนาประเมินงานนี้พวกเขาอาจแบ่งออกเป็นขั้นตอน: ทำการเปลี่ยนแปลงฐานข้อมูล เพิ่มประสิทธิภาพการเปลี่ยนแปลงฐานข้อมูลเพื่อความเร็ว เพิ่มส่วนหน้า HTML เขียนโค้ดฝั่งเซิร์ฟเวอร์ เพิ่มการตรวจสอบ เพิ่มจาวาสคริปต์ฝั่งไคลเอ็นต์ ใช้การทดสอบหน่วย ตรวจสอบให้แน่ใจว่าการตั้งค่า SEO ใช้งานได้ ใช้การยืนยันทางอีเมล refactor และเพิ่มประสิทธิภาพรหัสสำหรับความเร็ว ... สิ่งเหล่านี้อาจอธิบายได้ยากสำหรับบุคคลที่ไม่ใช่ด้านเทคนิคซึ่งโดยทั่วไปแล้วเห็นว่างานทั้งหมดเป็นเพียงการรวบรวม HTML และสร้างตารางเพื่อเก็บข้อมูล สำหรับพวกเขามันอาจจะเป็น 2 ชั่วโมงสูงสุด ดังนั้นจะมีวิธีที่ดีกว่าในการอธิบายว่าทำไมการประมาณการจึงสูงถึงผู้ที่ไม่ใช่นักพัฒนา

60 communication  estimation 

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

56 estimation  automation 

เราใช้ Scrum และบางครั้งพบว่าเราไม่สามารถทำเรื่องราวของผู้ใช้ให้จบได้ในการวิ่งที่วางแผนไว้ ในรูปแบบการต่อสู้ที่แท้จริงเราจัดส่งซอฟต์แวร์ต่อไปและพิจารณารวมเรื่องของผู้ใช้ในการวิ่งครั้งต่อไปในช่วงการวางแผน Sprint ถัดไป เนื่องจากเรื่องราวของผู้ใช้ที่เรากำลังดำเนินการอยู่นั้นเสร็จสมบูรณ์บางส่วนเราจะประเมินได้อย่างถูกต้องในเซสชันการวางแผน Sprint ครั้งถัดไปอย่างไร เราได้พิจารณาแล้ว: a) การปรับจำนวนคะแนนสตอรี่ลงเพื่อแสดงเฉพาะงานที่ยังคงทำให้เรื่องราวของผู้ใช้เสร็จสมบูรณ์ น่าเสียดายที่สิ่งนี้จะทำให้การรายงาน Backlog ผลิตภัณฑ์ล้มเหลว b) ปิดเรื่องราวของผู้ใช้ที่เสร็จสมบูรณ์บางส่วนและเพิ่มใหม่เพื่อใช้งานคุณสมบัติที่เหลือซึ่งจะมีคะแนนเรื่องราวน้อยลง สิ่งนี้จะส่งผลต่อความสามารถในการมองย้อนกลับไปในสิ่งที่เราไม่ได้ทำในการวิ่งครั้งนั้นและดูเหมือนจะใช้เวลานาน c) ไม่ต้องกังวลกับ a หรือ b และคาดเดาต่อไปในระหว่างการวางแผน Sprint ว่าสิ่งต่าง ๆ เช่น "เรื่องราวของผู้ใช้อาจเป็นจุดเรื่องราว X แต่ฉันรู้ว่ามันเสร็จ 95% ดังนั้นฉันแน่ใจว่าเราสามารถใส่ได้"

50 agile  scrum  estimation  planning 

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

42 project-management  estimation 

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

37 project-management  estimation  project 

เราเริ่มใช้ Story Points ที่นี่เพื่อการพัฒนาแบบ Agile ของเรา แต่ฉันคิดว่ามันยากที่จะอธิบายและไม่สามารถหาคำตอบที่ชัดเจนสำหรับสิ่งที่พวกเขาเป็น สิ่งที่ดีที่สุดที่ฉันสามารถทำได้คือชี้ไปที่เว็บไซต์อื่น ๆ (เช่นhttp://blog.mountaingoatsoftware.com/tag/story-points ) และให้ลักษณะทั่วไปที่คลุมเครือของสิ่งที่พวกเขาเป็น ฉันกำลังมองหาคำอธิบายที่ดีพร้อมตัวอย่างการใช้งานที่จะเป็นประโยชน์สำหรับผู้อื่นในการใช้งาน มีแหล่งข้อมูลที่ดีสำหรับการอธิบายประเด็นหรือไม่?

36 agile  estimation  planning 

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

32 teamwork  code-reviews  estimation  project-planning 

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

31 coding-standards  time-management  estimation