รีวิวและสรุปเนื้อหางาน Agile ในชีวิตจริง แบบไม่มีกั๊ก (ที่ตัวเองเข้า) #agilethailand2022

งาน Agile Thailand เป็นการรวมตัวของ Community คน (พยายาม) ใช้ Agile ในการทำงาน คนที่พยายาม Transform อะไรบางอย่างให้ทีม ให้องค์กร ซึ่งเป็นการ (แย่งกัน) กดตั๋วฟรี จำนวน 3 รอบ คือวันที่

• 7.7 เวลา 7:00 แน่นอนว่าสายเช้าและสายรีบอย่างเรากดได้บัตรรอบนี้ (ต้องขอบคุณพี่ปอม Lean In ที่แชร์โพสต์ และ FB algorithms ไม่ใจร้ายกับเรา)
• 13.7 เวลา 13:13
• 20.7 เวลา 20:20 ซึ่งรอบนี้เต็มเร็วมาก อัตราการแย่งชิงสูงกว่ารอบที่1 อย่างมีนัยยะ

พอกดบัตรรอบแรกได้แล้ว พี่ปอมก็ทักมาขอ Quote ว่า Agile ในชีวิตจริงของเราคืออะไร ก็ส่งให้พี่เค้าไปพร้อมภาพหน้าตัวเอง ซึ่งใช้เวลาไม่นานสิ่งนี้ก็ไปอยู่ในเพจ Agile Thailand ก็ช่วยแชร์มันออกมาไว้ที่หน้าตัวเอง มีหลายคนมากที่คิดว่าเราไปเป็น Speaker งานนี้ ซึ่งมันไม่ใช่ล่ะ 55+

ซึ่งพอไปไถดูของพี่ๆ คนอื่นแล้ว ทุกคนล้วนมีสาระเรื่องการงาน ตัดภาพมาทางนี้ก็คือ… ข้ามเราไปแล้วกันนะ

โดยงานพบปะครั้งนี้ใช้เมโดล “งานบุญ” คือสปอนเซอร์ต่างๆ ขนของมาช่วยกันแจก (ซึ่งปีนี้พิธีกรบอกว่าเป็นปีที่ ของแจกและของกินอลังการมาก) /ขอบคุณค่ะ ขอบคุณค่า

ก่อนจะถึงงาน ก็มีคนเข้ามาในกลุ่มไลน์เรื่อยๆ เพื่อถามหาบัตรเข้างาน แต่ก็ไม่มีให้กดอีกแล้ว เลยเกิดเป็นอีก 2 model ขึ้นมาคือ

1. ถ้าตั้งใจจะเป็น speaker จะได้บัตรเข้างาน (เอาหัวข้อที่จะพูดไปแปะใน miro ได้)
2. สัญญาว่าจะ Blog เขียนงานนี้หลังจบงาน

ก่อนวันงาน 24 ชม. ทุกคนต้องตรวจ ATK และส่งผล ซึ่งตอนนี้ก็เตรียมใจอยู่ว่า แม้ไปขีดเดียว แต่ก็อาจจะกลับมาแบบสองขีดได้ 55+

ตัดภาพมาที่วันงาน (6 Aug) กันเลยดีกว่า

ด้วยความเป็นคนตรงต่อเวลา เค้าบอกให้มา 08:30 ก็มาถึงประมาณ 08:20 ทางผู้จัดงานแจ้งว่า ถึงเร็วก็จะได้รับของแจกเยอะ ถ้ามาช้าลงเรื่อยๆ ของแจกก็จะน้อยลงตามลำดับ

มารอเริ่มงานอยู่สักพักด้วยความอึกทึก ผู้คนที่ทยอยเดินทางมา และความดีดของพี่ MC ที่พยายามเอนเตอร์เทนตลอดเวลา ไมค์ลำโพงที่นี่เค้าเสียงดังดีจริง อยู่นานๆ แล้วปวดหัว 55+

และแล้วก็ถึงเวลาเริ่มงาน โดยพี่ปอม เป็นผู้ขึ้นมากล่าวเป็นคนแรก สรุปใจความได้ดังนี้

• Transformation คือการเปลี่ยนจากจุดที่ “เรามีปัญญาแค่นี้ ทำไม่ได้หรอก” แล้วมี/ได้แรงบันดาลใจจากใครสักคน ในการค่อยๆ ขยับ เช่นเดียวกับการวิ่งของพี่ปอมที่เริ่มจาก 3km->5km โดยมี อ.ชัชชาติเป็นแรงบันดาลใจ
• เราเชื่อว่า ใครๆ ก็สร้างแรงบันดาลใจ เป็นกำลังใจให้กันและกันได้ You Can Inspire!
• Agile ในชีวิตจริง ขอบคุณเหล่า Micro Influencer ที่แชร์โพสต์ แต่ไม่ได้เป็น Speaker (โห ได้รับเกียรติเป็น Influencer ของพี่ปอม /กราบค่ะ ขอโทษที่เน้นเรื่องเที่ยวมากไปหน่อย 55+)
• ขอบคุณทีมงาน และสปอนเซอร์งานบุญที่ทำให้เกิดงานนี้ขึ้น

จากนั้นส่งไมค์ต่อให้กับคุณเก่ง ตัวแทนเจ้าของสถานที่จัดงาน

• BitKub จากวันแรกที่มีพนักงาน 10 คน ปัจจุบันมี 1.6k คน ในส่วนของ CS มี 800 คน การเติบโตของ people โตประมาณ 100 เท่า
• รายได้ปีแรก 30M ปีที่สองเป็น 300M ปีที่สามเป็น 3,000M เป็นการโตหนึ่งร้อยเท่าในระยะเวลา 2.5 ปี เจอกับการเปลี่ยนแปลงในบริษัทเยอะมาก นับตั้งแต่วันแรกเริ่มจนถึงวันนี้ ถ้าเราทำอะไรเหมือนเดิม เราไม่สามารถมี growth ได้มากขนาดนี้
• ช่วงต้น — War time ตัดสินใจโดดลงจากหน้าผา รีบประกอบเครื่องบินให้ทันเพื่อ take off เหมือนกับหลายๆ startup โดยใช้ Concept: take control — take action ต้องการคนที่ทำตามคำสั่งได้ดี และต้องการคนสั่งงานที่ดี เพราะ runway เราจะสั้นลงเรื่อยๆ ผ่านไป 1ปี มีเงินเหลือจะรันบริษัทต่อแค่ 2 เดือน ถ้าไม่ layoff ก็ปิดบริษัทเอาเงินคืนผู้ถือหุ้น แต่แล้วคุณท๊อปก็หา investor มาลงต่อได้
• ช่วงที่สอง — Scale Up รายได้จะเข้ามาเยอะมาก วันที่เราเปลี่ยนจาก startup to scale up เป็นสิ่งที่เราไม่รู้ตัว เมื่อปีที่แล้ว exchange Bitkub ระเบิด กลต. สั่งให้หยุดรับลูกค้า มีคนมาสมัคร 40k ทุกวัน จน capacity ที่เคยทำรับไม่ไหว เลยต้องปิด exchange ไป 70 ชั่วโมง และคนใน team tech ก็ไม่ได้นอนหลับต่อเนื่อง เรื่องก็เข้าสภาด้วย หลังจาก 70–80 ชม. ผ่านไป ปริมาณ code ที่เราอัพเข้าไปผ่าน git commit เท่ากับ ปริมาณที่เราเคย commit ทั้งหมด 6 เดือน “เราทำได้ เพราะคิดว่าเราทำได้” รายได้พุ่งขึ้นเป็นพันเปอร์เซ็นต์ ต้อง capture growth ให้ทัน รับ พนง. เพิ่ม (เข้ามาเดือนละสองร้อยคน ติดต่อกันเป็นเวลาสิบเดือน) ไม่ประหยัดเรื่อง server แล้ว ผู้บริหารต้องปรับ mindset ให้ทัน ซึ่ง Capacity ตอนนี้รองรับ user เข้าใช้งานได้มากกว่า 50 เท่า ซึ่งต้องขอบคุณทีมงานที่เกี่ยวข้อ
• ช่วงที่สาม — Please Time (ไม่แน่ใจว่าคำนี้หรือเปล่านะ / พี่ปอมช่วยแก้ว่าน่าจะเป็นคำว่า ‘Peace Time’ มากกว่า) มีหลายบริษัทที่ยังอยู่ได้คือ Walt Disney แม้เจ้าตัวผู้สร้างไม่อยู่แล้ว แต่ culture ดีๆ ยังคงมีอยู่มากมาย จะสร้างบริษัทให้เป็น long lasting ได้ คนบอกเวลาต้องเปลี่ยนเป็นคนสร้างนาฬิกา ให้มันเดินด้วยตัวเองได้ เช่นเดียวกับ Agile ที่มี self-organization เลือกงานทำเอง รู้ role, norm ของตัวเอง เลือกสิ่งที่สร้าง value ให้ลูกค้า อีก 20 ปี ถ้าผู้บริหารองค์กรไม่อยู่แล้ว แล้วมีคนขึ้นมาพูดสิ่งนี้ที่คุณเก่งกำลังพูดอยู่แบบเดียวกันได้ organization ถึงจะสามารถอยู่ได้ด้วยตัวเอง Bitkub เชื่อในสิ่งนี้ จึงให้ความสำคัญกับ people และ process
• ผมเองก็โตมาจาก agile tour ที่ launchpad เมื่อสิบปีก่อน และเชื่อว่า community นี้จะช่วยให้ long-lasting

