แวะมาฟัง Agile Thailand 2025 #ATH2025

สำหรับงานปีนี้จัดที่ตึก K+ ของ KBTG แถวๆสามย่านมิตรทาวน์ครับ เดินทางสะดวกเลยนั่ง 40 หลับตืนๆมาฟังนึมากถึงงานครับ ปีนี้มาใน Concept เดิม unconference + Open Space Principle + Law of Two Feet

Opening KBTG

Speaker พิชญา เพ็ญจันทร์ / ธนัญญา พีรพัฒนาการ

KBTG เป็น บ เทค ที่มา Support ในส่วนของงาน KBank และการ R&D ด้วยนะ อย่างตัว เหมียวจด / ขุนทอง / coral / kubix ที่ให้จองเหรียญบุพเพ / AINU เป็นเบื้องหลังการ scan หน้า qr ไว ๆ และมี service ให้คนนอกใช้ด้วย / Future you - Digital twin ของเราเอง รวมถึงงาน R&D ด้าน Tech อื่นๆ อย่าง insure tech ด้านประกัน

โดย Agile เป้นส่วนนึงในการขับเคลี่ยน มองว่าเหมือน Oxygen ในการขยับทำ Digital Tranformation ตั้งแต่ก่อน 2020 เริ่มจาก

• Early adoption เอายาก project เล็กๆ
• Transformation Lead เอา practice ที่ดี adopt ไปทั้งส่วน tech automation agile
• Expand with the new way of thinking เน้น productivity / velocity

นอกจากนี้

• Deepen Maturity - connect วิธีการ แต่ละทีมเข้าด้วยกัน และ metric driven ใาในการปรัยปรุง
• Continuous Learning แนวคิด flight level และมีทำ product ตัวภายในมาช่วย อย่าง MLP1 เอา
  - Agentic AI มาช่วยใน SDLC หาข้อมูลที่เกี่ยวข้อง มาสรุปให้ + อื่นๆด้วยนะ
  - และ Chai Lai มาช่วย Gen Test Case / Test Data / Test Script (Given When Then) เหมือนเห็น Tiktok KBTG

และมีงาน KBTG Techtopia ตอน 2 SEP 2025 แงกดไม่ทันบัตร Early

Quickly But Not Hurry

Speaker Thor Verapat Chantravannakul

- ทำไมมาแชร์เรื่องนี้

เพราะงานที่ทำอยู่ Innovestx มีการกำกับดูแลโดยภาครัฐ อย่าง กลต และ BOT อีกที Tech support Business ที่ไปไว อย่างตอนนี้เป็นส่วนหลักทรัพย์ + Crypto เลยกลายเป็นว่าเราต้องเริ่ม dev ใน requirement ที่มีอยู่

คำว่า Agile ตอนนี้ ไม่เป็น Buzzword  ของ IT ทาง ฝั่ง Managment รู้จักระดับนึงแล้ว แต่แน่ใจว่าเรารู้จักในนิยามเดียวกัน อาจจะเข้าใจว่ามันทำให้เร็ว และ Cost ลดลงแต่ Agile ไปแล้วยังมีเคสที่เกิดปัญหา อาทิ เช่น

• Develop จน Delivery แล้ว เจอว่าตรวจ Security Check ไม่ผ่าน !!
  ทางแก้
  - หาคน approve + การ rework ตามแก้เวลาที่กำหนดไว้ เพื่อ Issue Security ปัญหาตาม Severity
  - ส่วนระยะยาวต้องดึงเอา Security เข้ามาตั้งแต่ช่วงแรก Shift Left จนมีคำ DevSecOps เข้ามา
• Develop จน Delivery แล้ว เจอว่าไม่ผ่าน Compliance ของ Regulator เป็นต้น
  ทางแก้
  - เชิญ Compliance มาคุย พูดคุยกับเค้าบ่อยๆ ให้เจ๊งในกระดาษ แก้แล้วค่อยทุ่ม resource ลงมาทำ

- "Be quick, but don't hurry"

คำพูดของ John Wooden โค๊ชทีมบาสเกตบอล โดยมีความเชื่อว่า

• quick ความรวดเร็วเกิดจากการเตรียมตัวที่ดีและความตั้งใจที่จะไม่ทำผิดพลาด
• ต่างกับ hurry ที่ทำเร็วเหมือนกัน และลนลาน

- ตัวอย่างของ quick + hurry

