(credit cover: เพจ บริษัท สยามชำนาญกิจ จำกัด https://www.facebook.com/siamchamnankit)
ผมได้มีโอกาสเข้าร่วม Micro-Learning Class ยามเช้าตรู่ Scrum Framework โดยพี่ ประธาน ด่านสกุลเจริญกิจ ซึ่งผมได้ข้อคิด และความประทับใจในหลายส่วน จึงขอมาแบ่งปันที่ตัวเองสัมผัสได้ประมาณนี้ครับ
Refinement
(Product Backlog) Refinement คือหนึ่ง Workshop (ผมขอมองเป็น Workshop นะครับเพราะ ต้องใช้แรงกาย แรงสมอง สมาธิ อย่างเข้มข้น) ที่จำเป็นต้องทำอย่างมาก เพราะเป็นการ เตรียมของ (End to End Flow, Task) ที่จะทำใน 2-3 รอบการทำงานถัดไป ที่ คณะทำงานนั้น สามารถหยิบไปทำได้เลยโดยไม่มีข้อกัลวล (ข้อกังวล และ Limitation ต่างๆ นั้น จะถูกคุยและทำให้ชัดเจน, ประสานงานกับคนที่เกี่ยวข้องเช่น เจ้าของ requirement, Product Owner ผู้มีสิทธิ์ในการตัดสินใจฟันธงลงมติ จนได้ข้อสรุปแล้ว)
ประสบการณ์ส่วนตัวผมที่เคยพลาดมาจากการ เตรียมของในช่วง Sprint Planning นั้น ด้วยเวลาที่จำกัดมากๆ ทำให้เกิดการหลุด Scenario บ้าง, ตัดสินใจกำหนด Task งานด้วยความไม่เข้าใจ ส่งผลให้ไม่สามารถส่งมอบได้ตามที่คุยกับ ผู้มีส่วนได้ส่วนเสีย (Stakeholder) และเกิดผลกระทบเป็นลูกโซ่กับรอบการทำงานต่อๆไป
Meet the GOAL
การ Synchronize ข้อมูลกันระหว่างคณะทำงาน ที่มีการให้ข้อมูลในรูปแบบ เมื่อวานนี้ทำอะไร, วันนี้ทำอะไร, ติดปัญหาอะไรบ้าง ถ้าการให้ข้อมูลดังกล่าว แต่ละคนในคณะทำงานมีเป้าของวันนั้นๆ ไม่เป็นไปในทางเดียวกัน ข้อมูลที่ sync กันนั้น แทบไม่มีประโยชน์อะไรต่อการส่งมอบสำหรับ รอบการทำงานนั้นๆเลย (แม้แต่ output ที่จะเกิดขึ้นในแต่ละวันก็ไม่ได้ช่วย)
การตั้ง เป้าหมายรายวันจากสมาชิกแต่ละคนในคณะทำงานดังกล่าว เป็นการย้ำเตือนว่า สิ่งที่ทำในเมื่อวาน สิ่งที่จะทำในวันนี้ ตอบรับกับ เป้าที่มีหรือไม่? และปัญหาอุปสรรค์ที่เกิดนั้น มีผลกับการไปไม่ถึงเป้าหมายมากน้อยขนาดไหน (เพื่อปรับแผน และ/หรือ ขอความช่วยเหลือแต่เนิ่นๆ)
PDCA
Plan Do Check Act เป็นเครื่องมือในเชิงวิศวกรรม, อุตสาหกรรม ที่ผมเองทึ่งมากว่า สามารถนำมาใช้ได้อย่างเนียนๆ อย่างมีประสิทธิภาพในการพัฒนาซอฟต์แวร์ และ มันกลมกลืนกับการทำงานให้เกิด Output ในแต่ละวันทำงานได้ดีมาก
Career Path
การพัฒนาตัวเองเพื่อเติบโตไปตามสายงาน (Career Path) เป็นหน้าที่รับผิดชอบที่แต่ละคนต้องทำเอง ควรแบ่งเวลา 20 ชั่วโมงต่อสัปดาห์จากเวลาส่วนตัว เพื่อพัฒนาฝึกฝน (จากการเรียน Online/Offline, เข้าร่วมสัมนา, Coaching, อ่านหนังสือ, เอาโจทย์งานมาฝึกออกแบบ ฝึกเขียน test และ implementation code, อื่นๆ)
Rule of Integration
การทำงานย่อยๆ ของสมาชิกแต่ละคนในคณะทำงานนั้น มารวมกัน ณ ที่ใดที่หนึ่ง (ในบริบทนี้ ผมขอเรียกว่า repository) จำเป็นต้องมีข้อตกลงร่วมกันว่า สิ่งที่นำเข้ามารวม ต้องตรงตาม Standard ที่กำหนดไว้ (เช่น Coding Convention, ฟังก์ชั่นการทำงานต้องผ่านชุดทดสอบ ระดับ Unit และ Integration ด้วยการ Mock ส่วนที่การทำงานนั้นไปแตะ) จึงจะถูกยอมรับให้นำมารวมกันได้ เพื่อป้องกันการ ทำงานหนึ่งงานใด แล้ว มีผลกระทบการทำงานที่ผิดพลาดกับสิ่งที่มีอยู่ก่อนหน้านี้
ซึ่งในขั้นตอนนี้ การสร้าง Pipeline ที่มีขั้นตอน Automation Test, Automation Build Automation Deploy จะช่วยให้เกิด Feedback Loop กับคณะทำงานได้เร็ว เพิ่มความคล่องตัวมากขึ้น
ใคร? ต้องเป็นคนทำการแตกงาน (Task breakdown)
ส่วนนี้ ง่ายๆ เลยครับ คณะทำงานทั้งหมด (Programmer, Tester, BA, อื่น) ช่วยกันทำการแตกงานจาก End-to-End Flow เพื่อลงในระดับว่า ใช้โครงสร้างข้อมูลแบบไหน มีฟังก์ชั่นอะไรบ้าง กำหนดเวลาแต่ละงานที่เหมาะสม โดยการคุยแลกเปลี่ยนมุมมองความเชี่ยวชาญของแต่ละคน กับงานดังกล่าว
First Come First Serve
อย่างไรก็ตาม ชิ้นงานที่ส่งมอบ จะเป็นไปตาม Priority ของ Product Backlog ซึ่งทาง Product Owner ทำการจัดสรรตามคุณค่าทางธุรกิจและ Return Of Investment แล้ว ไม่มีการหยิบงานมาทำตามอำเภอใจ อะไรง่ายเอามาทำก่อน
อุปมา Order การสั่งอาการ การเสิร์ฟแต่ละจานทำตามลำดับที่ได้ก่อนหลัง เช่นกัน