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

คำถาม: ฉันทามติของอุตสาหกรรมซอฟต์แวร์คือรหัสที่สะอาดและเรียบง่ายเป็นพื้นฐานของความมีชีวิตในระยะยาวของฐานรหัสและองค์กรที่เป็นเจ้าของ คุณสมบัติเหล่านี้นำไปสู่การลดค่าใช้จ่ายในการบำรุงรักษาและเพิ่มโอกาสในการสร้างรหัสฐานอย่างต่อเนื่อง อย่างไรก็ตามรหัส SIMD นั้นแตกต่างจากรหัสแอปพลิเคชันทั่วไปและฉันต้องการทราบว่ามีฉันทามติที่คล้ายกันเกี่ยวกับรหัสที่สะอาดและใช้งานง่ายที่ใช้เฉพาะกับรหัส SIMD พื้นหลังคำถามของฉัน ฉันเขียนโค้ด SIMD (คำสั่งคำสั่งเดียวหลายข้อมูล) มากมายสำหรับการประมวลผลภาพและการวิเคราะห์ที่หลากหลาย เมื่อเร็ว ๆ นี้ฉันยังต้องพอร์ตฟังก์ชั่นเหล่านี้จำนวนเล็กน้อยจากสถาปัตยกรรมหนึ่ง (SSE2) ไปยังอีก (ARM NEON) รหัสนี้เขียนขึ้นสำหรับซอฟต์แวร์ที่มีการย่อขนาดดังนั้นจึงไม่สามารถขึ้นอยู่กับภาษาที่เป็นกรรมสิทธิ์หากไม่มีสิทธิ์การแจกจ่ายซ้ำเช่น MATLAB ตัวอย่างของโครงสร้างรหัสทั่วไป: ใช้ประเภทเมทริกซ์ของOpenCV ( Mat)สำหรับการจัดการหน่วยความจำบัฟเฟอร์และอายุการใช้งานทั้งหมด หลังจากตรวจสอบขนาด (ขนาด) ของอาร์กิวเมนต์อินพุตพอยน์เตอร์ไปยังที่อยู่เริ่มต้นของแต่ละแถวของพิกเซลจะถูกนำมาใช้ จำนวนพิกเซลและที่อยู่เริ่มต้นของพิกเซลแต่ละแถวจากเมทริกซ์อินพุตแต่ละอันจะถูกส่งผ่านไปยังฟังก์ชัน C ++ ระดับต่ำ ฟังก์ชัน C ++ ระดับต่ำเหล่านี้ใช้ SIMD ภายใน (สำหรับสถาปัตยกรรม IntelและARM NEON ) โหลดจากและบันทึกไปยังที่อยู่ตัวชี้แบบดิบ ลักษณะของฟังก์ชั่น C ++ ระดับต่ำเหล่านี้: สิทธิพิเศษหนึ่งมิติ (ต่อเนื่องกันในหน่วยความจำ) ไม่จัดการกับการจัดสรรหน่วยความจำ …

14 performance  optimization  estimation 

เราเริ่มใช้ Agile / Scrum ในทีมนักพัฒนา 4 คน เราทำการประมาณค่าเรื่องราวของเราและสั่งซื้อเรื่องราว Primed ในการค้างสินค้า เราเริ่มต้นด้วยการประมาณตามจุดบนความซับซ้อนจาก 1 ถึง 5 แทนที่จะเป็นปกติ 1,2,3,5,8,13 .... และอื่น ๆ หลังจากทำงานสองสามเรื่องเรารู้สึกว่าบางเรื่องที่ประเมินที่ 4 จุดควรเป็น 2 เท่านั้นในขณะที่อีกเรื่องที่ประมาณ 2 มีความซับซ้อนมากขึ้นและควรได้รับการประเมินเป็น 5 ฉันต้องการ ทราบ: ตกลงไหมที่จะเปลี่ยนการประมาณเรื่องราวของเราในระหว่างการทำซ้ำ? มันโอเคไหมที่จะใช้คะแนนการประเมินปัจจุบันจาก 1 ถึง 5 แทนที่จะเป็นปกติ 1,2,3,5,8,13 .... และอื่น ๆ แม้ว่าโดยส่วนตัวแล้วฉันรู้สึกว่ามันไม่ควรจะเป็นสำหรับทั้งสองกรณี แต่ฉันต้องสำรองตัวเองเพราะความเข้าใจของตัวเองยังไม่ชัดเจน (วัสดุอ้างอิงที่ดีจะดีมาก!)