หลังจากจบ speech ของคุณเก่ง ก็จะเป็นการ pitch เนื้อหาของ speaker สั้นๆ เพื่อเชิญชวนให้เข้า session คนละ 20 วินาที

Unconference

• หัวข้อละ 45 นาที / QA และเดินเปลี่ยนห้อง 15 นาที
• Principles: Open space คนที่มาคือคนที่ใช่ สิ่งไหนเกิดขึ้นแล้ว สิ่งนั้นดีเสมอ เริ่มเมื่อพร้อมจะเริ่ม จบเมื่อพร้อมจะจบ
• Law of two feet: ถ้าพบว่าตัวเองไม่ได้ทำประโยชน์หรือเรียนรู้อะไรแล้ว สามารถใช้สองเท้าพาตัวเองไปที่อื่นได้ โดยไม่เป็นการเสียมารยาท

จากนั้นก็อธิบายสถานที่ว่าแต่ละ Space อยู่ตรงจุดไหน และเริ่ม Session แรกในเวลา 10:00

10:00 Agile Budgeting (KBTG)

[พี่จิ๊บ]

• เคยทำมาหลายอย่างแล้ว แต่ยังไม่มีคำตอบ what/how ที่เป็น practices
• ทำ IT มาเกือบ 20 ปี เป็น Developer -> ผู้บริหาร transformation มาหลายๆ size พบว่าไม่มีวิธีการทำ software ที่ดีไปกว่าการทำ agile principle ไม่ได้บอกว่าเป็น framework ไหน
• เห็นมาเยอะว่าทำด้วย scrum แต่ทำไป ผู้บริหารก็ track งานด้วย project (fix scope, fix cost, fix time)
• Agile: ถ้าทำมาจากทีม คนด้านบนไม่เห็นผลลัพธ์ เวลา track progress/deliverable เป็น project มันต้านกัน
• Team จัด organization ยังไงให้ enable Agile ให้เห็นจากบนลงล่างได้อย่างชัดเจน
• เราต้องเปลี่ยนองค์กรเป็น product-based แล้วเลิกทำ project หรือทำทั้งสองอย่าง หรือทำ project แต่มี agile เพื่อให้เกิด Maximum benefit
• Walt Disney: ไม่มีทฤษฎี ทำ agile, develop แล้วสำเร็จ มีการทำ character ใหม่ เตรียมของนู่นนี่ไปแล้ว ผู้บริหารคนหนึ่งอยากเพิ่ม 1 page ใน merchandise ก่อนวันเปิดตัว ต้องทำให้เสร็จภายใน 24 ชม. แล้ว IT ก็ทำได้ เป็นการ proof ว่า agile เพิ่ม productivity, เพิ่ม speed, เพิ่ม quality, ลด cost ซึ่งหน้าเพจที่ขอเพิ่มวินาทีสุดท้ายนี้ เป็นหน้าที่ทำเงินให้กับบริษัทได้จริงๆ (สามารถ react กับ change ได้รวดเร็ว)
• elephant in the room คือ budgeting เพราะต้องทำเงินให้กับบริษัท

[พี่ต่อ]

• Budgeting in corporate เป็นสิ่งที่สำคัญที่สุด ในการทำ activity
• 1 ใน mindset ของผู้บริหารที่เปลี่ยนยากสุดคือ ยิ่งใหญ่ยิ่งซวย ถ้า ceo ไม่เอาด้วย ก็ไม่ไป พยายามอยู่หลายวิธีบน agile transformation เอา business unit เล่นด้วยแล้ว แต่พอเจอ group corp ก็ชนอยู่ดี
• ทุกบริษัทมี physical year แล้วให้มัน flexible ได้ไหมล่ะ?
• Finance ของบริษัท buy-in ด้วยแล้ว สรรพากรเอาด้วยไหม group-finance เอาด้วยไหม มันจะมีด่านเยอะเลย ตอนนี้เองก็ยังไม่มีคำตอบ พยายามเปลี่ยนวิธีไปเรื่อยๆ
• Short-cycle ไม่ใช่ 5 years plan
• Local CFO กล่อมกันเป็นปีเลย พอเปลี่ยนคน ก็กล่อมใหม่อีก เค้ายังคงได้ Quarterly, Half-year planning แนวทางคือ เป็นก้อนแล้วแบ่ง pie ด้านใน ซึ่งแต่ละบริษัทต้องไปดิ้นรน/หาทางของตัวเอง
• ไม่ใช่ finance ไม่เห็นด้วย แต่มี regulation บางอย่างที่เค้าต้องปฏิบัติ
• Think Big, Start Small ขอพื้นที่เล็กๆ ในการสร้างผลงานให้เห็น

[พี่ดีน, ในฐานะ outsource ของบริษัท​]

• จะไปถึง budgeting ได้ ต้องมีฟันเฟืองชิ้นอื่นๆ ว่าเรา funding project ต่างๆ ใช้เทคนิคยังไงในการ seed เงินให้กับ initiative ต่างๆ
• องค์กรที่จ้าง vendor ต้องมีการเตรียม budget (ซึ่งมันคือ waterfall process)
• ถ้ามันยัง fix scope, time อยู่ เราจะเอา agile มาทำยังไง
• Contract ถ้า agile มากๆ จะเข้าสู่โหมด scope ไม่ fix ใช้กี่คน ใช้กี่วัน ต้องเบิกของอะไร เป็นภาพรวม budget จะเป็นตามวันที่ทำงานแทน มันจะดีในลักษณะที่ scope variable ได้ ลูกค้ามี sth. change ก็มาคุยกัน แต่ก็มีความเสี่ยงในมุมลูกค้า ว่าตอนจบแล้วจะได้ของที่อยากได้ไหม เป็น model ที่แชร์ความเสี่ยงซึ่งกันและกัน
• PO ของลูกค้าก็ต้อง manage requirement ให้ดี vendor ก็ต้อง open to change
• Process ตอนแรกต้องลดความ structure ก่อนแล้วค่อยมาคิด budget ว่าจะคิดกับมันแบบไหน ซึ่งมันก็ดูเสี่ยงมาก และเป็นไปได้ยาก แล้วจะ transition มันมายังไง? ต้องทำ agile contract แบบไหน

[พี่ริน, thoughtworks]

• จะมีปัญหาเรื่อง time material เพราะการทำ agile เราไม่รู้ว่าอีก 6 เดือนข้างหน้า product หน้าตาเป็นแบบไหน
• การดีลกับ finance คือการสร้างความสบายใจ ความเชื่อใจ ทั้งเราและ stakeholder ของเรา
• ถ้าเรา deliver outcome ที่เป็น big bang, ทุก sprint ก็เชิญ finance, procurement มาให้ร่วมด้วย
• ทำ release ออกมาเป็น docs เป็นเรื่องเป็นราว มียอด engagement อย่างไร, go-live ในระยะเวลา
• Negotiate กันระหว่างทาง demo, sprint-review แล้วก็มี sign off เรื่อยๆ เป็น small chunk
• สำหรับบางองค์กร ที่ทำ budget เป็นรายปีหรือ Quarter มันไม่มีใครสบายใจหรอก เค้าจะได้ของไหม เราจะได้ deliver งานได้ไหม จะมีการทำ workshop ร่วมกัน ไม่เน้น estimate requirement เพราะ est. ถูก take ไปเป็น deadline ทำได้แค่กะคร่าวๆ (min-max) เพื่อทางเค้าจะได้มี flexibility ว่าใช้จริงเท่าไหร่ก็จ่ายตามนั้น และมีช่วงเวลาที่จะไป allocate budget การทำเป็น range จะมีเวลาให้เราหายใจมากขึ้น
• รัฐบาลที่เจอ จะเห็นอะไรเป็นชิ้น/อัน เป็น scope ในแง่ของการจัดซื้อจัดจ้าง แบบ waterfall แต่มีอีกรูปแบบคือ แบบที่ปรึกษา (ค่าตัวประมาณปี 2543) ทำยังไงให้มีการจัดซื้อแบบที่เรทยี่สิบปีที่แล้วแต่เราไม่ขาดทุนเกินไป ก็ต้องคุยกับ procurement, stakeholder มีการทำ report ไปเลยทุก 2 weeks ได้ outcome อะไร
• พอไปท่าที่จะไป deliver value คนคุยของเราจะเป็น compliance and security แทน ที่จะเอาของขึ้นบ่อยๆ จะขึ้นยังไง ปลอดภัยไหม ด้วยสัญญาเราไม่สามารถรอ 6 เดือนได้ ต้องมี infra, process, engineering practices ที่น่าเชื่อถือ (แต่ไม่สามารถ commit ได้)
• functional requirement — non functional requirement ปกติเวลาทำสัญญา ทำแค่ feature แต่ไม่ได้ทำ non fuctional เช่น ระบบไม่ล่ม, ความปลอดภัย, การ recovery, deployment frequency,​ รองรับลูกค้าได้กี่คน
• การเอาคุณภาพของ agile ไป educate finance, Cost ของความเสี่ยง ผลกระทบที่ตามมาเป็นอย่างไรบ้าง

