🛑 “เปิดแผล Agile”…เมื่อ AI ทำให้ความคล่องตัวปลอมๆ ซ่อนตัวไม่อยู่

🛑 “เปิดแผล Agile”…เมื่อ AI ทำให้ความคล่องตัวปลอมๆ ซ่อนตัวไม่อยู่

(ทำไมองค์กรที่เกลียดการวางแผน อาจกำลังสร้างความเร็วแบบหลงทางในยุค Agentic AI?)

ขออนุญาตพูดความจริงที่หลายคนในวงการ Tech น่าจะรู้สึกอยู่ลึกๆ แต่ไม่ค่อยอยากพูดออกมาเท่าไร

“หลายองค์กรไม่ได้ทำ Agile เพื่อให้ทีมคล่องตัวขึ้นจริง แต่ทำ Agile เพื่อให้ตัวเองรู้สึกดีขึ้นกับการไม่มีแผนที่ชัดเจน”

เรามี Daily Stand-up

มี Sprint Planning

มี Retrospective

มี Board

มี Story Point

มี Scrum Master

มี Product Owner

มี Ceremony ครบถ้วน

เหมือนเปิด Checklist จากตำรา แต่พอถามว่า

“ลูกค้าต้องการอะไรจริง?”

“ระบบนี้ควรวางโครงสร้างอย่างไร?” “

ใครเป็นคนตัดสินใจสุดท้าย?”

หรือ “เรากำลังสร้างสิ่งนี้เพื่อแก้ปัญหาอะไร?”

ห้องประชุมกลับเงียบกว่าที่ควรจะเป็นบ่อยๆ?

“นี่คือภาพลวงตาที่ AI กำลังเปิดแผลให้เห็นชัดขึ้นเรื่อยๆ”

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

พูดให้ตรงกว่านั้นคือ “Agile ไม่ได้ตาย”

แต่ Agile ปลอมๆ ที่ใช้คำว่า “Iteration” เป็นข้ออ้างของการไม่คิดให้ลึก กำลังถูก AI เปิดโปงอย่างหนักมากในยุคนี้

⸻

📉 เมื่อ Agile กลายเป็น Ceremony Economy

ถ้าเรากลับไปดู Agile Manifesto ดั้งเดิม หนึ่งในประโยคที่ทรงพลังที่สุดคือ “Individuals and interactions over processes and tools” หรือการให้คุณค่ากับคนและการปฏิสัมพันธ์ มากกว่ากระบวนการและเครื่องมือ

แต่เรื่องตลกร้ายคือ “หลายองค์กรกลับสร้างระบบที่ตรงกันข้ามกับประโยคนี้แทบทุกอย่าง”

* Daily Stand-up กลายเป็น Mini Status Meeting ที่ทุกคนรายงานใส่หัวหน้า

* Sprint Planning กลายเป็นเวทีต่อรองงานที่ไม่มีบริบทพอ

* Planning Poker กลายเป็นโรงละครเล็กๆ ของตัวเลขที่ดูเหมือนแม่นยำแต่แทบไม่มีใครอธิบายได้ว่า Story Point นั้นสะท้อนความเสี่ยง ความซับซ้อน หรือความไม่รู้กันแน่?

* Retrospective กลายเป็นพิธีกรรมระบายความในใจที่จบด้วย Action Item เดิมๆ ซึ่งไม่มีใครตามไปแก้จริง

Ceremony จะมีประโยชน์ ถ้ามันช่วยให้ทีมเห็นปัญหาเร็วขึ้น ตัดสินใจดีขึ้น และเรียนรู้ร่วมกันเร็วขึ้น แต่เมื่อ Ceremony กลายเป็นเป้าหมายในตัวเอง มันจะเริ่มเผาพลังของคนในองค์กรเปล่าๆ?

ตลกร้าย คือ องค์กรมักเริ่มวัดว่าทีม Agile หรือยัง?

“จากการมีประชุมต่างๆ ครบหรือไม่?” มากกว่า “วัดว่าทีมส่งมอบคุณค่าจริงหรือเปล่า?”

นี่คือสิ่งที่ผมขอเรียกว่า “Ceremony Economy” คือเศรษฐกิจของพิธีกรรมที่ทำให้ทุกคนดูยุ่ง ดูมีระบบ ดูมีจังหวะ แต่ไม่ได้แปลว่ากำลังสร้างของที่ถูกต้อง

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

⸻

🚧 AI ไม่ได้ฆ่า Agile แต่มัน “ฆ่าข้ออ้างของ Agile ปลอม”

