[SCK เปิดบ้าน] Practical Agile (Software Development) For Leader

ที่มาที่ไป พี่ยุ้ย กานดา เป็นเพื่อนกับพี่ศร และได้อ่าน Facebook ที่พี่ศรเขียนจากการไปดูงานที่ ODDS แล้วสงสัยว่า ทำได้จริงเหรอ ก็เลยทักมาถามพี่หนุ่มว่า ทำได้จริงไหม ที่มัน Flat มากๆ มีไม่กี่ตำแหน่งในบริษัท พี่หนุ่มก็เลยเสนอว่า มาพูดคุยกันไหม จะเล่าให้ฟัง ก็เลยเป็นที่มา ที่พี่ยุ้ย พี่ศร คัดเลือกคนที่สนใจ แล้วมารวมตัวกันในวันนี้

พี่หนุ่มเปิดตัวด้วย การแนะนำสถานที่ SCK Dojo

• SCK เป็นชื่อ
• Dojo แปลว่า ลานฝึก

ตอนนี้ได้เข้าไปช่วยคุณยุ้ยที่ The Able ประมาณ​ 2–3 สัปดาห์แล้ว ดูว่าสิ่งที่ The Able ต้องการกับที่ SCK มี จะช่วยอะไรได้ไหม

2013 — สยามชำนาญกิจ ก่อตั้งด้วยคนสามคน รวมพี่ Ruff และคุณจั๊วะ (ODDS) ด้วย ตอนนั้นโหวตให้พี่หนุ่มเป็นผู้เซ็นเอกสาร

• ทำ Training, Leading Change
• ณ 2013 คำว่า Agile = Scrum ซึ่งตอนนี้ผ่านมาเป็นสิบปีแล้วก็ยังไม่ต่าง
• ณ 2013 พี่หนุ่มก็มีส่วนทำให้ Agile มันบิดเบี้ยว 5–6 ปีหลัง กำลังทำงานใช้บาป (ซ่อม) อยู่
• ในบริษัทอาจจะเรียก Agile Transformation — Transformation คิดภาพลดนำ้หนัก 100kg ให้เหลือ 60kg จะต้องเข้ายิมหนักมาก เราจึงใช้คำว่า Leading Change

2018 — แตก Line ออกมาทำ Training ในบริษัทของ Shu Ha Ri

• ที่นี่ไม่มีตำแหน่ง มีแค่แต่ละคนถนัดเรื่องใด ก็ไหลมารวมกัน เช่น พี่พฤทธิ์ เทียบได้กับ C-Level ของบริษัท เป็นพี่ใหญ่ ที่ดูแลภาพรวมด้านบนของบริษัท พี่หนุ่ม ประสบการณ์ Software Tester และเขียนโค้ดมาบ้าง และเคยทำ IT Operation ของเว็บ Sanook
• ปัจจุบันเราส่วนมาก ให้ความสำคัญกับ Agile เยอะมาก โดยละเลยความสำคัญของ IT Operation
• เคยทำการทดลองหนึ่ง เพื่อพิสูจน์ Self-managing Team หรือ Self-Organizing Team เข้าไป Site ลูกค้า ไม่สามารถทำให้ได้ เพราะไม่ได้ให้คุณให้โทษ และบางคนก็ดื้อตาใส ก็เลยทำ Project รับคนเข้ามาแบบไม่คัด Skill ไม่คัดประสบการณ์ เอามาผ่าน Bootcamp 11 สัปดาห์ โดยตัวเลขน่าจะมาจากการฝึกของ Navy Seal ทำงานรายสัปดาห์ (PDCA)
• ส่วนใหญ่ในไทยใช้ Extreme Programming อยู่ เช่น DevOps แต่ใช้โดยไม่รู้ตัว เป็นการใช้รวมในส่ิงที่เรียกว่า Agile
• ทีมงานที่เอามา Build เกิดจาก คน 6 คนจากฝั่งเรา และธนาคารแห่งหนึ่งส่งมาอีก 6 คน แล้วบ่มให้เกิด Self-managing Team ปลายทางคืออยากได้ทีมที่ส่งไปอยู่ Site ลูกค้าแล้วไม่ต้องสั่งการอะไร รับ REQs เอง วางแผนเอง เขียนโค้ด Deploy เอง มีปัญหาจัดการเองได้ ก็ได้ผลระดับหนึ่ง และส่งไปในบริษัทที่กำลัง Change อยู่ เพื่อให้เห็นว่า คนที่ถูกฝึกจริงจังหน้าตาเป็นอย่างไร เมื่อเทียบกับ ที่บอกว่าอยากได้ แต่ไม่มีเวลาให้ฝึก
• ที่ ODDS และ SCK เราเริ่มจากศูนย์ ไม่มีพนักงานอยู่เลย ซึ่งจะต่างจากพี่ๆ ทุกคน ที่มีคนเดิมอยู่แล้ว
• เวลาเข้า Site ลูกค้า เราเลือกไม่ได้ว่าจะส่งใครมาให้ปรับ มีแบบไหนก็ต้อง Build ให้ได้ เวลาพี่หนุ่มเลือก ก็ไม่คัด Skill เช่นกัน
• สำหรับพี่หนุ่ม ที่ Based เป็น Project Manager อยากได้ Skill คนที่สามารถจัดการได้ ทัศนคติได้ วัดว่า ตัวเองสามารถ Build คนพวกนั้นได้ไหม แล้วคนเหล่านี้จะถูก Build แบบรับความกดดันได้ไหม
• มันเหมือนซื้อหวย ไม่รู้หรอกว่าจะได้หรือเปล่า จนกว่าจะอยู่ได้กัน อยู่แล้วฝึกได้ หรือโยนหนังสืออะไรให้ไปแล้ว อ่านไหม หรือต้องตาม (Self-Learn)
• บังคับให้อ่าน มี Set หนังสือ มีมอบหมายและนั่งอ่านด้วยกันทุกเช้าก่อนเริ่มงาน หนังสือเป็นภาษาอังกฤษทั้งหมด ปัญหาของเด็กไทยคือแปลไม่ได้
• สนใจคนที่ช้าที่สุด และถ้าเราต้องการให้เป็นทีม อัตราความเร็วของทีม จะตามคนที่ช้าที่สุด
• สองสัปดาห์แรกจะดราม่ามาก มีทั้งคนเดิม และคนเข้ามาใหม่ ก็ต้องปรับสภาพ