[พี่ดีน]

• KPI คือ revenue ตลอด เลยไม่ได้ concern non-functional แล้วมันก็เลยเป็นปัญหา IT
• เคยทำให้ รบ.สิงคโปร์ contract เป็น fix scope แต่ budgeting มาเป็นก้อน แล้วเรา own outcome — Delivery on time, feature, เงินก้อนที่เหลือ based on outcome เช่น time to recovery, เป็นผลลัพธ์ที่จะได้ ถ้าเราอยู่ใน range นั้นจะเอาเงินก้อนนึงให้เรา เป็นการแชร์ความเสี่ยงระหว่าง business, consult
• Scope มาเป็น chunk ถ้าทำ module ก้อนนี้เสร็จก็จะ unlock ก้อนนึง ถ้าทำตาม matrix ของ non-functional ได้ ก็จะ unlock อีกก้อนนึง เพราะสุดท้ายเค้าได้ตัวเลข matrix ไม่ได้ต้องการ architecture (Matrix = governance)
• ถ้าอยากได้ functional แบบนี้ ต้องมี non-functional แบบไหน และให้ visible ทั้งกับลูกค้าและคนทำงาน
• ใน context ของ รบ. สิงคโปร์ มาเป็น quarter ตอนต้นจะคุยภาพใหญ่ก่อน แพลนเปลี่ยนได้ตลอด quarter หน้าจะยังเหมือนเดิมไหมหรือเปลี่ยน เป็น checkpoint ว่า ให้เงินมาแล้ว ทำอะไรได้บ้าง ยอดเท่าไหร่ โตตามที่กำหนดไหม (อารมณ์คล้ายๆ startup)
• Revenue, user-based เป็น business มากไป แต่ owned เรื่อง security, พวกนั้นได้ แล้วก็ต้อง work ร่วมกันว่า outcome business ที่อยากได้คืออะไร แล้วก็เอา PO ที่เก่งเข้ามา

[พี่ผู้ชายท่านหนึ่ง /มีคนแจ้งว่าน่าเป็น พี่ Pornthep]

• เคยเป็น pm, transformation manager เคยทำ mobile app ให้ law of HongKong (สมาคมทนายความ) สิ่งที่ต้องทำ budget คือ การ estimate คน, Tools, ตอบโจทย์ scope สองส่วนคือ Transformation (coach) + project และต้องมี buffer 25% ในส่วนของ project (Capex)
• มี cross-charge ทุกเดือน
• เวลา present จะดู waterfall มาก แต่ข้างในคือ agile 2 weeks
• สิ่งที่ est. คือ story point ของ epic — business value + technical task (functional and non functional) แล้วก็เอา velocity -> timeframe โดยคร่าวๆ
• Velocity มาจาก ดึงคนจาก resource manager มา โดยดึงคนจากหลายๆ ทีม เอามา agree story point ก่อน แล้ว estimate velocity จากงานสมมติก้อนหนึ่ง แล้วก็จะได้ period มันจะประมาณ​ 10 เดือน ก็แปลงเป็น 12 เดือน แล้วก็แปลงเป็น cost แล้วก็ใส่ capex ซึ่งท้าย project เงินเหลือ เพราะเรา buffer เยอะไป ก็ reallocate funding ไปให้ทีมอื่นได้

[พี่นิค wisesight]

• Set budget หมุนเวียน (จริงๆ) ในบริษัท เอา project มาทำเสร็จก่อนแล้วค่อยไปขอเงิน
• สิ่งที่ deliver, value ที่คิดว่าจะได้ ทำแล้วเอาเงินมาคืน budget หมุนเวียนให้ เคยทำกับ project ที่ size ไม่ใหญ่มาก
• ถ้าโชคดี เราจะมี budget หมุนเวียนอยู่แล้ว แต่ถ้าเค้าไม่มี สิ่งแรกที่ต้องทำคือ over buffer จากตรงอื่น เพื่อเอามาสร้าง budget หมุนเวียน

[พี่หนึ่ง global enterprise]

• เงินที่ให้ไป ได้อะไรกลับมา ไม่สนว่าจะทำวิธีไหน
• Agile transformation coach -> educate ผู้บริหาร
• Break การ provide funding เป็น product funding
• Req ที่มา มาจากหลายทาง พอเป็น funding มัน based on value จริงๆ
• ถ้าเป็น project ใหญ่ จะมี project management team ว่าจะแพลนยังไง
• As a project ถ้าจะเอา agile เข้าไป จะรันแบบไหน สองโลกต้องมารวมกัน

เป็น session ที่คุยกันมันส์มาก และแน่นอนว่าไม่จบในเวลา มีการ Create Group เพื่อคุยกันต่อเนื่องอีก (ขอรับบทแอบฟังแล้วเอามาปรับใช้)

11:00 เมื่อ PO ต้องพัฒนา software แทนระบบอายุ 20 ปี ในรูปแบบ Agile (CPF-IT + SCK)

Transform product 20 ปี คน support กำลังจะเกษียณ เลยถึงเวลาที่จะต้องปรับ เคยพยายามมาแล้ว 1 ครั้ง

• บอล PO ในบริบทของ CPF IT ก่อนหน้าเป็น BA, BD, IT PM ส่วนงาน เป็นการส่งมอบงานให้หน่วยงานราชการ ซึ่งรูปแบบการส่งมอบจะเป็น waterfall (phase) scale ค่อนข้างใหญ่ ใช้เวลานาน นอกจากต้องมาเร่งการพัฒนาให้ส่งมอบทันการตรวจรับแล้ว บางทีคนตรวจรับก็ไม่อยู่แล้ว สิ่งที่เราคิดไว้อาจจะไม่ตอบโจทย์ผู้ใช้งานคนใหม่ (โครงการนานสองปี) ปิดโครงการด้วย การตรวจรับ
• ตอนนี้เป็นเดือนที่ 5 ที่ CPF IT ก็มี job open ตลอด งาน PO เป็นงานท้าทาย ได้มาเรียนรู้ที่นี่ไปพร้อมๆ กัน

มาเจอ Scurm ทำงานเป็น sprint ในบริบทของ SCK

• เคยได้ยิน agile มา เข้าใจว่ามันส่งเร็วขึ้น ได้ดีขึ้น แต่ไม่เคยได้ทดลองทำ พอเข้ามาทำงานได้เจอ SCK เล่าตั้งแต่ Agile คืออะไร ตั้งต้นมายังไง และการทำงานเป็นแบบไหน
• Agile ที่แท้จริงไม่ใช่แค่เรื่องการส่งมอบรวดเร็ว แต่มีความยืดหยุ่น ปรับเปลี่ยน ทุก 5–10 วัน เพราะ user มี req เพิ่มเติมอีกแล้ว

เจอ Agile ใช้ scrum ทำงานเป็น sprint
วิสัยทัศน์ท่านประธานอาวุโส: ส่งมอบ software เร็วอย่างมีคุณภาพ
ทำสิ่งนี้ให้เป็นรูปเป็นร่าง แต่ต้องตีความ “เร็ว” “อย่างมีคุณภาพ” ออกมาอีกทีหนึ่ง

