มาฟังงาน Agile Thailand 2023 #ATH2023

งานวันนี้จัดที่ True Digital Park พองานจัดไกลอยู่เลยต้องวางแผนการเดินทางครับ จากสายใต้ใหม่ ถ้านั่งรถ 511 ทางด่วน จะมาไวมาก เลยออกมาดักรอ ได้รถตอน 06:52 และถึงที่ True Digital Park ตอน 08:00 และก็ผมไม่หลงแบบรอบที่แล้วและครับ ที่จำ True Digital Park เป็นที่เดียวกับ Bitec 555

งานนี้จัดที่ True Digital Park (west) นะครับ ชั้น2 คิดว่าน่าจะเป็น Zone ที่น่าจะทำมาใหม่นะ พอมาถึงเจอที่จัดงานเลยครับ ลงทะเบียน รับของ และนั่งทำ ChaiyoGCP#3 ไปสักพักรองานเปิดครับ ตอน 09:00 ซึ่งพอถึงเวลามีเปิดงานเล็กน้อย และยังคง Concept เดิมของงาน โดยเป็นงาน

• unconference ไม่มีหัวข้อกำหนดแต่แรก มา Pitch กันหน้างาน
• Open Space
• Law of two feet

งานปีนี้เป็น Theme Business + Develop work together โดยตั๋วมีแจกเป็นรอบๆ นี่ไปกดทันตอนวิ่งพอดี สำหรับหัวข้อในงานที่ผมฟังๆ มาจะมีดังนี้ (เลือกแบบที่เดินน้อยสุด ปวดหลัง 555 แบกคอมมาแก้ Build Pipeline)

AXONS Talk (คุณ​สรรเสริญ สมัยสุต)

• AXONS บริษัทเทคโนโลยีด้านการเกษตร (Agri-Tech) ของเครือ CP (CPF IT) ตอนแรกนึกว่า recruiter หา outsource เจอ ads เยอะมาก โดยเจ้า Agri-Tech พาไทยบุกตลาดโลกได้ในช่วงเวลานี้ เพราะ
  • Infra ดี ดินสมบูรณ์
  • Technology พร้อม IoT / 4g 5g ที่ราคาถูกลงมาก
  • Open Platform + infra
• คน + process + system มันถึงทำให้ business เติบโตได้ โดย Agile + Plan Do Check Act เป็นวิธีการหนึ่งที่ AXONS นำมาใช้งาน
• งานด้าน Agri-Tech มาเกือบหลังๆเลย เมื่อเทียบกับ Tech อื่นๆ แต่มันมีความท้าทายในตัวนะ เพราะเป็นงานที่ยุ่งกับยุ่งกับของสด และโรงงานกระจายไปทั่ว พอเอาระบบ IT มาช่วยแรกเกิดเป็น silo tech มีระบบมากมายเต็มไปหมด ลองผิดถูก และมีองค์ความรู้แล้ว สุดท้ายเลยพัฒนา Software ขึ้นมาใช้เอง เพื่อให้มาตอบโจทย์องค์กร และลูกค้าคนอื่น (Open Platform) + ลด Cost และมองด้วยว่า
• คนเป็น Asset ที่สำคัญที่สุดขององค์กร
• คน IT เก่ง Tech อย่างเดียวไม่พอแล้ว ต้องเข้าใจ Technical Business ด้วย Business มองเป็นจิตวิญญาณของ SW ได้เลย การทำ Software ต้องเข้าใจตรงนี้ไม่งั้น

Software ที่ได้มาแพงสุด Software ที่ไม่มีคนใช้งาน ต้องมอง Software มีชีวิตต้องปรับไปตามเวลาได้

• จุดอ่อนสาย tech ไทย การสื่อสาร + ทำงานเป็นทีม + คุยบน Fact ความจริง ส่วนตัวนึกถึง Blog นี้เลย เห็นด้วยและให้คำมั่นสัญญา ไม่เห็นด้วยและให้คำมั่นสัญญา ( Agree and Commit — Disagree and Commit) | by Ruv 48 | odds.team | Medium

ชวนคุย Agile for business squads by Kris KBANK

Agile มาใช้ใน KBANK นะ เพราะส่วน IT โยกไปอยู่ใน KBTG หมดแล้ว

