ผู้จัดการซอฟต์แวร์ที่ทำให้ผู้พัฒนาทำการจัดการโครงการ

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

เรายังมีผู้จัดการซอฟต์แวร์ซึ่งเป็นหัวหน้าของฉัน เขาทำให้ฉันเขียนและบำรุงรักษากำหนดการซอฟต์แวร์เอกสารการออกแบบ (การออกแบบระดับสูงและต่ำ) SRS การจัดการการเปลี่ยนแปลงแผนการตรวจสอบและรายงานการจัดการการเปิดตัวการทบทวนและหลักสูตรซอฟต์แวร์

เรามีวิศวกรทดสอบเพียงคนเดียวสำหรับทีมซอฟต์แวร์ทั้งหมด (สมาชิก 10 คน) และในเวลาใดก็ตามมีโครงการสองโครงการเกิดขึ้น

ฉันใช้เวลา 80% ในการทำเอกสารเหล่านี้ เจ้านายของฉันมาจากพื้นฐานกระบวนการและเชื่อว่าสิ่งที่เราต้องการคือเอกสารที่ดีกว่าในการปรับปรุงซอฟต์แวร์:

1. เขาคิดว่าการออกแบบเป็นสิ่งสำคัญยิ่งการเข้ารหัสคือ "เพียงแค่เขียนการออกแบบ" มันไม่ควรใช้เวลานานเกินไปและ "รหัสทั้งหมดควรจะเขียนก่อนที่ฮาร์ดแวร์จะพร้อม"
2. ไม่เข้าใจความแตกต่างระหว่างตัวควบคุม Central & Distributed Version แม้ว่าเราจะบอกเขาว่ามันง่ายกว่าที่จะทำงานร่วมกับแบบจำลองการกระจาย
3. ไม่เข้าใจรหัสและต้องการเข้าใจทุกข้อบกพร่องและแนวทางแก้ไขที่เสนอ
4. การตรวจสอบความเชื่อควรทำโดยนักพัฒนาและการตรวจสอบโดยผู้ทดสอบ สิ่งที่เป็นอยู่การตรวจสอบของเราเพียงตรวจสอบว่าการใช้งานถูกต้อง (เราไม่ได้เขียนการทดสอบหน่วยมันไม่เคยพิจารณาในตาราง) และการตรวจสอบคือการทดสอบกล่องดำดังนั้นการทดสอบหน่วยจะหายไป

ฉันสับสนจริงๆ

1. ฉันต้องรับผิดชอบในการดูแลรักษาเอกสารเหล่านี้ทั้งหมดหรือไม่ มันทำให้ฉันรู้สึกว่าฉันกำลังทำ Software Management Management เป็นหลัก ฉันใช้ได้กับเอกสารทางเทคนิค แต่ฉันเชื่อว่านักพัฒนาไม่ควรทำตามกำหนดเวลา / การวางแผน
2. ฉันไม่ชอบการสร้างเอกสารฉันต้องการแก้ปัญหาและเขียนรหัส จากประสบการณ์ของฉันการสร้างเอกสารการออกแบบจะช่วยเท่าที่ไม่เคยแก้ปัญหาของรหัสที่ดีขึ้นหรือเร็วขึ้น
3. ฉันรู้สึกว่าเจ้านายไม่ได้ใส่ใจกับการสร้างผลิตภัณฑ์ที่ดีกว่า แต่เกี่ยวกับการเป็นผู้จัดการที่ดีในสายตาของผู้บริหาร

ฉันควรทำอย่างไร ตลอดทั้งปีนี้ฉันได้ทำการเข้ารหัสจริง 3 เดือนส่วนที่เหลือใช้ในการทำเอกสารและรอรายงานข้อผิดพลาดจากลูกค้า

คุณฟังดูเหมือนวิศวกรซอฟต์แวร์

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

การเขียนและดูแลรักษาเอกสารการออกแบบและเทคนิคเป็นส่วนสำคัญของการเป็นวิศวกรซอฟต์แวร์และเหมาะสมกับบทบาทของคุณ สิ่งที่ดีมากเกินไปอาจไม่ดี (ดูบทวิเคราะห์ Paraylsis )

เขาคิดว่าการออกแบบเป็นสิ่งสำคัญยิ่งการเข้ารหัสคือ "เพียงแค่เขียนการออกแบบลงไป"