• อายุ software 18 ปี มี source code มรดกเลือด ไม่มี docs มีแค่ support ที่กำลังจะเกษียณ ทุกอย่างอยู่ใน DB ทุกอย่างเป็น configuration มีลูกค้าใช้อยู่ประมาณ​ 20 บริษัทในเครือ
• ถ้าต้อง replace ระบบนี้ ด้วยการทำงานแบบ waterfall น่าจะดูไม่จืด พอได้คุยกับทีมทำงาน, strategy เราจึงเลือกบริหารความเสี่ยงด้วยการทำงานเป็นรอบสั้นๆ ไม่ใช่หนูทดลอง แต่เป็นความท้าทาย ในการ replace ระบบ 18 ปี
• ปกติใช้ scrum ก็ทำไป แต่เลือกวิธีการทำงาน เป็นการคุมความเสี่ยงที่จะเกิดขึ้น
• ความสนุกอยู่ตรงที่การใช้ outsouce
• คนทำงานคือเด็กรุ่นใหม่ คนใช้ระบบคือคนที่หลับตาแล้วจำได้ว่าระบบเก่าเมนูอยู่ตรงไหน
• โชคดีที่ CPF IT มีการเอา ux/ui เข้ามาซักระยะหนึ่ง เพราะถ้า IT design จะมีความเหลี่ยม
• ซึ่งการทำงานมีการเปลี่ยนแปลงโดยตลอด เพราะเรามีผู้บริหารที่เป็น programmer คนแรกของ CPF IT

Software ใช้งานมาแล้ว 20 ปี

• เข้าไปศึกษาธุรกิจ ว่าผู้ใช้งานใช้ในธุรกิจแบบไหน เป็นอะไรที่ ยุ่ง ยาก เยอะ
• แกะ business flow โดย manual ก็ต้องหารือร่วมกับทีมวางแผนพัฒนา พยายามแก้ไข pain point ที่เป็น overall ของระบบ
• ผู้ใช้งานอยู่กับ software นี้มาเกิน 10 ปี ทำยังไงให้พัฒนาแล้ว expert คุ้นเคย และแก้ปัญหาเดิมที่เคยเจอ
• ถ้า software อยู่ได้ 20 ปี แสดงว่ามีจุดแข็งของมันอยู่ ต้องคิดและทำอย่างรอบคอบ ต้องไปลงพื้นที่ เข้าใจ business domain, workflow ก่อน (มีคนเกี่ยวข้องไม่ต่ำกว่า 12 ส่วนงาน)
• ให้วาง product roadmap (ยากมาก) ที่ไม่รู้เลยว่าจะเอาอะไรก่อน ทำ blueprint ใหญ่ๆ ว่าการเดิน flow ตั้งแต่ต้นจนจบเป็นยังไง
• จากนั้นตัด module ออกมาอันนึงก่อน คิดว่า 3 sprint จบ (เปิดใบงานขาย) คิดว่า key ข้อมูลเข้าไปเสร็จก็จบ แต่เจอช่องโหว่ที่เป็น pain point จาก stakeholder เข้ามา ตอนนี้ปัก release1 ไว้เดือน ต.ค. ให้ไปดูว่าจะ pilot งานนี้กับลูกค้าเจ้าไหนก่อน เพราะถ้าทำเป็น big bang น่าจะบันเทิง เลือก target group ที่ใช้งานระบบนี้เป็นหลัก เป็นบริษัทที่มีผู้ใช้งานในส่วนอื่นๆ (หลังบ้านที่ช่วย support การเดิน flow ธุรกิจ) ก็เริ่มไปเก็บจากผู้ใช้งานตรงนี้
• ทีมวางแผนพัฒนา + ux/ui เจอผู้ใช้งานจริง PDCA เก็บ pain point จาก insight ก่อนนำมาพัฒนา
• ux/ui เข้ามารับฟังปัญหาจากกลุ่มผู้ใช้งาน คุยกัน แล้วหา solution แล้วทำ prototype กลับไปหา target group ทดลองเล่นจริง รับ feedback มาปรับปรุง ลงรายละเอียดให้เป็น product backlog / user stories ให้พร้อมที่จะไป grooming เพื่อพัฒนาต่อไป
• ที่นี่มี PDCA อยู่แล้ว ดำริของท่านผู้บริหารสูงสุด คือให้ลงพื้นที่ ไม่ได้ให้นั่งมโนอยู่ในตึก ทำ prototype เสร็จ ลงพื้นที่ เก็บ feedback ทำ version สองก็ลงไป test อีก แล้วค่อยมาเขียน backlog
• เปลี่ยน custom ให้เป็น 1 to many
• Sign off UAT โดย user -> เปลี่ยนเป็น provide service ตาม roadmap Turn ตัวเองเป็นผู้ให้บริการ คนตรวจรับต้องเป็น PO

Test-first programming

• UX ขึ้นโครงเรียบร้อย จะเอา flow วิ่งจริงตามหน้าจอด้วย
• เอา data ของเดิมที่เคยทำมาบน prod ไหล data บน flow ใหม่
• แล้วเอาจังหวะนั้นวัดกับ user — Usability test — เปลี่ยนเป็นออนไลน์ ถ้า user บอกใช่ก็ใช่เลย
• ไม่มี uat (ตัดออก/ไม่บอก) เพราะเชิญทุกคนเข้ามาใน sprint review มี demo
• รันมา 6 sprint แล้ว จะเชิญ user มาเหมือนทำ uat แต่ไม่เหมือน uat — การเชิญเข้ามาหลังจากนี้ เค้าจะต้องเข้ามาในทุกๆ 10 วัน ต้องมีปริมาณงานมากพอ (เก็บมาระดับหนึ่ง) ถ้าจะ uat ทุกบริษัทที่ใช้งาน คงไม่ต้องทำอย่างอื่น บวกกับที่เข้าคิวว่าอยากจะใช้อีก บวกกับลูกค้ากลุ่มนั้นไม่ได้อยู่ในไทยอีก แย่/ไม่แย่ PO รับผิดชอบ
• (Stakeholder ไม่ pay attention ใน sprint review แต่ไปสนใจใน UAT มากกว่า) ก็เลยตัดปัญหาไม่มี UAT sign off ซะเลย
• Stories ไม่ได้เขียนเป็น as a … i want … so … that .. แต่ใช้เป็น flow + data ที่ต้องการ + output ออกยังไง ไม่มี test acceptance criteria ยกตัวอย่างเช่น เจ้าหน้าที่เข้ามาสร้างใบคำสั่งซื้อ และสร้างจนเสร็จ มันคือ scenarios ของ tester เลย
• ถ้า user confirm ก็เก็บเข้า tools -> Miro -> Azure board ทำงานบน miro แต่ manage งานใน azure
• User stories ของการทำสิ่งนี้จะใหญ่มาก อลังการจนต้องคิดว่ามันต้องละเอียดขนาดนี้เลยเหรอ
• (บอล + เอก) PO มีหน้าที่เคลียร์ level บนให้เรียบร้อย (ซึ่งมีทีมงานอยู่ด้านหลัง)
• ux/ui ที่ทดสอบมา -> refinement เล่าประกอบให้ทีมพัฒนาฟัง เพื่อหาจุดร่วมกันว่า user stories น้ีพร้อมที่จะไปพัฒนา ทุกคนเห็นตรงกัน เป็น stories ของทีม ถ้าไม่เสร็จ ไม่เสร็จเป็นทีม
• การรับมอบงานให้ PO อยู่บน uat เท่านั้น (เนื่องจาก preprod/prod ไม่เสร็จ)
• มี DoD แทน test acceptance criteria
• PO ใน scurm มี 1 คน แต่ระบบ 20 ปี เลยเป็น co-PO กันสองคน อาจจะแบ่งกันดูคนละ squard
• PO ในส่วน CPF IT ต้องมีความเป็น pm ด้วย เพราะต้องคุย internal, stakeholder, คนใช้งานเดิม, infra (ขึ้นอยู่กับประเภทของ software)
• ตอนนี้ บอล = outbound, เอก = inbound แต่ถึงเวลาก็ช่วยๆ กันอยู่ดี (sync) แยกกันเพราะว่ามันใหญ่ คนเกี่ยวข้องเยอะ เข้า planning ด้วยกัน ตัดสินใจร่วมกันว่าจะเอางานอะไรเข้า การ์ดไหนใครเป็นคนทำ คนนั้นเป็นคนมีอำนาจในการตัดสินใจ
• Outbound การสื่อสารกับผู้มีส่วนเกี่ยวข้อง คนใช้งาน คนที่อยากใช้งาน ประเทศอื่นที่อยากใช้งานระบบนี้ ผู้บริหารต่างๆ ทีม implementer ระบบเดิม ทีม infra ทีม security
• หยิบ scrum มาใช้เป็นเครื่องมือ ไม่ใช่เอา scrum มาทำให้ถูกต้องเป๊ะๆ

จะเสร็จเมื่อไหร่?