การเริ่ม Agile

• ต้องขอ bubble จากผู้ใหญ่ก่อนเลย เพราะองค์กรใหญ่ๆปัญหาออกของช้า ทำเป็นปี จะเอาเร็วขึ้น ต้องมี Sponsor ช่วย

• ปรับ Structure ขององค์กร จาก Model ของ Spotify (Tribe / Squads / Chapter / Guild) มาปรับให้เหมาะกับองค์กร
  - Business Pillar - จัดตามกลุ่มธุรกิจของธนาคาร
  - Control Pillar - Moniter Bank มันมี regulator มาเกี่ยวข้อง / Clear ปัญหา / bubble กับผู้ใหญ่ในองค์กร
  - Tribe - กลุ่มคนที่ทำงานร่วมกัน โดยแบ่ง Squads จัดการ
  - Squads - cross function เป็น Dedicate Resource ให้พอดี/ไม่มากไป น้อง 1 คนให้อยู่ได้ไม่เกิน 3 Squads Chapter Lead เลือกคน + เปิดโอกาศให้น้องลองขอย้าย Squads จะได้ไม่บีบไป
  - Chapter - กลุ่มคนที่มีทักษะเหมือนกัน ปกติจะเป็น Dev / QA ที่นี้จะเป็น Product / Marketing / Approval เป็นต้น
  - Agile Coach - คนกลางระหว่างทุกฝ่าย อยู่ที่ HR เป็นคนกลาง เวลา raise ปัญหา มันมีคนฟังมากกว่า เพราะไม่ได้สังกัดฝ่ายใดฝ่ายหนึ่ง เช่น IT / Business
• ปรับมุมมองการมองชิ้นจาก สามเหลี่ยมของ PM ที่
  - เดิม เริ่มจาก Scope และส่งผลกับ Cost / Time
  - ใหม่ Time + Budget มาตั้งต้น และจัดลำดับความสำคัญของ Scope
• ไม่ได้เริ่มจาก Business ล้วนๆ มีการนำคน IT จาก KBTG เข้ามาร่วมทีมด้วย Business 5 คน / IT 2 คนเพื่อ
  - ช่วยเรื่อง product discovery ให้มันเป็นไปได้ในด้านการทำ ไม่อิหยัง + และสวมหมวก Product Owner สื่อสารกับทีม IT KBTG ต่อ
  - ให้คน Business ที่เหลือเข้าใจ MVP

• ปรับ Goal Setting ให้ Win-Win ทุกฝ่าย Make sure ให้ value มันตรงกัน Customer <-> Business <-> IT จะได้หาคนเจอ
• ปรับจูนกับผู้ใหญ่
  - นอกจากที่มี Retrospective แล้ว หลังจากนี้จะมีส่วน Sponsor Check-in เข้ามารับทราบปัญหา และสถานะด้วย
  - มีการ Monitor ติดตาม เพื่อที่จะได้รู้ว่าอะไรที่ต้องจูน / Squads ที่ไม่ใช้จะได้ยุบเอา Resource ที่ไม่ใช้ทำอย่างอื่น
  - ทำให้มันเกิด Alignment + Visibility ให้เห็น dependency

ปล่อยให้ทีมโตทำยังไง - Team hierarchy of need by Chris Thoughtworks

• High performance Team หลายคนอาจจะตอบว่ามาจาก
  - Deliver As Promise - ส่งได้ตามที่ขอ
  - Collaborate Well
  - Manage Expectation
  - Safe Space
  - Take initiative ... etc.
• การทำให้เกิด High performance Team ขึ้นมาได้ หลายคนมีสูตร (playbook) ในการสร้าง เช่น
  - ทำให้เกิด Collaborate Well / Deliver ได้ทัน
  - หรือจะเป็นที่ตัว Lead (หลายที่อาจจะมองว่าเป็น Manager ก็ได้)
  - เอาวิธีการที่มีอยู่แล้วมาใช้ Agile / Design Pattern อะไรงี้
• มองที่ตัว Lead พี่คริสยกตัวอย่างแบบสุดขั้วมาเลย
  - Lead เข้าไปช่วยเสริม ในทีมคนเก่งอยู่แล้ว เขาจะดึงความสามารถของแต่ละคน สร้าง culture / team / autonomy
  - Lead ส่งไปดับไฟ แก้ปัญหา วาง structure ดุดัน
  ถ้า Lead ใช้ผิดมันจะทำให้ทีมเกิดปัญหาตามมาแทนได้