หากผู้จัดการโครงการพิจารณาเอกสารการออกแบบว่ามีความสำคัญที่สุดเขาคาดว่าเอกสารดังกล่าวจะส่งมอบในกระบวนการ ไม่ใช่เวลาของคุณถ้าเขารู้สึกว่าพวกเขามีความสำคัญพอที่จะจัดสรรเวลาให้คุณ 80%

ไม่ควรใช้เวลานานเกินไปและ "ควรเขียนรหัสทั้งหมดก่อนที่ฮาร์ดแวร์จะพร้อมใช้งาน"

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

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

(2) ไม่เข้าใจความแตกต่างระหว่างตัวควบคุม Central & Distributed Version

ทำไมเขาถึงต้องแคร์? มันส่งผลกระทบต่อเหตุการณ์สำคัญอย่างไร มันไม่ได้

3) ไม่เข้าใจโค้ดและต้องการเข้าใจทุกข้อผิดพลาดและวิธีแก้ปัญหาที่เสนอ

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

(4) การตรวจสอบความเชื่อควรทำโดยนักพัฒนาและการตรวจสอบโดยผู้ทดสอบ

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

ฉันไม่ชอบการสร้างเอกสารฉันต้องการแก้ปัญหาและเขียนรหัส

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

จากประสบการณ์ของฉันการสร้างเอกสารการออกแบบจะช่วยเท่าที่ไม่เคยแก้ปัญหาของรหัสที่ดีขึ้นหรือเร็วขึ้น

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

ข้อเท็จจริงของเรื่องคือเอกสารทางเทคนิคที่ดีที่สุดคือรหัสเอง

ฉันรู้สึกว่าเจ้านายไม่ได้ใส่ใจกับการสร้างผลิตภัณฑ์ที่ดีกว่า แต่เกี่ยวกับการเป็นผู้จัดการที่ดีในสายตาของผู้บริหาร

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

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

เราทุกคนต้องการดูดีต่อสายตาของหัวหน้าของเรา ไม่มีอะไรผิดปกติกับมันเป็นธรรมชาติของมนุษย์ที่จะให้บริการตนเอง นี่คือความจริงของชีวิต

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

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

FYI, Atlassionซึ่งเป็น บริษัท ซอฟต์แวร์มีอัตราส่วนของนักพัฒนา 13 คนต่อหนึ่ง QA และการทดสอบส่วนใหญ่ (การวางแผนและการดำเนินการ) นั้นดำเนินการโดยนักพัฒนา ฉันเรียนรู้สิ่งนี้ในระหว่างการนำเสนอของพวกเขาที่ Agile 2012 และทีมของเราที่ฉันกำลังพยายามเลียนแบบการปฏิบัตินี้

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

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

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

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

นอกจากนี้จากมุมมองทางธุรกิจที่เข้มงวดการจ้างงาน QA นั้นถูกกว่าการจ้างนักพัฒนา คุณจะสามารถครอบคลุมการใช้จ่ายเงินได้มากขึ้นหากทีมมีอัตราส่วน QA / DEV ที่ดี

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

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

คุณกำลังพูดถึงระบบการแพทย์ ... ดังนั้นความปลอดภัยจึงเป็นสิ่งสำคัญยิ่งและเอกสารประกอบ

ผู้ทดสอบคนหนึ่งดูเหมือนจะเบาไปหน่อย แต่นอกเหนือจากนั้นแล้วใช่ - คุณมีหน้าที่รับผิดชอบในการตรวจสอบเอกสาร

ประสบการณ์ของฉันในโลกการแพทย์มี จำกัด แต่ในโลกการบินและอวกาศ / การป้องกันเรามี Do-178B (ตอนนี้ C) ซึ่งกำหนดรูปแบบวงจรชีวิตที่ระบุเอกสารและระดับการทดสอบที่จำเป็น (ขึ้นอยู่กับความสำคัญด้านความปลอดภัย ระดับความมั่นใจในการออกแบบ] ของซอฟต์แวร์) และในโลกยานยนต์เราก็มี ISO26262 เช่นเดียวกัน

หากเอกสารไม่ได้อยู่ในสถานที่ผลิตภัณฑ์ไม่ได้รับการรับรอง

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