บางทีความไว ไม่เกิดจากการเร่งรีบทำ แต่เกิดจากลดการทำซ้ำ (Rework) ได้เท่าไหร่ และ การ Rework ถ้าเราเลือกช่วงเวลาที่เหมาะสม เมื่อเทียบกับสถานการณ์นั้นๆ ยกตัวอย่าง เช่น Line ที่เอา Feature ขึ้นมาก่อน ให้ทันตลาด แล้วค่อยปรับปรุง ไม่ได้แย่เสมอไปนะ

นอกจากนี้เราต้องดูให้เป็นว่าตอนนี้ quick หรือ hurry

📌 ถ้ามันเร็ว คำถามเร็วแบบยั่งยืนไหม หรือเป็นความเร็วแบบที่เข้าใจผิด เช่น

• งานมันถูกตีความเหมือนกัน เลยทำให้การประมาณเวลาผิด งานมันเสร็จแหละ แต่ทีม Stress ด้วย รวมถึงการเป็นการสร้างมาตรฐานใหม่ ที่ไม่ถูกต้อง
• ทางแก้ ต้องมีคุย DoD ให้ชัดเจนก่อน งานก่อนหน้า กับงานใหม่มันมีจุดที่ไม่เหมือนกันนะ การประเมินแบบยังไม่เหมาะ ต้องมาปรับ

📌 เร็วไป ต้องมีช่วงหยุด (Pause) เพื่อมาปรับ Align Tune ให้ไปทางเดียวกัน เช่น

• Refactor Code มาแก้ Technical Debt ทีมีอยู่
• แก้ปัญหา Security ที่พบใน Pipeline
• มาจับเข่าคุยกันทั้งในส่วน Biz + Biz และ Biz + Tech
• รวมถึงการ Pause เพื่อรอคอยจังหวะที่ดีกว่า เช่น ทิศทางตลาด / regulator / ผู้บริหาร

📌 Be quick ยังไง ?

• Clarify before motion รู้ก่อนว่าจะทำอะไร
• Discovery ศึกษา ก่อนส่ง Before Delivery
• Inclusion เอามาเข้ามาคุยกัน
  ก่อน Escalation คือ ตัว Escalation ไปหาคนที่ใหญ่กว่ามันใช้ได้ แต่ความสัมพันธ์จะไม่ดี จะกลายเป็นปัญหาเมืององค์กรไป
• Pausing early saves weeks later
  - มาจาก bottom up
  - หรือ คนที่ facilitate ต้อง raise ไป อย่าง agile coach / pm เมื่อเห็นอะไรตุๆ แล้ว

- 3 Thing You can try tomorrow

📌 ลองตั้งคำถามก่อน

• Ask "what do we still need to learn" ต้องหัด Deal เพิ่ม
  Before "when will be done"
• Bring compliance + คนอื่นๆที่เกี่ยวข้องกับเรา เช่น Security มาก่อน first not last
• Treat Discovery as Investment พอเรามีประสบการณ์ จะมีข้อมูลมากขึ้น และแผนจะชัดเจน สมเหตุสมผลขึ้นด้วย

📌 นอกจากนี้ยังมีคำถามให้คิดทิ้งท้าย

• เคยรีบจนเสียของไหม ?
• การ ชะลอเพื่อให้ชัด ถูกมองว่าช้าไหม ?
• มีไหมที่ ช้า เกินไป เพราะกลัวจะถูกมองว่า รีบ

- Recap QA เล็กน้อย

• Mid Managment ส่งที่รับเรากดทั้งจากบน และล่าง การที่ส่งผ่านจากบนลงล่างไปตรง อาจจะทำให้ culture เสีย และระบบเสีย การเสนอเปลี่ยนแปลง เริ่มยากจุดเล็กที่ปรับ culture ได้ และ คนเริ่มเจ็บเสมอ ฟังแล้วนึกถึง Automate Test ที่ตัวเองดันใน บ เลย ล้มมาหลายรอบเหมือนกัน
• ถ้า req มานิดเดว แต่ timeline fixed จัดการยังไง ?
  - รู้สัก 30-40% ก่อน และรู้มติ แต่เราต้องเอ๊ะ และถามคำถามในส่วนที่สงสัยก่อน จะได้เพิ่มความชัดเจนให้เรา
  - ใน agile daily meeting ช่วยเปิดโอกาส ให้เราช่วยเริ่มถาม และ learn ได้
