photo1

ออกตัวก่อนว่า ก่อนหน้าที่จะมาดำรงชีพด้วยการเป็น ScrumMaster นั้น ผมเองเคยสวมหมวก ในตำแหน่ง Team Leader เอย Project Manager เอย และ IT Development Manager เอย ซึ่ง โครตของโครต Command และ Control เลย ขอบอก แต่เมื่อวันที่ปรับเปลี่ยนตัวเองมาเป็น ScrumMaster แล้วนั้น อย่าเรียกว่านิสัยเลย ขอเรียกว่า สันดาน ในการเก้บบันทึกตัวเลขโน้นนี่นั่น เพื่อรวบรวมสถิติต่างๆ เพื่อใช้ในการวางแผนก็ยังคงมีอยู่ แต่เปลี่ยนจากการที่จะนำ ตัวเลข ต่างๆ นั้นมาใช้ในการวางแผนล่วงหน้า (Predictive) ผมกลับใช้มันในการดูประสิทธิภาพการทำงานของทีม โดยมีศัพท์หล่อๆ เรียกว่า Empirical แปลเป็นไทยแบบหล่อๆ ว่า อดีตขีดเส้นอนาคต (ได้มาจากหนังสือเล่มหนึ่ง)

จาก สันดาน เดิมๆ ผมก็นั่งคิดโน้นนี่นั่นตอนที่เข้าไป Coaching ณ บริษัท แห่งหนึ่งว่าจะเก็บสถิติต่างๆ ของ Delivery Team ของ Scrum ได้อย่างไรเพิ่มเติมบ้าง นอกเหนือจาก Burn Down Chart หรือ Burn Up Chart คิดไป คิดมา จนออกมาเป็นดังรูปด้านบนนี้ ซึ่งยังไม่รู้ว่าจะเรียกมันว่าอะไรเหมือนกัน

ท้าวความตามท้องเรื่อง

Screen Shot 2557-05-27 at 3.05.45 PM

Scrum ประกอบไปด้วย 3 บทบาท 6 กิจกรรม และ 3 ทรัพย์สิน (ทรัพย์สิน ใน Scrum ใช้คำว่า Artifacts ซึ่งถ้าแปลก็จะคือ ของที่มนุษย์ประดิษฐ์ขึ้น ซึ่งจะฟังดูแปลกๆ ผมและพี่รูฟ เลยเรียกว่า ทรัพย์สิน เพราะทรัพย์สินต้องมีผู้ถือครองดูแล และ 3 ทรัพย์สิน ใน Scrum ก็ล้วนแล้วแต่มีผู้ที่ต้องถือครองและดูแล) และ 1 ใน 3 ทรัพย์สิน นั้น ก็คือ Product Backlog ซึ่ง ถือครองและดูแล โดย Product Owner จะไม่ขอลงรายละเอียดละกันนะครับว่า Product Owner ทำอะไรบ้าง

ใน Product Backlog จะประกอบไปด้วย Product Backlog Item ซึ่งแบ่งได้ออกเป็น 4 ประเภท โดยขออธิบายแบบเข้าใจง่ายๆ ดังนี้ คือ

  • Feature, ความต้องการ (Requirement) ต่างๆ ที่ถูกแบ่งย่อยออกเป็นชิ้นเล็กๆ โดยมองให้เป็น 1 ระบบการทำงาน (Business Process)
  • Technical Work, งานด้านเทคนิคต่างๆ ที่จะต้องมีในการสร้าง Product ขึ้นมา เช่น ติดตั้ง Servers ต่างๆ
  • Knowledge Acquisition หรือชื่อเล่นว่า Spike, เรื่องอะไรบ้างที่จะต้องศึกษา หรือ ทดลองทำ เพื่อนำมาช่วยและใช้ในการสร้าง Product
  • Bug, ข้อผิดพลาดต่างๆ ที่พบใน Product

สมมุติว่า Product Owner จัดสรรของมาแล้วว่าในรอบการทำงานที่ 1 (Sprint 1) และ Delivery Team สรุปว่า น่าจะสามารถพัฒนา และส่งมอบได้ ประกอบไปด้วย

  • 3 Features
  • 5 Technical Works
  • 2 Knowledge Acquisitions
  • 0 Bugs

แล้วก็เริ่มสร้าง Product และดำเนินการจนจบ Sprint

เก็บสถิติ

ผมเองจะเก็บสถิติโดยเก้บตัวเลข 2 ตัว ในแต่ละ Product Backlog Item คือ

  • รับเข้า = Delivery Team รับปากกับ Product Owner ไว้ว่า น่าจะสามารถพัฒนา และส่งมอบอะไรได้ บ้าง
  • ตรวจรับ = Product Owner ตรวจรับ อะไรบ้าง หลังจากได้เห็น ได้เล่น ได้สัมผัส Product

ผมก็จะตีตารางบนกระดาษ A4 ตามภาพด้านบน แล้วก็เก็บตัวเลขทุกๆ Sprint ตลอดทั้ง Release นั้นไว้ เพื่อนำกลับมาสะท้อนให้ Delivery Team เห็นว่า รับปากอะไรมาบ้าง และส่งมอบได้จริงๆ เท่าไร เพื่อจะนำไปสู่การช่วยกันหาทางปรับปรุงวิธีการทำงานให้ดีขึ้นเรื่อยๆ เพื่อให้

ของที่รับปากว่าจะสร้างให้นั้น = ของที่ส่งมอบและได้รับการตรวจรับ

ซึ่งใน Sprint Retrospective ผมก็มักจะหยิบสถิติพวกนี้ มาให้ทีมได้คิด และนำเสนอหาทางเพื่อพัฒนาทีมขึ้นเรื่อยๆ เป็นต้น นอกจากนั้นผมยังสนใจเรื่องของจำนวน Technical Works, Knowledge Acquisition และ Bug ด้วยว่าเกิดขึ้นในแต่ละ Sprint เท่าไร โดยเฉพาะ Bug ซึ่งเป็น Product Backlog Item ที่จะต้องเกิดขึ้นน้อยมากๆ หากเกิดขึ้นเยอะ แสดงว่ามีเรื่องยังต้องปรับปรุงอีกหลายๆ อย่าง ตั้งแต่การได้มาของ Requirement การตีความและวิเคราะห์ ลากยาวไปจนส่งมอบ สิ่งเหล่านี้นำไปสู่เรื่องของการพัฒนาทั้งกระบวนการทำงาน และทักษะต่างๆ ของ Scrum Team ( Scrum Team = Product Owner + Delivery Team + ScrumMaster)

เน้นย้ำ…อีกที

บันทึกนี้ เกิดจาก สันดาน ของผมเอง ใน Scrum นั้นไม่ได้บอกอะไรเรื่องการเก็บสถิติแบบนี้ ผมคิด และสร้างมันขึ้นมาจาก

Empirical อดีตขีดเส้นอนาคต + ประสบการณ์การทำงานเชิงการบริหารจัดการ + การนำเสนองานให้จบภายใน 1 แผ่นจาก COO ญี่ปุ่นท่านหนึ่ง

สันดาน ก็คือ สันดาน ยากที่จะดัดให้ดีขึ้น แต่ผมก็ยังชอบ สันดาน นี้ของตัวเอง 🙂

 

วันอังคารที่ 27 พฤษภาคม พ.ศ. 2557
จตุจักร กรุงเทพมหานคร