ที่นี่พี่คริสเสนอว่าลองเอาแนวคิด Maslow’s Hierarchy of Needs มาปรับใช้ดู โดยมี 5 Level เรียงไปเลย โดย Lead ควรทำอะไร

1. Physiological Needs (Survival) - Deliver ให้ทัน
   - Lead ที่ช่วย ทำให้ดูเป็นตัวอย่าง
2. Safety Needs (Need for Consistency) เพราะตอนนี้ Deliver ตามเวลา
   - Lead ต้อง Transition ถอยออกมา และมาวาง Process ทำให้มัน Reliability เพิ่ม Bus Factor
3. Social belonging - มีคุณค่าในสังคมองค์กร ตอนนี้ Deliver ตามเวลา + Reliability แล้ว
   - Lead เริ่มออกไปคุย stakeholder / sponsor ออกไปกันจาก External (shield team) แล้ว ให้ทีมเดินได้ดู Process ที่ทำแล้ว
4. Self-Esteem - ทีม Self-Organize แล้ว
   - Lead delegate งานให้ทีม อย่าไป shield team ให้ Team ได้ Self-Organize และถอยออกมากำหนด Direction / goal / identity / culture purpose
5. Self-Actualization - คุณคริสยังไปไม่ถึงครับ

Key อันนี้ Leader ต้องโตไปก่อนทีม และเลือกใช้ท่า เหมาะสมกับปัญหาที่เจอ ซึ่งสร้างทีมแต่แรกง่ายกว่า การมองวว่าทีมต้องการอะไรยากเหมือนกันนะ หา Yarn ของแต่ละคนออกมา

Dealing with ML Product Complexities with non-Digital MVPs by Té ARV

สำหรับใน Session นี้ เอา MVP มาช่วยงาน Machine Learning Model ยังไง โดยงานที่ Speaker ได้ทำใน Bedrock ที่บริษัทที่จำ Digital Twin โดยตอนนี้ได้ไป Focus ในส่วนภาษีจากองต์กรปกครองส่วนท้องถิ่น โดยจะไปภาษีป้าย

• เมื่อก่อนใช้คนเดินนับ
• purpose solution ใช้ technology ทำรถ street view แล้วเอา AI มา detect ป้าย โดยที่ตอนทำ ML พบปัญหาว่า
  • ทำ App มาแล้ว UX / Usability ดี
  • แต่เจอปัญหาจาก raw data ป้ายเล็ก ใหญ่ เอียง จัดการยังไงนะ ตอน product discovery มันไม่พบนะ

MVP เอามาช่วยตรงไหน ?

• ช่วยเพิ่ม Accuracy ของงาน
  - ป้ายแบบไหน ที่ต้องจัดเก็บ อ้างอิงจาก street view ทำจาก A / B Testing ลองเอาแต่ละกลุ่ม กลุ่มแรก ป้ายใหญ่ / กลุ่มสอง ป้ายเล็ก
  - พบว่าคนแต่ละกลุ่มมีเกณฑ์ ต่างกัน คนที่ได้ป้ายเล็กจะหาป้ายใหญ่ด้วย แต่ป้ายใหญ่ จะไม่ค่อยมีคำถามอะไร ดังนั้นให้ได้ข้อมูลที่แน่นนอน ไม่งั้นจะได้คำตอบแบบเอาหมดเลย
• การสื่อสารด้วย tech บอก % ความมั่นใจ แต่ลูกค้าบอกว่าใช่ได้ ไม่ได้พอ มาจูนให้ตรงกัน ใกล้ประสบการณ์ที่เจอมา ต้องลองเอา result ให้ดู
• Impact ที่ได้มี 2 มุมนะ คนตรวจป้าย งานมันจะถูกต้องแม่นยำขึ้น และไวขึ้นด้วย / คนที่จ่ายภาษี อาจจะเข้าข่าย หรือไม่ต้องจ่าย เป็นต้น
• สิ่งที่ได้เรียนรู้
  - Customer reaction in right context !!!!
  - ML ยากกว่า user story มันเยอะ
  - บางอย่างไม่จำเป็นต้อง Digital อาจจะทำ Manual หาคำตอบมาก่อน เช่น แบบสำรวจ หรือลอง Interview