• รับมือการ change req ยังไง นอกจาก commit sign ยืนยัน + uat แล้ว
  - Analyst thinking - ต้องคิดเผื่อเค้า แย้งกะลูกค้าก่อน การ commit sign ยืนยัน + uat มันเป็นอีกทางนึงเท่านั้น พยายามเพิ่ม feedback cycle กับ stakeholder / req owner มากขึ้น ให้เค้าเอ๊ะ
• Pause เอามาทำอะไร
  - แก้เรื่อง Norm ที่เข้าใจผิดจาก Hurry เช่น เรื่อง Estimation ต้องมา align ให้ตรงกัน ว่ารายละเอียด มันเป็นยังไง ตกลง DoD (Definition of Done) มาช่วย ส่วน analyst ดู DoR (Definition of Ready)
  - ปรับจาก backlog / tech lead มา improve หรือ team member มาแนะนำ ถ้าไปถาม PO อาจจะได้ Feature
• Data Story Telling สำคัญ แต่ต้อง Base มาจาก Fact จริงๆ จะได้ไม่เกิดปัญหาในการทำงานภายหลัง
• องค์กรไม่ว่าจะเล็ก หรือใหญ่ สิ่งที่ complex เรื่องคน การเมืองในองค์กร

ชอบ Session นี้มาตอบชัดเจน และเข้าใจง่ายมากครับ

From Agile to AI: Revolutionize Software Development

Speaker Vachara Suwansophon

ปัญหาที่เจอ AI เอามาช่วย เกิด productivity จริง แต่ไม่ต่อเนื่อง

- 2 อย่างที่เรารู้ Generative AI กับ Develop ตอนนี่้

1. 40% ของ Code Commit มาจาก AI ข้อมูลจาก GitHub Copilot ณ 2024 ตอนนี้ปี 2025 ตัวเลขเพิ่มขึ้น เนื่องจาก

• Model เก่งขึ้น และ MCP (มองเป็นล่าม ให้เรา chat กับ ปลายทางที่ต้องกาาได้ อย่าง GitHub Jira Figma)
• Coding Agent อย่าง GitHub Copilot / cursor แจกงานให้ ai ช่วย
• ตอนนี้ AI ขึ้นมาอยู่ในระดับ junior developer แล้วนะ

2. AI มันมีข้อมูลเยอะ (Vast Information) แต่ Limit Context มหใเกิดปัญหา หลอน hallucination

• ถ้าจะแก้ปัญหา better Context / Specific Prompt

- ที่นี้ Palo-IT เสนอ Gen-E2 Approach

Gen-E2 Approach เอา AI ของเดิมมาใช้ แต่มาช่วยเน้น Context ให้รู้มากขึ้น เข้าใจบริบทมากขึ้น โดยเริ่มต้นจาก

• ขยายการใช้ AI จาก individual level ไปเป็น project level
  - เดิมต่างคนต่างใช้ AI ของตัวเอง
  - ให้ทุกคนใช้ AI ตัวเดียวกัน และใช้ Context + ข้อมูลร่วมกัน เช่น spec / code / design / wireframe แล้ว ให้ AI มันเรียน เป็นแหล่งข้อมูล
• ให้ Prompt Engineering มาช่วยลดงาน Manual Work ให้ทำ AI Draft + Human Check ในส่วน
  - User Story
  - Design
  - Dev
  - Doc
  - Test ทั้งในมุม quality/security

ตอนนี้ AI มาช่วย 90-95 % โดยมันจะช่วยเปลี่ยนวิธีการทำงาน อย่างการศึกษาของ McKinsey พอ AI มาช่วยงาน end to end software แล้ว ทีม dev เอาเวลาไปทำอย่างอื่นได้

นอกจากนี้ Benefit

• Time to market
• Deliver customer value sooner
• More good ideas see the light of day บางอันรีบไป cost มันสูง แต่เราเอา ai มัน gen ได้ iterate faster มี velocity มากขึ้น

ผลได้ที่งานเสร็จไวขึ้น 55% โดยที่ Quality / Security ยังไม่ตกลง โดยจุดที่กราฟพุ่งเยอะ เพราะ มันเป็นงานที่เริ่มที่ Pattern ทำซ้ำ เช่น กลุ่ม Login / CRUD เป็นต้น

From Traditional to AI Enable - ลด Loop การทำงาน ดึงคน + AI ในด้านนั้นๆ เข้ามาทำด้วยกัน พยายามเอา Blocker ออกไป

