[ATH2021] สรุปงาน Agile Thailand 2021: Agile & Pandemic

สำหรับการจัดงานครั้งนี้จะเป็นแบบ Virtual โดยใช้ระบบของ welo ครับ โดยเป็นห้องประชุมสัมมนา Online มันจะดูมี Feature ที่เยอะกว่า Zoom / MS Team และไม่ต้องลงโปรแกรมด้วย

Concept

  • สำหรับ concept งานยังเหมือนเดิม UnConference Format + Law of two feet

สรุปหัวข้อในงานที่ผมได้ฟังนะครับ

- KEYNOTE: Agile ไปช่วยทำระบบ Home Isolation ได้อย่างไร

  • ปัญหา จาก COVID-19 ทำให้เกิดปัญหามากมาย เด็กทันตะปี6 ไม่สามารถฝึกงานได้ เนื่องจากเป็นงานที่ต้องสัมผัสกันสูงมาก เสี่ยงกับการแพร่เชื่อได้
  • แนวคิด Home Isolation ใช้รักษาผู้ที่อาการไม่หนัก แต่ระบบจะจัดการดูแลอย่างไร เพราะบุคลากรมีจำกัด ถ้า Overload หมอป่วยติดเชื่อตามข่าวที่ออกกันครับ
  • เหตุการณ์ในช่วงนั้น มีผู้ป่วยจำนวนมาก จาก COVID-19 แต่บุคลากรทางการแพทย์มีจำกัด 1 จุด อาจจะมี 2-5 คน แต่ผู้ป่วยหลายร้อย ทำให้เกิดงาน Overload มีการป่วย / ติดเชื่อตามข่าวที่ออกกันครับ จึงมีแนวคิดทำ Home Isolation ต้องติดตามผู้ป่วยอาการ 2 สัปดาห์ เพื่อลดความแอดอัดของสถานที แต่ยังคิดปัญหาเรื่องบุคลากรทางการแพทย์
  • จากปัญหาเรื่องบุคลากรทางการแพทย์ + เด็กทันตะปี6 ไม่สามารถฝึกงานได้ จึงเกิดการนำเด็กทันตะปี6 มาช่วยลดภาระของบุคลากรทางการแพทย์ โดยช่วยได้อย่างไร ?
    • ช่วย Detect Online เพื่อกรองเคสให้คุณหมอจริงๆที่ต้องเข้าไปประจำติดตาม Onsite
    • ติดตามประสานความช่วยเหลือต่างๆ เช่น เครื่องมือ อาหารการกิน 14 วัน
    • เด็กทุกคนไม่ได้โทรติดตามผู้ป่วยทั้งหมด มีการแบ่งหน้าที่ในการจัดการ
  • Agile เอามาใช้อย่างไร
    • รับฟัง requirement จากผู้ป่วย / แพทย์หลัก รวมถึง constraint ต่างๆ เช่น ต้องแจ้งของก่อนที่ต้องการใช้ก่อนเทียง
    • จูนการสื่อสารให้เป้นภาษาเดียวกัน ต้องมี Adapter มาปรับการสื่อสาร
      • ศัพท์ต่างๆ การจดบันทีก
      • เอกสารราชการ: ใบรับรองแพทย์ ผลตรวจ RT-PCR / ATK หรือ เอกสารการเบิกจ่ายยา เป็นต้น
      • FAQ / KM
    • ตอบสนองการเปลี่ยนแปลงให้เร็วที่สุด
      • มีการทำ Daily Meeting เพื่อแชร์สิ่งที่พบ และปรับตัว
      • Monitor ความรู้สึกคนไข้ คนทำงาน
    • Cross Functional Team: หน้าที่อาจจะต้องปรับตาม Load ของผู้ป่วยที่ได้รับมา
  • กทม มี Software มาช่วยนะ ให้แต่ละศูนย์มาแจ้ง แต่ยังต้องมีการปรับจูนการใช้งานจริง ตอนแรกผมเข้าใจว่าแจ้งผ่านไลน์จริงๆนะ
  • ในยุค COVID-19 มี Keyword ใหม่ VUCA World : Volatility / Uncertainty / Complexity / Ambiguity

- Plan-Do-Check-Study-Act แค่นี้ก็ Agility ได้ อย่าเพิ่งไป Scrum เลย (10:00 - 10:45)

  • ต้องคุยกันก่อนว่า Agile คือ อะไร / ต้องการอะไร ? จำเป็นจริงๆไหม
  • AGILE ที่ทำอยากได้อะไรกัน - ถ้ายังไม่รู้อะไร อาจจะกำหนดตามนี้ก่อนได้ครับ

