Agile​ ​กับ​ ​Waterfall​ ​แตก​ต่าง​กัน​อย่างไร​ ​และ​ควร​เลือก​ใช้​แบบ​ใด

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

เปรียบเทียบสี่มิติ

1. แผน: Waterfall มักให้รายละเอียดงานต้นโครงการมากกว่า; Agile วางเป้าหมายรวมแล้วเติมรายละเอียดของงานใกล้ทำ
2. การตรวจผล: Waterfall มีจุดส่งมอบตามช่วง; Agile ตรวจงานที่ทำได้ในแต่ละรอบ
3. การเปลี่ยนแปลง: ทั้งสองวิธีเปลี่ยนได้ แต่ต้นทุนและขั้นตอนอนุมัติไม่เท่ากัน
4. ความเสี่ยง: Waterfall เหมาะเมื่อข้อกำหนดและข้อจำกัดค่อนข้างนิ่ง; Agile ช่วยเปิดข้อผิดพลาดของสมมติฐานเร็วขึ้นเมื่อผู้ใช้ให้ข้อมูลได้

ภาพที่ 1: จุดต่างสำคัญคือเวลาที่ทีมได้เห็นซอฟต์แวร์จริงและนำข้อค้นพบกลับไปปรับแผน

ตัวอย่างสมมติสองโครงการ

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

เกณฑ์เลือกที่ใช้ได้จริง

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

สำหรับรายงานเปรียบเทียบ

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

อ่าน Agile คืออะไร และ SDLC คืออะไร หรือดู บริการพัฒนา Web Application

วิเคราะห์กรณีศึกษาเพื่อนำไปเขียนรายงาน

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

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

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

แหล่งข้อมูลประกอบ

• IBM: Agile vs. Waterfall — การเปรียบเทียบรูปแบบการจัดโครงการ
• Principles behind the Agile Manifesto — หลักการพัฒนาแบบรับข้อมูลกลับ