นอกจากนี้มุม Coding มีคำว่า

• Vibe Coding โดยที่เจ้า prompt + code ถ้าต้องการผลที่ดีขึ้น ทำ requirement analysis+ ให้ context + instruction
• Context Engineering - เป็นแนวคิดว่า ไม่ Vibe แบบเราเราต้องมากำกับเยอะ เน้นการจัดข้อมูล + Context ให้พร้อมใช้ รวมถึงมีการแชร์ Context ในแต่ละ Step

Resource: Slide

ชวนคุย Software Architecture เกี่ยวกับ Agile ยังไง ?

Speaker Bas

สำหรับ Session นี้ตอนแรกจะไปฟัง แต่มีของพี่เดียร์มาที่ห้องใหญ่ + ขี้เกียจวิ่งขึ้นลงด้วย เลยตามมาฟัง Live ปิดท้ายแทน

- Software Architecture คือ อะไร

📌 Foundation ของ Variable Product ที่ช่วย Scale + Maintain + Support Enhancement
📌 การวางโครงสร้างรับ Biz
📌 เป็นภาพรวมของระบบ และเหมือนเป็น Guideline ในการวางของ

- ถ้าจากหนังสือ Foundation of Software Architecture //เล่มนี้ยังอ่านไม่จบ 555

📌 Architecture Characteristic - เข้าใจว่าอะไรที่ไม่ใช่ Functional Requirement พวก -ility พวก Availability / Scalability / Performance เป็นต้น
📌 Architecture Structure- ช่วยให้คนทำงานไปทางเดียวกัน
📌 Design Principle- มีโครงสร้างยังไง Code และความสัมพันธ์ของแต่ละส่วน ดูแลได้ยาว
📌 Decision - การตัดสินใจยุคนั้นเป็นยังไง

- Software Architecture เกี่ยวกับ Agile ยังไง ?

📌 การ Trade Off ทั้งส่วน Security vs Performance หรือ แม้ส่วนของเงิน
📌 การแบ่งทีม คนล้อตาม Architecture
📌 เกี่ยวเมื่อ Software มันใหญ่ขึ้น มี Dependency กัน และถ้า Requirement overlap ระหว่าง Component + Owner ที่แก้
📌 มันช่วยให้เห็น Feedback และเปลี่ยนแปลงได้ไว
📌 เกี่ยวเพราะมีผลกับ Quality

- แล้วเรารู้ได้ไง ว่า Software Architecture มัน Agile ตอบกับความต้องการได้

📌 ถ้าวางได้ดี รู้จุดแก้ไว และกระทบน้อย เช่น การแยก Layer Controller / Service / Repository
📌 นอกจากนี้ยังมีอีกมุม

• ช่วง Build From Zero (Green Field) ส่วน Architecture จุดที่ต้อง Focus ช่วงแรก ต้องการคนที่มี Know How / Knowledge ที่ โดยถูกคุมด้วย Cost / Time ต้องมีการแชร์ความรู้
• ช่วง Add On Feature - ต้องมีการ PoC ลองก้่อนให้เห็นปัญหาใน Sprint แรกๆ

📌 Iterative + Incremental มองว่า Architecture เติมโตได้ตาม Sprint ตาม Evolutionary Architecture แบบ TDD โดย Evolutionary Architecture มีการคุมเงื่อนไขไว้ + Governance ต่างๆ เช่น

• คุมจาก SonarQube มุม performance / security / maintainability ทำ Guard Rail ได้
• เอา Performance Test เอาไว้ในส่วน Regression Test
• PII Data มีหลุดไปไหมในแต่ละ Sprint มีการ Encrypt + ยืนยันตัวตนไหม + ใคร Access + เอาไปฝากที่ไหนได้บ้าง ทำ Threat Modelling (มี Blog ที่เคยจดไม่รู้เกี่ยวไหม) / Threat Intelligent + Risk และ ทำ Penetration Test เป็นช่วงๆ

📌 อีกมุมที่มีการแชร์ Scalability Monolith

• มันไม่ในสิ่งที่เลวร้ายในตอนทำ Day 1 นะบางทีอาจจะยังไม่ได้มี Load ที่จำเป็นก็ได้ เพราะ Cost + Maintain จะไม่คุ้ม
• แต่ Evolutionary Architecture - ให้แต่ละ Component มัน Loosely Couple อย่าง Dependency Injection / async แต่แรก ตอนแยกจะได้กระทบเยอะ
• อยากเข้าไปฟังจัง จริงมันมีอีก Idea ที่ผมศึกษาด้วย Modular Monolith