14 project-management  agile  estimation 

ทุกวันหลังจากยืนหยัดทีมของฉันและฉันจะอัปเดตประมาณการของเราสำหรับแต่ละเรื่อง ฉันรู้สึกว่ามีบางอย่างผิดปกติกับวิธีที่เราทำดังนั้นฉันต้องการความช่วยเหลือจากคุณ นี่คือวิธีที่เรา: เรื่องราวโดยประมาณ: 24 ชั่วโมง (8 ชั่วโมงต่อวันเราใช้ "อุดมคติวัน" เป็นตัววัด) วันที่ N: ผู้พัฒนาเริ่มทำงานในเรื่อง A ในตอนเช้า (8 ชั่วโมงทำงานเสร็จในตอนท้ายของวัน) วันที่ N + 1: การเล่าเรื่องใหม่ = 16 ชั่วโมง (หนึ่งวันทำงานนำออกจาก Story A ตั้งแต่วันที่ N) วันที่ N + 2: การเล่าเรื่องใหม่ = 8 ชั่วโมง (วันทำงานหนึ่งเรื่องถูกนำออกจากเรื่อง A ตั้งแต่วันที่ N + 1) วันที่ N + 3: เรื่อง A …

14 scrum  estimation 

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

13 programming-practices  ethics  estimation  feasibility 

ฉันทำงานกับระบบธุรกรรมทางการเงินขนาดใหญ่สำหรับธนาคารที่ดูแลเงินบำนาญและการลงทุน หลังจากการเปลี่ยนแปลงคุณสมบัติ 15 ปีค่าใช้จ่ายในการทดสอบการถดถอยแบบแมนนวลก็เพิ่มขึ้นเป็น $ 200K ต่อการเปิดตัว (10M LOC ทำธุรกรรม $ 10M ต่อวัน) ระบบนี้ยังเชื่อมต่อกับ 19 ระบบอื่น ๆ ทั่ว บริษัท ที่ย้ายข้อมูลจำนวนมาก ระบบนี้ถูกนำไปใช้ใน Java อย่างไรก็ตามสิ่งที่เราสังเกตคือยิ่งเราใช้ค่าใช้จ่ายในการทดสอบการถดถอยมากขึ้น (เหตุผลที่คุณต้อง "ทดสอบรหัสที่คุณแตะ" - และรหัสที่ใช้ซ้ำ / แชร์จะส่งผลกระทบต่อสถานที่หลายแห่งเมื่อมีการแตะต้องดังนั้นแม้จะมี 'DRY - อย่าทำซ้ำตัวเอง' - นั่นคืออย่าคัดลอกและวางรหัส - เราสังเกตสิ่งจูงใจทางการเงินเพื่อคัดลอกและวางรหัสนี่คือการลดค่าใช้จ่ายในการทดสอบการถดถอยเนื่องจากเราไม่ต้องการแก้ไขรหัสที่สามารถแชร์ได้เพราะจะทำให้เกิดผลกระทบการทดสอบการถดถอยครั้งใหญ่) คำถามของฉันคือมีหลักการวิศวกรรมซอฟต์แวร์ที่อธิบายความสัมพันธ์ระหว่างต้นทุนการทดสอบซ้ำและการถดถอยซ้ำหรือไม่ เหตุผลที่ฉันถามคำถามนี้คือเนื้อหามีประโยชน์ต้นทุนในการย่อยสลายระบบเป็นส่วนเล็ก ๆ ที่จะทดสอบ สมมติฐาน: 'การทดสอบการถดถอย' หมายถึง 'การทดสอบการยอมรับ' - นั่นคืออีกกลุ่มใช้เวลาในการเขียนการทดสอบแบบเก่าและนำมาใช้ซ้ำกับระบบในนามของธุรกิจรวมถึงการตั้งค่าสภาพแวดล้อมและข้อมูล ฉันรู้ว่าปฏิกิริยาการกระตุกเข่าต่อค่าใช้จ่ายในการทดสอบการถดถอยครั้งใหญ่คือ 'การทดสอบอัตโนมัติมากขึ้น' นี่เป็นหลักการที่ดี ในสภาพแวดล้อมนี้มีความท้าทายสองประการ …