2019 — เกิด We Love Bug ทำ Software testing เป็น Blog เขียนมาได้นานแล้ว แต่เพิ่งได้เริ่มทำ Testing Services จริงๆ ที่ไม่ใช่ กดหน้าจอ แต่เข้าไปช่วยปรับโครงสร้างการสร้าง Software หรือ Automation ที่มีอยู่เข้าไปซ่อมยังไง ทำยังไงให้เป็นเครื่องซักผ้าอัตโนมัติ ที่ใครอยากซักก็ซักได้ตลอดทั้งวัน

จาก Mar 2013 มีกันอยู่ 4 คน สู่ June 2024 มีอยู่ 30 คน และคิดว่าอยากโตไปให้ถึง 70 คน (ผมคิด: เหรอ)

Agile ปัจจุบันเพี้ยนไป

• ก่อนปี 2000 — Scrum ใช้ทำ Software แต่หลังจากนั้นใช้ทำ Software ไม่ได้
• พี่หนุ่มเป็นคนหนึ่งที่ช่วงปี 2013 พยายามทำให้มันทำ Software ได้ ตอนนั้นใน Workshop มันทำได้ เพราะมันเป็นระบบปิด แต่พอกลับไปหน้างาน ทำไม่ได้
• Business User ไม่สนใจหรอกว่า IT จะทำงานแบบไหน แต่จะเอางาน
• คนเจ้าของความต้องการเป็นผู้มีอำนาจสูงสุดก็ลัดคิว เกิดเป็นงานแทรกงานด่วน
• ตั้งแต่ปี 2013 มาจนปัจจุบันนี้ มีหลายที่แยกไม่ได้ว่าอะไรคือ Agile อะไรคือ Scrum

ช่วงพี่ๆ ที่เข้าร่วมกิจกรรม แนะนำตัวที่มาที่ไป และความคาดหวังจาก Session นี้

กลับมาที่พี่หนุ่มแนะนำที่มาที่ไป คุณลุง 17 คนผู้สร้าง (ปัญหา) ที่เป็นที่มาของ “Agile” (Alliance) ที่แต่ละคนนัดมาแชร์ประสบการณ์การทำงานของแต่ละคน (และครึ่งหนึ่งของ 17 คน มาจากสาย Software Engineering)

ถ้าเราเป็นผู้ว่าจ้าง จ่ายเงินคนที่มารับผลิต Software ที่ไหน?

เช่น

• พี่ๆ บางท่านยอมรับได้ที่ Test Env หรือต้อง Work บน Production ซึ่งก็มีความเสี่ยง อาจจะต้องถอยลงมาที่ UAT
• ขึ้นอยู่กับว่า แต่ละรอบ Objectives คืออะไร ตรวจรับกันอย่างไร เสร็จคืออะไร (Definition of Done) เช่น รู้ว่า Security ต้องทำ แต่ยังไม่ต้องทำตอนนี้ รอบนี้ขอดู Functional เล็กๆ ก่อน
• การมี Sprint คุมรอบการทำงาน ไม่ติด แต่ที่พยายามทำคือ ได้รับ Feedback จาก User ทุกสัปดาห์
• ความยากคือ ต้องมีคน Design ให้ได้ก่อนว่า Working Software คืออะไร นั่นคือการเตรียมการก่อน (ซึ่งมักถูกละเลยความสำคัญ)
• เวลาจริงใน Sprint (10 วัน) มีเวลาทำงานจริงแค่ 6–7 วันเท่านั้น มันยากมากที่จะได้ Working Software ใน 1 Sprint

นี่คือประสบการณ์ของคุณลุง 17 คน ที่เราไม่รู้ว่าเขาทำ Software อะไรกันมา บวกกับประสบการณ์ที่เขามีมากกว่า

— ในไทย CMMI ก็ประมาณ 20 ปี โดดมาอีกสิบปีก็ Agile อีก พอโดดมาเลยก็มีความนัวๆ อยู่

พี่พฤทธิ์ แนะนำ Agile Umbrella ที่ได้จากการพูดคุยกับหนึ่งในคุณลุง 17 คน

สิ่งที่พี่ๆ ต้องไปตั้งเองที่บริษัทคือ Agile ของบริษัทตัวเองหน้าตาแบบใด