📌 ถ้าได้ Feedback ไว ปรับตัวได้ไว

สิ่งที่สำคัญต้องรู้ Architecture Characteristic และทำ Trade Off มีเรื่อง Cap Theorem แปะเสริมไว้นิดนึง

- ทำยังไงที่จะให้ Design ไม่ Over และ Under Engineer มากไป ลดการ Rework ?

📌 ทำ Architecture Decision โดยต้องบอกด้วยว่า
📌 มีตัวเลือกอะไรบ้างเลือก และไม่เลือก เพราะอะไร ? ส่วนใหญ่ที่เจอ Record ตัวที่เลือก ส่วนตัวที่ไม่เลือกไม่ได้ใส่เหตุผลไว้
📌 ลองอ่าน Session Quickly, But Not Hurry มี Idea ตอบเหมือนกัน

การวาง Architecture ที่ดีช่วยลดเวลาการ rework ได้ ชอบเหมือนกัน

- มุม User ต้องคุยกับคนที่ทำ Software + Agile รู้ว่าภาพรวม Arch สัมพันธ์กันยังไง ?

📌 แก้ที่การสื่อสาร และ Set Expectation ให้ตรงกัน ว่าปัญหา คือ อะไร แล้ว ถ้าแก้ไปแล้ว กระทบในส่วนไหนบ้าง ให้เป็นภาษาเดียวกัน ตอนเขียน Blog นึกได้ ใน DDD ทำ ubiquitous language มาแปลภาษาของ user ↔ IT
📌 กำหนด Scope of Work ให้ตกลง แต่ยาก ถ้า Specific มากไปฝั่ง User ลำบากนะ มีตัวแทนขา Vender + Project ทำมาแก้ปัญหาอะไร แล้วเกี่ยวข้องกับ Requirement ไหน

เรียกว่าเป็นปม เพราะ Project สุดแอบเคือง 55 เคยเสนอแยก microservice ของ noti + message สุดท้ายผู้ใหญ่คิดว่า Requirement ไม่มีสุดท้ายมันมี และเพิ่มไม่ได้

มี Live ด้วยนะ https://www.facebook.com/agilethailand/videos/9988034911323853 ไม่แน่ใจว่า FB จะลบช่วงไหน

Platform Engineering and Agile

Speaker Jirayut Numsaeng

- What is Platform Engineering ?

📌 Platform - ส่วนพื้นฐานที่ทุกคนมาใช้งานร่วมกัน แชร์กัน
📌 Platform Enginerring นำแนวคิดทางวิศวกรรมมาช่วยลดต้นทุน อยากการสร้างรถยนต์พบว่าตัวโครงหลักๆของหลายรุ่นเหมือนกัน ต่างที่ Option บางส่วน ในมุมของ Software จะเป็นการ

• Involves design, building, operting เข้ามามีส่วนร่วมตั้งแต่ Day 1 หรือ ช่วงแรกของ Project รวมถึงรองรับการEvolvinig (เติบโต) ในอนาคตด้วย
• ทำให้การทำ Sofrtware Delivery ง่ายขึ้นด้วย โดยการทำ Guildline อย่าง Document + Tools เข้ามาช่วยทำ Automation
• Key เน้น Accelerate งานให้ไว เสริม Agile ที่เน้น Delivery ได้ feedback
• ลด Cognitive load ทำเฉพาะงานส่วนที่ตัวเองเกี่ยวข้องจริงๆ เช่น Dev มาเน้น Code ตาม Biz ไม่ต้องมาวุ่นวานด้าน Infra ใช้ Stack Set ที่เตรียมให้ได้เลย เป็นต้น

Platform Engineering มันไม่ใช่ศัพท์ใหม่นะ มีอยู่ใน Garther Hype Cycle อยู่แล้ว

- ทำไมถึงต้องมาสนใจ Platform Engineering

คุณเดียร์ได้แชร์ว่าประสบการณ์ของ Opsta ที่ดูงานและ Consult มา 3-4 ปี พบว่างานปรับ Infra + Software มันมีอะไรที่เป็น Pattern และ Reuse ได้ ได้แก่ กลุ่ม DevSecOps / Infra Cloud Container / K8S รวมถึงการทำพวก Observability System ด้วย แต่ถ้าให้ทุกคนไปเรียนรู้หมดจะซับซ้อน + ใช้เวลาเริ่มต้นนานไป

