เมื่อกล่าวคำอำลากับ Agile

• การทบทวนเชิงวิพากษ์ที่มองว่าวิธีการ Agile ซึ่งครอบงำอุตสาหกรรมซอฟต์แวร์มาอย่างยาวนาน แท้จริงแล้วเป็นเพียงหลักการที่คลุมเครือและการนำปัญหาที่ถูกแก้ไปแล้วมาห่อใหม่
• ภาพความขัดแย้งกับ Waterfall แทบจะเป็นภาพลวงตา และแนวคิดหลักอย่าง การพัฒนาแบบวนซ้ำและการมีส่วนร่วมของลูกค้า ก็ถูกเสนอไว้แล้วในงานวิจัยตั้งแต่ทศวรรษ 1970
• Agile ถูกนิยามมาโดยตลอดว่าเป็นเพียง สิ่งตรงข้ามกับโมเดล Waterfall แต่ข้อจำกัดของโมเดล Waterfall ก็เป็นเรื่องที่รู้กันอย่างกว้างขวางอยู่แล้วตั้งแต่ทศวรรษ 1970
• เมื่อไม่นานมานี้ จากการมาถึงของ large language model (LLM) ทำให้ Spec-Driven Development กลับมามีความสำคัญอีกครั้ง และการพัฒนาแบบยึดเอกสารเป็นศูนย์กลางกำลังกลับมาโดดเด่น
• คำขวัญของ Agile ที่ว่า “ซอฟต์แวร์ที่ใช้งานได้สำคัญกว่าเอกสารที่ครอบคลุม” กำลังเปลี่ยนไปเป็นความเข้าใจใหม่ว่า “เอกสารที่ครอบคลุมคือสิ่งที่สร้างซอฟต์แวร์ที่ใช้งานได้”
• ถึงเวลาแล้วที่จะก้าวข้ามความคลุมเครือที่ Agile ทิ้งไว้ และ กลับไปสู่หลักการที่ชัดเจนกับแนวทางเชิงวิศวกรรม

---

> RIP Agile, we hardly knew ye.
> And I mean that literally - because no one was ever clear on what it was.
> ลาก่อน Agile ขอให้พักผ่อนอย่างสงบ เราแทบไม่เคยรู้จักคุณจริง ๆ เลย
> และพูดอย่างตรงตัวก็คือ เพราะไม่เคยมีใครอธิบายได้ชัดว่าแท้จริงแล้วมันคืออะไร

ปัญหาเรื่องตัวตนของ Agile

• Agile เป็นกระแสขนาดใหญ่ที่แผ่ไปทั่วทั้งอุตสาหกรรมซอฟต์แวร์ แต่ในความเป็นจริงมันเป็นแนวคิดที่แพร่หลายออกไปทั้งที่ความหมายยังไม่ชัดเจน
• ทุกครั้งที่มีคนตั้งคำถาม ก็มักจะได้รับคำตอบซ้ำ ๆ ว่า “นั่นไม่ใช่ Agile ที่แท้จริง”
• หากลองอ่าน Agile Manifesto (2001) จริง ๆ จะพบว่าแทบไม่มีแนวทางที่เป็นรูปธรรม และอยู่ในระดับของ ถ้อยคำคติพจน์ที่คลุมเครือ เช่น “ความร่วมมือกับลูกค้าสำคัญกว่าการต่อรองสัญญา”
• หลักการอย่าง “ยินดีต้อนรับการเปลี่ยนแปลงความต้องการแม้อยู่ในช่วงท้ายของการพัฒนา” นั้น ไม่สมจริงในเชิงธุรกิจ
• ภายใต้คำกล่าวอ้างเรื่อง “True Agile” ปัญหาที่เกิดขึ้นในทางปฏิบัติมักถูกปัดออกไปว่าไม่เกี่ยวกับตัว manifesto
• หากอุตสาหกรรม Agile เองก็ไม่ได้ปฏิบัติ Agile อย่างถูกต้อง และตัว manifesto ก็แทบไม่มีความหมายชัดเจน ก็ยิ่งน่าสงสัยว่าแก่นแท้ของ Agile คืออะไรกันแน่

"ผีของ Waterfall หลอกหลอนวงการซอฟต์แวร์"