12 code-reuse  acceptance-testing  estimation 

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

12 estimation  quality  metrics  measurement 

ฉันอยู่ในทีมโปรเจคที่มี 4 devs ฉันรวมอยู่ด้วย เราได้มีการพูดคุยกันอย่างยาวนานเกี่ยวกับวิธีจัดการกับงานพิเศษที่เกิดขึ้นในรายการงานชิ้นเดียว งานพิเศษนี้มักจะเป็นสิ่งที่เกี่ยวข้องกับงานเล็กน้อย แต่ไม่จำเป็นเสมอไปที่จะบรรลุเป้าหมายของรายการ (อาจเป็นความเห็น) ตัวอย่างรวมถึง แต่ไม่ จำกัด เฉพาะ: refactoring ของรหัสการเปลี่ยนแปลงโดยรายการงาน refactoring code ที่อยู่ใกล้เคียงรหัสที่ถูกเปลี่ยนแปลงโดยรายการ ออกแบบพื้นที่โค้ดขนาดใหญ่รอบตั๋วอีกครั้ง ตัวอย่างเช่นหากรายการที่คุณเปลี่ยนฟังก์ชั่นเดียวคุณรู้ว่าตอนนี้ทั้งคลาสสามารถทำซ้ำได้เพื่อให้รองรับการเปลี่ยนแปลงนี้ได้ดียิ่งขึ้น ปรับปรุง UI บนแบบฟอร์มที่คุณเพิ่งแก้ไข เมื่องานพิเศษนี้เล็กเราไม่รังเกียจ ปัญหาคือเมื่องานพิเศษนี้ทำให้ส่วนขยายของรายการเกินกว่าการประมาณจุดคุณลักษณะดั้งเดิม บางครั้งรายการ 5 คะแนนจะใช้เวลา 13 คะแนน ในกรณีหนึ่งเรามีรายการ 13 จุดที่ในการหวนกลับอาจมี 80 คะแนนหรือมากกว่า ในการสนทนาของเรามีสองทางเลือกสำหรับวิธีจัดการกับปัญหานี้ เราสามารถรับงานพิเศษในรายการงานเดียวกันและเขียนออกเป็นการประเมินที่ผิดพลาด อาร์กิวเมนต์สำหรับสิ่งนี้ได้รวม: เราวางแผนสำหรับ "การเติมเต็ม" ในตอนท้ายของการวิ่งเพื่ออธิบายสิ่งนี้ ปล่อยให้รหัสอยู่ในรูปที่ดีกว่าที่คุณพบเสมอ อย่าเช็คอินงานครึ่งทาง หากเราออกจากการปรับโครงสร้างใหม่ในภายหลังมันยากที่จะกำหนดเวลาและอาจไม่เสร็จสิ้น คุณอยู่ใน "บริบท" ทางจิตใจที่ดีที่สุดในการจัดการงานนี้ในขณะนี้เนื่องจากคุณอยู่ลึกเข้าไปในรหัสแล้ว ดีกว่าที่จะนำมันออกไปให้พ้นทางและมีประสิทธิภาพมากกว่าที่จะเสียบริบทนั้นไปเมื่อคุณกลับมาในภายหลัง เราวาดเส้นสำหรับไอเท็มงานปัจจุบันและบอกว่างานพิเศษเข้าสู่ตั๋วแยกต่างหาก ข้อโต้แย้งรวมถึง: การมีตั๋วแยกต่างหากช่วยให้การประเมินใหม่ดังนั้นเราจึงไม่โกหกตัวเองเกี่ยวกับจำนวนของสิ่งที่เป็นจริงหรือต้องยอมรับว่าการประเมินทั้งหมดของเรานั้นแย่มาก …