เลยได้ลองทำ Product ของตัวเองขึ้นมาชื่อ Opstella มา Product ด้วย Platform Engineering

แต่จากที่ลองนำ Product เข้าไปหลายทีจะพบปัญหา 3 กลุ่มใหญ่ ได้แก่

• Cultural Resistance - ต้องปรับ App ถึงพร้อมใช้งาน เช่น ปรับตาม 12 Factor
• Knowledge Gap ง่ายแต่ทีมยังไม่พร้อม ยังไม่เข้าใจ กลัวกลางเปลี่ยนแปลงแบบ big bang
• Team Maturity ความพร้อม รับการเปลี่ยนแปลงได้ไหม

เลยมาแชร์ต่อว่า ถ้าเราจะเริ่มทำ Platform Engineering ใช้เอง ให้เริ่มจากทำ Working software โดยใช้แนวคิด Lean build mvp 》measure 》 learn จากนั้นวนปรับไป

📌 build mvp ไม่ต้องทำสิ่งใหญ่ๆ เริ่มจากทำจุดเล็กก่อน โดย Focus ว่า Target User เป็นใคร ส่วนของไหน และเริ่มคต้นจากการทำ Document + Script และเติม Tools ในแต่ละส่วน Code Component / Infra / KM / Self Service ที่ง่ายขึ้น

📌 measure วัดผลสิ่งที่ได้ปรับเปลี่ยนไป โดย

• เมื่อก่อนจะเป็น DORA Metric ที่วัดจาก 4 ตัว
  - Change Lead Time
  - Deployment Frequency
  - Change Fail rate
  - Fail Deployment Recovery Time (MTTR) ซ่อมกลับได้แค่ไหน
• 10 ปีผ่านไป ตัว DORA เติม อาจจะไม่ชัดเจน เลย DORA ตัวเดิมนี่แหละ นอกจากบอกว่า SW ไปไวแล้ว ต้องวัดความ Stable หลังเอาขึ้นไปด้วย

• นอกจากนี้มีตัว Maturity Model ของ CNCF มาช่วยวัดด้วยนะ

📌 learn จากวัดมา เราหา root cause ได้ไหม ตัวอย่าง เช่น ทำไม Team A กับ B ลองใช้แล้ว ผลต่างกัน อาจจะมาดู และดูว่านิยามของ A กับ B เป็นอย่างไร และทำ platform มาช่วย

จากนั้น build mvp 》measure 》 learn และขยาย Scope ไป หรือ Pause มาดูสิ่งที่ต้อง Tune

- อะไรถึงมองว่าเป็น Attribute of Platform Engineering

• ทำยังไงก็ได้ ที่คนมาใหม่ไม่ต้องเริ่มจาก 0 มี Document + Script + Automate XX สำหรับ onboarding ของใหม่
• ทำ platform ให้มัน product นึงขององค์กร ทำให้มีคนใช้จริง
• Self Service Dev จัดการเองได้
• รองรับการปรับเปลี่ยน Optional + Compose สิ่งใหม่ๆได้
• Secure By Default
• User Experience

- Platform Engineering Team Topology

Enterpise หลายที พยายามจัดทีมให้อยู่ในรูปแบบนี่ โดย

• Platfrom เหมือน Software House เล็ก มี Dev / QA / Infra / PO มาทำ Product ของตัวเอง
• SRE มาดูระบบให้ Stable + Practice ที่ดี
• ทีม App IT เดิมจะได้มา Focus กับ Business มากขึ้นด้วย

สำหรับ Session นี้ผมชอบ ทำแล้วต้องมีคนใช้ เริ่มจากสิ่งที่ง่ายที่สุด มีเอกสาร + เครื่องมือ ช่วยให้คนเริ่มต้นต่อได้ง่าย และมีการ Reuse ไม่ใช่ทำใหม่หมดทุกอย่าง และ AI เอามาช่วยได้นะ สำหรับงานที่ Common + Pattern แต่งาน Special ของมีคนทำอยู่นะ //ไม่คิดว่าจะได้ฟังด้วย

จริงๆอยากเสริมอีกอย่าง Status ของ Page DEVdose อ่านเมื่อเช้าพอดี ถ้าไม่ไหว อย่าฝืน เอาทีม Opstella เข้าไปช่วยได้