• Agile ถูกนิยามมาตลอดด้วยสิ่งที่มัน ไม่ใช่ นั่นคือ Waterfall โดยมีโครงตรรกะว่าถ้าไม่ทำ Agile ก็แปลว่ากำลังทำ Waterfall และ Waterfall ใช้ไม่ได้ผล
• แต่ความจริงที่ว่า Waterfall ใช้ไม่ได้ผลนั้น เป็นเรื่องที่รู้กันอยู่แล้วตั้งแต่ 1970 และ Winston W. Royce ก็ได้อธิบายเหตุผลไว้อย่างชัดเจน
• Royce เสนอทางเลือกไว้ว่า ให้เริ่มจากการออกแบบโปรแกรม, สร้าง software prototype เพื่อขัดเกลาความต้องการ, และให้ลูกค้ามีส่วนร่วมอย่างเป็นทางการ ลึกซึ้ง และต่อเนื่อง
• ทั้งหมดนี้ภายหลังถูกอ้างว่าเป็นนวัตกรรมของ Agile แต่ความจริงคือมันถูกเขียนไว้แล้วตั้งแต่ ปี 1970 ซึ่งเป็นปีถัดจากการลงจอดบนดวงจันทร์
• เชิงอรรถ 1: โปรแกรมเมอร์ของ Apollo Guidance Computer สร้างความสำเร็จระดับนั้นได้อย่างไร ทั้งที่ไม่มี story point และไม่เคยรู้หลักการอย่าง “ความใส่ใจอย่างต่อเนื่องต่อความเป็นเลิศทางเทคนิคช่วยเสริมความคล่องตัว”

งานวิจัย Bell-Thayer ปี 1976 กับประวัติศาสตร์ของการพัฒนาแบบวนซ้ำ

• งานวิจัยของ Bell และ Thayer ในปี 1976 เป็นเอกสารที่ ใช้คำว่า "Waterfall" เป็นครั้งแรก และตัวคำนี้เองก็ถูกใช้ในฐานะตัวอย่างของสิ่งที่ไม่ควรทำ
• ข้อสรุปจากการศึกษาเชิงประจักษ์ในงานนั้นคือ ข้อบกพร่องของความต้องการจะถูกค้นพบในกระบวนการพัฒนาซอฟต์แวร์ ก็ต่อเมื่อพยายามให้การออกแบบตอบสนองความต้องการนั้นจริง ๆ
• การพัฒนาแบบวนซ้ำไม่ใช่เรื่องใหม่ และได้ถูกขัดเกลาต่อเนื่องมาหลายสิบปีก่อน Agile
• แม้ก่อนที่ manifesto จะอ้างว่าปลดปล่อยวงการ แต่ Waterfall ก็ไม่ใช่เทคโนโลยีล้ำสมัยอยู่แล้ว และก็แทบไม่มีใครสงสัยอย่างจริงจังถึงประสิทธิผลของ requirements และ specification

การกลับมาของ Spec-Driven Development และหลังยุค Agile

• ด้วยการแพร่หลายของ large language model (LLM) กระแสที่โปรแกรมเมอร์หันกลับมาเขียน specification กำลังชัดเจนขึ้นอีกครั้ง
  • LLM เปราะบางต่ออินพุตที่กำกวม ดังนั้นการอธิบายปัญหาให้ชัดเจนจึงกลายเป็นวิธีที่ช่วยให้สร้างโค้ดที่ถูกต้องได้
  • หาก Agile เน้นว่า “ซอฟต์แวร์ที่ใช้งานได้สำคัญกว่าเอกสารที่ครอบคลุม” การพัฒนาแบบขับเคลื่อนด้วยสเปกก็เสนอข้อความตรงกันข้ามว่า “เอกสารที่ครอบคลุมสร้างซอฟต์แวร์ที่ใช้งานได้”
• Royce เคยชี้ไว้แล้วตั้งแต่ปี 1970 ว่า “การจัดทำเอกสาร, specification, และการออกแบบ คือแนวคิดเดียวกันจนกว่าจะเริ่มเขียนโค้ด และถ้าเอกสารแย่ การออกแบบก็จะแย่ด้วย”
  • เขาเน้นด้วยว่า หากไม่มีเอกสาร ก็ไม่มีการออกแบบ