• เราต้องสื่อสารให้เร็ว ไม่ใช่รอเค้ามาถาม ต้องประเมินความเสี่ยงของโครงการ มีอะไรที่เราต้อง take action เลยไหม ต้องคิดถึงจุดที่เรา commit กับ stakeholder ว่าจะพบความเสี่ยงอะไร
• สามารถทำได้ใน sprint review (official) เลย เช่นขอ resource ต่างๆ stakeholder ก็จะมา support ทันที
• การสร้าง trust เป็นเรื่องสำคัญ
• เนื่องจากระบบนี้เคยมีความพยายามครั้งนึงแล้ว แล้วมันไม่รอด ผู้บริหารสูงสุดจึงรู้ว่ามันไม่ง่าย
• เขียน roadmap ไปถึงปีหน้าเลยว่า จะมีอะไรออกเมื่อไหร่ จะ release แบบไหน เช่น major ทุก quarter, mini ทุกเดือน ผู้บริหารจะเห็นภาพ
• Sprint review เจอผู้บริหาร อะไรเกิดขึ้น เราขอคำปรึกษา/การสนับสนุนในตรงนั้น มี choice 1, 2 ในมุม PO เราตัดสินใจแบบไหน หรือขอให้เค้าตัดสินใจ โดยเกิดขึ้นทุกสิบวัน
• ผู้บริหารบอกว่า ห้องเปิดเสมอ ให้เข้ามาได้เลย จะได้ไม่โดนซัดใน sprint review ทำให้ผู้บริหารทราบว่า เราอยู่ตรงไหนแล้ว
• มีภาพใหญ่ให้ดู และมีภาพที่อัปเดตเรื่อยๆ ถ้าไม่ on plan เพราะอะไร

ทดลองให้คุ้นชิน

• ก่อนจะเริ่มทำ project จริง จะเอาทีมพัฒนามาก่อน 6 วัน วันแรก เอามาปูพื้น ทำ refinement ก่อน
• จ. ทำ planning, set plan, review ทำทุกวัน จนวัน ศ. มี review
• มาทดลองทำอะไรบางอย่าง ทำ sprint review แล้วเอาผู้บริหารเข้ามาเลย
• 5 วัน ของไม่ได้ใช้งานได้เลย แต่มีของ demo จริง
• มีอะไรเป็น Gap ไหม หรือใครเป็นจ่าฝูง จังหวะที่เค้าอยู่ด้วยกันก็สังเกตพฤติกรรม ว่าต่างคนต่างทำหรือมีการพูดคุยกัน เป็นการ assessment คนไปด้วยเลย
• ถ้าเป็น physical ก็คือ คนเข้ารีวิวจะไปเล่นแต่ละเครื่องเลย
• ใจนึงคืออยากทำซักเดือน (คงไม่มีใครยอม) pack เล็กสุดคือ 6 วัน
• CPF IT โตมา 17 ปี แบบ waterfall เด็กรุ่นใหม่ โตกับการทำงานแบบใหม่ design thinking, ux/ui
• Agile จะสำเร็จ เพราะผู้บริหารลงมาฟัง (Programmer คนที่ 1 ก็มาฟัง sprint review ตลอด)
• พอเค้าเห็นภาพว่ามันช่วย ตลอดระยะเวลา 10 วัน เราขอเวลาแค่ 1 ชม. เท่านั้นล็อคยาวล่วงหน้าไปเลย
• Sprint review เข้ามาล่าสุด 94 คน -> รีบบอกให้ไม่เกิน 15 คน ไม่งั้นจะกลายเป็น workshop แทน
• Test-First ต้องคิดก่อนว่าจะทดสอบยังไง พี่หนุ่มเคย Build กอล์ฟ โดน 5 วันทุกสัปดาห์ เป็นเวลา 6 เดือน (offline) 8:30–9:30 เป็น coding do-jo เขียนทุกวัน เพื่อให้เขียน Test-First ได้ ซึ่งพอมันเป็น online มันจะใช้เวลาเทรนนานกว่านั้น

Scrum (timebox) ตารางพิธีกรรมเหมือนเด็กอนุบาล

• ช่วงแรกรู้สึกว่ามันเยอะมาก เพราะเคยทำงานแบบ time management ตอนนี้ชินแล้ว
• ไม่ใช่การประชุม เรียกว่าพิธีกรรม
• refinement ไม่เกิน 2 ชั่วโมง หลังจากนั้นต้องไปเขียน code
• เดิม waterfall ต้องเก็บของทั้งหมด ส่วนตอนนี้ทำงาน เก็บ req เป็นหย่อมๆ รู้สึกว่ามันดีกว่า เก็บเป็นรอบ/ระยะ เป็นการสร้างความสัมพันธ์ที่ดีกับเราและ user เพราะได้ไปคุยกับเค้าตลอด
• การประชุม/หารือ แค่ 2 ชม. อาจจะไม่พอ ถ้าเราทำเรื่อยๆ หรือมีจุดไหนที่เราสงสัยว่าตอบโจทย์ได้จริงไหม ก็เข้าไปถามเค้าเลย แล้วก็ไล่เก็บตาม business process
• Way ในการ confirm ลูกค้าคือ sprint review (demo แล้วเชิญผู้ใช้งานที่เราไปทดสอบกับเค้า เข้ามาฟัง) พอเห็นของจริงๆ ก็อยากเสริม/ปรับหน่อย เช่น format ของ delivery plan (field หนึ่ง) ตอนทำ ux/ui อาจจะไม่เห็น ถ้าเราทำโครงการในลักษณะเดิม เป็น phase ก็อาจจะไม่เห็น (เห็นตอนท้าย ก็ต้องแก้อยู่ดี) Refinement ครั้งหน้าก็คือเอางานนี้มาเข้าในรอบหน้าได้เลย
• ใช้ miro มาเป็นตัว confirm
• แนะนำให้พา stakeholder มา review ตอน Sprint 7 เพราะเริ่มมีของแล้ว -> และหลังจากนี้จะขอให้มาทุกสัปดาห์

Failed

• เกือบ cancel sprint ครั้งนึง เพราะประสบการณ์ในการออกแบบระบบของเราน้อยกว่า stakeholder ก็คิดว่าเราต้อง cancel ไหม ของที่พัฒนาคืออะไร เปลี่ยนแปลงการพัฒนาได้ไหม ทำการปรึกษาผู้บริหาร (เสียงไมค์ส่วนกลางดังขัดแล้ว ฟังไม่รู้เรื่องค่า)

[พักเบรกช่วงเที่ยง] แล้วไปลุยกันต่อ

13:00 เสริมหล่อให้ Product Backlog Refinement ด้วย REQs Dev. + Test First Programming + SCK A-DAPT Blueprint (SCK)

• Scrum ทำงานเป็น sprint/ เป็นรอบ แต่ไม่มีการเตรียม Req ที่พร้อม เพื่อส่งเข้าไปผลิต
• คนคิด Scrum ใช้เวลา 2 ปีในโรงงาน toyota ไปศึกษาการผลิตรถยนต์ การเตรียมชิ้นส่วนต่างๆ แล้วส่งเข้า line การผลิต (Line การผลิต control ได้)
• การเตรียม requirement ให้เรียบร้อย ก่อนส่งให้ทีมพัฒนาผลิต
• การวิเคราะห์ เขียนโค้ด เทส uat และแพ็คของ ส่งมอบ
• ไม่ใช่ sprint dev ให้เสร็จ เทสวันสุดท้ายหรือ sprint ถัดไป แบบนั้นเรียก waterfall
• เท่าที่เจอใน site ลูกค้า เราใช้เวลามากในการทำ planning (เกิน 3 ชม. มาจาก การเอา req เข้าแค่บรรทัดเดียว หรือมีการทำ ux/ui มาก็มีแค่นั้น)
• เสร็จใน sprint ที่ทำ แต่องค์รวมไม่สามารถใช้ได้
• Scrum guide ล่าสุดเขียนแบบสัญญาจ้าง คือผู้จ้างไม่ผิด
• เราจะเอา Scrum มาช่วยในการเดิน project ยังต้องมี req, design ระบบ/api, ประเมินเวลา, การเทส
• การทำงานเป็นรอบ เตรียม — confirm — ส่งไปผลิต มันจะเป็น loop แบบนี้
• Grooming/product backlog refinement ใช้เวลาประมาณ​ 1–2 ชั่วโมง sprint หน้าจะเอาอะไร? มีคำถามอะไรไหม? programmer ยังไม่รู้เลยว่าจะทำอะไร เสร็จแล้วก็ไปตายใน planning
• Key สำคัญคือ timebox
• Sprint นึง 10 วัน planning 2 ชั่วโมง เดลี่ 15 นาที รีวิว 2 ชั่วโมง Retro 2 ชั่วโมง
• ให้กันเวลาไว้ 8 ชั่วโมงในการทำ product backlog refinement
• Planning ใช้เวลาเท่าไหร่ก็เหมือนกัน วันรุ่งขึ้นก็เปลี่ยนแผน Plan ให้ได้แค่ 2 ชั่วโมง อีก 6 ชั่วโมงที่เหลือไปทดสอบสมมติฐานว่ามันใช่ตามนั้นหรือเปล่า
• product backlog refinement เกิดก่อน sprint เสมอ และเตรียมล่วงหน้า 2 sprint เสมอ ถ้ามีบางอย่างเกิดขึ้นใน sprint ที่ดำเนินอยู่ แล้วต้องมีของออก จะได้มีของเข้าไปเติม ในสิ่งที่ใช้เวลาเท่ากัน
• Product Backlog refinement is the act of Adding detail, Estimate, And ordering items In the product backlog ใน scrum guide ไม่ได้บอกว่า Product Backlog refinement ต้องทำยังไง แค่เขียนสั้นๆ แค่ประโยคเดียว
• Scrum น่ารักตรงที่ไม่ได้บอกว่า Adding detail ต้องเป็นยังไง FE, API, DB, …
• จุดเริ่มต้นของการทำ software คือ Requirement ปัญหาที่เจอคือ Requirement ไม่ชัด
• Requirement engineering ประกอบไปด้วย การพัฒนาความต้องการ และการบริหาร change