Satir Self Esteem Toolkit

Speaker Jua

📌 หัวข้อที่ส่วนตัวสนใจ หลังจากได้เข้าพบจิตแพทย์มา 2-3 ครั้งในปีนี้ สำหรับผมจริงๆแล้วได้ยิน Satir มาจากครอสของพี่คริส

📌 วันนีเหมือนจะเป็นอีกมุมเป็นมุมที่บอกว่าคนที่มีความสุข การจัดการชีวิตจะลงตัว มันจะมีเครื่องมือ Satir Self Esteem Toolkit โดยเครื่องมือนี้เจ้าตัว Satir ไม่ได้จดเอง เหมือนจะเป็นลูกศิษย์สรุปมาจากตอนแกช่วยบำบัด ผมชอบอันนี้ Satir มองโลกนี้ไม่มีคนป่วยทางจิต แต่เป็นมุนุษย์ที่เจอกับสภาพแวดล้อมที่แย่มาก ที่ปรับตัว จน Action ออกมาแบบนั้น โดยเครื่องมือ 7 ตัวนี้ ดังนี้

1. Wishing wand ถ้ามีสติ เราตะชัดเจนว่าต้องการอะไร
2. Detective Hat สงสัยใคร่รู้ แต่ไม่ได้ตัดสินนะ มี Empathy มองมุมเค้า / บริบท ก่อน action ช่วง Q&A มีคำถามเรื่องนี้เยอะ และมีแนะนำหนังสือ Becoming Supernatural ตอนมาเขียน Blog มีคนสรุปด้วยลองฟังยาวๆไป
3. Courage Stick กล้าหาญ ถ้าอยากเพิ่มต้องตั้งคำถามกับตัวเอง
   - ชาตินี้จะทำไหม
   - ทำเมื่อไหร่
4. Golden key ช้วยให้เอาออกจากกรอบ มีกุญแจพาออกไป idea ใหม่
5. Yes No Medallion ทำให้เราชัดเจน
   - ถ้ายังลังเล มีเทคนิคช่วยให้ตัดสินใจง่ายขึ้น แล้วตั้งคำถาม best case / worst case ที่เกิดขึ้นทางนั้น
   - หรือ (อันนี้ผมไปคุยส้่วนตัวหลังจบ) ถ้าตัดสินใจพลาดไปแล้ว ก่อนนอน หรือนั่งรถ เราจะมีช่วยเอ๊ะ เสียดาย ว่าทำไมทำแบบนั้น ให้ติดการตัดสินใจอีกทางด้วย ถ้าทำแบบนั้น ให้ร่างกายมันซึมซับ และเอามาตัดสินใจได้ในอนาคต
6. Wisdom Box มีปัญญา เป็นความรู้จดจำลงในกล้ามเนื้อ กาย ใจ ไปทางเดียวกัน
7. Heart ความเข้าอกเข้าใจคนอื่น

📌 จะรู้ได้ยังไงว่า Satir Self Esteem Toolkit ตัวไหนเรามี หรือหลุดง่าย ?
-ต้องสังเกตุตัว หรือ คนรอบข้างเล่า ตอนเราน๊อตหลุด

📌 เราพัฒนายังไง ถ้า Satir Self Esteem Toolkit ไป
-เอ๊ะค่อยๆคิด ตามเทคนิคของคุณจั๋ว จะเน้นยังหลุดง่าย

📌 เทคนิคอะไรที่ทำให้กาย กับใจ ตรงกัน ?
-Keyword Internal Family System คนเราปกติจะมีแก่นแท้ ทำให้เราคุมกายใจได้ แต่บางทีเรามีแต่อารมณ์ คุยกับเสี่ยงของตัวเอง หนังสือ Self Theraphy เจอ Blog Speaker พอดี

เหมือนลอง Search มี Slide (Satir Self Esteem Toolkit) ด้วยนะ

Agile คือ อะไร กลับไปหารากเหง้า ก่อนเม้าอนาคต

Speaker Dahm Mongkol Hongcha

📌 คำว่า Agile มีมาตั้งแต่ปี 1994 แล้วนะ หนังสือตอนปี 1994 คำว่า Agile มาจากกลุ่ม Manufacfactoring พวกการผลิตรถยนต์ แล้วในปี 2001 มีการถกชื่อ Idea นี้กันว่าจะชื่ออะไรดีตอนแรกจะได้ Lightweight สุดท้ายอิงจากหนังสือตอนปี 1994 เลยได้ชื่อ Agile มาพร้อมกับ

