คุณจะสร้างกระบวนการซอฟต์แวร์สำหรับโครงการได้อย่างไร

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

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

ฉันขอแนะนำให้คุณดูการเขียนโปรแกรมแบบเปรียว

มีหลายสายพันธุ์ แต่พวกเขามักจะมีบางสิ่งที่เหมือนกัน:

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

สถานที่ที่ดีที่จะเริ่มต้นจะเป็นชายเปรียวหรือการแย่งชิงกัน

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

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

เราใช้Prince2สำหรับกระบวนการจัดการโครงการและทำงานได้ดีมาก ฉันอยากจะแนะนำว่ามันดูคดเคี้ยวสำหรับ บริษัท ที่ไม่มีการจัดการโครงการในสถานที่ แต่!

เราปรับเปลี่ยนขั้นตอนการพัฒนาที่สรุปไว้ในวิดีโอนี้ตามความต้องการของเราโดยใช้ TeamCity เป็นเซิร์ฟเวอร์ CI ของเรา

http://channel9.msdn.com/shows/ARCast.TV/ARCastTV-Tuning-The-Development-Process-at-Spot-Runner/

TC เป็นระบบ CI เดียวที่ฉันรู้ว่ามันเป็น repository-push แทนที่จะเป็น pull ซึ่งหมายความว่า (ในทางทฤษฎี) ไม่มี build ที่เสียหายอีกต่อไป!

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

ตรวจสอบบทความเหล่านี้เกี่ยวกับการรวมอย่างต่อเนื่องสำหรับ. NET การเขียนโปรแกรมโดยใช้ MSBuild, CruiseControl.NET, FxCop, NUnit, NCover และการโค่นล้ม ...

จากร่องลึกการพัฒนาซอฟต์แวร์