• เมื่อย้อนกลับไปดูงานวิจัยในปี 1970 และ 1976 จะเห็นได้ว่า Agile Manifesto ปี 2001 ไม่ได้มอบข้อค้นพบใหม่ใด ๆ
  • Agile เพียงแทนที่แนวทางเชิงวิศวกรรมเดิมด้วย นิยามที่คลุมเครือและการห่อเชิงพาณิชย์ โดยไม่ได้สร้างความก้าวหน้าที่แท้จริง
  • บทความวิชาการของวิศวกรเหล่านั้นกลับมีความหมายที่ชัดเจนกว่ามาก
• ในช่วงเวลาที่การพัฒนาซอฟต์แวร์ยังคงเปลี่ยนแปลงและวิวัฒน์ต่อไป ตอนนี้อาจถึงเวลาที่ต้อง ส่ง Agile เข้าสู่หน้าประวัติศาสตร์และเปลี่ยนไปสู่มุมมองใหม่
  • เราควรกลับไปหาหลักการที่ชัดเจนและวิธีคิดเชิงวิศวกรรมที่จริงจัง ซึ่งวิศวกรในอดีตได้ทิ้งไว้ให้

[savvykang]

ผมไม่เข้าใจว่าทำไมถึงยกย่องวิธีวิทยาเหล่านี้ราวกับเป็นคัมภีร์ ผู้เขียนต้นฉบับเองก็แค่มีแนวทางต่างออกไป แต่ผมคิดว่าในแง่ความยึดติดแบบหลักการตายตัวก็ไม่ได้ต่างกัน

[tekart]

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

[unknowncyder]

เห็นด้วยครับ

แค่เรื่องการทลายการตัดสินใจแบบบนลงล่าง และการปรับปรุงซ้ำ ๆ ในรอบสั้น ๆ ก็ทิ้งสารที่มีความหมายไว้ให้เราอย่างมากแล้ว (แน่นอนว่าเทคนิค/เครื่องมือการจัดการโปรเจ็กต์ก็เช่นกัน)

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

[lukeskywalker]

เห็นด้วยครับ Agile ยังคงใช้ได้อยู่ ดูเหมือนเป็นคำพูดลอย ๆ ของคนที่ไม่เคยอยู่หน้างานจริงมากกว่า

[dopeflamingo]

เป็นบทความที่งี่เง่านะครับ ประเด็นสำคัญคือเราต้องเขียน spec. ให้มีความ agile ตั้งแต่ตัวมันเอง... Agile คือการปรับตัวให้เข้ากับการเปลี่ยนแปลงของความต้องการจากลูกค้าอย่างรวดเร็ว

เพราะมีคนที่มีความเข้าใจผิดและจินตนาการแบบครึ่ง ๆ กลาง ๆ เกี่ยวกับ Agile แบบนี้แหละ ทั้ง Agile และวัฒนธรรมการพัฒนาถึงได้ค่อย ๆ ผิดเพี้ยนไป

[snisper]

การเขียน spec ให้เป็น agile เองนี่หมายความว่าอะไรกันแน่?

1. เขียน spec แบบคร่าว ๆ
2. เขียน spec ตามที่ลูกค้าบอกมา
3. ถ้าความต้องการของลูกค้าเปลี่ยน ก็อาศัยพลังของเครื่องมือเพื่อดูแลรักษาให้สามารถแก้ spec ได้อย่างรวดเร็ว
4. เขียน spec แบบ agile

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

[dopeflamingo]

นี่เป็นเนื้อหาพื้นฐานที่มักปรากฏอยู่ในหนังสือเกี่ยวกับแนวทาง Agile ส่วนใหญ่ เช่น Extreme Programming ของ Kent Beck และ Scrum ของ Jeff Sutherland เป็นต้น จะดูจาก user story ก็ได้ คนส่วนใหญ่มักไม่ค่อยรู้ว่ารากฐานของ Agile คือสปรินต์ระยะสั้นและเดโมเพื่อให้ปรับตัวต่อความต้องการของลูกค้าได้อย่างรวดเร็ว

[lukeskywalker]