Improvement - จัดการ Delivery ตอนนี้แยก app / ml ตอนนี้หำลังจะปรับแบบ cross function และภาษีป้าย ยังมีที่ดิน สิ่งปลูกสร้างมีอะไรที่ยาก และท้าทายว่าพื้นที่นั้นๆทำอะไร เกษตร ไร่ สวน มันมีกฏเหณฑ์ของมัน ส่วนไหนเขตเมือง เป็นต้น ส่วนไหนเป็นบ้าน หรือ solar cell (บางทีติดที่พื้น Model จับเป็นบ้าน หรือแหล่งน้ำ)

Continuous Product Discovery and Delivery by Pondd

หัวข้อนำมาเสนอว่าตัว Product Discovery ที่ใช้ในด้าน UX / Design Thinking กับ ตัว Scrum เอามาช่วยได้นะ เหมือน Do the Right Thing และ Do the Thing Right นั้นเอง เพราะปัญหาที่เจอพบว่าบางทีมีทำ Product Discovery มา แต่ทว่าทำเสร็จปุ๊บ หรือนั่งเทียนขึ้นมาเอง ส่งงานต่างให้ Develop Team ทำเลย ผลทำให้ product มี risk ได้ ถ้าไม่ปรับเปลี่ยนนะให้ทันตามตลาดนะ

การจับมารวมให้เป็น 1 ทีม 2 Track ทาง Speaker เอาตัว Flight Level เข้ามาช่วยเพราะกำหนดบทบาทของทุกคนในองค์กรได้ชัดเจน ใน 3 Level Stategic <-> Coordination (จูนแต่ละหน่วยงานมาช่วยกัน) <-> Operational Key ให้ Goal มัน Sync กันทุกฝ่าย

และที่นี่ภาพที่นำเสนอจะเป็น ให้ 1 ทีม 2 Track: Track: Discovery / Track: Delivery ทำขนานกันไป และมีช่วงสุดท้ายที่มา Sync ร่วมกัน Discovery
- rotate คนจาก delivery เข้ามาให้เกิด Team Ownership + sync
- วันพุธ มีเอา Test User 1 ครั้ง 1 Sprint โดยทีม Declare Way of Work ไปก่อนเลย ว่าทำงานแบบนี้นะ ถ้าทำบ่อยๆ เป็นประจำช่วยลด Cost ที่เกิดได้
- มีส่วนของ Research Show Case เอามาแนะทำทีม + stakeholder ฟัง

สำหรับการคุยการวางแผนใช้ตัว Kano model เอามาช่วยจัดสำดับความสำคัญของงาน อะไรที่ควรมี และไม่ควรมี และที่ควรมี มันต้องจัดอยู่ในส่วนไหน

• Expected (Must Have) ทุกคนคาดหวัง มันควรจะทำได้สิ มันเป็น Foundation เลย ถ้าไม่พร้อมขั้นถัดมาจะพังหมด นึกถึงภาพ App E-Commerce ระบบ Chatbot เทพ แต่ซื้อของไม่ได้
• Performance - จุดดีกว่า Expected แต่ยังไม่ Wow
• Delighters อะไรที่ wowwwww จุดที่ทำให้เหนื่อกว่าคู่แข่ง

สุดท้าย Feature is an Experiment ที่ทุกคนต้องเข้าใจ โดยเฉพาะ Stakeholder

Reduce Risk with Continuous Delivery + How to Measure Them (Bas OODS)

ในชีวิตจริงพบปัญหาเหล่านี้

• Dev QA แก้กันหลายรอบ และกว่า Code ที่แกะจะขึ้น Production ได้ รอหลายเดือน
• กว่าจะเพิ่ม feature ทีบัคเพียบ ทำไมทัน กว่าจะได้ Feedback จาก User อีก หรือลูกค้าไม่ใช้
• แก้ code เพิ่ม release ใหม่ เวอร์ชันพัง
• Merge แล้วพัง อันนี้เคืองสุดผมเองเพิ่งเจอมาไปช่วยน้องที่รับหน้าที่ Merge มา ต้นทางยัง Build ไม่ได้เลย
• Tester ไม่ไหวจะทำ Regression Test แล้ว เป็นต้น

