สมมติว่าสถานการณ์ที่ทีมสี่นักพัฒนากำลังสร้างแอปพลิเคชัน ในระหว่างขั้นตอนการทดสอบผู้ใช้จะรายงานข้อบกพร่อง ใครควรแก้ไขพวกเขา คนที่ทำรหัสผิดพลาดหรือใครก็ตามที่ว่าง?
อะไรคือวิธีการที่ต้องการในการพัฒนาแบบเปรียว (scrum)?
คำตอบ:
แนวทางที่ต้องการในการพัฒนาแบบเปรียวคือการแก้ไขให้เร็วที่สุดโดยใครก็ตามที่มีอยู่ นี่เป็นเพียงเพราะความเป็นเจ้าของรหัสไม่ได้ตกอยู่กับบุคคลใดคนหนึ่ง แต่ต่อกลุ่มนักพัฒนาทั้งหมด หากบุคคลหนึ่งทำให้เกิดข้อบกพร่องอย่างต่อเนื่องนั่นเป็นอีกปัญหาที่ต้องแก้ไขแยกต่างหาก
โดยค่าเริ่มต้นบุคคล เหตุผลง่ายมาก: ข้อเสนอแนะ ข้อบกพร่องให้โอกาสที่ดีสำหรับข้อเสนอแนะส่วนบุคคลและเป็นมืออาชีพ หากคนอื่นแก้ไขข้อบกพร่องของฉันฉันจะทำผิดพลาดอีกครั้งเพราะฉันจะไม่เรียนรู้จากมัน
หากบุคคลนั้นไม่ว่างบุคคลอื่นสามารถแก้ไขได้ แต่บุคคลนั้นควรทำตามวงจรชีวิตของแมลง
ในฐานะ PM ฉันจะหลีกเลี่ยงการเชื่อมโยงข้อบกพร่องกับนักพัฒนาเฉพาะ หากจำเป็นต้องทำให้ผู้จัดการการทำงาน / การพัฒนาทำเช่นนั้น กังวลกับทีม มีข้อผิดพลาดที่ทีมต้องแก้ไข
ฉันไม่ทราบว่า scrum จัดการกับสถานการณ์นี้ได้อย่างไร แต่ในทีมของฉันเรามีบางอย่างที่เหมือนการทดสอบข้ามรหัส / ด้วยวิธีนี้ในกรณีที่พบข้อผิดพลาดทั้งผู้พัฒนาและผู้ตรวจทานจะหารือถึงวิธีที่ดีที่สุดในการแก้ไข
ฉันเชื่อว่าตราบใดที่วิธีการแก้ปัญหาเหมาะสมกับมันไม่สำคัญว่านักพัฒนาหรือผู้ตรวจสอบจะนำไปใช้ อย่างไรก็ตามมีความสำคัญเพื่อหลีกเลี่ยงความขัดแย้งใด ๆ ระหว่างผู้พัฒนาและผู้ทดสอบ
Rgds
แก้ไข: ไม่แน่ใจว่าฉันทำให้ตัวเองชัดเจนหรือไม่ แต่สิ่งสำคัญคือต้องเน้นว่าผู้ตรวจสอบเป็นนักพัฒนาคนอื่นในทีม
ฉันเห็นด้วยกับสตีเว่นเกี่ยวกับรหัสเป็นของทีมทั้งหมด และมีสาเหตุเพิ่มเติมบางประการที่คุณไม่ควรให้ข้อบกพร่องกับผู้สร้าง:
อย่างที่ฉันรู้ในหลายกรณีเป็นการยากที่จะระบุว่าใครเป็นคนทำให้เกิดข้อผิดพลาด แม้ว่าคุณจะใช้ระบบการจัดการเอกสารเช่น SVN การติดตามรหัสข้อผิดพลาดอาจใช้เวลานาน ดังนั้นในมุมมองของฉันเพียงแค่ให้ข้อผิดพลาดสำหรับทุกคนที่มีอิสระ
หากคุณต้องการติดตามว่าข้อผิดพลาดเกิดขึ้นในเวลาว่างคุณสามารถถามช่างซ่อมเกี่ยวกับเคส (ก่อนทีมทั้งหมด) เนื่องจากทีมของคุณมีขนาดเล็กฉันคิดว่าสิ่งนี้จะแบ่งปันประสบการณ์เกี่ยวกับข้อผิดพลาดที่อาจเกิดขึ้นได้และไม่ทำให้ใครลำบากใจ
มีเพียงสามเหตุผลในการดูแลว่าใครแก้ไขข้อบกพร่อง: ค่าใช้จ่ายความเร็วและการพัฒนามืออาชีพ
และมีข้อดีข้อเสียสำหรับทั้งสาม ยกตัวอย่างเช่นการพัฒนาวิชาชีพในทางกลับกันโอกาสในการเรียนรู้เพิ่มเติมเกี่ยวกับรหัสในอีกด้านหนึ่งถือเป็นโอกาสอันดีที่จะตระหนักถึงข้อผิดพลาดที่คุณทำและหลีกเลี่ยงบางอย่างในอนาคต หรือใช้ค่าใช้จ่ายสันนิษฐานว่าคนที่ทำผิดจะสามารถแก้ไขได้เร็วขึ้นและอาจถูกกว่าในทางกลับกันมีค่าใช้จ่ายสำหรับเวลาที่ระบุว่าใครทำผิดและมอบหมายให้คนที่เหมาะสม - เวลา ซึ่งในหลายกรณีเกินกว่าการแก้ไขบั๊ก
แนวทางแบบว่องไวคือการให้ผู้พัฒนากำหนดปัญหาเองฉันจะลบล้างสิ่งนั้นด้วยเหตุผลที่ดีเท่านั้น
ในทีมของฉันเรามักจะตัดสินใจตามลำดับความสำคัญ หากบุคคลที่ส่งรหัสพร้อมใช้งานเขา / เธอจะแก้ไขรหัส หากบุคคลนั้นกำลังทำงานในเรื่องที่มีลำดับความสำคัญสูงกว่าทุกคนที่สามารถใช้งานได้และสามารถแก้ไขรหัสได้โดยเร็วที่สุดจะสามารถแก้ไขได้ หากทุกคนกำลังยุ่งกับการทำงานกับภารกิจที่มีลำดับความสำคัญสูงกว่าในการทำซ้ำปัจจุบันการแก้ไขจะถูกกำหนดไว้ในการทำซ้ำครั้งถัดไปตามลำดับความสำคัญเมื่อเทียบกับเรื่องราวและข้อบกพร่องอื่น ๆ
คิดเกี่ยวกับ: ใครมีข้อมูลเพิ่มเติมเกี่ยวกับบั๊กบ้าง ทีมพัฒนา
ดังนั้นให้พวกเขาตัดสินใจว่าจะทำอย่างไรกับข้อผิดพลาด พวกเขาเป็นเจ้าของรหัสดังนั้นพวกเขาจึงรับผิดชอบมัน
คุณสามารถช่วยให้พวกเขาด้วยการจัดการโครงการจัดสรรเวลาบางส่วนในขอบเขตของโครงการสำหรับแก้ไขข้อผิดพลาดและให้พวกเขาเพียงอย่างเดียวในการทำงาน
หลีกเลี่ยงการตัดสินใจหลายอย่างที่คุณ (ในฐานะบทบาท PM) มีข้อมูลน้อยกว่าทีม
ดูคำถามเกี่ยวกับ: วิธีหลีกเลี่ยงการจัดการทีมพัฒนาซอฟต์แวร์ขนาดเล็กได้อย่างไร?
ฉันบอกว่าคุณต้องมีระบบติดตามบั๊กเพื่อบันทึกข้อผิดพลาดที่เกิดจากสิ่งที่รายงานโดยจากนั้นมอบหมายบั๊กให้กับคนอื่นตามภาระงานของพวกเขา ระบุว่ารหัสใดที่ทำให้เกิดข้อผิดพลาดจากนั้นมีรายงานแสดงจำนวนผู้เข้ารหัสและแอพใดที่ทำให้เกิดข้อผิดพลาดจำนวน x ในระหว่างสัปดาห์
จากนั้นคุณสามารถแสดงให้ผู้เขียนโค้ดเห็นว่าพวกมันก่อให้เกิดข้อบกพร่องอย่างไร
และวิธีที่ดีที่สุดในการป้องกันข้อบกพร่องคือให้ทุกคนมีส่วนร่วมในการแก้ไข ฉันหมายถึงมอบหมายการแก้ไขข้อผิดพลาดให้กับคนที่แตกต่างกันเพื่อมอบประสบการณ์การปัดเศษของสิ่งที่ทำให้เกิดข้อบกพร่องและสิ่งที่แก้ไขพวกเขา
หลังจากนั้นหนึ่งหรือสองเดือนในการแก้ไขข้อบกพร่องแก้ไขหรือสร้างแนวทางการเขียนโค้ดเพื่อช่วยป้องกันข้อผิดพลาดในอนาคตทั้งระบบโดยมีมาตรฐานเป็นลายลักษณ์อักษร / เอกสารสำหรับวิธีการโปรแกรมของคุณ
เมื่อพบข้อผิดพลาดมันเป็นความรับผิดชอบของทีมพัฒนาทั้งหมดในการแก้ไข
หากผู้คนเชื่อว่าข้อผิดพลาดควรได้รับการแก้ไขโดยผู้เขียนมันก็เหมือนกับพูดว่า "ฉันไม่ได้แก้ไขปัญหาหลุมไม่ได้อยู่ข้างเรือ" แต่เรือจะยังคงจมถ้ารูไม่คงที่และคุณอยู่บนเรือลำนั้นกับคนอื่น
บุคคลต้องตระหนักว่าพวกเขาเป็นส่วนหนึ่งของทีมและเข้าใจว่ารหัสพร้อมกับความรับผิดชอบเป็นของพวกเขาทั้งหมด ความสำเร็จของโครงการขึ้นอยู่กับสมาชิกทุกคนในทีม