• พี่ ศ: เชื่อว่า Agile ไม่ได้ช่วยเรื่องเวลา แต่ช่วยเรื่องคุณภาพ Waterfall คือ User ไม่ได้ของที่ฉันพูด แต่ต้องทน เพราะทนมา 1 ปีแล้ว
• พี่ ค: บอกว่า Agile ทำให้คุณภาพตก เพราะว่าเรารีบทำไปหมดเลย รีบขึ้น ตัดหลายอย่างออก พวก Non-functional ก็ไม่ได้รับการพิจารณา ไม่เชื่อเรื่อง Quality แต่ Trade-off เรื่อง Business ได้
• พี่หนุ่ม: จะ Trade-off เอาขึ้น Production ก็ได้ แต่บอกทีม Operation ด้วย จะได้รับมือทัน
• พี่อีกท่านก็คิดว่า เราประเมินงานพลาดหรือเปล่า มันไม่ควรรีบ
• พี่หนุ่ม: ใน Scrum ฉันมีกำลังการผลิตเท่านี้ ของก็ต้องตวงมาให้มันพอดี
• พี่ ก: มันลดความเสี่ยง เพราะ User ได้เห็น ว่ามันไม่ได้ผิดจากที่ฉันคิด ถ้าผิดก็เห็นเร็วหน่อย Comment เร็วหน่อย คุณภาพเป็นเรื่องที่ต้องควบคุม แต่ก็ต้องควบคุม User ให้อยู่นะ เพราะ User บางคนก็จะฟุ้ง
• พี่ จ1: ผมชอบที่พี่บอกว่า มันช่วยเรื่อง Change
• พี่ ธ: เขาอยากขึ้น Production อันนี้เห็นด้วย แต่ไม่ได้อยากได้ปัญหา อยากเข็นของขึ้นไป โดยไม่ Damage เรื่องคุณภาพ
• พี่ จ2: สิ่งที่ Agile ให้คือ ได้เห็นความคาดหวังของ User ได้เร็ว เช่น โครงการ 2 ปี ต่อให้มี UAT เก็บ REQs ทำ Prototype ไปดูดี แต่พอ UAT คนละเรื่อง ที่ทำอย่างน้อยก็ 5–7 Sprints ซึ่งก็ดีกว่าทั้งโครงการแล้วอีกสองปีมาเจอกัน เพราะตอนนั้น ความคาดหวัง ความต้องการของ Business อาจจะเปลี่ยนไปหมดแล้ว ทีมต้อง Full Team เลยไม่เจอปัญหาขาดคน ถ้าขาดคนก็เติม หรือไม่ก็ไม่รับงาน
• พี่หนุ่ม: Quality จ้างผมเขียนโค้ด ถ้าส่งมอบให้ลูกค้าแล้ว ลูกค้าดูแลต่อไม่ได้ ตกเรื่อง Maintainability หรือรับโหลดอะไรไม่ได้ ก็ตกเรื่อง Scalability การทดสอบที่พลาดเยอะ คือ เราไม่เคยเอา Stakeholders ที่เป็น Infra, Security มาให้ REQs เชิง Performance ระบบเลย
• พี่พฤทธิ์: เราอยู่ในธุรกิจ IT เดียวกัน แต่บริบทไม่เหมือนกัน รูปแบบของพี่ จ. ที่เป็นราชการก็เป็นอีกจักรวาลหนึ่งเลยนะ ต้องถอยกลับมาก่อน เข้าใจ Value Steam ของเราก่อน ว่าไลน์การผลิตของเรา ตอบโจทย์ธุรกิจอะไร มี Value อะไรที่จะส่งมอบ ใครคือ Stakeholders ใครคือ User จริงๆ ที่จะรับ Outcome ตัวนี้ นี่คือส่ิงที่เราต้องทำความเข้าใจ

Iterative Development

จบ 1 รอบ ได้ทำการทดสอบ ได้ Feedback จากผู้ใช้งาน

• พี่หนุ่ม: ปัญหาที่พบตอนนี้คือ Testing ที่เอาวิธีการทำงานแบบ Waterfall มาใส่ในการทำงานเป็นรอบ วิธีแก้คือ ยก QA ออกไปนอก Sprint เอาคนที่เป็นคนกด Manual ออก และใส่ Automation เข้าไป
• พี่ ศ: เข้าใจว่า ทำ Automation Test ได้แค่ Unit Test เท่านั้น
• พี่หนุ่ม: Postman ทำได้ก่อน ที่จะเอาไป Dev
• พี่ ก: พยายามทำอยู่ แต่ยังไม่ได้อย่างที่อยากได้
• พี่ ธ: Automation มี Costในการ Maintain
• พี่หนุ่ม: ใช่ Cost ในการ Maintain Automation สูงมาก ถ้าฝากไว้ที่ QA จะลำบากมาก เพราะ QA ไม่ได้ขึ้นไปอยู่บน Production ด้วย
• พี่พฤทธิ์: ชวนมองว่า QA คือกิจกรรม เป็นหนึ่งในทักษะของการสร้าง Software
• พี่หนุ่ม: ถ้า User มารอบแรกแล้วไม่เห็นของ หรือเห็นของง่อยๆ เขาจะไม่มาอีกเลย ณ​ วันนั้นที่เคยทำกับธนาคารแห่งหนึ่ง คาดว่า 3 Sprints น่าจะเห็น ขอเชิญ น้อยที่สุดของสามกลุ่มตัวแทน ตกลงกันไปมา เชิญมาทำ Sprint Review ได้ 90 คน โดยแต่ละห้องจะมี BA ที่ดูแล Business Domain มีทีม Vendor ประจำ ต่อ Projector ขึ้น เอาใบกระดาษ ปากกาใส่ไว้ให้ในห้อง เชิญ User เข้าไปในห้อง แล้ว Demo งานจำนวน 3 Sprints แล้วให้ลองเล่นในห้อง คนเขียน REQs คือ BA ธนาคาร ไม่เคยเป็น Sales หน้างาน
• พอ User มาจริงๆ พบว่า สิ่งที่ทำมาไม่ตอบโจทย์จริงในการไปหาลูกค้าที่หน้างาน
• กระดาษ A4 ประมาณ​ 200 ใบ Post-it ที่เตรียมไป ใช้ 6 Thinking Hat ถ้าไม่ชอบ มาด้วยคำแนะนำ อันไหนชอบ ก็ชมหน่อย ได้กลับมา 500 Post-it
• ช่วงบ่าย ทีมงานแยกข้อมูล Feedback User แล้วตัดสินใจว่า จะทำอะไรกับสิ่งนี้ หรือจะทำของตามแผนงานใน Sprint 4 ที่วางไว้