โดยปัญหาข้างต้นมัน ทำให้ product fail และล้มเหลวได้ ซึ่งถ้าเราเจอ defect เร็ว cost ที่ Fixed จะน้อยลงมา โดยทำแบบนั้นได้ต้องมาลด Release/Cycle Time โดยต้องให้

• Idea - Release รับ Feedback จาก user
• Execute Spec (acceptance test) - Build
• Unit Test - Code

การส่งมอบของไวมีอะไรบ้าง

• Agile
• Lean - ทำเท่าที่จำเป็น ทำที่ละเล็ก
• Scientific method: curios > hypothesis > deduction > experiment > falsify

Continuous Delivery คือ อะไร ?

• การทำ Software ให้
  - Short Cycles -
  - Reliably Released - ทุก Commit ได้ Release Canidate ที่ต้องเอาไปทดสอบ + acceptance ก่อนถึงขึ้นได้
  - Production like stack - จะได้ทดสอบได้ใน Environment ที่ใกล้กับกับ Production หลายทีมีแบบ Staging / SIT / UAT ก่อนจะมาถึง Step Go-live ได้
• ส่วนเสริมจากคำเดิม Continuous Integration โดยจะจบเมื่อ Release Canidate ขึ้น Production
• การทำให้ Continuous Delivery เกิดขึ้นมาได้
  - repeatable + reliable process
  - automate
  - จัดเก็บทุกอย่าง Code + Config ลง Version Control เวลาทำ Release Canidate ไปด้วยกัน
  - If it hurts, do it more Frequently - bring the pain forward ถ้ามันพัง ทำให้บ่อยขึ้น จะได้ Feedback ไวๆ
  - Built Quality In เพิ่ม Automate Test เช่นมา โดยที่ควร Run ไม่เกิด 5-10 นาที //ไม่รวมพวก Coverage
  - ทุกคนมีส่วนร่วม
  - Done means "In the hands of user's delivery value"
  - Continuous Improvement - ปรับ process ให้เหมาะสมะ

เริ่มยังไง Simple กันก่อน

ต่อยอดที่ละส่วน

แต่ละส่วน คือ อะไรบ้างนั

• Source Repository (GIT): Dev Test ที่ Local แล้ว
• Commit: พยายามให้เกิด Branch น้อยที่สุด (เดียวมีขยายตวามตอนตกผลีก) และ เข้า CI Build Test ออก Release Canidate
• Acceptance: business เอาทดสอบ //Integration test อยู่ส่วนนี้
• Manual System: - Nice to user โดยถ้าลองทำแล้ว พบว่าอะไร automate ได้ ค่อยปรับ
• Component Performance: System Fast Enough ทำ API Test กำหนด SLA
• System Performance: Can be Scale? //วัดให้รู้ Capacity ของระบบที่รับได้ก่อน
• Data Migration: test break จาก v1 > v2 ต้องมาเตรียม Data ยังไงบ้าง

วัดผลยังไง ?

• Efficiency

Throughput = Frequency (เพิ่ม ความถี่ที่ Run Pipeline บ่อยๆ) + Leadtime (ที่ลดลง)

• Quality

Quality = Change Failure Rate (ลดลง) + Failure Recovery Time 

ตกผลึก CI/CD ขึ้น

• Code ใหม่ๆ บังคับทำ Test แต่แรก เพิ่ม Confident จะได้กล้า Merge เข้า master ที่ละเล็กน้อย เพราะการ Merge มันใช้ Cost สูงมาก (ส่วนตัวล่าสุด 3 วันที่ต้นทาง Build ไม่ได้ต้องมาแก้ก่อน และอีก 2 วันมา Code Review เรียกคนเขียนมาถามว่าเขียนอะไร ?)
• แต่ถ้า Code มันอยู่มานาน อาจจะต้องหาจุด Automate ได้ก่อน แล้วค่อยๆ ลดเวลาลงมา สิ่งที่ชอบใน session นี้ การถกกันจากเคสของการตั้ง Branch ตามรูปด้านล่าง แล้ว CD มาเข้าช่วยยังไง

