(Day#2) จังหวะ..จะ..เดิน

(Day 1 อ่านที่นี่ค่ะ) วันนี้เป็นวันที่ 2 ของการทำงานใน Sprint และเป็นวันแรกที่เริ่มทำงานเต็มที่ เพราะ ไม่มี planning ช่วงเช้าเหมือนวันแรก ดังนั้น เมื่อทีมมาถึง ก็เริ่มทำงานกันทันที…

โดยวันนี้ สิ่งที่พี่หนุ่มทำแล้วสะดุดตาภา คือ

• มาเช้ามาก คือ มาก่อนเวลาเริ่มงานไม่ต่ำกว่าครึ่งชั่วโมง (ภารู้ได้จากการ check-in และ tag ภามาผ่าน Facebook ซึ่งตอนนั้น ภายังอยู่บนถนนอยู่เลย แถมสุดท้าย มาช้า 5 นาทีด้วย)
• คอยตอบคำถาม และจูนความเข้าใจของ Management
• พาทีมไปหา Solution เนื่องจากเมื่อวานตอนเย็น ทีมบอกว่ามีปัญหาทางเทคนิค ทำให้ build งานช้ามาก…วันนี้พี่หนุ่ม จึงเอา Solution มาให้แต่เช้า พร้อมทั้งต่อสายให้คุยกับพี่ปุ๋ย somkiat.cc
• ให้หนังสือภามาเสพ 1 เล่ม พร้อมสมุดจดแบบที่ภากำลังอยากได้
• ถามทีมเป็นระยะ ว่ายังคิดว่าจะสามารถส่งมอบงานได้ตามกำหนดหรือไม่ โดยช่วงจังหวะที่ถาม จะเป็นช่วงประมาณ…
  - หลัง Stand-up Meeting
  - มี task เพิ่ม / บางครั้งที่ task ขยับ

อีกอย่าง คือ Stand-up Meeting วันนี้ พี่หนุ่มบอกทีมเพียงแค่ว่า ให้มายืนด้วยกันหน้าบอร์ด แล้วพูด 3 อย่างตามที่เราคุ้นเคย (เมื่อวานทำอะไร, วันนี้ทำอะไร, มีปัญหาอะไร) และให้พูดเลย ซึ่งภาก็แอบสงสัยว่า…อ่าว รอบนี้ไม่อธิบายเหตุผลแหะ ว่ากิจกรรมนี้ทำเพื่ออะไร, ทำไมต้องมายืน (และวันที่ 3 ภาได้รับคำตอบเรียบร้อย…ติดตามอ่านได้ที่บทความถัดไปนะคะ #เรียกแขก ฮา)

นอกจากนั้น..ตลอดวันตั้งแต่เช้าถึงบ่าย ก็มีประโยคที่ออกมาเป็นระยะ ที่รู้สึกสะกิดใจ และปรับมุมมองใหม่ มากมาย โดยที่ภาอยากแชร์เพิ่มคือ

1. Tester…ในบางส่วน เราควรเปลี่ยนจากทดสอบ UI มาเป็นทดสอบ Business Logic ดีกว่าไหม
   
    หลังจากฟังที่พี่หนุ่มอธิบาย…ภาเข้าใจว่าเพราะ 
    — UI มันมีการเปลี่ยนแปลงได้ตลอดและบ่อยมากๆ ส่วน Business Logic คือสิ่งสำคัญและซีเรียสกว่าเวลาหลุดไป ทั้งยังเปลี่ยนแปลงไม่บ่อยเท่า UI อีกด้วย
    — UI ไม่จำเป็นต้องใช้ test team ทำเท่านั้นก็ได้หรือเปล่า ความเป็นจริง developer ก็เทสได้ (เอาจริงๆแม่บ้านตึกก็เทสได้เหอะ) แต่สิ่งสำคัญคือ เอาเค้าเข้า planning part 1 ด้วยนะ เค้าจะได้เห็น flow รวม
    
    ซึ่งเรื่องนี้ เป็นเรื่องที่ภาไม่เคยคิดถึงมาก่อน ก่อนหน้านี้ภาคิดแค่ว่า อยากจะ prevent bug, test first, automated test แต่ไม่เคยคิดว่า ต้องหยิบจุดไหนมา automated และจุดไหนไม่ต้อง (เมื่อก่อนคิดว่า อะไร automated ได้ ก็จัดเต็มโล้ด)
    
    อีกอย่างที่ภารู้สึกว่าสำคัญมากๆ ที่จะทำให้เรามองออกว่า จุดไหนต้องทำ automated คือ การแตกงานที่เห็นภาพชัดเจน…ซึ่งรอบนี้ พี่หนุ่มใช้ Service Blueprint มันเลยเห็นภาพชัดขึ้นมาก ว่าเวลาร้อย flow แล้ว เส้นไหน เป็นระดับ UI หรือ Business logic (ใครเป็น tester ผ่านมาอ่าน ลองศึกษาเรื่องนี้เพิ่มเติมดูนะคะ แนะนำเลย)
2. ต้องเชื่อทีม Estimate งาน
    
    ปัญหาโลกแตกอีกข้อหนึ่ง คือ เราจะรู้ได้ยังไง ว่าทีมประเมินงานได้ถูกต้อง ไม่ได้ตีเวลาเผื่อๆ เพื่อให้สบายหรือกันเหนียวไว้ และสุดท้าย…เมื่อรู้สึกว่ามันไม่ศักดิ์สิทธิ์ ตัวเลขก็ไม่มีประโยชน์อะไร ก็จะทำไปเพื่ออะไร เสียเวลาโหวต เสียเวลานั่งถก
    
    มีคนถามแบบนี้กับพี่หนุ่ม…และพี่หนุ่มตอบง่ายมาก ซึ่งก็คือ… 
    “ไม่เห็นยากเลย ก็ผมเห็นอยู่” (ทุกคนทำหน้างง) 
    “ผมก็เดินผ่านทีม ผมก็เห็นทีมทำงาน ไม่ได้เล่นเฟส ไม่ได้ Youtube เค้าก็ทำอยู่เต็มที่นะ”
    
    จริงด้วย!!! นี่มันหน้าที่ Scrum Master เลยนะ (สำหรับภา..นี่เป็นอีกเหตุผลที่ทำไมควรมี Scrum master อยู่กับทีม)
    การที่ Scrum Master ทำแบบนี้ มันทำให้ตอบง่ายมากเลย ว่าทีมทำเต็มที่แล้ว บางคนอาจจะคิดว่า นี่ต้องคอยจับผิดเหรอ ดูแลตัวเองไม่ได้ self-managed ไม่ได้หรือไง
    สำหรับภา ภาจะเลือกเชื่อใจทีมก่อน แต่ที่ต้องทำ…เพราะมันคือการมีข้อมูลเอาไว้เพื่อใช้ “ปกป้องและพัฒนา” มันไม่ใช่การจับผิด หรือทีมไม่ self-managed
    
    เพราะฉะนั้น เมื่อเรื่องความเชื่อใจเคลียร์ ที่เหลือก็เป็นแค่เรื่องความแม่นยำในการประเมินงานของทีมละล่ะ ซึ่งมันสามารถฝึกกันได้ วิธีหนึ่งคือ ใช้ตัวเลข Estimate / Actual ของแต่ละรอบมาคุยกัน
    
    อีกอย่างคือ…ถ้าไม่ให้ทีมประเมินงาน แล้วจะให้ใครทำล่ะ ในเมื่อเค้าเป็นคนทำงาน เค้าควรจะรู้ดีที่สุดหรือเปล่า?

สุดท้าย วันนี้จบลงด้วยการ Sync งาน และพี่หนุ่มยิงด้วยกลุ่มคำถาม เช่น

• ตอนนั้นที่..(จุดๆๆ)..ภารู้สึกถึงพลังงานอะไรไหม
• วันนี้ได้อะไรฉุกคิด หรือเป็นเรื่องหลักกลับบ้านไปบ้าง
• มีจังหวะไหนงงบ้าง