Requirement Development

• Elicitation
• Analysis
• Specification
• Verification and Validation (เรากับเจ้าของ Req เห็นภาพตรงกันไหม + เรากับเจ้าของ Req ใช้รูปแบบ/วิธีการทดสอบแบบเดียวกันไหม) > ตอนเก็บ Req ให้ Design UAT ไปด้วย

• ในบริบทของ scrum PO คือนักลงทุน รายละเอียดความต้องการจะทำเองหรือส่งต่อก็ได้
• ตอนที่ BA คุย refinement Req ให้หนีบ tester ไปด้วย (มีลักษณะ ที่เขียน scenarios ได้เลย หรือโยนเคสที่ไม่มีใน scenarios ได้ทันที ใน 1 นาที)
• เริ่มต้นจาก business requirement (process) ก่อน ถ้ามี ux ด้วย เอา user journey ขึงก่อนเลย ว่าจะเข้ามาทำงานแบบไหน เพื่อให้เรากับลูกค้าเห็นภาพตรงกันว่ามันเดิน flow ยังไง
• Business process นั้นเดินทางถูกต้องไหม ให้ใส่ test scenarios ลงไปด้วย เช่น นาฬิกา garmin ให้ใส่รุ่น และเขียนความต้องการของ expected result ว่าต้องการแบบไหน
• ตั้ง product backlog ตาม business process แล้วเรียง priority
• ตัด flow แรกที่จะทำลงมา จากนั้นเอา data production ลงมา แล้วกราบทีม ux/ui ให้ทำข้อมูลจริงแทน lorem ipsum ให้หน้า mock มีตัวอย่าง data เลย แต่ให้ระวังเรื่อง PDPA ด้วย
• เริ่มต้นด้วย ลูกค้าเป็นใคร มีคุณสมบัติอย่างไร (persona) + test data + initial data รองรับการ search กี่แบบ (ตัวเล็ก/ตัวใหญ่) ผลการค้นหาจะเจออะไร บางทีเราอาจจะรอ ui ให้เสร็จไม่ได้ ก็ไม่ต้องรอให้เสร็จ เพราะ PO จะต้องบอกได้ว่า มันต้องแสดงอะไร เป็นตัวอักษรนี่แหละ ถ้ามีอัตราแลกเปลี่ยน 100 บาท = 1 แต้ม ถ้า 34.99 usd จะต้องได้ 12 แต้ม (expected result)
• ถ้าเป็นการทำงานระหว่าง PO + UX + Tester ก็คือ UAT (แต่ต้น ตั้งแต่เก็บ req เลย)
• ไม่ใช้ scenarios ว่า ซื้อสินค้าสำเร็จ เพราะมันไม่สามารถตรวจได้ว่าผิดหรือถูก
• ถ้าเอา data นี้ไปทำบน mock up ก็จะได้เคลียร์กันตั้งแต่เอา UI ไป confirm ถ้าผิดจะได้เคลียร์กันตั้งแต่ตอนนั้น
• ใน requirement ต้องคุยถึงเรื่อง digit ของ ID และ format ให้ใส่ไปตั้งแต่ตรงนี้
• สิ่งที่เล่าให้ฟังตรงนี้คือ test-first programming ให้เข้าใจก่อนจะไปเขียน code (Act, Assert)
• เอา user interface แปะเข้าไปใน miro แล้วเอา case แปะลงไป
• หลาย business process อาจจะอยู่ในหน้าจอเดียว ถ้าเราเริ่มตัวหน้าจอ เราอาจจะหลุด backend process
• Automation test ผ่าน UI หาตำแหน่งของ id element ต่างๆ ของหน้าจอ แปลว่า FE สามารถกำหนด id ได้ และเขียน automation script ได้เลย

Business process — Test end to end — Screen

• เอา user เจ้าของ requirement เข้ามาด้วย และมัดมือให้ใช้ scenarios นี้ในการตรวจรับ
• การขึงมาถึงระดับนี้ = มันอาจจะดูเยอะ แต่ถ้าไม่คุย แล้วมาแก้บัคตอนท้าย ใช้เวลากี่ชั่วโมง? หรือกี่วัน?
• คนเราโฟกัสจริง ได้ไม่เกิน 2 ชั่วโมง เพราะฉะนั้น product backlog refinement เอา 8/2 = 4 วัน
• ให้ทุกคนคุ้นกับวิธีการทำงานก่อนแล้วค่อยแตกไปเป็นทีมย่อยๆ
• ถ้าอยากได้เร็วกว่าน้ี = มาทำด้วยกัน จะได้รู้ว่ามันไม่ง่าย
• ชั่วโมงที่ 4–6 ให้ Design API ลงไปเลย เราต้องการแค่ภาพใหญ่ ชื่ออะไร, method, request, …ไม่ต้องกังวลว่า design ไม่ครบ มันเพิ่งทำรอบแรก ทำไปให้รอดก่อน แล้วค่อยมาเติมรายละเอียดอีกที
• ปกติจะเริ่มทำ flow สำเร็จก่อน แล้ว exception ค่อยมาเก็บทีหลัง เพราะถ้าคุยไปพร้อมกัน อาทิตย์นึงก็ไม่จบ
• กดปุ่ม search หรือ กด enter ใส่ request, response ลงไป
• ถ้ามี function ก็ draft คร่าวๆ ถ้าต้องไปปรับลด ปรับแก้ ก็ design DB คร่าวๆ ไปเลย
• ถ้าต้องไป integrate กับระบบภายนอก ก็ต้องใส่ internal/external service เข้าไปด้วย
• มันก็จะกลายเป็น board ใหญ่ๆ เราต้องทำ software เราเลยต้องใส่ทุกอย่างเข้าไป
• เมื่อก่อนใช้ flipchart -> miro Consult plan 60$/5 คน คุ้ม ถ้าจ่ายเงินเราจะ export อะไรก็ได้ ถ้า free ต้อง capture ไป

Service Design Blueprint ถ้ามันหมุน ก็คือ sequence diagram ดีๆ อันนึงนี่เอง -> A-DAPT Blueprint (sequence + activity diagram) = A-Design Analysis Planning Test

• customer visible (acceptance test + ui)
• customer invisible (api, DB, บลาๆ)

User stories (XP) = requirements + acceptance functional tests

• พอเรามีภาพแล้วก็แตก task ลงไปเลยว่า ใช้เวลาทำกี่ชั่วโมง (ประมาณการ)
• ระบุการ test เข้าไปได้เลยในบอร์ดนี้

14:00 Remote First, Internal Communication (Villa Technologies)

ขอ Remark ไว้ก่อนสรุปว่า Slide ตอนที่ดูไม่เรียงหัวข้อ มันมีความเลขกระโดดไปมาอยู่ แต่ขอจดเรียงหัวข้อด้วยตัวเองนะ

• เมื่อไหร่ที่เราจะรู้ได้ว่าเรื่องนี้ใช้การคุยหรือการพิมพ์

องค์กรพยายามใช้อีเมล เพื่ออะไร?

• meeting, mom เพื่อให้ทุกคนเข้าใจตรงกัน การประสานงานกันเพื่อให้ไม่ตกหล่น เพราะบางที เวลาทุกคนต่างจด อาจจะลืม แต่พอส่งเมลคุยกัน ก็ไม่ค่อยอ่าน เพราะเวลาเช็คเมลแต่ละคนก็ไม่เท่ากัน (evidence)
• อีเมลสื่อสารได้เฉพาะคนที่อยู่ใน loop email นั้น อาจจะไม่ใช่คนทั้งองค์กร หรือคนที่ยังไม่ได้เข้ามา
• ในแนวคิดของ basecamp (tools for remote first) มี provide 2 เรื่องคือ internal communication กับ shape up ทุกๆ 6 weeks จะมี software ตัวใหม่ออกมา gathering idea, ตัดสินใจและ work on it ไม่ได้ชัดเจนขนาดเป็น test scenarios ได้
• Gitlab เป็น remote first ตั้งแต่ 2014 ไม่มี office ทำงานทั่วโลก เป็น open source contributor การคุยทุกอย่างเขียนเป็นหนังสือ ว่าถ้าอยาก contribute จะทำยังไง และรายละเอียดต่างๆ ในการทำงาน feature ใหม่ที่จะเข้า change ที่จะเปลี่ยน

