ฉันจะเอาชนะโมเดลการพัฒนาซอฟต์แวร์ที่มีโครงสร้างที่ไม่ดีได้อย่างไร

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

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

ต้องขอบคุณที่ฉันมีงานทำโอกาสปรากฏตัวและในที่สุดฉันก็รับผิดชอบแผนก Business Intelligence ของ บริษัท เช่นกัน บริษัท เชื่อในตัวฉัน ฉันเองศึกษาคลังข้อมูลและแนวคิด BI และประสบความสำเร็จในการรวม GIS กับ BI ด้วย

นอกจากนี้ฉันกำลังทำงานร่วมกับนักพัฒนาสองคนในเครื่องมือ BI ของเราใน C # WPF ซึ่งฉันยังเล่นบทบาทของนักพัฒนาในบางครั้ง (ซึ่งฉันชอบ)

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

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

เรามีปัญหาที่คล้ายกัน (โดยไม่มีรายละเอียดทางเทคนิคแน่นอน) ใน บริษัท ที่ฉันทำงานประมาณสองปีที่แล้ว

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

สร้างช้า (แต่เร็วที่สุดเท่าที่จะทำได้: P) อย่างต่อเนื่องและแน่นอน

ฉันอยากจะแนะนำขั้นตอนต่อไป (ในการทำเช่นนี้คุณอาจเปลี่ยนจากการจัดการเป็นการพัฒนาในขณะที่ควรจะดี)

1. เรียนรู้ระบบควบคุมเวอร์ชันที่ดีและเรียนรู้ได้ดี โดยส่วนตัวฉันจะแนะนำ git หรือ mercurial มีเอกสารจำนวนมากทั้งคู่
2. สร้างแกนของแข็งในการปฏิบัติและรูปแบบการ อ่านหนังสืออ่านบล็อกดู screencasts กับสมาชิกในทีม สิ่งนี้จะให้อากาศใหม่แก่การพัฒนา
3. เรียนรู้TDD / BDDและลองนำไปใช้ในรหัสใหม่เช่นเดียวกับในรหัสเก่าที่คุณอาจสัมผัสเมื่อทำคุณสมบัติใหม่
4. Do เขียนโปรแกรมคู่ สองหัวคิดดีกว่าหนึ่งและ 4 ตาดีกว่า 2 :)
5. ค้นหาเกี่ยวกับเครื่องมือที่ใช้บ่อยและล่าสุดในชุมชนของภาษาที่คุณกำลังพัฒนา เรียนรู้เกี่ยวกับพวกเขาและพยายามที่จะรวมพวกเขาบางส่วนในโครงการ ดูว่าสิ่งเหล่านี้ถูกสร้างและเรียนรู้อย่างไร
6. ใช้ต่อสู้ การทำซ้ำเรื่องราวจุดเรื่องราวอุปสรรคเป็นแนวคิดทั้งหมดที่คุณควรทำความคุ้นเคย สำหรับฉันแล้ว scrum ได้พิสูจน์แล้วว่าเป็นเวิร์กโฟลว์ที่ดีที่สุดสำหรับการพัฒนาและการจัดการซอฟต์แวร์ นำไปใช้และเรียนรู้จากประสบการณ์ในแต่ละวัน
7. สอนโดยยกตัวอย่างเช่น นักพัฒนามือใหม่ส่วนใหญ่กระตือรือร้นที่จะเรียนรู้สิ่งใหม่ ๆ แต่บางคนก็ขี้เกียจมาก อย่างไรก็ตามแสดงสิ่งใหม่ที่คุณได้เรียนรู้และนำไปใช้และหวังว่าจะทำให้สมองของพวกเขาดีขึ้น

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

อย่าขี้เกียจหรือท้อแท้ เพียงแค่เรียนรู้จากความผิดพลาดของคุณและลองวิธีการต่าง ๆ นี่เป็นเพียงจุดเริ่มต้น!

แก้ไข:

นี่คือลิงค์และหนังสือบางส่วนที่ฉันได้อ่าน / ใช้เมื่อเร็ว ๆ นี้ ...

การเรียนรู้ git: Pro Git

นี่คือบางส่วนของบล็อกที่ฉันอยากจะแนะนำ (ส่วนใหญ่เป็น. NET oriented):

• บล็อก Java
• บล็อกของ Karl Seguinและรากฐานการเขียนโปรแกรม
• CodeBetter.com
• คิดรหัส
• Los Techies
• ทำความสะอาด Coder
• และยังเชื่อมโยงไปยังคำถามล้นสแต็ค

สำหรับหนังสือคุณสามารถดูรายการBuiding A Solid Programming Core ได้ที่ amazon ฉันอยากจะแนะนำเหล่านี้:

• ทำความสะอาดรหัส
• การพัฒนาซอฟต์แวร์หลักการรูปแบบและการปฏิบัติที่คล่องตัว
• หนังสือเกือบทุกเล่มจากThe Pragmatic Bookshelf

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

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

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

