Agile คืออะไร: หลักคิดในการพัฒนาซอฟต์แวร์แบบ Iterative
Agile เป็นแนวคิดส่งมอบงานที่ใช้ได้ เรียนรู้จากผู้ใช้ และปรับแผนเป็นรอบ ไม่ใช่เพียงการประชุมหรือแบ่งงานเป็น Sprint
Agile คือแนวคิดการพัฒนาซอฟต์แวร์ที่ให้ความสำคัญกับการร่วมมือ ส่งมอบสิ่งที่ใช้งานได้ รับข้อมูลกลับ และปรับตัวเมื่อเรียนรู้เพิ่ม การทำงานแบบ Iterative แบ่งงานเป็นรอบสั้นพอให้ตรวจผลและแก้ทิศได้ แต่ไม่ได้หมายความว่าทุกอย่างต้องเปลี่ยนตลอดเวลา หรือไม่ต้องวางแผน
หลักคิดที่อยู่เบื้องหลัง
Agile Manifesto ให้คุณค่ากับคนและการสื่อสาร ซอฟต์แวร์ที่ทำงานได้ ความร่วมมือกับลูกค้า และการตอบสนองต่อการเปลี่ยนแปลง โดยไม่ได้บอกว่าเอกสารหรือแผนไม่มีค่า สิ่งเหล่านั้นยังจำเป็นเมื่อช่วยให้ทีมทำงานและตรวจสอบได้ คำถามสำคัญจึงเป็น “สิ่งที่ทำในรอบนี้สร้างคุณค่าอะไร และเราเรียนรู้อะไรจากมัน”
ภาพที่ 1: รอบการพัฒนาที่สั้นช่วยให้ข้อค้นพบจากผู้ใช้ส่งผลต่อแผนรอบต่อไปได้เร็วขึ้น
รอบหนึ่งควรมีอะไร
เริ่มจากเป้าหมายที่ชัด เลือกขอบเขตที่ทำเสร็จและตรวจได้ ออกแบบเท่าที่จำเป็น พัฒนาและทดสอบ แล้วแสดงผลให้ผู้เกี่ยวข้องดู ข้อมูลกลับอาจเป็นการทดลองใช้งาน ข้อผิดพลาด หรือคำถามใหม่ จากนั้นปรับลำดับงาน ไม่ใช่เพิ่มทุกคำขอเข้าแผนทันที หากไม่มีเกณฑ์ว่าอะไรถือว่าเสร็จ การแบ่งเวลาเป็นรอบก็อาจได้เพียงงานค้างหลายชุด
ตัวอย่างสมมติ: ระบบติดตามคำขอ
รอบแรกทำให้พนักงานส่งคำขอและเห็นเลขอ้างอิง รอบถัดไปให้เจ้าหน้าที่รับงานและเปลี่ยนสถานะ เมื่อทดลองแล้วพบว่าผู้ยื่นไม่รู้ว่าต้องเติมข้อมูลใด ทีมจึงปรับแบบฟอร์มก่อนเพิ่ม Dashboard แผนเปลี่ยนเพราะหลักฐานจากการใช้งาน ไม่ใช่เพราะเลี่ยงการวาง Requirement
ข้อจำกัดและการนำไปใช้ในรายงาน
งานที่มีข้อกำกับหรือระบบภายนอกยังต้องระบุข้อจำกัด สิทธิ์ และหลักฐานการทดสอบ Agile ไม่ใช่ข้อยกเว้นด้านคุณภาพ หากผู้ตัดสินใจไม่พร้อมดูงานเป็นระยะหรือทีมไม่มีช่องทางรับข้อมูลผู้ใช้ การทำงานเป็นรอบก็ไม่ช่วยมาก รายงานควรแสดงเป้าหมายรอบ สิ่งที่ส่งมอบ ข้อมูลกลับ และเหตุผลที่ปรับแผน โดยแยกผลจริงออกจากสิ่งที่คาดว่าจะเกิด
อ่านต่อ Agile กับ Waterfall และ Scrum คืออะไร หรือดู บริการพัฒนา Web Application
วิเคราะห์กรณีศึกษาเพื่อนำไปเขียนรายงาน
ลองกำหนดกรณีศึกษาเป็น ทีมเล็กส่งระบบติดตามงานทีละส่วนทุกสองสัปดาห์ และเขียนขอบเขตให้ชัดว่ามีผู้ใช้กลุ่มใด ข้อมูลใดเข้าสู่ระบบ และต้องการผลลัพธ์อะไร เริ่มจากสภาพก่อนพัฒนา แล้วอธิบายการตัดสินใจที่บทความนี้เกี่ยวข้องโดยใช้ตัวอย่างข้อมูลหรือเหตุการณ์ที่สมมติขึ้นอย่างระบุว่าเป็นตัวอย่าง การกำหนดขอบเขตเช่นนี้ช่วยให้ผู้อ่านแยกหลักการทั่วไปออกจากข้อเท็จจริงของโครงการได้
หลักฐานที่ควรแสดงคือ เป้าหมายรอบ งานที่ใช้ได้จริง และข้อเสนอแนะจากผู้ใช้ ควรอธิบายสัญลักษณ์ คำย่อ หรือเงื่อนไขในหลักฐานนั้นให้ผู้อ่านที่ไม่อยู่ในทีมเข้าใจ และบอกว่ามันเชื่อมกับ Requirement ข้อใด ถ้ามีหลายทางเลือก ให้ระบุเหตุผลที่เลือกทางหนึ่งและผลกระทบต่อผู้ใช้ ทีมพัฒนา หรือผู้ดูแลระบบ แทนการเขียนเพียงว่าใช้แนวทางที่ “ดีที่สุด” โดยไม่มีเกณฑ์เปรียบเทียบ
เกณฑ์ประเมินตัวอย่างคือ รอบถัดไปเปลี่ยนตามสิ่งที่เรียนรู้พร้อมรักษาคุณภาพ ส่วนข้อจำกัดที่ต้องระบุคือ การทำงานเป็นรอบไม่ใช่ข้ออ้างให้ละเลยการออกแบบหรือทดสอบ หากยังไม่ได้ทดลองกับผู้ใช้หรือข้อมูลจริง ให้เขียนว่าเป็นข้อเสนอเชิงออกแบบ ไม่สรุปเป็นผลที่พิสูจน์แล้ว การมีทั้งเกณฑ์และข้อจำกัดช่วยให้รายงานตรวจสอบเหตุผลได้ และเปิดทางให้ผู้อื่นนำกรณีเดียวกันไปทดสอบซ้ำในบริบทของตน
แหล่งข้อมูลประกอบ
- Manifesto for Agile Software Development — คุณค่าหลักของ Agile
- Principles behind the Agile Manifesto — หลักการส่งมอบ เรียนรู้ และรักษาคุณภาพ