Principle ของ basecamp

1. ถ้าเราไม่อยากสื่อสาร มันก็คือการสื่อสารรูปแบบหนึ่ง การไม่สื่อสารก่อให้เกิดผลเสีย
2. Real-time sometimes, async most of time เน้น tech based เช่น slack, discord ลดเรื่องของการ real time คุยงานให้น้อย เวลาเรา meeting กัน ถ้าคนเยอะ มันก็คือ 1 ชั่วโมงของทุกคนที่เข้าร่วม เวลาทำงานแบบ remote-first เราไม่ต้องการ interrupt เวลาของทุกคนมาใช้ในการประชุม ใช้การแชท, เขียน docs, ใช้ notion ในการเก็บ/สรุป ถ้าทีมอยากรู้ ก็มาดูใน notion (หรือ google docs ที่เป็น single source of truth) เรามาดูข้อมูลในเวลาที่เราอยากรู้ได้ ถ้าทำงานคนละ timezone ก็ set เวลาระหว่างกัน ว่าช่วงไหนติดต่อได้
3. ถ้าเรามีเรื่องที่ต้องคุยกัน ก็คุยเป็น long form ไปก่อน แล้วถ้าจำเป็นจริงๆ ก็ค่อยนัด meeting ซึ่งต้องนัดเป็นช่วงเวลาสั้นๆ มี timebox
4. พยายามเขียนอธิบายว่าสิ่งที่เราทำคืออะไร จดสิ่งที่คุยระหว่างประชุมด้วย เน้นจดมากกว่าคุยปากเปล่า (culture แบบ written down)
5. ถ้าประชุม จะต้องสร้าง docs ขึ้นมา title, time, agenda, timebox (ดูตัวอย่างได้ที่ gitlab)
6. เราจะไม่รีบตอบๆ ไป เพื่อให้ได้คำตอบ เพราะมันนำมาซึ่งหายนะ เช่น business ถาม เสร็จเมื่อไหร่ต้องขึ้นแล้ว หรืออยากได้ตัวเลข เราไม่มีเวลาพอที่จะเช็คว่าสิ่งที่ตอบไปทำได้จริงไหม
7. การ meeting เป็น option สุดท้ายที่เราจะใช้ การใช้ mds ของคนที่ค่าตัวแพงมากๆ มันก็ไม่ effective ถ้าเค้ามาอยู่ใน meeting แล้วไม่ได้ทำอะไร
8. การที่เราเขียนอยู่ในแชท มันก็จะไหลไปเรื่อยๆ ข้อมูลนี้มันสำคัญไหม ถ้ามันสำคัญ แสดงว่ามันต้องถูกเก็บไว้ที่อื่น การไม่ใช้ slack version pro พอ 90 วัน (หรือเท่าไหร่ msg) มันก็เคลียร์ทิ้ง ถ้ามีอะไรสำคัญให้เอาไปเก็บที่ single source เช่น notion, google docs, wiki การเอาไปเก็บในคลัง (KM) ก็จะทำให้คนที่มาทีหลังเข้าใจง่ายขึ้น เวลาเก็บคือ “เลือกแบบไหน สาเหตุคือ trade-off ข้อดีข้อเสียคือ” ทุกๆ decision มันส่งผลกระทบ เพราะ software มันคือ evolution (transform ตัวเองไปเรื่อยๆ)
9. การจดบันทึก = ศิลาจารึกพ่อขุนรามคำแหง ทายาทอสูรที่ต้องมารับช่วงต่อจากเราในอนาคต (ดูตัวอย่างได้ที่ gitlab)
10. ระวังเรื่องของการตีความ ข้อมูลไม่ควรตีความยาก ทำให้เคลียร์ agile, unit test, integration test, refinement ของเราเท่ากันหรือเปล่า เพราะคำๆ นึงมันดิ้นได้
11. อย่าคาดหวังให้ใครตอบคุณทันที ให้เวลาเค้าตัดสินใจบ้าง เว้นแต่ว่าจะมีเรื่องฉุกเฉิน
12. ถ้าเป็นเรื่องที่ต้องย้ำตัวเองบ่อยๆ เป็นเรื่องเดิม หรือเรื่องใหม่ ถ้าเรื่องใหม่ให้ย้ำตัวเองบ่อยๆ (อันนี้ฟังแล้วงงๆ)
13. Communication ที่แย่ สร้างปัญหา เช่น req ไม่ชัดเจน
14. ปัญหาของบริษัทไม่ใช่เรื่องการสื่อสาร แต่เป็นความเข้าใจของแต่ละคน/แต่ละฝ่ายไม่เหมือนกัน เป้าหมายของแต่ละฝ่ายไม่เท่ากัน DoD ของแต่ละคนไม่เท่ากัน
15. เราต้องแยกข้อมูลระหว่างข้อเท็จจริงกับส่วนขยาย
16. ‘Now’ ไม่มีอยู่จริง แต่ต้องรู้ว่าเมื่อไหร่ที่ต้องการข้อมูล เช่น อยากได้ แต่ยังไม่ได้ใช้เลยตอนนี้
17. เราไม่รีบให้ใครหาคำตอบให้ ลองมองมุมกลับบ้าง ว่าถ้าเราโดนถามจี้ให้เอาคำตอบบ้าง เราจะเป็นยังไง?​
18. ถ้าต้องการคำตอบ จะเจอพวกที่ตอบเยอะ (ไม่ได้ทำ) กับพวกที่ทำ (แต่ไม่ตอบ) ก็ต้องหาวิธีการที่จะสื่อสารกับคนพวกนั้น เช่น ถามเป็น automatic ชวนคุย เช่น ส/อา ไปทำอะไรกันมา เพื่อก่อให้เกิดการสื่อสารในองค์กร (และสร้างความสัมพันธ์)
19. สิ่งที่จะสื่อสาร จำเป็นต้องสื่อสารไหม เช่น ไม่พิมพ์/ไม่พูดอาจจะดีกว่า
20. “ด่วน(ที่สุด)” ไม่มีอยู่จริง เรียง priority ตาม business value ไม่เรียงตามใจ
21. ถ้ามีคำถามให้ถามเลย อย่าเก็บไว้จนลืม/กลายเป็นปัญหาในภายหลัง
22. นิยามคำศัพท์ ว่า ศัพท์เฉพาะพวกนี้หมายถึงอะไร
23. สื่อสารให้ถูกเวลา ไม่ใช่ขอวันศุกร์แล้วจะเอาวันจันทร์ (ยกเว้นเรื่องคอขาด เช่น prod ร่วง)
24. ทิ้งช่วงการบอกข่าวดี/ข่าวร้าย พยายามหาช่วงแยกมันออกจากกัน อย่าให้ปนกัน
25. การคุยปากเปล่า เหมือนการเล่นเกมทายคำ ที่ท่ามันเปลี่ยนไปเรื่อยๆ แล้วมันก็เพี้ยน ถ้ามันต้องทำ คุยเสร็จก็จดสรุปไว้
26. ทำให้เคลียร์ พร้อมที่จะเอาไปทำงานได้ ถ้ามี Gap ก็ให้ discuss ให้เคลียร์
27. การสื่อสารที่ดี ถูกเรื่อง ถูกที่ ถูกเวลา ถูกช่องทาง

Basecamp = tools นึง centralized ทุกอย่างไว้ในนี้ (internal tools) ที่ทุกคนเข้าถึงได้ และทุกคนแชร์ข้อมูลกัน ทุก 6 weeks = heart beat ว่าทำอะไรบ้าง มีอะไรที่สำคัญ (release note) ที่ทีมของตัวเอง เอา principle ของ basecamp มาใช้ มี slack + gg meet + Notion + Miro

15:00 มาทำ Scrum Test แล้วดูเฉลยด้วยกัน (ODDS)

ต้องบอกว่าหลังจากที่เดินตัดสินใจอยู่ 5 นาทีว่า session สุดท้ายจะเข้าอันไหนดี ก็มาลงท้ายที่อัฒจันทร์ตรงนี้

เป็น Session ที่เหมือนมา Quiz ความรู้ไปด้วยกัน แล้ว Speaker ก็อธิบายคำตอบ หรือข้อสงสัยเพิ่มเติม

