การตายอย่างช้าๆ และเจ็บปวดของ Agile และ Jira
(ehandbook.com)"เมื่อ Agile ไม่ได้เป็น Agile อีกต่อไป ก็ถึงเวลาที่ Agile จะหายไปพร้อมกับ Jira"
- วงจรการพัฒนาซอฟต์แวร์ยาวนานขึ้นเรื่อยๆ ทีมเทคนิคใหญ่ขึ้นเรื่อยๆ ต้องใช้แอปในการบริหารการพัฒนามากขึ้นเรื่อยๆ คนที่ลงมือเขียนโค้ดจริงๆ กลับน้อยลงเรื่อยๆ และในช่วงเวลาที่สั้นลงเรื่อยๆ ความคืบหน้าระหว่างจุดตรวจสอบต่อเนื่องกลับลดลงเรื่อยๆ
- Agile เริ่มผิดพลาดตั้งแต่ตรงไหน?
- Agile เป็นวิธีการที่พัฒนาขึ้นในช่วงต้นทศวรรษ 2000 เพื่อเป็นทางเลือกแทนกระบวนการพัฒนาซอฟต์แวร์แบบเดิมที่หนักไปทางเอกสาร
- แต่ปัจจุบัน Agile กำลังกลายสภาพเป็นวิธีการบริหารโครงการที่ซับซ้อนแบบเดิม
ภาวะเทคโนโลยีพองตัว (Tech Bloat) คือปัญหาหลัก
- เหตุผลหลักที่หลายคนเลิกใช้หรือกำลังจะเลิกใช้ Agile คือภาวะเทคโนโลยีพองตัว
- ภาวะเทคโนโลยีพองตัวเป็นศัตรูของทุกบริษัทเทคโนโลยี และยังเป็นความเสี่ยงต่อบริษัทที่ไม่ใช่เทคโนโลยีแต่มีทีมพัฒนาภายในหรือจ้างภายนอก
- ภาวะเทคโนโลยีพองตัวต่างจากหนี้ทางเทคนิค แต่ก็ก่อให้เกิดหนี้ทางเทคนิคได้
- อาการของภาวะเทคโนโลยีพองตัวมีดังนี้:
- คุยกับลูกค้าแบบวนซ้ำอยู่เรื่อยๆ แต่ไม่เคยกลายเป็นผู้เชี่ยวชาญด้านพฤติกรรมลูกค้า
- ประเมินและประเมินใหม่เรื่องเดดไลน์และวันส่งมอบอย่างไม่หยุดหย่อน
- ลังเลอย่างมากที่จะเริ่มกระบวนการพัฒนาจนกว่ารายละเอียดทุกอย่างจะถูกบันทึกเป็นเอกสาร
- เกิดแรงจูงใจให้เริ่มจากงานที่ง่ายที่สุดแทนงานที่เสี่ยงที่สุด
ผลลัพธ์อันสับสนของภาวะเทคโนโลยีพองตัว
- เอกสารที่เพิ่มขึ้น
- การทำเอกสารที่ไม่ได้ติดตามแค่ว่าพัฒนาอะไรและทำไม แต่รวมถึงติดตามว่า "พัฒนาอย่างไร" ก็แทรกซึมเข้าไปในกระบวนการ
- "วิธีการ" นี้กลายเป็นจุดสนใจของการอัปเดตสถานะ ทำให้ทีมต้องประเมินใหม่ตลอดเวลาว่าทีมกำลังทำงานกันอย่างไร
- ทีมใช้เวลาถกกันว่าทำไมงานยังไม่เสร็จ มากกว่าจะใช้เวลาทำงานให้เสร็จ
- การตั้งเดดไลน์ถี่ขึ้น
- การมีเดดไลน์มากขึ้นตามจุดตรวจสอบที่ถี่ขึ้น ทำให้เกิดการบริหารแบบจุกจิกในทุกจุดเปลี่ยนของกระบวนการที่โดยเนื้อแท้แล้วเป็นงานสร้างสรรค์
- สิ่งนี้สวนทางกับการผลิตซอฟต์แวร์คุณภาพ เพราะทุกอย่างต้องถูกส่งตามกำหนด ไม่ว่างานจะถูกทำได้ดีแค่ไหนก็ตาม
- ความสงสัยไม่สิ้นสุดจากกระบวนการประเมินใหม่
- ความสงสัยอย่างต่อเนื่องในช่วงการประเมินใหม่ทำให้ไม่สามารถประกาศแนวปฏิบัติที่ดีได้ ไม่สามารถกำจัดความสูญเปล่า และไม่สามารถมองเห็นการประหยัดต่อขนาดได้
- การบริหารกระบวนการผลิตแบบจุกจิก
- เมื่อฟีเจอร์โดยรวมเสร็จไปประมาณ 30% มันก็มักจะไม่ใช่เรื่องสำคัญอันดับต้นๆ อีกต่อไป
- องค์กรจะตกอยู่ในวงจรมรณะที่ต้องผลิตตามโรดแมป โดยไม่คำนึงว่าโรดแมปนั้นยังนิยามการสร้างผลิตภัณฑ์ที่ประสบความสำเร็จอยู่หรือไม่
- ผลลัพธ์สุดท้าย
- ผลิตภัณฑ์ต้องแบกรับน้ำหนักของความต้องการลูกค้าที่หลากหลายและขัดแย้งกัน
- ฟีเจอร์มักออกสู่ตลาดช้า และถูกส่งมอบในรูปแบบและลำดับที่เหมาะกับทีมเทคนิคที่สุด ไม่ใช่แบบและลำดับที่เหมาะกับตลาดที่สุด
- สุดท้ายทีมขาย/การตลาดก็เริ่มต่อต้าน เพราะไม่รู้ว่าตัวเองกำลังขายอะไร และลูกค้าก็ไม่รู้ว่ากำลังซื้ออะไร
- จากนั้นองค์กรก็เข้าสู่การปรับโครงสร้างครั้งใหญ่
โลกต้องการซอฟต์แวร์ที่เบาและทำเรื่องสำคัญให้ดีขึ้น ไม่ใช่ซอฟต์แวร์ที่มีฟีเจอร์มากขึ้น
- นี่ไม่ใช่แนวคิดใหม่ แต่เป็นแนวคิดที่ทุกวิธีการมักค่อยๆ ห่างออกไปในท้ายที่สุด
- สุดท้ายผู้คนก็เริ่มถามว่าวิถีแบบ Toyota นั้น Toyota พอหรือยัง และสิ่งนั้นก็กลายเป็นงานที่สร้างงานเพิ่มขึ้นอีก
- ตอนนี้ Agile ได้กลายเป็น PMP ที่มีชื่อเรียกน่ารักขึ้น การประชุมสั้นลง และมีกฎมากขึ้น
- ปัญหาไม่ได้อยู่ที่แนวคิดของ Agile แต่อยู่ที่การนำไปใช้และการขาดภาวะผู้นำที่ควบคุมมันได้
- มันเป็นปัญหาของผู้บริหารระดับกลางที่โฟกัสกับเดดไลน์มากกว่าประโยชน์ใช้สอย โฟกัสกับการตัดลดมากกว่าการเติบโต และโฟกัสกับการประหยัดมากกว่าความก้าวหน้า
ความเห็นของ GN⁺
- Agile กำลังกลายเป็นระบบราชการและพิธีรีตองมากขึ้นสวนทางกับเจตนาเดิม จนกลายเป็นปัจจัยที่ทำให้การพัฒนาซอฟต์แวร์ช้าลง
- ภาวะเทคโนโลยีพองตัวไม่ใช่ความเสี่ยงที่ Agile ต้องระวังเท่านั้น แต่เป็นความเสี่ยงที่ทุกองค์กรเทคโนโลยีควรใส่ใจ
- การทำเอกสาร การตั้งเดดไลน์ และการบริหารแบบจุกจิก อาจทำให้ทั้งคุณภาพและความเร็วลดลงได้
- แก่นแท้ของ Agile คือการยึดลูกค้าเป็นศูนย์กลาง การทำงานร่วมกัน และความยืดหยุ่น ดังนั้นแทนที่จะยึดติดกับรูปแบบ ก็ควรย้อนกลับไปทบทวนหลักการ
- สิ่งสำคัญในการพัฒนาซอฟต์แวร์ไม่ใช่การมีฟีเจอร์มากขึ้น แต่คือการทำฟังก์ชันหลักให้ดี
- วัฒนธรรมองค์กรและภาวะผู้นำเป็นตัวชี้ขาดความสำเร็จหรือล้มเหลวของ Agile ดังนั้นผู้จัดการสายเทคนิคควรให้ความสำคัญกับเรื่องนี้
- ดูเหมือนว่าจะถึงเวลาต้องมองหาวิธีการใหม่ๆ ที่ก้าวข้าม Agile แล้ว
17 ความคิดเห็น
แม้ต้นฉบับจะเป็นบทความแบบเสียเงินเลยยังอ่านไม่จบ แต่คิดว่าน่าจะขัดเกลาสำนวนแปลอีกสักหน่อยครับ
"Agile ไม่เป็น Agile อีกต่อไปแล้ว ดังนั้นถึงเวลาที่ Agile จะหายไปพร้อมกับ Jira"
=> "Agile หยุด being agile แล้ว ดังนั้นถึงเวลาที่ Agile จะหายไปพร้อมกับ Jira"
มีแนวคิดเรื่องการแยกใช้ Agile ตัวพิมพ์ใหญ่กับ agile ตัวพิมพ์เล็กอยู่ครับ
และแม้ being agile กับ doing agile จะเชื่อมโยงกัน แต่ก็มองว่าเป็นคนละเรื่องกัน
being agile by doing agile.
เหตุผลที่นำ Agile มาใช้สำคัญนะครับ เอามาใช้เพื่อให้พัฒนางานได้ดีขึ้นงั้นเหรอ? ผมทนดูพวกคุณอู้ไม่ได้หรอก เดี๋ยวผมจะคอยดูเองว่าขยันกันแค่ไหน ใช้กันด้วยความคิดแบบนี้นี่แหละ สุดท้ายมันก็กลายเป็นนรก
ถึงขั้นนี้ก็น่าจะต้องมีเช็กลิสต์ตรวจการปฏิบัติตาม Agile แล้วล่ะครับ
ก่อนจะไปถึงประเด็นว่าเป็น Agile หรือ waterfall หากผู้คน วัฒนธรรม และสภาพแวดล้อมยังเหมือนเดิม ต่อให้ยัดเยียดวิธีการพัฒนาสุดล้ำแค่ไหน สุดท้ายก็มีแต่จะถูกทำให้กลายเป็น K-OOO เท่านั้น
ถ้าแทบจะไม่มีการเปลี่ยนแปลงความต้องการเลย จากมุมของคนพัฒนาแล้ว วิธีแบบ Waterfall ก็เป็นวิธีที่สบายจริง ๆ นั่นแหละ ตราบใดที่ไม่มีการเปลี่ยนแปลงความต้องการเท่านั้น…
Agile แบบ K ไม่มีการทบทวนประเมินใหม่เลยด้วยซ้ำ.!
ลูกค้า: ปุ่มบนหน้านี้น่าจะวางตรงนี้ดีกว่านะ
นักพัฒนา: (แปลว่าต้องอดนอนทั้งคืนสินะ ทั้งที่ยังมีงานใหม่อีก)
ลูกค้า: น่าจะต้องมีปุ่มอยู่ในอีกหน้าจอหนึ่งนะ
นักพัฒนา: (ใครก็ได้ช่วยใช้วิชาแยกร่างที) ครับ ฮ่าๆ..
ลูกค้า: ยังไม่เสร็จอีกเหรอ ตามกำหนดการมันควรเสร็จหมดแล้วไม่ใช่เหรอ?
นักพัฒนา: (ช่วยด้วย) ครับ..;;
แทบไม่มีกรณีที่นำ Agile ไปใช้อย่างเป็น Agile และใช้งานต่อเนื่องในระยะยาว
ดูเหมือนว่าองค์กรส่วนใหญ่จะลงเอยด้วยงานแบบ Waterfall ที่มีเดดไลน์สั้นๆ
ปัญหาไม่ใช่ Agile แต่เป็นคนที่ทำมันต่างหาก ไม่ว่าจะเอาวิธีการแบบไหนมา สุดท้ายก็ขึ้นอยู่กับว่าคนที่ทำจะทำอย่างไร ผมคิดว่า Agile ไม่ใช่วิธีการ แต่ใกล้เคียงกับแนวคิดในการพัฒนาผลิตภัณฑ์ให้เติบโตเป็นรอบๆ มากกว่า ถ้าพลาดประเด็นนี้ไปแล้วมัวแต่วางแผนกับทำรีโทรสเปกทีฟแบบไม่ลืมหูลืมตา ก็ดูเหมือนจะเป็นการเสียเวลาเปล่าๆ
นึกว่ามีแค่ Agile แบบเกาหลีเท่านั้นที่เป็นแบบนี้ ที่แท้ก็เป็นปรากฏการณ์ระดับโลกเหมือนกันนี่เอง
รู้สึกเหมือนกำลังเอาแต่ตีผิดจุดอยู่เรื่อย ๆ นะ... มันควรจะตัดสินจากการดูว่าตรงกับปฏิญญา Agile หรือไม่มากกว่า...
แม้แต่ uncle bob ซึ่งมีส่วนร่วมใน Agile Manifesto ก็เข้าใจปัญหานี้ตั้งแต่เนิ่นๆ และได้ตีพิมพ์หนังสือ Clean Agile ในปี 2019 เพื่อแก้ไข Agile ที่ผิดเพี้ยน แต่ปัญหาแบบนี้ก็ยังคงดำเนินต่อไปนะครับ/ค่ะ ส่วนตัวผม/ฉันคิดว่าเป็นเพราะ Agile ไม่มีแนวทางมาตรฐาน และใช้คำที่คลุมเครืออย่าง "วัฒนธรรม" จึงอยากให้มีการนำเสนอแนวทางมาตรฐานที่เป็นรูปธรรมครับ/ค่ะ
ผู้เขียนคงจะโต้แย้งว่า ไม่ว่าวิธีการแบบไหนก็ควรถูกทิ้งไปทันทีที่มันกลายเป็นระบบราชการ
เห็นด้วยครับ/ค่ะ ดูเหมือนว่ากำลังมีคนทำ Agile แบบผิดๆ แล้วก็บอกว่า Agile นั้นผิดมากขึ้นเรื่อยๆ
ขณะเดียวกันก็อดคิดไม่ได้ว่า แม้จะผ่านมาเป็นเวลาพอสมควรแล้ว แต่การสั่งสมแนวปฏิบัติให้ดีนั้นก็ยังยาก ซึ่งก็ดูเหมือนเป็นสิ่งที่หลีกเลี่ยงไม่ได้เหมือนกัน
วนไปวนมาก็กลับไปเป็นแบบเดิมหรือเปล่า?
ความเห็นจาก Hacker News
ปัญหาของ Agile
หลักการของ Agile Manifesto
แก่นสำคัญของ Agile
ความยืดหยุ่นของ Agile
ความเห็นเกี่ยวกับ JIRA
ที่มาของ Agile
สถานะปัจจุบันของ Agile
ปัญหาของ JIRA
การประยุกต์ใช้ Agile