ข้อ 3 และ 4 ครับ การเขียนสเปกให้ละเอียดนั้นลงลึกได้ไม่สิ้นสุด สิ่งสำคัญคือมันมีระดับที่เหมาะกับแต่ละองค์กร จากประวัติการสร้างบริการที่ประสบความสำเร็จ เท่าที่ผมเข้าใจ ใน 99% ของกรณี ประเด็นสำคัญคืออย่าทุ่มแรงไปกับการเขียนสเปกให้เป๊ะเกินไปจนเกินจำเป็น คือไม่จมอยู่กับสิ่งนั้นนั่นเอง ดูได้จากกรณีอย่าง Summoners War, Dungeon & Fighter, Zigbang, Lineage ว่ามันถูกสร้างขึ้นมาอย่างไร

[nvkzrx]

ถ้าวัฏจักรแบบวอเตอร์ฟอลหมุนครบได้ภายในวันเดียวล่ะ?

[aciddust]

ช่วงนี้ผมเห็นกรณีแบบนี้บ่อยขึ้น

[osw0124]

น่ากลัวตรงที่ดูเหมือนจะเห็นบ่อยที่สุดเลย...

[myc0058]

ในประเทศเรา Agile ไม่ได้เป็นอะไรมากไปกว่าเครื่องมือไว้กดดันกำหนดการของนักพัฒนา

[galadbran]

ในบางเกณฑ์ ทุกคนก็ล้วนเป็น Agile กันทั้งนั้นนะครับ ไม่รู้ว่าเคยมีช่วงเวลาไหนที่เราปล่อยขึ้นใช้งานได้เร็วและรับฟีดแบ็กได้เหมือนยุคนี้หรือเปล่า

[fnwinter]

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

[flowkater]

บทความนี้เองก็ไม่ Agile!

[develosopher]

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

[snisper]

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

[willom2c]

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

[snisper]

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

[develosopher]

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

[GN⁺]

ความคิดเห็นจาก Hacker News

• ผมสังเกตเห็นปรากฏการณ์ที่น่าสนใจผ่าน Agile
  ถ้าล้มเหลว ก็มักจะถูกตีความว่า “ทำไม่มากพอ”
  ผมเห็นรูปแบบเดียวกันนี้ในคลาวด์, ไมโครเซอร์วิส, นโยบายรัดเข็มขัด และเรื่องอื่น ๆ — สาเหตุของความล้มเหลวมักถูกอธิบายว่าเป็นเพราะ ลงมือไม่พอ ไม่ใช่เพราะแนวทางนั้นอาจผิดตั้งแต่ต้น

  • Agile-ism ที่ผมชอบคือคำจำกัดความที่ว่า “กระบวนการที่เหมาะกับทีมคือ Agile”
    ถ้าทีมลองทำ Agile แล้วไม่เวิร์ก ก็จะมีตรรกะแบบป้องกันตัวว่า “นั่นไม่ใช่ Agile ที่แท้จริง” สุดท้าย Agile ก็กลายเป็นแนวคิดที่ไม่มีวันล้มเหลวได้
  • รากของความสับสนคือการเข้าใจ Agile ว่าเป็น process
    Agile Manifesto พูดถึงแค่คุณค่าและหลักการเท่านั้น ปัญหาคือวัฒนธรรมองค์กรที่พยายามยัดมันให้กลายเป็น process แบบฝืน ๆ
  • รูปแบบนี้เห็นได้ในศาสนาและ จิตวิญญาณ เช่นกัน
    โครงสร้างที่ทำให้เราหันกลับมามองตัวเองเมื่อเกิดความล้มเหลวไม่ใช่เรื่องแย่เสมอไป ในแง่ที่กระตุ้นให้เกิดการทบทวนตนเองแทนการโทษปัจจัยภายนอก มันอาจเป็นระบบที่ดีต่อสุขภาพก็ได้
  • บริษัทส่วนใหญ่ไม่ได้ต้องการ Agile อย่างแท้จริง
    roadmap ที่สัญญาไว้กับลูกค้า กับการตอบสนองอย่างยืดหยุ่นนั้นอยู่ร่วมกันได้ยาก ความจริงคือองค์กรที่ยึดแผนเป็นศูนย์กลางแค่เลียนแบบ Agile เท่านั้น
  • ประเด็นนี้ทำให้นึกถึง Agentic software development
    ถ้าล้มเหลว ก็จะสรุปกันว่า “น่าจะต้องใช้เอเจนต์ให้มากกว่านี้” ฟังดูเหมือนมุกที่ว่า “token ไม่มีทางพออยู่แล้ว”