AGILE = output (Product) + OUTCOME (Feedback)

  • Sprint คือ อะไร ?
  • PDCA - มันดีอย่างไร หลายๆมาตรฐานอย่าง CMMI มีแนวคิดนี้เข้ามานะ แล้ว Agile เอามาใข้อย่างไร
    • Plan : ทำ Daily Scrum กำหนด Goal ของวันนั้นๆ หรือ Sprint นั้นๆ ให้ชัดเจน
    • Do : Development งานการที่ได้วางแผน โดยของที่ส่งให้ Test ได้ เป็น output
    • Check : Daily Review เจออะไรที่เกิดขึ้น การ Review Code รวมงานส่วนที่เป็น CI/CD (Automation เพื่อลดภาระ โดยคำนึง Function + Non Functional
    • Act (Response to Change จาก OUTCOME มาจาก Feedback ที่ได้จากลูกค้า มองว่า OUTCOME เพื่อลด Risk
  • Study มาตอนไหนหละ ?
    • ทุกคนที่เข้ามาทำงานร่วมกัน อาจจะไม่รู้จัก Agile ต้องมีการปูพื้น โดยเอาแนวคิด PDCA มาแนะนำปรับรูปการทำงานให้เป็นรอบๆ (Sprint)
    • จากนั้นมาศึกษา (Study) เพิ่มเติมจากตอน Check เพื่อเอา Feedback มาศึกษา และ Act ตอบกลับในรอบถัดไป
    • ปล. นอกจาก PDCA ยังมี PDSA (Plan Do Study Act) ด้วย
  • กลับมาที่ The Sprint
    • ทำงานให้ได้ตาม Sprint Goal โดยกำหนดช่วงละ 10 วัน (2 Week)
    • วันแรก Sprint Planning >> เพื่อให้ได้ Sprint Goal
    • Develop 2-9 วัน ตามแผน โดยที่ทุกวันมี Daily Review
  • Plan-Do-Check-Study-Act >> Agility

- ชวนคุย! Change ที่วุ่นวายจัดการด้วย Agile ได้ไหมนะ? (11:00 - 11:45)

  • อะไร คือ Change : เกิดขึ้นได้ปกติ แต่จะรับมือได้ไหมนี่สิ ส่วนตัวเจอปัญหามากมายกับ Change สรุปไปอาจจะมี Inner เข้าไปด้วย 555
  • รูปแบบ Change
    • รูปแบบ
      • ฟ้าผ่า : ตอบสนองลูกค้า / Marketing / เราไม่คุยกัน
      • วางแผน : เพื่อปรับการทำงานต่างๆ
    • ความรุนแรงมาก ปานกลาง น้อย

((- จัดการ Change อย่างไร -))

  • Understand Change (เข้าใจ) ทำไมถึงอยากปรับมีเหตุผลอะไร แล้วใครจะได้ประโยชน์บ้าง ส่งผลดีกับธุรกิจ ต้องทำให้สำเร็จอย่างไร ?
  • Plan Change (วางแผน) ทำให้ทุกคนที่เกี่ยวข้อง มีส่วนร่วม เข้าใจ/ยอมรับ ในผลกระทบที่เกี่ยวขึ้น
  • Implement Change (รับมือ ขับเคลื่อนให้เกิด) โดยอาจจะใช้ ADKAR Model
    • Awareness - ทุกคนที่เข้าใจความจำเป็นของการเปลี่ยนแปลง ให้ DEV ช่วยทำ Automate Test ตัว DEV เองเข้าใจประโยชน์ คนที่เกี่ยวข้องรอบด้านทั้ง Marketing / PM
    • Desire - อยากที่จะทำจากใจ
    • Knowledge - Know How to Change ต้องปรับอย่างไร และ Know How to Perform in the Future และหลังการเปลี่ยนแปลงต้องทำตัวอย่างไร รวมถึงต้องมีการ Train เสริมความรู้อะไรด้วยนะ
    • Ability - มีความรู้ แล้วฝึกจนสามารถทำได้ เช่น สามารถเริ่มเขียน Test ได้ ออกแบบ Code ใช้ Test ง่าย
    • Reinforcement - การวัดผล และช่วยให้การเปลี่ยนแปลงยั่งยืน ถ้าเรื่อง Test มันต้องมาดูตัวระบบเดิมมันเอื้อกับการ Test ไหม หรือต้องค่อยๆขยับการเปลี่ยนแปลงไปทีละขั้น ผมมองว่ารวมถึงการ Defend ด้วยนะ
  • Communicate Change (สื่อสาร ใครที่กระทบ)
    • เน้นสื่อสารทำให้คนที่เกี่ยวข้องคิดบวก
    • บางองค์กรมีหน่วยงานกลาง เพื่อจับให้เกิดการสื่อสารของ Change ว่าไปทำอะไรแล้วใครต้องมามีส่วนร่วมบ้าง เช่น แก้ API แล้วใึครต้องเกี่ยวข้อง พวก Release Note ตัวผมเองคิดว่าเป็นช่องทางนึงของการสื่อสารนะ
  • อ่อ ทุกการปรับเปลี่ยนต้องมีบันทึก และติดตามนะ จากประสบการณ์ส่วนตัว Change ตัว Requirement ที่มาหลังๆ หรือไม่คุยกันก่อนเป็นอะไรที่น่ากลัวมาก ขอแปะทวิตเตอร์ของ 9arm ประกอบ

- Agile retreat

  • ผมเข้ามาช่วงหลังๆ เลยสรุปว่า Agile ต้องมี Soft Skill เพื่อช่วยให้เกิดการเปลี่ยนแปลงได้

- Mutation Testing - Beyond Unit Test Code Coverage (13:00 - 13:45)

  • Mutation Test คือ การเปลี่ยนแปลง Code บางจุด เช่น A+B เป็น A-B เพื่อดูว่าตัว Test Case เดิม มันทนทานกับ Code ที่เราไปแก้ไข (Mutant) หรือไม่ ? ผลลัพธ์ที่ได้
    • KILLED: Mutant ถูก Test Case เดิม Detect พบ
    • LIVE(SURVIVED): Mutant ที่แก้ยังรอดพ้นจาก Test Case ได้
  • การวัดคุณภาพของ Mutation Testing จะใช้ Metric Mutation Score เอามาตรวจสอบ Test Case นั้นเพียงพอสำหรับทดสอบ Code หรือไม่
  • Mutation Test หากจะฝากไว้ใน Build Pipeline ได้ แต่ต้องระวังเรื่องระยะเวลา เพราะใช้เวลามาก ปกติตัว Automate Test มันจะใช้เวลายาวนานที่สุด ฮ่าๆ
  • Stryker.NET เป็น Nuget Library ตัวนึงที่ช่วยให้การทำ Mutation Testing ได้สะดวก และมีตัวแสดง Report ในระบบด้วยครับ (ตัว Stryker มีรองรับหลายภาษา สามารถดูเพิ่มเติมได้จาก https://stryker-mutator.io/)
  • NOTE: ส่วนตัวเดี๋ยวคงเอา Thesis ที่ทำด้าน Mutation Testing มาสรุปลง Blog เสริมอีกที ดองไว้นานและ 555

- Management 3.0

  • Session นี้ ผมกระโดดแวํบไปมาระหว่างห้อง Mutation Testing หลายๆอย่างอาจจะไม่ครบได้
  • KUDO CARD/BOX การชมเชย เพื่อให้คนทำงานรู้สึกดี เน้นให้พนักงานแสดงทักษะจาก Environment ที่เตรียมสนับสนุนไว้แต่การทำแบบนี้ อาจจะมีการกำหนด Limit ไว้ด้วยนะ
  • Delegation Poker & Delegation Board กำหนด Level ของความรับผิดชอบ ว่าสามารถจัดการอะไรได้บ้าง โดยมีหลายรูปแบบทั้งไม่กล้าตัดสินใจ หรือตัดสินใจไปเลย
  • ช่วยท้ายๆ มีอีกหลาย Keyword เลย: Motivation 3.0 / Theory X, Y กับ Management 3.0

- Pair Programming สิบปีที่ผ่านมา (14:00 - 14:45)

  • Software เป็น Product ไม่ใช่ Project ดังนั้นต้องทำให้มัน Maintainability ได้ ทำให้มัน Long Live และไม่ยึดติดกับใครคนนึง
  • 10 ปีก่อน: Pair Programing ให้ 2 คนใช้คอมเดียวกันเขียน Code โดยมี navigator + driver
    • ข้อดี ทั้งสองคนรู้งาน เพราะทำร่วมกัน แชร์ KM / Skill ของคนถูกจูนให้เข้ากัน / ลด Commination Cost ในทีม
((- 10 ปีผ่านไป -))
  • Pair Programing มีงานวิจัยรองรับแล้ว Paper: THE COLLABORATIVE SOFTWARE PROCESS
  • Keyword Collective Ownership - ไม่ให้ Software ตกอยู่ในมือคนคนเดียว (จริงๆ น่าจะเป็นการทำงานอื่นๆ ด้วยนะ) การ Maintain มันจะขึ้นกับคนนั้นดูแล เกิดการคอขวด และลด risk
  • Benefit จาก Pair Programming
    • Pair-Pressure ช่วยกันดึง ให้เข้าใจร่วมกัน
    • Pair-Think - ได้ Solution ที่หลากหลายจากการ Pair
    • Pair-Relaying เพิ่งสิ่งที่แย่ไปเลย เขียน Test ผ่านแล้ว แต่ตอน Commit & Release ใส่ Fixed Bug 55 ถ้ามี Pair นอกจาก Product จะดี KM ยังถูกส่งต่อด้วยผ่าน เช่น Commit Message หรือ Release Note เป็นต้น
    • Pair-Reviews - มีคนคอยช่วยทวนสอบความคิดเรา
    • Debugging by Explaining - ทดสอบความเข้าใจระหว่างเรา และคู่ว่าเข้าใจตรงไหนไม่จากการพูดคุย และถกกันจนทำให้
    • Pair-Learning - เรียนรู้ไปด้วยกัน
  • Key Success Factors
    • Pair Jelling รู้ว่าทำไมถึงต้องทำ มี Goal อะไร
    • Project Ownership
    • Mutual and Self-Respect - อย่าคิดลบ สร้างกำแพงมาล้อมตัวเอง
    • Ego-Less Programming - คิดบวก และเปิดรับ พยายามอย่าเป็นคนเก่งที่สร้างความเจ็บปวดให้คนอื่น << อันนี้ชอบ
    • Workspace Layout - เช่น จอใหญ่พอให้คนช่วยกันดู มี Environment ที่ช่วยให้เกิดการสื่อสาร
  • จากทำงานเป็น Pair มี Code Coverage ดีกว่า มันลด Defect และช่วยให้ลด Effort ที่ใช้จัดการ Defect ให่น้อยกว่า Effort ที่ใช้สร้าง Feature ใหม่
  • Pair Programing ไม่จำเป็นต้องนั้งคู่ตลอดทั้งวัน อยู่กันสักนิด 15-20% ของวัน ซึ่งดีกับคนที่เป็น Introvert  และค่อยแยกย้ายไปทำงาน และ ช่วยbreak the ice และให้คู่ที่ Pair กล้าออก Idea ใหม่ๆ
((- จาก Pair Programing > Collective Ownership -))
  • การทำ Software ไม่ได้ทำแค่ Component เดี๋ยวๆ แต่เราต้องรู้ว่ามันเกี่ยวกับส่วนไหนของ Business
  • อย่าแบ่งงานส่วนใครส่วนมัน (SILO) พยายามทำให้ Cross Function ได้ จะได้ Move คนไปส่วนอื่นได้ โดยคนอื่นกลุ่มที่เรามาต่อสามารถดูแลต่อได้อย่างไม่มีสะดุด
  • เน้นทำให้เกิด Collective Ownership มองว่าตัว Code เป็นของทุกคนในองค์กรไม่ใช่ของคนใดคนหนึ่งในองค์กร จัดการได้ว่า Code ส่วนไหนที่เป็น Domain ที่เป็น Core ตรงนี้เราสามารถแบ่งงาน จัดความสำคัญได้ (Inhouse / Outsource) และถ้ามี Process ที่คุม Quality ที่ดี ส่งเสริมเกิดการ contribute feature เพิ่ม (อันนี้ผมมอง Open Source Project แต่ Scope อยู่ภายในองค์กรครับ)
  • สุดท้าย IT มันเข้าไปอยู่กับทุกองค์กร ไม่มี Agile for Non-IT (ไม่ชัวร์ว่าฟังมาถูกมะ 55)

- Facilitate Session Online (15:00 - 15:45)

  • Facilitator : คนที่ดำเนินการประชุม จัดการงาน / พิธีกร Moderator
  • Key Point ของ Session Facilitation สร้างพื้นที่อย่างไร ให้คนกล้าแสดงออก เพราะ Online ติดต่ออะไรยากกว่า Offline อีก อาจจะใช้วิธี Chat / Breakout Room
    จุดประสงค์ต้องการให้การประชุมมี Engagement สูงขึ้น อย่าในเกิด Dead Air

Blog ของท่านอื่นๆ

สุดท้าย


Discover more from naiwaen@DebuggingSoft

Subscribe to get the latest posts sent to your email.