• Agile Manifesto 4 Value
• และ 12 Principles

📌 แล้ว Agile คือ อะไร มีคนมาเสริมนิยามหลายคน

• agilealliance มองว่าเป็น mindset (กรอบที่ช่วยปรับแนวคิด) และทำให้เกิด ability create + respond to change
• Jim Highsmith - ability to adapt and respond to change … agile organizations view change as an opportunity, not a threat.
• Martin Fowler - Agile is adaptive + people-oriented และเน้นมากกว่ากระบวนการ (process-oriented) และพวก process มาจาก ISO ที่มองอีกมุมว่ากระบวนการดีของออกมาดีมาจากพวก ISO ถ้าพลาดมาจะเจอ CAR “Corrective Action Request” มาปรับ Process

📌 ตอนแรกฝั่ง Sofrware ไม่ได้มี Practice ของตัวเอง เลยเอาจากส่วนของ Manufacfactoring / construction มาใช้งาน มันจะเน้น Waterfall + Process จนมาเป็น Agile และตอนนี้ Agile เรียกว่ามี Keyword แยกย่อยเต็มไปหมด

📌 อย่าง Scrum เป็น Keyword ที่มีมานานแล้ว แล้วเอามาใช้การทำ product ตั้งแต่ปี 1986 ก่อน Agile เสียอีก แต่เราเอามาใช้ให้เกิด Value ของมันไหมทั้ง 5 ส่วน commitment/ courage/ focus / openness / respect.

📌 Extreame Programming (XP) ในอุตสาหกรรมอื่นจะเรียก shadowing เราจะเอามาปรับใช้ Pair Programming ทำ , km sharing และมีแนวคิด 40-Hour Week (มีจริงด้วย) ที่ให้ทีมทำงานไม่เกิด 40 ชั่วโมงต่อสัปดาห์ เพื่อไม่ให้ล้าเกินไป

เราต้องพัฒนาตัวเองหลายด้าน เผื่อโดน layoff จากต้องเป็นคน Shape I / T ตอนนี้เป็น เป็ด เหมือนแอดทอยสอนเลย ถ้าใน Agile Principle Technical Excellence ซึ่งเริ่มต้นง่ายๆ เรียนรู้ในสิ่งเราไม่รู้ ปรับ mindset

📌 แล้วเราจะเพิ่มตรวจไหน เพื่อให้เกิด Acceleration / Velocity

• เพิ่ม F แรงผลักดัน กำลังใจ วิสัยทัศน Technical Excellence
• ลด m process หรือ อะไรที่ขวางการทำงาน

📌 Planning Poker เอา มา Communicate ให้มาคุย แลัวเข้าใจตรงกัน / Estimate เป็นส่วนเสริม

📌 Principle Motivated People/ Environment ควรเป็นสิ่งแรกที่เข้าไปทำก่อนจะ Transform เท่าที่ฟังอารมณ์แบบกายพร้อม ใจพร้อม เราทำได้ เช่น ถ้าพนักงานอยากได้คอมใหม่ รองรับงานเพิ่มขึ้น เราจัดหาให้ หรือ มี Training พัฒนาตัวพนักงานเองจริงๆ

📌 Principle Constance pace / sutainable development ปรับ align ทุกคนให้พร้อมกัน ปรับยังไง ได้แนวคิดนึงมา มีแบบ Waive หนักเบา / หนักยาว แบบหนักเบาที่เป็๋น Waive ส่งผลกับ productivity ดีกว่า

นอกจากนี้มี PREM Model การเป็นผู้นำทีดีต้องมีของ ดังนี้

• Motivation
• Problem Solving
• Relationship ประสานงาน และ ประสานงาบ้าง
• Empathy

Blog ท่านอื่นๆ

• สรุปนิดๆ จากที่ไปร่วมงาน Agile Thailand 2025 : myifew.com
• Agile Thailand 2025: Agile Awakening by Khun Pichest Pongsiriwilai

ปิดท้ายขอบคุณทีมงานที่ท่านที่จัดงานครับผม ^__^ ตอนแรกเกือบไม่ได้ Blog แล้ว เมื่อคืน Save แล้วเหมือน WordPress ที่เพิ่ง Update จะติดปัญหาตัว Emoji