• ผมเริ่มกลัว การทำ Agile ให้เป็นทางการเกินไป
  ผมเคยบริหารทีมขนาด 40 คนได้สำเร็จ แต่ Agile ที่แท้จริงสรุปได้แค่สี่ประโยค — ผู้คน, ซอฟต์แวร์ที่ใช้งานได้, ความร่วมมือกับลูกค้า, และการตอบสนองต่อการเปลี่ยนแปลง
  ปัญหาคือ ‘Agile ตัวใหญ่’ กลับกลายสภาพเป็น process ที่ไม่ยืดหยุ่น

  • ทั้งสี่ประโยคนี้ยอดเยี่ยม แต่ในความเป็นจริงมันเวิร์กดีเฉพาะกับ ทีมเล็ก
    พอคนมากขึ้น การจัดแนวเป้าหมายก็ยากขึ้น และสุดท้ายก็ต้องพึ่งการควบคุมกับขั้นตอนต่าง ๆ
  • ผมเห็นโปรเจกต์นับไม่ถ้วนที่เรียกตัวเองว่า “Agile” แต่จริง ๆ แล้วเป็น Waterfall
  • องค์กรส่วนใหญ่รับเอาเฟรมเวิร์กอย่าง Scrum, SAFE ราวกับเป็นคัมภีร์
    ถึงขั้นจำกัดสิทธิ์ในการสร้าง ticket ซึ่งห่างไกลจากความยืดหยุ่นมาก
  • คำพูดที่ว่า “ซอฟต์แวร์ที่ใช้งานได้สำคัญกว่าดอกสาร” กลับให้ผลตรงข้ามใน ระบบที่ความปลอดภัยเป็นสิ่งจำเป็น
    ถ้าเอกสารไม่เพียงพอ การบำรุงรักษาก็แทบเป็นไปไม่ได้ และสุดท้ายก็ไหลไปสู่ การพัฒนาแบบ YOLO
  • เวลาผมเห็นองค์กรพูดว่า “เราทำงานแบบ Agile” แล้วเอา แผนภาพ SAFE มาโชว์ ผมก็อดขำไม่ได้

• Agile ในบริษัทใหญ่ที่ผมเคยอยู่คือ คำโกหก
  เพื่อนร่วมงานคนหนึ่งเคยพูดว่า “ถ้าทำงานของ sprint ถัดไปล่วงหน้า ก็จะส่งทันตลอด”
  นั่นหมายความว่า Agile ทำงานเป็น ระบบผลิตตัวชี้วัด มากกว่าจะเป็นระบบทำงานจริง

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

• มันคุ้มค่าที่จะกลับไปอ่านต้นฉบับของ Agile Manifesto
  นั่นคือจุดร่วมเพียงหนึ่งเดียวที่ทุกคนเห็นพ้องกัน เราต้องไม่ลืมว่า Waterfall ก่อนยุค Agile นั้นเลวร้ายแค่ไหน

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

• อย่างที่ Kent Beck พูดไว้ใน “Extreme Programming” Agile คือความพยายามจะหลีกเลี่ยง ทรราชย์ของความเชื่อว่าตัวเองมองเห็นทุกอย่างได้หมด
  Waterfall ในอดีตพยายามคาดการณ์ทุกอย่างตั้งแต่ช่วงออกแบบ และเพิกเฉยต่อการเรียนรู้กับ feedback
  แต่เมื่อเวลาผ่านไป พิธีกรรมและรูปแบบ ของ Agile กลับเข้ามาบดบังแก่นแท้
  ผมยังชอบ Agentic programming อยู่ แต่สุดท้ายสิ่งสำคัญคือ บทบาทของมนุษย์ในการเชื่อมโยงบริบท

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

  • การพัฒนาแบบวนซ้ำมีมานานพอ ๆ กับประวัติศาสตร์มนุษย์
    Agile เป็นเพียงรูปแบบหนึ่งของแนวคิดนั้น ปัญหาคือมีการนำไปใช้แบบแย่ ๆ มากมาย
    ผลิตภัณฑ์ที่ดีสุดท้ายก็มาจากวงจร สเปก → เรียนรู้ → แก้ไข
  • agile ตัวเล็กหมายถึงการพัฒนาอย่างยืดหยุ่น แต่ Agile ตัวใหญ่กลับเพี้ยนไปเป็น ลัทธิพิธีกรรมแบบ Scrum
    ขั้นตอนอย่าง Backlog Grooming, Sprint Review กลับยิ่ง กดการเปลี่ยนแปลง