ส่วนตัวมองว่างานเร่งแค่ไหน มี Test สักอันพอ ถ้าใครให้มาช่วยจะตามหา Test ก่อน ไม่มีก็ไปเขียน 55

จากประสบการณ์ คุณเริ่มทํา API Testing อย่างไร - Anan, Sutin, Ked AXONS

API ตัวกลางสื่อสารของ web microservice ต่างๆ โดยการ Test ดูจาก

• Spec
  • Document Endpoint / response code + message
  • Sequence Diagram
  • ที่เด่น swagger มัน Generate จาก code ได้เลย
• Collection Postman

Tools for Test API

• Postman นอกจาก Run ที่ละตัว
  - มี collection ด้วย export collection ไปใช้ ci/cd
  - Mock Respond โดย Capture Request Mock / script check ได้ด้วเพิ่งรู้ 555
  - และ performance
• Insomnia
• Robot Framework + Request Library
• Mockoon - Mock Response สำหรับ mock test และทำเงื่อนไข
• mountebank - Mock Response ไปในเชิง dev ยิงของ set response ได้ / katate ทำ perf test ได้
• Playwright
• ส่วนตัวผมใช้ VSCode + REST Client เบาดี

ออกแบบการทดสอบ API ยังไง ?

• Sucess + Required Field
• Success + All Field
• Pagination
• Data format เช่น Datetime ถ้าตอน dev ตกลง format ISO8601 จะได้ลดเคสได้ แต่บางเคสอาจจะเจอ epoctime
• Fail Case Error Code 400 / 500 เบื้องต้นให้ dev เตรียมมาก่อน แล้ว mockoon
• Scenario: API Chain จาก API 1 ต่อด้วย API2 .. ใช้ POSTMAN Capture
• Connectivity กับ External Party
• เก็บ Responsetime ถ้าสังเกตุแล้วเจอ แจ้ง dev ก่อน DB Test เตรียม Data ให้ใกล้ของจริง มี growth rate จะได้รู้ Response ตอน DB เปล่าๆ / ควรจะให้พลังเท่าๆกัน

Functional Test แล้วจำเป็นต้อง Performance Test ไหม ?

• กำหนดจุดประสวค์ responsetime / error / การใช้ resource ให้ชัดเจน
• จะได้ไม่ test วนไปวนมา
• Tool jMeter / WRK( Lua Script) / Loadrunner / K6

อื่นๆ

• ใน CI/ CD แต่ละ Sprint จะร้อยเรียง API มาเป็น Scenario ต่อกันๆ ถ้าใช้ robot test ui ก็มี test นะ มันจะช้า เลยเน้นAPI Test แทน เน้น API ช่วยกันเรื่อง Critical Error ด้วย Run CI/CD ทุกครั้งที่มีการ Deploy
• UI เน้น Happy Path ที่สำคัญ
• นอกจาก Test Pyramid ตอนนี้มี Test Trophy ด้วยนะ ซึ่วจะเน้น Integration (API Test)
• การเลือก Test Tools ต้องดูการ manage ด้วยนะ ใช้หลากหลายจะมี gap skill คน / maintain / cost / time
• เสริม security checkmarx ช่วยดูทั่วไป โดยทาง security มาเสริม pipeline ตรงนี้ และมี tools static check อย่าง SonarQube + OWASP
• Holistic testing เข้าไป Test ในทุก phase ของ project อย่างเช่น Requirement บางทีถ้าทาง Test ทัก Input แปลกได้ไหม จะได้กันตั้งแต่ต้น + ตรวจ Cross Site Script + SQL Injection
• ถ้า Run API Test แล้วนานๆ Robot + Database Library เอาเตรียม Data ที่เป็น pre-condition ของ API ช่วยลดเวลา Test

ได้มาเยอะเหมือนกัน เอาจริงแอบเห็นหัวข้อนี้เลยมางานนี้ 55 ไม่งั้นได้ไปโผล่ที่งาน After Build ของ MS

Scrum มูลบทแห่งสกรัม (ทฤษฏี) โดยพี่รูฟ