• PO คนตัดสินใจ “ของใน backlog” คือของที่ต้องแก้ sprint นี้จะให้ทีม focus กับปัญหาไหน
• ทีม ปัญหาที่เลือกมาแล้วนั้นเราจะแก้มันยังไง พร้อมจะรับผิดชอบกับ solution ที่คิด
• Scrum ไม่มี role ที่ชื่อว่า Project manager
• The most common length of a sprint is 2 weeks
• Scrum = built-in reality check which complex products are developed (ไม่ใช่ best practices)
• เมื่ออยู่ใน sprint retrospective หน้าที่ของ scrum master คือ facilitate เพื่อให้ใช้เวลาคุ้มค่า และปลอดภัย ไม่ต้องจด ไม่ต้องทำ report ส่งนาย
• DoD เป็นสิ่งที่ PO คุยกับทีม (product backlog item) ว่า “เสร็จ” คืออะไร เป็นสิ่งที่ใช้ apply ทั้ง backlog (ตาม scrum guide) item เขียนด้วย user story + acceptance test criteria หรือ sprint goal
• คน estimate effort backlog item = development team ทีมถึงได้มี commitment สูงสุด PO เป็นคนเขียน เลือกว่าจะแก้อะไร เป็นคนเรียง priority — ทีมเป็นคนเลือก solution เพราะฉะนั้น estimate ถึงอยู่กับทีม
• Skills อะไรที่ทีมต้องมี = DB, Testing, Business Req analysis, functional writing, coding, software architecture/design, UXUI เนื่องจากเป็น cross-functional team ยิ่งทีมครอบคลุมมากเท่าไหร่ ของเวลาเอาเข้า sprint ก็จะ validate ได้เยอะ Scrum ก็จะยิ่งแสดงพลัง
• ก้าวสั้น ก้าวยาว ขึ้นกับ effort, value จะได้มากน้อย ขึ้นกับ PO เช่น เลือก effort น้อย value เยอะ แต่ละก้าวของทีมก็จะได้ ROI เยอะ
• DoD ถ้ารวมเรื่องการต่อเชื่อมกับคนอื่น มันก็จะมี dependencies สูง agility จะต่ำ
• CEO บอกว่ามีงานเพิ่มที่ไม่ใช่ goals ของ sprint นี้เข้ามา ต้องทำยังไง? -> ให้ PO ไปคุยกับ CEO ซึ่งหลังจากคุยแล้ว มันอาจจะกลายเป็นเอางานเข้า sprint หน้า หรือเอางานเข้า sprint นี้ แล้วเอางานที่มี point เท่า value น้อยออก (swap ของที่ยังไม่ได้ทำ) แต่ไม่ควร add เข้าไปเลย (เพราะทีมจะตาย)
• Sprint planning = 8 hours for a 4-week sprint ถ้าระยะเวลาสั้นกว่านั้น ชม. ก็น้อยกว่านั้น
• Sprint forecast (Sprint committed) owner = team ด้วยกัน
• Sprint backlog สร้างตอนอยู่ใน sprint planning part 1 — PO มาเจอกับทีม แล้วก็ confirm requirement (PO ต้องอยู่เสมอ เพราะทีมจะ confirm solution)
• sprint planning part 2 คือ ทีมรับงานมาจาก PO แล้ว มาคุยว่าจะทำให้เสร็จยังไง (PO ต้องสามารถเข้าถึงได้ ติดต่อได้ แต่ไม่ต้องอยู่ก็ได้)
• ถ้า sprint นึง 2 weeks ก็ใช้เวลา planning 4 ชั่วโมง (2+2)
• scrum ถ้ามีสองทีม ก็ต้องมีการ sync กัน ซึ่งแต่ละทีมไม่ควรมีเกิน 7 คน (ใช่ตัวเลขนี่ไหมนะ) เพราะคนยิ่งเยอะ เส้นการสื่อสารก็ยิ่งพัวพันตามกันไปด้วย
• Product backlog items ทุก items ต้องมี value กับ customer ไม่ได้ represent work to be done
• Task จะเกิดตอน planning part 2 ซึ่งมีแค่ทีมเท่านั้นที่อ่านรู้เรื่อง
• Development Team ทำทุกอย่าง ทำไม่ได้แค่เลือก PO — จัดการ internal conflict, monitor and optimize to meet sprint goal daily, SM ต้องกำจัดอุปสรรคภายใน 24 ชั่วโมง ถ้าทำไม่ได้ ให้เอาไปเทรนนิ่ง, monitoring productivity and learning

ปิดงานด้วยการกล่าวจากคุณเก่ง Bitkub อีกซักรอบ และตัวแทนของผู้ร่วมงานสามท่าน (พร้อมรับมอบของ) ถ่ายภาพหมู่ ดนตรีสด และเบียร์สดแบบ Unlimited จากทาง PALO IT

สิ่งที่ชอบ:

• มีการจัดงานที่ค่อนข้างดีเลย มีการสื่อสารในกลุ่มไลน์ล่วงหน้าตลอด มีคนใหม่มาถามซ้ำ Staff ก็ตอบแล้วตอบอีก (เป็นกำลังใจให้ตลอดนะคะ) มีการทำภาพ Visual สรุปสิ่งที่จำเป็นต้องรู้
• ทางทีมงานให้บัตรตอบแทน 1 ใบ สำหรับคนที่ช่วยไปมอบ quote (ถึงแม้ฉันจะไม่ใช่ Influencer ตัวจริงในวงการนี้ก็ตาม)
• สถานที่เดินทางสะดวก (มาด้วย MRT) จัดโซนของแต่ละ space ห่างกันพอควร มีพื้นที่เดินหลบไปมาค่อนข้างมาก
• พอมีอาหาร/เครื่องดื่มจากสปอนเซอร์ให้ทำให้ไม่ต้องหลุดไปไหนเลย ไม่ต้องเจอจราจรติดขัดช่วงพักกลางวัน (ต้องใช้ลิฟต์ขึ้นลง)
• ตรงต่อเวลาดีมาก อาจจะเป็นเพราะมี buffer 15 นาทีด้วย ทำให้ทุก session สามารถเริ่มได้ตรงเวลา และสามารถไปพักผ่อน เข้าห้องน้ำก่อนได้
• Photo Booth เป็นกิจกรรมที่น่ารักดี (aka ตู้สติกเกอร์ ในสมัยวัยเด็ก แต่เดี๋ยวนี้มันไม่มีกาวแบบนั้นแล้ว ><)

สิ่งที่รู้สึกว่าดีขึ้นได้อีก:

• จอทีวีเล็ก สถานที่ฟังค่อนข้างกว้าง มองไม่เห็น แล้วพอโซนไหนที่กว้างมากๆ เนื่องจากไม่มีการใช้ไมค์ ก็ไม่ค่อยได้ยินอีก 555+
• มีบางโซนที่หนาวมาก แต่บางโซนก็ร้อนเลย (เช่นโซนหกในช่วงเช้า รับอากาศธรรมชาติกันสุดๆ แต่ทีมงานก็เปลี่ยน space ได้ในช่วงบ่าย Agile มาก ประทับใจ)
• เสียงไมค์กับลำโพงส่วนกลางดังชัดอลังการมาก พี่พิธีกรทั้งสองก็ดีดมากๆ จนปวดหัว (อาจจะเป็นความผิดฉันคนเดียวที่ไม่ชอบเสียงดัง)
• อาจจะเพิ่ม level ผู้ฟัง หรือ Year of Agile Experience ในแต่ละหัวข้อได้ เช่น beginner, intermediate, (expert ไม่ต้องใส่แล้วกัน 55+) เป็นการ set expectation ของผู้ฟังเองว่าจะเจอกับอะไร เพราะบาง session ก็ต้องอาศัยการมีประสบการณ์มาแล้วส่วนหนึ่งถึงจะเข้าใจว่า context ต่างๆ ที่ถูกยกมาคืออะไร

ขอบคุณ Staff ที่ช่วยกันจัดงาน Drive Community นี้ค่ะ เรียกตัวเองว่าเป็นมือใหม่ในวงการ ที่ไม่เคยมางานนี้มาก่อน (เคยไปแค่งาน Agile Tour Bangkok 2020 ครั้งเดียว) ขอบคุณ Sponsors ทั้งสถานที่ อาหารการกิน และของแจกจำนวนมากมาย ขอบคุณเหล่าพี่ๆ Speaker ที่มาแชร์ความรู้แบบไม่อั้นด้วยค่า

/me ไปงานตั้งแต่เช้า ตั้งใจตลอด รัวนิ้วในคอมไม่หยุด ตาปรือตั้งแต่หลังอาหารเที่ยงจนถึงตอนนี้ แต่ถ้าคืนนี้ไม่เขียน Blog นี้ มันจะไม่มีวันได้ Publish อีกเลยในชาตินี้ พอถึงบ้านก็เลยถ่างตา และทำให้เสร็จภายใน 2 ชั่วโมง (กว่าๆ) เย้!