• สิ่งสำคัญคือ เบอร์หนึ่งด้านบนที่ดูแลฝั่ง Business User ต้องไปกับเราด้วย

การขึ้นเงินเดือนที่ SCK (ที่ ODDS ก็น่าจะใช้เหมือนกัน)

• น้องๆ ที่นี่เห็นเงินเดือนของทุกคน เพราะรู้ว่า แต่ละคนทำอะไรได้
• เวลาขึ้นเงินเดือน ให้เอา Skill มาแลก ไม่ใช่เอา จำนวนงาน (ปี) มาแลก
• Career Path ในองค์กรคือ ตำแหน่ง
• Career Path ของที่นี่คือ Skillset ที่เพิ่มขึ้น

พี่ ก.: เราพยายามทำเป็น Flat แต่ น้องๆ มาบอกว่า ไปกู้บ้านไม่ได้ เพราะคนปล่อยกู้ไม่ใช่ตำแหน่ง Manager ไม่เข้าใจตำแหน่ง

พี่หนุ่มแชร์ตัวอย่าง การขอขึ้นเงินเดือนของน้องๆ WLB ที่ต้องเอา Skill มาแลก (Post-Paid)

• ขอด้วยเหตุผลอะไร
• เอา Skill อะไรมาแลก Technical Skill และ Soft Skill (ซึ่งไม่ใช่ Skill อะไรมาแลกก็ได้ พี่หนุ่มแอบล็อค Spec แบบเบาๆ)
• ทำแผนมาให้ พร้อมด้วย จะวัดอย่างไร ซึ่งที่นี่จะวัดเป็นตัวเลข
• จะใช้ใครเป็น Mentor ใครเป็นผู้วัด
• พี่หนุ่มถามทุกไตรมาส และให้บอกล่วงหน้า 1 ไตรมาส

พี่พฤทธิ์: การเตรียมความพร้อมสำคัญมาก ก่อนจะมาเขียนแบบนี้ได้ อาจจะธาตุไฟเข้าแทรกก่อน

พี่หนุ่ม:

• เอาวิธีนี้มาจากฟุตบอลอาชีพ
• ถ้าจำนวนคนเกิน 50 คน ก็ต้องเพิ่มคนมาช่วยรีวิว เพราะพี่หนุ่มคนเดียวไม่พอ
• ในฝั่งของ WLB คือ Post-Paid ส่วนเคส SCK บางคน (Pre-Paid) อย่างผมกับพี่นุ่น (เม้ง นัท) ที่บังคับให้ แล้วค่อยเอา Skill ตามมาแลก
• ให้เทียบกับตัวเองเมื่อวาน ถ้าเทียบกับคนที่เก่งกว่าเราก็จะเหนื่อยเลยนะ
• ปลายปีที่แล้ว ถึงเวลาวัดผล ชาว WLB มีแต่แผนงาน ไม่มี Progress สรุปว่า ไม่มีใครได้ขึ้น
• ก็เลยปรับเป็น เมื่อไหร่ที่ไปทำงาน แล้วลูกค้าเซ็นสัญญา บวกเงินเพิ่มทันที
• เดือนที่แล้ว มีใครอยากขึ้นเงินเดือนไหม ก็มีตอบมาแค่สองคน ที่เหลือก็ยังไม่ขอขึ้น
• ซึ่งล่าสุด ก็เพิ่งมีคนลาออกไป 5 คน เพราะความเป็นอยู่ที่นี่ ไม่ง่าย
• น้อง WLB ไม่เข้าใจการทำงานเป็น Sprint แต่ต้องทำงานเป็นสัปดาห์ ตั้งแผนและส่งมอบงานได้ ทุกเย็น ต้องนัดลูกค้า เพื่อ Demo งานให้ดู
• ต้องดูว่า ความเร็วระดับไหนที่ตอบโจทย์องค์กร และบริหารความเสี่ยง

พี่พฤทธิ์:

• รายสัปดาห์ รายวัน
• หนึ่งในปัญหาคือการประมาณการ (Estimation) เราเดาได้ใกล้เคียงแค่ไหน
• ถ้าทีมยังไม่สามารถวางแผน และส่งมอบไม่ได้ในระดับวัน ลืมไปเลยว่าจะทำได้ในระดับสัปดาห์ หรือ Release

พี่หนุ่ม:

• Technical Skill ผ่านการ Train เขียนโค้ดอะไรได้ Waterfall ยังมี Manager ช่วยขึงอะไร แต่พอเป็น Sprint ทำงานกันเอง มันตีกันแน่นอน ทำยังไงจะ Build ขึ้นมาเป็นทีมได้ ก็ต้องเสริมพวก Soft Skill เข้ามาด้วย
• ที่บริษัทตอนนี้ เป็นทีมหรือเป็น Working Group ตอนนี้ทีมมีเป้าร่วมกันหรือเปล่า?
• SCK ที่เราเข้าไปช่วย ยัง Build เป็นทีมไม่ได้ เพราะเราไม่ได้เป็นคนให้คุณให้โทษ เป็นเรื่องของ Manager ที่ Site ลูกค้าต้องดูแลต่ออีกที
• Micro-learning แทนที่จะเรียน 3 วัน ก็จัดเป็นเรียนสั้นๆ วันละชั่วโมงหรือสองชั่วโมง เรียนถี่ๆ เช่น 17:00–19:00 น. ชั่วโมงแรกเป็นเวลาบริษัทในการลงทุน อีกหนึ่งชั่วโมงคือการเอาเวลาตัวเองมาลงทุนด้วย คนเป็น Manager ต้องวางแผนพัฒนาทักษะล่วงหน้า เพื่อให้เวลาทำงานจริงสามารถใช้งานได้
• ส่วนมาก คนจะเพิ่มทักษะเมื่อจะย้ายงาน

พี่ ธ: Self-managing Team คือ empower ทีม ให้อำนาจในการตัดสินใจ

พี่หนุ่ม:

• ทีมที่เคยสร้าง ใช้เวลาในการ Build และเสียค่าใช้จ่ายอย่างน้อย 2M (ต้นทุนสูง) แต่รุ่นนั้น ก็ออกตามวาระการเปลี่ยนงาน (ประมาณสองปี)
• Gen Z และ ยุคโควิดเบ่งบาน จะรับความกดดันแบบนี้ไม่ได้ ถ้าต้องอยู่ช้า ทำงาน ส. อา. จะออกอาการทันที เวลาทำงานอยู่บน Social
• ตอนนี้ไม่มีทีมพัฒนาให้เช่า แต่เรารู้แล้วว่าทำอย่างไร
• ทีมต้องเป็น Long-Live ถึงจะเก็บ Velocity ได้

พี่ท่านหนึ่งแชร์ว่า ยิ่งมี Roles ใน Software เยอะ และแต่ละ Roles ก็ดูสูงส่งมากขึ้นเรื่อยๆ มันก็เลยยากในการจะสร้างทีมแบบนี้)

พี่หนุ่ม: ถ้า Build ทีมแบบนี้ไม่เหมาะ ก็สร้าง Skill เป็นผู้เชี่ยวชาญ พอรวมตัวกัน ก็รู้ว่าต้องไปรบยังไง

พี่พฤทธิ์: พี่ๆ ทุกท่านรู้ใช่ไหมครับ การเติมคนเข้าไป ไม่ช่วยทำให้เร็วขึ้น — พี่ๆ ทุกคนกล่าวว่า รู้ อย่างเสียงดังฟังชัด ส่วนคำตอบก็คือ

• แต่มันไม่มีทางเลือก
• การไม่เติมคน ไม่ช่วยเขา ไม่ช่วยทีม
• ทำงานช้า คนไม่พอ เติมคนไป ลูกค้าสบายใจ แต่เรารู้อยู่แล้วว่า มันไม่เร็วขึ้นหรอก
• ใน Steering ไว้กล่าวว่า เรารู้ปัญหาแล้วครับ คนกำลังจะมา

พี่หนุ่ม: ของ ODDS — Scale เพราะต้องรับงาน แต่องค์กรของพี่ๆ ไม่ได้ Flat ขนาดนั้น ไม่ใช่ทุกคนทำงานแบบนี้ได้ บางคนก็เก่งเฉพาะด้าน มันไม่ใช่เรื่อง Skills แต่คือสภาพจิตใจ

• มีเป็น Sprint แต่ก็ต้องให้ฉันตัดสินใจทั้งหมด (พี่ ก: ใช่)
• และธรรมชาติของ Developer ที่พยายามสู้สุดชีวิต จนบ้านไฟไหม้

พี่ ย: ทีม In-house ใน Corporate และมี Vendor มาทำงานให้ มันรันคนละตำราหรือเปล่า

พี่หนุ่ม: อย่างที่บอกไป ทุกที่ใช้ Agile หมด แล้วแต่ละที่ไม่เหมือนกัน แต่ Vendor เขาต้องเล่นในเกมเรา เพราะแต่ละที่ ไม่เหมือนกัน ถ้าคุณมีหนทางอื่น เสนอมา แต่เราต้องควบคุม เพราะทุกที่ก็ต้องรักษาผลประโยชน์ตัวเองเป็นหลัก

พี่ ธ: ตอนนี้เหมือนเล่นกันคนละกระดาน และแต่ละที่ก็มี Academy ของตัวเอง ส่งเข้าไปแล้วออกมาเหมือนกัน

พี่พฤทธิ์: ปกติแล้ว ไม่ว่าจะ Ixx หรือ Axx ก็จะมี framework แต่จะโดน customize บางอย่างที่หน้างาน

พี่​ ธ: แต่สุดท้ายเขาก็จะรักษาผลประโยชน์อยู่ดี (conflict of interest)

พี่หนุ่ม: เพื่อไม่ให้คอขวดที่ Manager ก็ต้องบอกว่า เขามี Authority ที่ระดับไหน

พี่พฤทธิ์: ถ้าเราเป็นผู้ว่าจ้าง แล้วจะอยู่กันระยะยาว ต้องมีส่วน Support กัน

พี่ ธ: เคยไปช่วยธนาคารแห่งหนึ่ง แล้วต้อง outsource ก็มี workshop คุยเรื่อง process การทำงาน มีการ define R&R ส่งต่ออะไร ส่งมอบอะไร