สิ่งที่ AI กำลังเปลี่ยน ไม่ใช่แค่ความเร็วของการเขียนโค้ด แต่มันกำลังเปลี่ยนสมการของการพัฒนา Product ทั้งระบบ

เมื่อก่อนทีมอาจใช้เวลาหลายวันหรือหลายสัปดาห์ในการสร้าง Prototype แรก วันนี้ AI-assisted development และ Agentic Coding ทำให้การสร้างเวอร์ชันแรกเร็วขึ้นมาก

สิ่งที่เคยเป็นคอขวดในฝั่ง Engineering เริ่มขยับไปอยู่ตรงอื่นแทน โดยเฉพาะคำถามว่า “เราควรสร้างอะไร?” และ “ทำไมสิ่งนี้ถึงควรถูกสร้าง?”

Andrew Ng เคยชี้ประเด็นไว้ชัดมากว่า เมื่อ Agentic Coding เร่งความเร็วของการเขียนซอฟต์แวร์ได้ คอขวดใหม่จะย้ายไปที่ Product Management หรือความสามารถในการตัดสินใจว่าจะสร้างอะไร (LinkedIn - https://www.linkedin.com/posts/andrewyng_grok-raises-questions-meta-poaches-talent-share-7351623554741751808-7FvT)

นี่คือจุดที่ Agile ปลอมเริ่มลำบาก

เพราะถ้าองค์กรเคยใช้ Sprint เพื่อหลบการตัดสินใจยากๆ เคยใช้คำว่า “เดี๋ยวค่อย Iteration” เพื่อเลี่ยงการคิด Architecture เคยใช้ Backlog เพื่อซ่อนความไม่ชัดของ Strategy หรือเคยใช้ Retrospective เพื่อพูดเรื่องเดิมซ้ำๆ โดยไม่เปลี่ยนระบบจริง AI จะทำให้ความบกพร่องเหล่านี้เห็นชัดขึ้นทันที

เพราะ AI ไม่ได้ต้องการแค่ Task

AI ต้องการ Context

และนี่คือสิ่งที่หลายองค์กรไม่เคยสร้างไว้อย่างจริงจัง

⸻

🧠 “AI หิว Context” แต่หลายองค์กรยังป้อนเศษขนมปัง

คนที่ใช้ AI Coding Assistant หรือ Agentic AI อย่างจริงจังจะเริ่มเห็นความจริงข้อหนึ่งเร็วมาก นั่นคือ

“คุณภาพของผลลัพธ์ไม่ได้ขึ้นกับความฉลาดของโมเดลอย่างเดียว แต่ขึ้นกับคุณภาพของ Context ที่เราป้อนให้มันด้วย”

ถ้าคุณป้อน User Story สั้นๆ แบบแยกส่วน เช่น “ในฐานะผู้ใช้ ฉันต้องการกดปุ่ม เพื่อให้เกิดผลลัพธ์นี้” AI อาจช่วยสร้างโค้ดได้จริง แต่โค้ดนั้นมักทำงานภายใต้บริบทแคบๆ ไม่เห็นข้อจำกัดของระบบใหญ่ ไม่รู้ Integration Point ไม่เข้าใจ Data Model ไม่เห็น Security Requirement และไม่เข้าใจเหตุผลทางธุรกิจที่อยู่หลังฟีเจอร์นั้น

แต่ถ้าคุณให้บริบทที่ดี เช่น Architecture ของระบบ ข้อจำกัดของโดเมน โครงสร้างข้อมูล Dependency Map รูปแบบการทดสอบ Coding Standard และเป้าหมายทางธุรกิจ AI จะทำงานได้ต่างออกไปมาก มันไม่ได้แค่ “เขียนโค้ด” แต่มันเริ่มช่วยคิดเชื่อมโยงข้ามระบบ ดัก Edge Case และเสนอ Trade-off ได้ดีขึ้น

นี่คือเหตุผลที่คำว่า Context Engineering กำลังสำคัญขึ้นมากในโลก Software Development ยุคใหม่

งานเขียนทางเทคนิคของ Anthropic อธิบายว่า Context Engineering คือการคัดสรรและจัดการข้อมูลที่เหมาะสมให้โมเดลใช้ระหว่าง inference ไม่ใช่แค่การเขียน Prompt เท่านั้น (Anthropic - https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)

งานวิจัยปี 2025–2026 เกี่ยวกับ AI coding assistants ก็เริ่มศึกษาอย่างจริงจังว่าการให้ project context เช่น project structure, coding guidelines, workflows, interface specifications และ constraints ส่งผลต่อคุณภาพของงาน AI อย่างไร? (arXiv - https://arxiv.org/abs/2510.21413)

แปลเป็นภาษาคนทำงานคือ

“ถ้าองค์กรไม่มี Context ที่ดี AI ก็ไม่มีทางสร้างผลลัพธ์ที่ดีอย่างสม่ำเสมอ”

และนี่คือปัญหาใหญ่ของ Agile แบบที่ถูกใช้ผิด

เพราะหลายทีมถูกฝึกให้คิดเป็นชิ้นเล็กๆ จนลืมเชื่อมภาพใหญ่

เราแยก Story จนเล็ก แต่ลืม System

เราแตก Task จนละเอียด แต่ลืม Architecture

เราวิ่ง Sprint ได้เร็ว แต่ลืมถามว่า Sprint เหล่านี้กำลังพา Product ไปทางไหน?

“AI จึงไม่ได้ทำให้ Agile ใช้ไม่ได้”

แต่มันทำให้ Agile ที่ไร้บริบท ใช้ยากขึ้นเรื่อยๆ

⸻

🔥 Iteration ไม่ใช่ใบอนุญาตให้ “ไม่คิด”

ผมต้องให้เครดิต Agile เรื่องหนึ่งอย่างชัดเจน หลักการส่งมอบบ่อย การเปิดโอกาสให้ product รับ feedbak และปรับตัวจากการเรียนรู้จริง ยังเป็นหลักการที่ถูกต้องมาก โดยเฉพาะในโลกที่ลูกค้าเปลี่ยนเร็ว ตลาดเปลี่ยนเร็ว และความไม่แน่นอนสูง

แต่สิ่งที่ผิดคือการเอาหลักการนี้ไปตีความแบบมักง่าย เช่น

“เดี๋ยวไว้ Sprint หน้าค่อยแก้”

“เดี๋ยวลูกค้า Feedback แล้วค่อยคิด”

“เดี๋ยวค่อย Refactor”

“เดี๋ยวค่อยจัด Data Model ให้ดี”

“เดี๋ยวค่อยออกแบบ Flow ใหม่ หลัง MVP ออกแล้ว” เป็นต้น

คำว่า “เดี๋ยวค่อย” ถ้าใช้ถูก มันคือการลดความเสี่ยงของการลงทุนเกินจำเป็น แต่ถ้าใช้ผิด มันคือการผัดวันประกันพรุ่งทางสถาปัตยกรรม

และในยุค AI ความมักง่ายแบบนี้อันตรายกว่าเดิมมาก

เพราะเมื่อ AI ช่วยสร้างโค้ดได้เร็วขึ้น ความผิดพลาดจากการออกแบบผิดก็แพร่กระจายเร็วขึ้นเช่นกัน

ถ้าคุณวาง Data Model ผิด AI จะช่วยคุณสร้างโค้ดจำนวนมากบน Data Model ที่ผิด

ถ้าคุณตั้ง Boundaries ของระบบไม่ชัด AI จะช่วยคุณสร้าง Integration ที่ดูเหมือนเดินได้ แต่ซ่อน Technical Debt ไว้ทั่วระบบ

ถ้าคุณไม่เข้าใจ Domain ให้ดี AI จะช่วยคุณผลิตฟีเจอร์ที่ดูเรียบร้อย แต่ไม่แก้ปัญหาลูกค้าจริง

“AI ทำให้ Output ถูกลง แต่ทำให้ Judgment แพงขึ้น”

นี่คือประโยคที่ Product Leader และ Tech Leader ต้องจำให้ขึ้นใจ

เพราะในโลกที่การสร้างของเร็วขึ้น สิ่งที่สำคัญที่สุดอาจไม่ใช่การสร้างให้เร็วกว่าเดิม แต่คือการคิดให้ชัดกว่าเดิมว่าอะไรควรถูกสร้างตั้งแต่แรก

⸻

🏗️ สิ่งที่ควรกลับมา ไม่ใช่ Waterfall แต่คือความเคารพต่อการออกแบบ

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

สิ่งที่ควรกลับมา ไม่ใช่ Waterfall

“แต่คือความเคารพต่อการออกแบบ”

การวางแผนไม่ใช่ศัตรูของความคล่องตัว การเขียน Spec ไม่ใช่ศัตรูของการเรียนรู้ และ Architecture ไม่ใช่สิ่งที่ทำให้ทีมช้าเสมอไป ตรงกันข้าม ถ้าวางให้ดี มันคือการสร้าง Context ที่ทำให้ทีมและ AI วิ่งได้เร็วขึ้นอย่างปลอดภัยกว่าเดิม

โลกยุค AI ต้องการวิธีทำงานที่ผมอยากเรียกว่า “Specification-first, Iteration-on-feedback”

เริ่มจากการทำความเข้าใจปัญหาให้ชัด เขียนบริบทให้ดี ระบุ Constraint ให้ครบ วาง Architecture ให้พอแข็งแรง สร้าง Decision Record ให้ทีมและ AI ใช้ร่วมกัน แล้วค่อยสร้างของจริงอย่างรวดเร็วเพื่อรับ Feedback จากโลกจริง

ไม่ใช่คิดทุกอย่างให้จบแบบ Waterfall แต่ก็ไม่ใช่โยนความไม่ชัดเข้า Sprint แล้วหวังว่า Retrospective จะช่วยล้างบาปให้เราได้ทุกสองสัปดาห์

⸻

⚙️ จาก Agile Ceremony สู่ AI-Native Operating Model?

องค์กรที่อยากอยู่รอดในยุค AI คำถามที่ควรถามคือ

“วิธีทำงานของเราช่วยให้มนุษย์และ AI มีบริบทที่ดีพอหรือยัง?”

“ทีมของเราตัดสินใจเรื่องสำคัญเร็วพอหรือยัง?”

“Product Strategy ถูกแปลงเป็น Prioritization จริงหรือยัง?”

“Architecture Decision ถูกบันทึกและเรียนรู้ต่อหรือยัง?”

“ลูกค้าให้ Feedback ในจุดที่สำคัญจริงหรือยัง?”

และ “Ceremony ที่เรามีอยู่ ช่วยให้เกิด Outcome หรือแค่ช่วยให้ปฏิทินดูเต็ม?”

นี่คือการเปลี่ยนจาก Agile Ceremony ไปสู่ AI-Native Operating Model

ในโลกใหม่ บาง Ceremony อาจยังอยู่ แต่ต้องพิสูจน์คุณค่าตัวเองใหม่ Daily ต้องช่วย Unblock จริง ไม่ใช่รายงานใส่หัวหน้า Planning ต้องช่วยเชื่อม Strategy, Constraint และ Capacity จริง ไม่ใช่แค่ต่อรอง Story Point Retrospective ต้องนำไปสู่การเปลี่ยนระบบจริง ไม่ใช่แค่ Post-it สีสวยบน Miro

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

เพราะในยุค AI บทบาทที่อยู่รอดไม่ได้วัดจากการคุมกระบวนการ แต่วัดจากการลดความฝืดขององค์กร

⸻

🧭 วิธีทำทำงานให้รอดในยุค AI?

สำหรับองค์กรที่ “ไม่อยากติดกับดัก Agile Ceremony และไม่อยากกลับไป Waterfall แบบเก่า” เพราะในยุค AI คนที่ชนะไม่ใช่คนที่แตก Task ได้เล็กที่สุด แต่คือคนที่ให้บริบทได้ดีที่สุด

1. “เริ่มจากปัญหาลูกค้า” - ไม่ใช่เริ่มจาก Backlog ถ้ายังตอบไม่ได้ว่าลูกค้าเจ็บตรงไหนและทำไมต้องแก้ตอนนี้ อย่าเพิ่งให้ AI ช่วยสร้างอะไรเพิ่ม เพราะมันอาจช่วยให้เราสร้างสิ่งที่ไม่จำเป็นได้เร็วขึ้น

2. “เลิกวัดความสำเร็จจากจำนวน Story ที่ปิด จำนวน Sprint ที่วิ่ง หรือจำนวน Feature ที่ปล่อย” - ให้วัดว่าลูกค้า ทีม หรือธุรกิจดีขึ้นจริงหรือไม่

3. “AI ต้องการเรื่องราวและเหตุผล ไม่ใช่แค่ Task สั้นๆ” - ทีมควรมีบริบทของระบบ เป้าหมาย ข้อจำกัด ลูกค้า และเหตุผลของการตัดสินใจ เพื่อให้ทั้งคนและ AI ทำงานบนความเข้าใจเดียวกัน

4. “Architecture กลับมาสำคัญมากขึ้น” ไม่ใช่เพื่อสร้างเอกสารให้ audit ตรวจสอบ แต่เพื่อป้องกันไม่ให้ AI ขยายความผิดพลาดทางเทคนิคเร็วเกินควบคุม

5. “Iteration ยังจำเป็น แต่ต้องเป็น Iteration ที่ได้รับ feedback และเรียนรู้จาก Evidence จริง” - ไม่ใช่แค่เปลี่ยนตามเสียงดังที่สุดในห้องประชุม

6. “ให้ทีมทดลองเร็วได้ แต่ต้องมี Guardrail” - ทั้งเรื่อง Data, Security, Cost, Quality และ Maintainability เพราะ AI ทำให้การทดลองถูกลง แต่ความเสี่ยงจากการทดลองมั่วก็ขยายเร็วขึ้นเช่นกัน

7. “ใครตัดสินใจเรื่องอะไร ต้องชัดเจน” - ถ้า Decision Rights ยังคลุมเครือ AI จะช่วยให้ทีมสร้าง Option ได้มากขึ้น แต่ไม่ได้ช่วยให้องค์กรเลือกได้ดีขึ้น

นี่คือกระบวนการแบบที่ควรอยู่ต่อในยุค AI ไม่ใช่ Agile ที่นับจำนวน Ceremony แต่เป็นกระบวนการที่ให้บริบท ชัดเจน และเรียนรู้เร็วจริง

⸻

✨ จุดจบของลัทธิเกลียดการวางแผน

สิ่งที่กำลังจะตาย ไม่ใช่ Agile

แต่คือความเกลียดชังการวางแผนที่ถูกแต่งตัวในชื่อ Agile

สิ่งที่กำลังจะสูญพันธุ์ ไม่ใช่การทำงานแบบ Iterative

แต่คือการใช้คำว่า Iteration เป็นข้ออ้างของการไม่คิด ไม่ออกแบบ ไม่ตัดสินใจ และไม่รับผิดชอบต่อผลกระทบระยะยาว

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

“ในโลกยุคก่อน AI ความไม่ชัดอาจค่อยๆ เผยตัวหลังผ่านไปหลาย Sprint”

แต่ในโลกยุค AI ความไม่ชัดจะถูกขยายเป็นโค้ด เอกสาร Prototype และระบบจำนวนมากภายในเวลาไม่นาน

เพราะฉะนั้น งานของผู้นำยุคนี้ไม่ใช่การเลือกข้างระหว่าง Agile กับ Waterfall แบบศาสนาเดิมๆ

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

“เพราะความเร็วที่ไม่มีบริบท ไม่ใช่ความคล่องตัว มันคือการหลงทางด้วยความมั่นใจสูงขึ้นกว่าเดิม”

#วันละเรื่องสองเรื่อง

#Agile

#AgileTransformation

#AgenticAI

#AITransformation

#ProductDevelopment

#SoftwareEngineering

#ExecutiveMindset

#TechTransformation

#ProductLeadership

#ContextEngineering

⸻

📚 Source / Reference

* Agile Manifesto — ใช้เป็นฐานคิดเพื่อแยก “Agile ดั้งเดิม” ออกจาก “Agile แบบพิธีกรรม” โดยเฉพาะหลักการให้คุณค่ากับบุคลากรและการปฏิสัมพันธ์มากกว่ากระบวนการและเครื่องมือ

* Andrew Ng / DeepLearning.AI — แนวคิดเรื่อง Product Management Bottleneck ใช้เป็นฐานคิดว่า เมื่อ Agentic Coding เร่งความเร็วการเขียนซอฟต์แวร์ได้ คอขวดใหม่จะย้ายไปที่การตัดสินใจว่าจะสร้างอะไร

* Anthropic Engineering — บทความ Effective Context Engineering for AI Agents ใช้เป็นฐานคิดว่า AI Agent ต้องการการจัดการ Context ที่ดี ไม่ใช่แค่ Prompt สั้นๆ หรือ Task ที่ถูกตัดออกจากบริบทระบบ

* งานวิจัย Context Engineering for AI Agents in Open-Source Software — ใช้เป็นฐานคิดเรื่องการให้บริบทกับ AI Coding Agent ผ่านข้อมูลอย่าง project structure, build/test instructions, code style และ policy เฉพาะของโปรเจกต์

* งานวิจัย An Empirical Study of Developer-Provided Context for AI Coding Assistants in Open-Source Projects — ใช้เป็นฐานคิดว่า context ของโปรเจกต์ เช่น conventions, guidelines, project information และ examples มีบทบาทสำคัญต่อคุณภาพของการใช้ AI Coding Assistant

* Block / Jack Dorsey layoff reports จาก Axios และ Investopedia — ใช้เป็นบริบทของกระแสการปรับโครงสร้างองค์กรเทคในยุค AI โดยไม่สรุปเกินหลักฐานว่า Agile เป็นสาเหตุของการเลย์ออฟ

* การสังเคราะห์ของผู้เขียน เพื่ออธิบายวิธีทำงานแบบ AI-Native ที่ไม่หลงพิธีกรรม Agile และไม่ถอยกลับไป Waterfall แบบเก่า