การพัฒนาเอกสารซ้ำเป็นไปได้และส่งมอบเอกสารที่มีประสิทธิภาพหรือไม่


11

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

ตัวโครงการเองต้องการให้เราทำเอกสารงานของเรามากมาย ดังนั้นนอกจากการส่งรหัสซึ่งนับรวมเครื่องหมายบางอย่างแล้วเราต้องส่งเอกสารดังนี้:

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

การส่งมอบเหล่านี้จะต้องจัดส่งในลักษณะดังต่อไปนี้:

  • RAD ก่อน
  • ตามด้วยโครงการโครงการใช้แบบจำลองและการทดสอบ (ประมาณ 3 สัปดาห์ต่อมา)
  • สุดท้ายเอกสารประกอบของโปรแกรมจริงกระบวนการทดสอบ ฯลฯ + โปรแกรมจริง (ประมาณ 5 สัปดาห์ต่อมา)

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

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

  • ฉันสามารถตกลงกันได้หรือไม่ว่าจะต้องส่งเอกสารทั้งหมดด้วยวัฏจักรการพัฒนาที่รวดเร็วทำซ้ำ / สร้างต้นแบบ?
  • มีกลยุทธ์ในการสร้างเอกสารในลักษณะวนซ้ำหรือไม่?
  • ฉันไม่มีเหตุผลเลยที่จะขอสิ่งนี้และคาดหวังว่าจะทำได้ในมหาวิทยาลัยหรือไม่?

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

อย่างไรก็ตามขออภัยเกี่ยวกับระยะเวลานี้และถ้าคุณอ่านจนจบขอบคุณ! หากคุณสามารถใช้เวลาในการตอบฉันจะขอบคุณมาก! ขอบคุณ!


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

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

2
แน่นอนว่าการทำต้นแบบนั้นถูกต้อง ในความเป็นจริงใน บริษัท ขนาดใหญ่คุณอาจพบว่าตัวเองกำลังสร้างต้นแบบเพื่อปรับการวิจัยและพัฒนาให้เป็นทุน (มันเป็นเรื่องของการบัญชีไม่ใช่เรื่องทางเทคนิค) แม้ว่าคุณจะไม่มีความตั้งใจที่จะใช้ต้นแบบเป็นพื้นฐานสำหรับระบบสุดท้าย ในความเป็นจริงแล้วต้นแบบที่ดีที่สุดคือสิ่งที่ให้คำแนะนำและจะถูกทิ้งไป ถ้าฉันมีนิเกิลสำหรับต้นแบบ "ผลิตผล" ทุกอันที่ต้องการการเขียนซ้ำทั้งหมดในอีกสองสามปีต่อมาฉันจะมีนิคมากมาย
Ross Patterson

คำตอบ:


5

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

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

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


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