พี่ ค: ฝึกพวก Soft skill ยังไง

พี่หนุ่ม:

• เรียนแล้วต้องทำซ้ำ
• มีทั้งสอน หรือ 1–1 หรือ ทำให้ดูเป็นตัวอย่าง
• ทำได้ไม่ได้ไม่รู้ แต่ต้องทำ
• ซึ่งวัดผลยากได้ ต้องสังเกตพฤติกรรม ทั้งต่อหน้าและลับหลัง
• ที่พี่หนุ่มให้ความสำคัญมากคือ Project Management มีวางแผน ถ้ามีปัญหาต้องรีบบอกทันที

กลับไปที่บริษัทของทุกคน ถ้าต้องทำงานเป็นรอบ Loop แบบไหนที่เหมาะสม ที่จะดึง Business User มาด้วย

การสร้างทีม ทำไมมันถึงแพง? เพราะต้องเอาคนมาเฝ้า

• ตอนนั้นฝึกทีมแบบ XP ให้หา Coding Standard กันเอง พอกลับมา Review ถ้าผิดตาม Coding Standard หรือสะกดผิด เพียงจุดเดียว ลบทิ้งหมด และทุก Code ต้องมี Unit Test คลุม (TDD) ถ้าพบการเอาโค้ดที่ลบทิ้งไปแล้วกลับมาเมื่อไหร่ ออกทุกคน
• โดนลบไปสองครั้ง รอบหลังมีคนหนึ่งจะมาคอยรีวิวกันเองก่อนที่จะเจอ พี่หนุ่ม หรือ พี่บอย
• แต่งประโยคชื่อ function ต้องอ่านแล้วรู้ ถ้าพี่หนุ่มอ่านแล้วไม่รู้เรื่อง ต้องลบ แก้ไข

ผู้เข้าร่วมท่านหนึ่ง: ทุกวันนี้มันมี AI เด็ก Gen Z อาจจะรู้สึกว่าไม่ต้องมาเรียน หรือมา 1–1?

• ถ้าเขียน Code ใหม่ อาจจะไม่ยาก แต่ถ้า Code อยู่มาสิบปีแล้ว มันจะเขียนตามกันได้ไหม
• พี่หนุ่มคิดว่า ใช้ได้ แต่เด็ก Gen ใหม่ ต้องถูกให้ความรู้ก่อนว่า ระบบ หรือสถานการณ์หน้างานเป็นอย่างไร
• เพราะตอนนี้น้องๆ WLB ก็ใช้อยู่ ในการช่วยเขียน Test Cases แต่ผลที่ออกมา ก็ต้องบอกได้ด้วยนะว่า มันใช่หรือไม่ใช่
• พี่พฤทธิ์: ของใหม่ที่ใส่เข้ามา ยังไงก็ต้องโดน Regression test สิ่งที่เราออกแบบยังต้องทำงานได้อยู่ ที่เราออกแบบต้องใช้งานได้ ที่คนอื่นออกแบบก็ต้องใช้งานได้

พี่ ก: ขึ้นกับตัว Test ว่ามันครอบคลุมแค่ไหน? มีอะไรเปลี่ยนเข้าไปปุ๊บ โดน impact ไปหมดแล้ว

พี่หนุ่ม

• Regression test มี 1,200 แต่จะแก้ ก็ต้องระบุก่อนว่า Direct Impact อยู่ที่ไหน ต้องคนมีชั่วโมงบินสูงมาช่วยวิเคราะห์
• ถ้ามี Automation คลุมทั้งหมด 1,200 ให้ดึงตัวที่ต้องใช้มารันก่อน ไม่ต้องใช้ทั้งหมด
• ตอนนี้ Automation ระบาดมาระยะหนึ่ง และจะกลายเป็นใช้ไม่ได้จริง เพราะไม่ได้ถูก maintain หลังขึ้น Production (ที่มี CR, Incident)

พี่ ก: พอเราเอา Dev มาช่วยทดสอบ เขียนเอง ทดสอบเอง ยังไงก็ผ่าน พอเจอ User คลิกๆๆ ตายหมดเลย

พี่หนุ่ม:

• ตอนที่พี่หนุ่มเคยใช้ ถ้า QA หลุด แบบที่ User ไม่ได้มี Design อะไร ให้ QA และ Dev ไปนั่งดู User กด แล้วเอากลับมาคุยกันว่า ทำไมสิ่งนี้ถึงหลุดขึ้นไป
• Scrum จะมี Retrospective แนะนำให้เอาปัญหามาคุยกัน เพราะที่มาของพิธีกรรมนี้คือ Toyota — Problem Solving
• หาคนที่มี Skill Problem Solving มาใช้ เอา Data มาคุย เพราะนายเก่าพี่หนุ่ม เป็น Lean Sigma
• ต้องมีคนเข้าไปช่วย หาคนเข้าไป Implement และมี Cost ในการ Maintain ด้วย

พี่พฤทธิ์:

• Continuous Build และ Improvement เวลาที่เราสร้างชิ้นงานหนึ่ง หรือ REQs เข้ามาเป็น E2E Process มันจะถูกฉีกด้วย Test Cases/Test Scenarios ซึ่งก็มีความ Challenge เพราะต้องใช้ผู้มีประสบการณ์
• การเริ่มด้วย Automation เลยอาจจะไม่ใช่ทางเลือกที่ถูก ต้องเริ่มจากการออกแบบ ทำด้วยมือก่อน แล้วค่อยเลือกสิ่งที่ทำ Automation เพราะ Cost มันสูง

พี่บอม:

• บางทีเราเห็นอะไรบางอย่าง เราคิดว่ามันจะแก้ปัญหาอะไรบางอย่าง
• Impact Analysis, การ Design ก็สำคัญ
• เราต้องรู้ว่า เงื่อนไขอยู่ตรงไหน เราจะทดสอบเมื่อไหร่ ถ้าเราเอาทุกอย่างมาทำ ก็จะพัฒนาเยอะ รันก็นาน ค่าใช้จ่ายในการทำซ้ำก็จะเยอะมาก
• E2E อาจจะตอบในกรณีที่มันร้อยกัน แต่มันตอบ Business Logic จริงหรือเปล่า
• Condition ที่เราต้องการทดสอบอยู่ไหน อาจจะเป็น function เดียว หรือหน้าจอเดียว เราก็ทดสอบที่ตรงนั้น
• 1,200 cases มีโอกาสมากที่ต้อง Login เข้ามาก่อน เพื่อจะเข้าไปให้ถึง function นั้นที่ต้องการทดสอบ
• เราไม่ได้มีเรื่องเดียว ที่จะแก้ปัญหาทุกเรื่อง
• ต้องเอา Expert มาวิเคราะห์ว่ามัน Impact ตรงไหนที่มันมีผลกระทบ แต่ถ้าเรามีน้องใหม่ ก็ต้องค่อยๆ เติมเข้าไป

พี่ ก: ถามไปถึง Tools เลยนะ เรากำลังแก้ Field นี้อยู่ มันจะไปกระทบกับใครบ้าง เช่น 18 หน้าจอ 20 รายงาน มันมีเครื่องมือไหม

พี่บอม: ใน software development พยายามหา เช่นพวก microservices เราก็ยังต้องใส่อะไรหลายๆ อย่างเข้าไป มันต้องทำให้ service รู้ได้ว่าเค้าต้องคุยกับใคร เบื้องต้น เริ่มตั้งแต่ design แต่ถ้ามันเจอปัญหาแล้ว ระบบ monitoring มันต้องชัด ถ้าเรามี information เราจะเริ่มวาดจักรวาลของ software ได้ เริ่มเห็นแล้วว่า ถ้าเราแก้ ใครใช้ต่อ แปลว่ามีความเสี่ยง ถามว่า โยนไปแล้วให้มันวิเคราะห์ได้ ตอนนี้ยังมองหาอยู่เหมือนกัน

พี่หนุ่ม: เคยไปช่วยลูกค้า มีคนที่พยายามเขียนอยู่ว่า ถ้าแก้ตรงนี้กระทบตรงไหน เชื่อว่าใน Academic น่าจะมีอยู่ เดี๋ยวขอไปหาก่อน

พี่พฤทธิ์: ทุกอย่างมี Cost ของการ Maintain ใน Telco บอกได้เลยว่า ถ้าอันนี้ตาย แตะ Service ตัวไหน เพราะมันมี SLA อยู่

พี่บอม: Jenkins, GitLab CI คือ มีเอาไว้แปลงของที่คนต้องทำ ให้ระบบมันทำ

• เช่น Pack file ไปวางบน Server ถ้าเดิมไม่เคยได้ Quality เอาไปใช้ ก็ไม่ได้ Quality เหมือนเดิม
• ถ้าจะคุยเรื่อง Quality กลับมาที่เรื่องคนก่อน ทำงานบน Quality หรือเปล่า แล้วค่อยเปลี่ยนเป็นเครื่องมือ
• ใช้คน Review Source Code ซึ่งเดิมใช้คนมาตัดสินใจ ก็เลยมี Tools มาบางอย่าง เช่น SonarQube ที่มาช่วยเช็คเบื้องต้น

คำถาม: ถ้ามีคนทำแบบนี้ได้ในบริษัทของพี่ๆ อยู่ในทีมเล็กๆ 6–7 คน (ทีม) ที่บริษัทของแต่ละคน ทำได้ไหม คุ้มทุนไหมที่จะ Build

อารมณ์เหมือนมี Avengers ทีม แต่มัน Duplicate ไม่ได้นะ เพราะแต่ละคนไม่เหมือนกัน

• Practical = ในชีวิตจริงมันไม่ได้ง่ายขนาดนั้น พี่หนุ่มเลยใช้พื้นเป็นสีดำ เพราะการ Build ทีมจริงๆ มันไม่ง่าย
• Agile = เป็นสีแดง เพราะเดือดแบบนี้มาตลอดสิบกว่าปี — Scrum เป็นแค่ยานพาหนะหนึ่งเท่านั้น ถ้าไปแล้วมันไม่สะดวกก็เปลี่ยนยานพาหนะ (ภาพประจำ 3 Layers ที่ SCK ใช้ DSDM — SCK — XP)

พี่ ศ: ด้วยความที่มีอำนาจ ใครไม่พร้อมปรับก็จากไป

พี่หนุ่ม: ถ้าเป็นต้นไม้ที่ตายแล้วก็ต้องหาที่ใหม่ให้อยู่ ส่วนคนใหม่ก็ต้องค่อยๆ Build ซึ่งสภาพ การเป็นอยู่คือ ต้องชัด และต้องมีคนไปถางป่ารอไว้ก่อน เช่น ส่งทีมไปในจุดที่พี่บอยอยู่ แล้วทำงานจริงตามที่เทรนมา ซึ่งระดับ Manager ต้องทำให้ดูเป็นตัวอย่างได้ ก็ไม่ใช่ทุกคนอีก