Agile นั้นไม่ดีในโดเมนการพัฒนาทั้งหมด ใช้งานได้สำหรับบางประเภทโครงการล้มเหลวอย่างน่าสังเวชในประเภทอื่น ๆ คุณอาจจะต้องลองวิธีการที่แตกต่างกันไม่กี่ก่อนที่คุณจะหาคนที่ทำงานได้ดี

ได้รับการควบคุมเวอร์ชันตั้งค่า จริง ๆ แล้วมันใช้เวลา 5-10 นาทีในการตั้งค่า Git อีกสองสามนาทีเพื่อให้การทำงานขั้นพื้นฐานลดลงและการอ่านหนึ่งหรือสองวันเพื่อให้ได้แนวคิดขั้นสูงมากขึ้น

อืมไม่แน่ใจว่าฉันพบคุณที่งาน Agile / XP ในโตรอนโตหรือไม่ฟังดูคุ้น ๆ

ดูเหมือนคุณจะต้องหยุดพัก ใช้เวลาช่วงวันหยุดยาวดื่มถ้าคุณชอบและลืมงานสักสองสามวัน

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

มีเว็บไซต์ (เบต้า) pm.stackexchange.com ซึ่งกำหนดเป้าหมายไว้ที่การบริหารโครงการคุณอาจได้รับคำแนะนำ / การสนับสนุนที่เป็นประโยชน์บ้าง - แต่โดยทั้งหมดแล้วโปรดเก็บคำถามไว้ที่นี่ด้วย

ย้ายไปยังสิ่งที่ techie:

ไม่มีระบบควบคุมเวอร์ชัน

ใส่หนึ่งในความสำคัญสูงสุดของคุณ ฉันชอบระบบแบบรวมศูนย์เช่น SVN (การโค่นล้ม) มากกว่า git / mercurial เพราะแล็ปท็อปที่ถูกขโมยจะไม่มีประวัติในพื้นที่มากนัก สำคัญอย่างยิ่งหากมีสิ่งใดเป็นความลับสุดยอด (เช่นรหัสผ่านและ ssh-keys) โดยไม่ได้ตั้งใจ แต่มันเป็นเรื่องของรสนิยม ไม่มีอะไรเสียเวลาไปกว่าข้อบกพร่องจาก 'การควบคุมเวอร์ชันด้วยตนเอง' - เช่นการใส่รหัสกลับไปที่สิ่งที่คุณคิดว่ามันเป็น

โชคดี

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

ส่วนที่ยากที่สุดของหมายเลข 1 คือการจดจำว่าผู้บริหารระดับสูงมักไม่สนใจรายละเอียดของสิ่งที่คุณกำลังทำอยู่ (ถ้าพวกเขาพวกเขาจะทำมันเองแทนที่จะมอบให้คุณ!) ดูเหมือนว่าสิ่งกีดขวางขนาดใหญ่คือ 'ทำไม' และคุณอาจต้องการดู CMM 1.1 สำหรับคำอธิบายของผลประโยชน์ทางธุรกิจของการปรับปรุงกระบวนการ โปรแกรม. ไม่ว่าคุณจะใช้ CMM หรืออย่างอื่นเพื่อปรับปรุงกระบวนการของคุณจริง ๆ แล้วจะไม่สำคัญกับการสนทนานี้มีเพียงข้อมูลจากการศึกษา Carnegie-Mellon ซึ่งแสดงให้เห็นว่าองค์กรที่เป็นผู้ใหญ่มากขึ้นส่งมอบโครงการได้เร็วขึ้น

มีถนนมากมายสู่ความสำเร็จในการปรับปรุงกระบวนการพวกเขาทั้งหมดมีแนวโน้มที่จะยาวมาก ประสบการณ์กับ CMM แสดงให้เห็นว่าอาจใช้เวลา 8 ถึง 10 ปีในการย้ายจากระดับ 1 ถึง 5 ประสบการณ์กับ 6 sigma แสดงให้เห็นว่าการวนซ้ำแต่ละครั้งมีการปรับปรุงบ้าง แต่ต้องมีการวนซ้ำหลายรอบเพื่อขจัดปัญหาที่อาจเกิดขึ้นส่วนใหญ่ 6 sigmas of quality, งานกำลังทำแตกต่างไปจากเดิมอย่างสิ้นเชิงโดยไม่ต้องเสี่ยงกับการพยายามเปลี่ยนทุกอย่างทันที

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

คุณจะไม่ชนะทุกครั้งที่ขอการสนับสนุนด้วยวิธีนี้คุณอาจได้รับรูปลักษณ์ที่ว่างเปล่าน้อยลงและชนะมากขึ้น!

ขอให้โชคดี

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

ตามที่คนอื่น ๆ ได้ชี้ให้เห็นคุณจำเป็นต้อง:

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