Skip to content

Latest commit

 

History

History
31 lines (31 loc) · 7.21 KB

12.4. Quality management and agile development.md

File metadata and controls

31 lines (31 loc) · 7.21 KB

Quality management and agile development Quality management and agile development

  • การจัดการด้านคุณภาพ (Quality management) ในการพัฒนาแบบ agile ถือว่าเป็นเรื่องไม่เป็นทางการ
  • มันขึ้นอยู่กับการสร้างวัฒนธรรมที่มีคุณภาพของทีม ซึ่งสมาชิกในทีมทุกคนควรรู้สึกรับผิดชอบต่อคุณภาพของซอฟต์แวร์ และดำเนินการทุกวิธีเพื่อให้มั่นใจว่ามีการรักษาคุณภาพไว้ทุกขั้นตอน
  • ชุมชน agile มักจะมีพื้นฐานแนวคิดที่สวนทางกับมาตรฐานและกระบวนการคุณภาพตามที่กำหนดไว้ใน ISO 9001 Shared good practice
  • ตรวจสอบก่อนเช็คอิน (Check before check-in)
  • โปรแกรมเมอร์มีหน้าที่รับผิดชอบในการจัดทำบทวิจารณ์โค้ดของตนเองกับสมาชิกคนอื่นในทีม ก่อนที่โค้ดจะถูกนำเข้าสู่ระบบเพื่อสร้างซอฟต์แวร์
  • อย่าทำลายระบบ (Never break the build)
  • สมาชิกในทีมไม่ควรนำเข้ารหัสที่ทำให้ระบบล้มเหลวเข้าสู่ระบบ
  • นักพัฒนาซอฟต์แวร์ต้องทดสอบการเปลี่ยนแปลงโค้ดกับทั้งระบบ และมั่นใจว่างานเหล่านี้จะได้ผลตามที่คาดไว้
  • แก้ไขปัญหาทันที่ที่พบ (Fix problems when you see them)
  • หากโปรแกรมเมอร์ค้นพบปัญหาหรือความคลุมเครือในโค้ดที่พัฒนาโดยบุคคลอื่น พวกเขาสามารถแก้ไขปัญหาเหล่านี้ได้โดยตรงแทนที่จะส่งไปให้ผู้พัฒนาเดิมดำเนินการ Reviews and agile methods
  • กระบวนการรีวิวในการพัฒนาซอฟต์แวร์แบบ agile มักไม่เป็นทางการ
  • ในการพัฒนาแบบ scrum มีการประชุมทบทวนหลังจากแต่ละ iteration ของซอฟต์แวร์เสร็จสิ้นลง (เรียกว่า sprint review) ซึ่งอาจมีการกล่าวถึงประเด็นด้านคุณภาพและปัญหาต่างๆ
  • ใน Extreme Programming การเขียนโปรแกรมแบบคู่ (pair programming) ช่วยให้มั่นใจได้ว่าโค้ดจะถูกตรวจสอบและรีวิวโดยสมาชิกคนอื่นในทีมอยู่เสมอ Pair programming
  • ในวิธีการนี้ สมาชิก 2 คนในทีม มีหน้าที่ในการพัฒนาโค้ดและทำงานร่วมกันเพื่อให้บรรลุเป้าหมาย
  • รหัสที่พัฒนาขึ้นโดยสมาชิกจึงถูกตรวจสอบและตรวจทานโดยสมาชิกอีกคนในทีมอย่างต่อเนื่อง
  • การเขียนโปรแกรมคู่จะนำไปสู่ความรู้ที่ลึกซึ้งของโปรแกรม เนื่องจากโปรแกรมเมอร์ทั้งสองต้องเข้าใจในรายละเอียดของโปรแกรมเพื่อพัฒนาต่อ
  • การเขียนโปรแกรมคู่สามารถหาข้อบกพร่องที่ไม่สามารถค้นพบได้ในการรีวิวอย่างเป็นทางการ Pair programming weaknesses
  • ทั้งคู่อาจทำความเข้าใจข้อกำหนดของระบบผิดพลาดเหมือนกัน ยิ่งคุยกันมากขึ้นก็อาจจะยิ่งเพิ่มความผิดพลาดเหล่านั้น
  • ทั้งคู่อาจจะลังเลที่จะมองหาข้อผิดพลาด เนื่องจากไม่ต้องการชะลอความคืบหน้าของโครงการ
  • ความสามารถในการค้นพบข้อบกพร่องของคู่นี้อาจจะถูกทำให้แย่ลง เนื่องจากความสัมพันธ์ในการทำงานอย่างใกล้ชิดมักจะนำไปสู่การไม่เต็มใจที่จะวิพากษ์วิจารณ์เพื่อนร่วมงาน Agile QM and large systems
  • เมื่อมีการพัฒนาระบบขนาดใหญ่ แนวทาง agile ที่อาศัยจัดการด้านคุณภาพด้วยเอกสารอย่างน้อยนิด อาจไม่สามารถเป็นไปได้ในทางปฏิบัติ
  • ถ้าลูกค้าเป็นบริษัทขนาดใหญ่ อาจมีกระบวนการบริหารจัดการคุณภาพของตนเองและคาดว่าบริษัทพัฒนาซอฟต์แวร์จะสามารถรายงานความคืบหน้าในทางที่เข้ากันได้
  • ในกรณีที่มีทีมงานที่กระจายตัวทางภูมิศาสตร์หลายแห่ง นักพัฒนาอาจมาจากบริษัทอื่นที่ใช้ภาษาถิ่นแตกต่างกัน ดังนั้นการสื่อสารแบบไม่เป็นทางการอาจใช้ไม่ได้
  • สำหรับระบบที่มีอายุการใช้งานยาวนาน อาจจะมีการเปลี่ยนแปลงสมาชิกในทีมงานพัฒนา สมาชิกในทีมใหม่อาจไม่สามารถเข้าใจเอกสารเหล่านั้น