คอขวดที่ใหญ่ที่สุดคืออะไรเมื่อพัฒนาโครงการขนาดใหญ่ [ปิด]


11

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

กรุณาใช้การอ้างอิงในคำตอบของคุณหรือระบุประสบการณ์ของคุณในเรื่อง


4
มีนักพัฒนาที่ดีไหม?

@ Thorbjørn Ravn Andersen สมมติว่ามีส่วนผสมที่ดีและไม่ดีเหมือนกับ Microsoft
David

1
นี่คือการระบุอย่างรุนแรงและไม่สามารถตอบได้

คำตอบ:


3

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

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

โดยวิธีการนี้จะไม่ซ้ำกับโครงการซอฟต์แวร์ เป็นจริงสำหรับทุกโครงการขนาดใหญ่ที่คุณพยายามทำสิ่งใหม่ ดูที่ Boeing Dreamliner มีหนังสือหลายเล่มที่เขียนเกี่ยวกับเรื่องนี้ The Mythical Man Month เป็นเดือนหนึ่ง


37

สมมติว่าข้อกำหนดทั้งหมดอยู่ในสถานที่และองค์กรทำงานอย่างสมบูรณ์

คุณเคยคิดว่า "คอขวด" สองอันที่ใหญ่ที่สุดในกระบวนการพัฒนาซอฟต์แวร์ไม่มีอยู่ (จากประสบการณ์ส่วนตัวของฉัน)


4
++ ใช่ และสมมติฐานที่ว่าถ้าคุณมีรายละเอียดพวกเขาจะไม่เปลี่ยน ต้องใช้นักพัฒนาผู้เชี่ยวชาญเพื่อทราบวิธีการคาดการณ์การเปลี่ยนแปลงที่ยังไม่ได้รับการร้องขอและวิธีจัดการกับพวกเขาเมื่อพวกเขาทำ
Mike Dunlavey

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

8

แม้ในโลกที่สมบูรณ์แบบสมมุติของคุณมีบางประเด็นที่ฉันเห็น:

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

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

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


ฉันคิดว่านี่เป็นคำตอบที่ยอดเยี่ยม!
David

4

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


2

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


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

1
การทดสอบซ้ำไม่ใช่ปัญหา คอขวดจริงมักพบข้อผิดพลาดในความคิดของฉัน แต่การค้นหาการแก้ไขที่เหมาะสมอาจใช้เวลาค่อนข้างเท่ากัน

2

ฉันคิดว่า Brandon Moretz มีคำตอบที่ดีที่สุด แต่ฉันต้องการเพิ่มว่าการรับรุ่นแรกออกจากโครงการขนาดใหญ่นั้นไม่ใช่เรื่องยาก โดยส่วนตัวฉันไม่เคยพลาดที่จะทำเช่นนั้น

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


0

ใช่ฉันจะเห็นด้วยกับสิ่งต่าง ๆ ข้างต้นและจะต้องติดตามรุ่นซอฟต์แวร์ตามความรู้ของฉันสิ่งสำคัญคือ:

1. การบริหารเวลา 2. ประสิทธิภาพของทีมและการจัดการทีม 3. ความร่วมมือในทีมและ 4. ความเข้าใจที่ดีขึ้นกับลูกค้า

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


0

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

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