พี่พฤทธิ์: เครื่องมือเป็นอะไรที่ตกเร็ว แต่สาระสำคัญคือ พฤติกรรมของคน

พี่หนุ่ม: ให้เป็น Project Manager ที่ Upskill เอา Timebox มาใช้ในการบริหารจัดการความเสี่ยง อย่าเอามาเป็น Scrum Master ไม่งั้นทีมจะโดนไล่บี้หนัก

พี่พฤทธิ์: สิ่งที่น้องๆ ทุกคนสัมผัส คือสิ่งที่ส่งมอบกับลูกค้า ทุกคนรู้ค่าตัวรายวันของตัวเองอยู่แล้ว ถ้ามันไม่เกิดการซื้อซ้ำในมุมลูกค้า นั่นหมายความว่า ตัวเองต้องพัฒนา

พี่หนุ่ม​: อ่านไม่อ่านก็แล้วแต่ แต่เรียกใช้เมื่อไหร่ต้องได้ แต่ก็ต้องรู้จัก Build ของแต่ละคน

พี่พฤทธิ์: น้องๆ สามารถสร้างความสัมพันธ์สิ่งที่เค้าทำ กับ outcome จริงๆ ได้หรือเปล่า เช่น ทำในเชิงเทคนิค ทำให้ยอดขายไตรมาสนั้นขึ้น ก็จะส่งผลกระทบกับ performance

พี่หนุ่ม​: วิธีแบบนี้อาจจะใช้ไม่ได้แล้ว เพราะเขาไม่ได้สนใจการเติบโต ไม่มี sense of ownership แล้ว ถ้ามหาวิทยาลัยไม่ได้ติดมา ก็ต้องสอนกันใหม่

พี่ ศ: สัมภาษณ์เด็กเองทุกคน มีเด็กๆ เยอะมาก ที่คิดว่า เขาอยากเก่ง อยากได้ของ มาลอง อยากได้อะไรใหม่ๆ เราก็ให้ตัวเลขเขา ก็ Happy แต่พอเทียบกับคนเก่าก็ไม่ได้ ก็จะมีเด็ก 2x ที่ได้ค่าตัวดีอยู่ “อย่าเพิ่งหมดหวัง”

พี่หนุ่ม: ตัวเลข 1–1.5 ปี อาจจะเป็นตัวเลขที่เด็กๆ จะอยู่

พี่ ศ: ช่วงแรกเป็นแบบนี้เลย อยากได้สัญญาระยะสั้น 6 เดือนได้ไหม แต่พออยู่ไป เคมีมันเริ่มตรงกัน

พี่หนุ่ม: ตอนอยู่ที่เดิมก่อนมาทำ SCK ให้น้องๆ เข้ามาสัมฯ ด้วย แล้วมีสิทธิประเมินว่าจะรับหรือไม่รับ ตอนประเมิน Probation ทีมก็ต้องมาให้คะแนนด้วย

พี่ ศ: ตอนแรกจะคุยเรื่องตัวเลขเป็นหลัก ช่วงหลังเริ่มมีความสนุก หลายคนกลับมา office เพราะอยากเจอทีม

พี่หนุ่ม: พอ Gen Gap มันห่างมาก Style มันจะต่างกันมาก แนะนำให้ Build คลีนๆ มาเลย แล้วให้คนมีประสบการณ์มาเป็น Domain Expert ซึ่งก็ต้อง Groom เพื่อให้รู้ว่าพี่ๆ ต้องทำอะไร และเขาก็ยังต้องเป็นเดอะแบกไปอีกสักพักหนึ่ง

ถ้าเป็นบริษัทพี่ๆ ทุกคน พี่หนุ่มควรอยู่ตำแหน่งอะไร?

พี่ จ2: ที่บริษัทมี Resource Pool Manager: Recruit — Retain — Release

พี่ ธ: People and Culture ในมุม Technical Skill

พี่ ก: Performance management มันมีหลายอย่างที่จะ Drive performance ได้ ไม่ใช่ 1 solution fit all

พี่ น: ถ้าพูดถึง Industry ที่อยู่ คือสามารถ Drive Organization Performance ได้ ไม่ใช่แค่เรื่องคนอย่างเดียว

พี่หนุ่ม:

• กลับไปที่บริษัท ดูคนของตัวเองก่อน ต้องมีกลุ่มคนที่รับผิดชอบเรื่องนี้เฉพาะ
• ตอนนี้ Agile Transformation มากสุดคือ การทำงานเป็น Sprint แต่สุดท้ายแล้ว Skill เป็นเรื่องสำคัญ
• ตอบคำถามที่มาที่ไปของวันนี้ว่า มันสร้างได้จริง แต่ ที่ SCK และ ODDS เริ่มจากศูนย์ขึ้นมาเลย ซึ่งสมการของพวกเรากับพี่ๆ ที่มาร่วมวันนี้ ไม่เหมือนกัน
• Bas Vodde คือคนที่ตั้งบริษัท Odd-E สิงคโปร์ เคยมาสอน Certified Scrum Master มีคนถามว่า ถ้าอยากเปลี่ยนองค์กร ต้องใช้เวลาเท่าไหร่ Bas ตอบว่า ต้องใช้เวลา เท่ากับที่สร้างบริษัทมา
• เราอยากได้ Scrum Organization หรือต้องการ Deliver ของให้ทันท่วงที?

ช่วงพี่ๆ ให้ Feedback หรือพี่หนุ่มเรียกว่า Return On Time Investment

“รู้อะไรไม่สู้ รู้จักกัน “ — คำคมปิดท้าย จากพี่ยุ้ย