ฉันคิดว่ามันเป็นจริงในบางสภาพแวดล้อม Agile ใช้เป็นข้อแก้ตัวสำหรับการไม่มีระเบียบวินัย ปัญหาที่แท้จริงคือเราไม่ทราบว่าทำไมเราถึงมีวิธีการใด ๆ โดยส่วนตัวแล้วฉันรู้สึกว่าวิธีการเป็นปัญหาทางสถาปัตยกรรมในแง่ที่ว่าสถาปัตยกรรมของระบบควรจะกล่าวถึงคุณลักษณะที่ไม่ได้ใช้งานได้คุณภาพวิธีการนั้นควรจะกล่าวถึงคุณลักษณะบางอย่างที่เหมือนกัน (ความสามารถในการบำรุงรักษา et al.)
การดูวิธีการเป็นตัวควบคุมสำหรับคุณลักษณะกระบวนการแสดงถึงสองสิ่ง: 1) หากไม่มีเมทริกเราจะไม่สามารถเปรียบเทียบประสิทธิภาพของวิธีการหนึ่งกับอีกวิธีหนึ่งได้ 2) การตัดสินใจที่แอ็คทีฟต้องทำเกี่ยวกับคุณลักษณะที่สำคัญ (เวลาส่งมอบเทียบกับรหัส คุณภาพเทียบกับการถ่ายโอนความรู้)
โดยไม่ต้องมีทั้งตัวชี้วัดและเป้าหมายที่เป็นรูปธรรมเราเพียงแค่เลือกวิธีการเป็น "ขนนกขนนก" ของเราซึ่งถ้าเรายึดมั่นแน่นเราจะสามารถส่งมอบซอฟต์แวร์ได้
ทีนี้ผู้พูดไม่เก่งของ Agile, XP, Scrum และอื่น ๆ พูดถึงความเปราะบางของวิธีการนั้น ๆ การโต้แย้ง: ทำไมใช้วิธีการที่สามารถก่อวินาศกรรมโดยบุคคลหนึ่งที่ขาดวินัยในการปฏิบัติตามกฎทั้งหมด? คำถามคือคำถามที่ถูกต้อง อย่างไรก็ตามนั่นคืออาการไม่ใช่สาเหตุ หากชุดเมทริกของกระบวนการมีความถูกต้องและมีความหมาย (ซึ่งเป็นส่วนที่ยาก) จะมีการกำหนดทดสอบและส่งข้อเสนอแนะในเวลาที่กำหนดเนื่องจากฉันคิดว่าเราจะค้นพบวิธีการเฉพาะนั้นมีส่วนเกี่ยวข้องกับความสำเร็จเพียงเล็กน้อย (การพูดโดยสังเขปฉันได้เห็นโครงการที่ประสบความสำเร็จโดยใช้วิธีการมากมายและล้มเหลวเป็นสองเท่าโดยใช้วิธีการเดียวกัน)
แล้วเมตริกคืออะไร? พวกเขาแตกต่างจากโครงการไปยังโครงการทีมงานเป็นทีมและเป็นครั้งคราว มีประโยชน์เมื่อตารางการส่งมอบมีความสำคัญสิ่งที่ฉันใช้เป็นการส่วนตัวคือทักษะการประมาณและคุณภาพ นักพัฒนาส่วนใหญ่สามารถประมาณงานที่ต้องใช้เวลาไม่เกินหนึ่งสัปดาห์ ดังนั้นวิธีหนึ่งคือการแบ่งโครงการออกเป็นงานหนึ่งสัปดาห์นักพัฒนาและติดตามผู้ทำการประเมิน เมื่อโครงการดำเนินไปพวกเขาอาจเปลี่ยนการประมาณของพวกเขา หลังจากงานเสร็จสมบูรณ์หากปิดมากกว่า 10% (1/2 ต่อวัน) เราปฏิบัติเช่นนี้เป็นข้อบกพร่อง - เราระบุว่าเหตุใดการประมาณการจึงปิด (เช่นตารางฐานข้อมูลไม่ได้ถูกพิจารณา) ระบุ การดำเนินการแก้ไข (เช่นเกี่ยวข้องกับ DBA ในการประมาณค่า) แล้วไปต่อ การใช้ข้อมูลนี้เราสามารถสร้างตัวชี้วัดเช่น # ของข้อบกพร่องการประมาณต่อสัปดาห์, # ของข้อบกพร่องต่อนักพัฒนา
แล้วอะไรล่ะ นั่นคือเมื่อวิธีการเข้ามา - หากคุณมีแบบจำลองการทำนายที่ล้มเหลวในการตอบสนองคุณภาพของกระบวนการคุณสามารถเลือกที่จะเพิ่มหรือลบบางแง่มุมของวิธีการและดูว่ามันมีผลต่อแบบจำลองของคุณอย่างไร จริงอยู่ที่ไม่มีใครอยากเล่นกับกระบวนการพัฒนาเพราะกลัวความล้มเหลว แต่เราก็ล้มเหลวในอัตราที่สูงและคาดการณ์ได้อย่างต่อเนื่อง ด้วยการเปลี่ยนแปลงแต่ละอย่างและการวัดผลลัพธ์คุณอาจพบว่า Agile เป็นวิธีการที่สมบูรณ์แบบสำหรับทีมของคุณ แต่คุณสามารถหา RUP น้ำตกหรือเพียงแค่การหลบหลีกของแนวปฏิบัติที่ดีที่สุดได้อย่างง่ายดาย
ดังนั้นข้อเสนอแนะของฉันคือให้หยุดกังวลเกี่ยวกับสิ่งที่เราเรียกกระบวนการวางการตรวจสอบที่เกี่ยวข้องกับเป้าหมายกระบวนการพัฒนาของเราและทดสอบด้วยเทคนิคต่าง ๆ เพื่อปรับปรุงกระบวนการนั้น