12 agile  refactoring  estimation  sprint 

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

11 agile  estimation 

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

11 development-process  estimation 

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

11 estimation 

Iteration ได้เริ่มขึ้นแล้วโปรแกรมเมอร์ใหม่เข้าร่วมทีมงาน task X ได้รับการประเมินว่าใช้เวลา 30 ชั่วโมงโดยนักพัฒนาซอฟต์แวร์รายอื่น การปฏิบัติที่ดีที่สุดในสถานการณ์นี้คืออะไร? นักพัฒนาใหม่ทำงานโดยใช้การประมาณที่กำหนด (ความคิดที่ว่าความคลาดเคลื่อนใด ๆ จะได้รับการแก้ไขเมื่อมีการคำนวณความเร็ว) ใหม่ประมาณงานของนักพัฒนาหรือไม่ (ถ้าเป็นเช่นนั้นจะเกิดอะไรขึ้นถ้ามันสูงขึ้นอย่างมากและไม่เหมาะกับการทำซ้ำอีกต่อไป?) โยนมือของเราขึ้นแล้วกลับไปที่น้ำตก? อย่างอื่นอย่างสิ้นเชิง?

11 agile  estimation 

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

11 open-source  estimation  metrics 

ฉันกำลังทำงานในโครงการและเรามีการประชุมปกติ (โดยปกติทุกสัปดาห์) การประชุมอย่างไม่เป็นทางการซึ่งเราจะหารือเกี่ยวกับสถานะของโครงการและ GUI ของมัน ฉันเป็นนักพัฒนาเพียงคนเดียวที่นั่นอีก 4-5 คนมีพื้นหลังที่ไม่ใช่ด้านไอที การประชุมนี้ใช้เวลานานกว่าปกติมาก แต่ ณ จุดหนึ่งเพื่อนร่วมงานคนหนึ่งของฉันถามเกี่ยวกับบางสาขาในโปรแกรมและวิธีการเติม ฉันตอบและในการสนทนาฉันสังเกตเห็นว่าฉันมีกระบวนการผิดทั้งหมดในใจของฉัน แต่เมื่อเราพูดถึงมันและพบข้อผิดพลาดล่วงหน้าฉันสามารถเปลี่ยนได้อย่างรวดเร็ว ในขณะที่คิดเกี่ยวกับเรื่องนี้ฉันได้ถามตัวเองว่าถ้ามีเวลาระหว่างการประชุมเมื่อมันมาถึงการประหยัดเวลาในการพัฒนา? ตัวอย่างเช่นเวลา 1 นาทีของการประชุมอาจช่วยประหยัดเวลาในการพัฒนา X นาที ถ้าเป็นเช่นนั้นสิ่งนี้จะช่วยในการกำหนดความถี่และระยะเวลาในการประชุมของเรา (เพียงเพื่อชี้แจง: ฉันไม่ต้องการที่จะทำให้การประชุมที่ดีขึ้นแม้จะสามารถกำหนดความยาวของการประชุมเป็นตัวเลือกฉันมักจะสนใจถ้ามีความสัมพันธ์ระหว่างเวลาการประชุมและเวลาในการพัฒนาเหตุผลของฉันถาม: อยากรู้! )

10 estimation  meetings 

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

10 user-story  extreme-programming  estimation 

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

10 estimation  startup