• การพัฒนาแบบอิงสเปก น่าจะอยู่ได้ไม่นาน
  การสร้างซอฟต์แวร์ที่ใช้งานได้แล้ววนปรับซ้ำยังเร็วกว่า — ซึ่งสุดท้ายก็คือการหวนกลับไปหา Agile

  • แต่ทุกวันนี้เป็นโครงสร้างที่ เอเจนต์เป็นคนเขียนสเปก แล้วมนุษย์ค่อยตรวจทาน
    คุณภาพของสเปกดีขึ้น และการรีวิวก็ง่ายกว่าการอ่านโค้ด
  • ยังมีความพยายามอย่าง Compound Engineering ที่พยายามหาจุดกึ่งกลางระหว่างสเปกกับการทำซ้ำ
    ดู GitHub link

• ใน manifesto ไม่มีคำอย่าง Daily Standup หรือ Agile Coach
  แก่นของมันคือ “อย่า micromanage โปรแกรมเมอร์”
  หรือก็คือ จงมอบสภาพแวดล้อมและความไว้วางใจให้กับคนที่มีแรงจูงใจ

• ผู้ก่อตั้งอย่าง Kent Beck, Martin Fowler เดิมตั้งใจให้มันเป็น แนวทางที่ยืดหยุ่น
  แต่เมื่อเวลาผ่านไปมันก็ถูก ทำให้เป็นธุรกิจ และเกิดผู้ติดตามแบบศรัทธาสุดโต่งขึ้นมา จนความสับสนยิ่งหนักกว่าเดิม
  ความสำเร็จหรือไม่สำเร็จสุดท้ายขึ้นอยู่กับ ความสามารถและทัศนคติของผู้คน
  ความยาวของ sprint ก็ควรปรับตามสถานการณ์ และถ้าไม่มีสเปก ทีมก็ควรช่วยกันสร้างขึ้นมาเอง
  ต่อให้เป็นยุค AI ถ้ายังมี คนที่ใช้ Agile อย่างชาญฉลาด มันก็ยังใช้ได้อยู่

• ผมสงสัยว่า “เขียน spec” จริง ๆ หมายถึงอะไร
  ทุกโปรเจกต์ Agile ที่ผมเคยทำมี เอกสารการออกแบบ และ ticket ก็ต่อยอดมาจากเอกสารนั้น
  การพัฒนาแบบอิง ticket โดยไม่มีเอกสารน่าจะเป็นนรกแน่ ๆ

  • ใช่เลย ของเราก็มีเอกสาร แต่ เต็มไปด้วยเรื่องไม่จริง
    ทุกคนตีความเข้าข้างตัวเองหมด
  • แต่ถ้า “เอกสารการออกแบบคือจุดเริ่มต้น” แบบนั้นก็ ไม่ใช่ Agile ที่แท้จริง
    วิธีที่ยึด ticket เป็นศูนย์กลางกลับใกล้เคียง Agile แบบบริสุทธิ์มากกว่า
  • ใน Agile ที่แท้จริง การพูดคุยกับผู้ใช้ คือแหล่งความจริง
    Agile ปลอมทำเหมือนว่าเอกสารที่ PO หรือ PM เขียนขึ้นคือความจริง
  • ในฐานะคนเขียนบทความเอง ผมขอบอกว่าท้ายที่สุดแล้วชื่อ “Agile” จะเอาไปติดตรงไหนก็ได้
    วิธีที่คุณพูดมานั่นแหละใกล้เคียงที่สุดกับความหมายของ ‘การเขียนสเปก’ ที่ผมตั้งใจจะสื่อ