ก่อนจะเริ่มพี่รูปเปิด VDO First Follower: Leadership Lessons from Dancing Guy ซึ่งตรงนี้มันมี Key ที่สื่อว่า
- ถ้ามีคนบ้าทำอะไรก็ไม่รู้ใน VDO เป็นการเต้น คนแรกที่ขึ้นมาต้อง Easy + Public
- จากนั้นคนที่ 2 รวมรวมความกล้าตามมา คนที่ 2 คนที่ทำตาม Leader
- และคนที่เหลือจะตามมาเอง

กลับที่ Scrum เป็นFramework Agile คนนิยมทำกันมาก ซึ่งมัน simple / easy to start โดยทำมาเพื่อ

10 ปี่ผ่านมาอยูาไหนนะ

• Stop Copy Paste Spotify Model เพราะ ไม่เข้าใจ และปรับใช้กับองค์กรไม่ได้ จนเรื่อง Ability to Change มันทำไม่ได้

• ภาพที่ควรจะเป็น flat organization / 1 คนต่อ product

Scrum Value ทีมที่ดี จะได้ทำให้ได้ Product ที่ดี

• Courage - extend ability ให้มากที่สุดเท่าที่ได้
• Focus - deliver valuable items ของพร้อม test
• Commitment - เลือกของที่อยากทำ
• Respect - เคารพคน จากความสามารถ
• Openness - ฝึก constructive feedback

Key

• Share Responsibility (Team) - management skiil ใส่ลงใน team
• Empowerment - Self Manage Team
• Multi-Learning - Cross Function Team (Core + Support Skill) เลิกใช้ resource pull เอาคนยัด project เป็น %
• Inspect-adapt
  • Feedback ทำบ่อย ยิ่งเชียว
  • Iterative & repeating
  • Full Cycle เน้นปรับในแต่ละ Sprint วันเท่ากัน ทั้ง org เริ่มจบวันเดียวกัน
• Improvement
  • เลือกของเข้า sprint โดยทีม มากกว่าผุ้ใหญ่สั่งมา / ลดงานที่ซ้ำซ้อน / Automation
  อย่าละจนไม่เหลืออะไรเลย

ชอบภาพนี้มาก Functional Programming ก็มา จริงมันเรียกว่า Apply ได้หมด และกล้าปรบอะไรมันอิหยังให้เข้ากับตัวเอง องค์กร

สำหรับงานปีนี้ได้ฟังอะไรที่ไม่รู้ หรือที่ทำมาแล้วแต่ยังไม่สุด จากเดิมเล็งๆหัวข้อ API Test ไว้ มีหลายอย่างที่เติมเต็มสิ่งที่ไม่รู้เยอะมาก โดย Session ที่ผมชอบ Continuous Delivery มันมีการถกไปด้วยทำให้เห็นภาพใหม่ด้วย และไปแจมด้วนิดหน่อย 555

เสียดายตอนปิดงานผมไม่ได้อยู่นะ รีบกลับบ้านเอาข้าวไปให้แมวจร เด๊๋ยวน้องรอนาน ^__^

Blog ท่านอื่นๆ

• สรุปเรื่องที่เข้าฟังในงาน Agile Thailand 2023 ช่วงเช้านิดหน่อย (somkiat.cc)
• 23 บทเรียน Software Project Management จากกูรูด้าน Agile
• [ShareEXP] AXONS X Agile Thailand 2023 — Business and Development together | by Tan Kanteera Kongyuen | Jun, 2023 | Medium
• รีวิวและสรุปเนื้อหางาน Agile Thailand 2023 ที่ได้เข้า #ATH2023 | by Parima Spd | Jun, 2023 | Medium
• AXONS Presents Agile Thailand 2023 : Business and Developer together | by Thanthai Jitprathum | odds.team | Jun, 2023 | Medium
• สิ่งที่ได้จากหัวข้อ “ปัญญา 3 ศูนย์” จากงาน Agile Thailand 2023 | by Keattiwut Joe Kosittaruk | Jun, 2023 | Medium >> อ่านแล้วมาอ่านอันนี้ต่อได้เลย บันทึกการเรียน Humanistic Software Architecture
• Non-IT HR พาเที่ยวงาน Agile Thailand 2023 At True Digital Park | by Thirapat Jiravorapat | Jun, 2023 | Medium
• สรุป "From Project to Product" จาก พี่เจน Odd-e by Cherry-Pick