สกรัม หนึ่ง สอง สาม ปลาฉลามขึ้นบก

ออกแบบ Sprint Backlog เพื่อนำ Visualization มาช่วยให้เราพัฒนาอย่างต่อเนื่องเรื่อยๆ

Sprint-Backlog-Scrum-Guide

สวัสดีดช้าวันจันทร์ที่ 28 มีนาคม พ.ศ. 2559 เช้าวันที่การจราจรในพระนครน่าจะหนึบหนับเพราะฝนเทลงมาตั้งแต่เช้ามืด เนื่องจากมีพลขับให้เลยเปิดเครื่องมาพล่ามเรื่องของ Sprint Backlog ลงใน SCRUM123 ปลาฉลามขึ้นบกนี้นะจ๊ะ

หนึ่งในสามของ Artifacts (หลังจากนี้ขอเรียกว่า ทรัพย์สิน) ของ SCRUM นั้นคือ Sprint Backlog ผมขออ้างอิงจากเอกสาร Scrum Guide ฉบับ กรกฎาคม พ.ศ. 2556 ของลุง Jeff Sutherland และลุง Ken Schwaber โดยขอสรุปพอสังเขปว่า

Sprint Backlog จะประกอบไปด้วย Product Backlog Item (PBI) ที่ทีมพัฒนาและส่งมอบซอฟต์แวร์วางแผน ประมาณการ และคาดการณ์ แล้วว่าจะน่าจะสามารถส่งมอบได้ตาม Definition of Done และเป็นไปตามเป้าหมายของ Sprint นั้น (Sprint Goal) โดย Sprint Backlog ต้องอยู่ในบริเวณที่ทุกๆ สมาชิกของทีมพัฒนาและส่งมอบซอฟต์แวร์สามารถเข้าถึงได้ง่าย และตลอดเวลา

ในเอกสารของทั้งสองลุงไม่ได้บอกถึงหน้าตาของ Sprint Backlog ว่าจะต้องหล่อประมาณไหน โดยส่วนใหญ่ Sprint Bacnklog จะมาในรูปแบบพื้นๆ ง่ายๆ คือ กระดานที่แบ่งออกเป็น 3 ช่อง คือ สิ่งที่ต้องทำ (To-Do) สิ่งที่กำลังลงมือทำอยู่ (Doing) และสิ่งที่ทำเสร็จไปแล้ว (Done) ตัวอย่างเช่น

IMG_0223

เคยมีครูบาอาจารย์ในสาย SCRUM บอกผมว่า

ScrumMaster ไม่มีหน้าที่สร้าง Sprint Backlog ให้ทีมพัฒนาและส่งมอบซอฟต์แวร์

เพราะต้องให้ทีมเขาเลือกเองว่าเขาอยากจะออกแบบขั้นตอนการทำงานของตัวเองอย่างไร แต่สำหรับผมนั้นเมื่ออุปโลกน์ตัวเองขึ้นมาเป็น ScrumMaster นั้น หนึ่งในหน้าที่คือ Coach และครูบาอาจารยือีกท่านที่เป็นสายโค้ชสั่งสอนมาว่า โค้ชต้องทำหน้าที่เป็น กระจกเงา เพื่อสะท้อนให้ โคชชี่ ได้ตระหนัก เห็นว่าตนเองต้องพัฒนาอะไร และอยากจะไปกับเราไหมที่จะนำพาโค้ชชี่จากจุดหนึ่งไปยังอีกจุดหนึ่งโดยไม่บังคับ

ดังนั้นผมเองจะนิยมที่จะออกแบบและสร้าง Sprint Backlog ให้ทีมพัฒนาและส่งมอบซอฟต์แวร์โดยยังคงยึด 3 ช่อง To-Do, Doing และ Done ไว้เสมอ แต่หน้าตาจะแตกต่างกันไปแล้วแต่ว่าผมได้เจอทีม และสิ่งที่ทีมต้องส่งมอบแบบไหน

พื้นฐานของตัวผมเองนั้นทำงานสาย Project Management รวมทั้งดูแลจัดสรรกำลังพลของสมาชิกในทีมพัฒนาและส่งมอบซอฟต์แวร์ และทีม Test มาก่อน ดังนั้นเมื่ออุปโลกน์ตัวเองเป็น ScrumMaster ผมนิยมชมชอบในการให้ทีมพัฒนาและส่งมอบซอฟต์แวร์ใช้เวลาของ Sprint Planning อย่างมีประสิทธิผล และใช้ Sprint Backlog เป็นเครื่องมือในการบริหารจัดการการทำงานใน Sprint นั้นๆ

สิ่งที่จะได้เสพเป็นตัวอย่างของ Sprint Backlog ที่ผมออกแบบให้ทีมพัฒนาและส่งมอบซอฟต์แวร์ ณ ที่แห่งหนึ่ง โดยจากการเข้าไปพูดคุยมีปัญหาที่อยากจะแก้ไขให้ดีขึ้นอยู่ 3 ข้อ เลยทำการออกแบบ Sprint Backlog ออกมาหน้าตาแบบนี้ โดยใช้ 2 เครื่องมือมาประยุกต์ คือ Service Design Blueprint + Visualisation และหยิบหลักปฏิบัติ 1 ข้อจาก Kanban คือ Limit WIP (หรือใช้มันครบทั้ง 6 ข้อเลยว่ะ!!!)

IMG_7063

ผมใช้เครื่องมือชื่อ Service Design Blueprint เข้ามาใช้ในการทำ Sprint Planning ทั้ง Part I และ Part II (ไว้จะมาอธิบายอีกทีเรื่อง Service Design Blueprint) โดย Sprint (ระยะเวลา 5 วัน) นี้รับ Product Backlog Item (PBI) เข้ามา 1 การทำงานอยู่บนกระดานสีขาวฝั่งซ้ายมือออกมาโดยให้สมาขิกในทีมพัฒนาและส่งมอบ คิด วิเคราะห์ และแตกงาน (Work Break Down) ออกมาว่าถ้าจะส่งมอบ Story บนกระดานนี้จะต้องทำอะไรบ้าง ซึ่งแต่ละงาน (Task) เขียนลงใน Post-it พร้อมทั้งประมาณการเวลาที่จะใช้คราวๆ โดยให้ตัวเลขกับทีมเป็น

  • 30 นาที
  • 1.0 ขั่วโมง
  • 2.0 ชั่วโมง
  • 3.0 ชั่วโมง
  • 4.0 ชั่วโมง

หากงานไหนประมาณการมาว่าเกิน 4.0 ชั่วโมง แสดงว่าเรายังสามารถแบ่งงานให้ย่อยได้อีก
(ลำดับเวลาที่ผมใช้มิได้ตายตัวนะครับ เกิดจากการพิจารณาจากข้อมูล และโจทย์ที่ต้องแก้ไข)
และนำงานที่เขียนลง Post-it ทั้งหมดที่ได้จาก Sprint Planning Part II ที่ใช้เวลาประมาณ 2.0 ชั่วโมง ไปแปะไว้บนกระดานสีขาวในตำแหน่งของแต่ละงานว่าจะเกิดขึ้นที่ตรงไหนบ้าง

Sprint Backlog

Sprint-Backlog-1

Sprint Backlog ผมได้ออกแบบให้ทีมออกมาหน้าตาแบบนี้โดยจะประกอบไปด้วย

  • Daily To-Do ช่องสำหรับแปะงานในแต่ละวัน โดยนำหลักปฏิบัติ Kanban ข้อกำหนด Limit WIP มาประยุกต์ใช้
  • Doing ช่องสำหรับแปะงานที่ทำในแต่ละวัน โดยผมออกแบบให้ช่อง Doing นั้นแปะ Post-it ได้แถวละ 2 ใบเท่านั้นสำหรับแต่ละคนในหนึ่งช่วงเวลา โดยนำหลักปฏิบัติ Kanban ข้อกำหนด Limit WIP มาประยุกต์ใช้
  • Done ช่องสำหรับแปะงานที่เสร็จโดยแยกเป็นรายวัน
  • Impediment อุปสรรคต่างๆ ที่เกิดขึ้นมาระหว่างรอบการทำงาน

Daily Scrum

ทุกวันที่ทีมพัฒนาและส่งมอบซอฟต์แวร์มาทำพิธีกรรม Daily Scrum กันนั้น โดยใช้คำถาม 3 พื้นฐานที่สมาชิกของทีมพัฒนา และส่งมอบซอฟต์แวร์ควรจะต้องตอบตามรูป

12370866_10153196298572371_7878208443234279727_o

วันที่ 1 ของ Sprint

Sprint-Backlog-Done

พอจบ Sprint Planning เริ่ม (09:00 น. – 12:00 น.) แล้วสมาชิกแต่ละคนของทีมพัฒนาและส่งมอบซอฟต์แวร์ก็เลือกหยิบงานที่ตนเองจะลงมือทำจากกระดานสีขาวเอาไปไว้ในช่อง Daily To-Do ที่คิดว่าจะทำได้และเสร็จได้ในวันที่ 1 แล้วก็ย้ายงานที่แปะไว้ในช่อง Daily To-Do มาไว้ที่ Doing และเมื่อเสร็จแล้วก็ย้ายงานนั้นไปไว้ที่ช่อง Done โดยในช่อง Done ผมได้ทำการแบ่งออกเป็นรายวันตั้งแต่วันที่ 1 – วันที่ 5 ของ Sprint และแบ่งในแต่ละแถวออกเป็น 3 ช่อง คือ

  • Task จาก Sprint Planning ที่ Done แปะงานที่ถูกระบุว่าจะต้องทำจาก Sprint Planning และเมื่อทำเสร็จแล้วให้นำมาแปะไว้ที่ช่องนี้ของวันที่ 1 พร้อมกับใช้ปากกาขีดเส้นทับเพื่อเป็นสัญลักษณ์
  • Task ที่เพิ่มระหว่างวัน แปะงานที่ถูกพบว่าจะต้องทำแต่ไม่ได้ถูกระบุไว้ตอน Sprint Planning หากทำงานนั้นเลยในวันที่ 1 และเสร็จ พร้อมกับใช้ปากกาขีดเส้นทับเพื่อเป็นสัญลักษณ์ หากยังไม่ได้ทำงานนั้นในวันที่ 1 ก็นำ Post-it งานนั้นไปแปะไว้ที่กระดานสีขาว
  • Task จาก Sprint Planning ที่ไม่ถูกทำ แปะงานที่ถูกระบุว่าจะต้องทำจาก Sprint Planning และพบว่าไม่ต้องทำงานนั้นๆ ให้นำมาแปะไว้ที่ช่องนี้ของวันที่ 1  ไม่ต้องขีดเส้นทับ

Daily Scrum วันที่ 2 ของ Sprint

สมาชิกของทีมพัฒนาและส่งมอบซอฟต์แวร์แต่ละคนก็ตอบ 3 คำถามนี้ พร้อมทั้งกระทำการดังนี้

  • คำถามที่ 1: เมื่อวานทำอะไรที่ช่วยให้ Sprint นี้ส่งมอบ Product ได้
    • สมาชิกแต่ละคนก็ชี้งานที่เสร็จที่แปะไว้ในช่อง Done ของวันที่ 1 ทั้ง 3 ช่อง
  • คำถามที่ 2: วันนี้จะทำอะไรที่ช่วยให้ Sprint นี้ส่งมอบ Product ได้
    • สมาชิกแต่ละคนเลือกงานที่จะทำในวันที่ 2 จากกระดานสีขาวมาไว้ที่ช่อง Daily To-Do
  • คำถามที่ 3: ติดปัญหาอะไรที่ต้องการความช่อยเหลือให้ Sprint นี้ส่งมอบ Product ได้
    • สมาชิกแต่ละคนเขียนอุปสรรคต่างๆ ที่เจอลง Post-it แล้วแปะไว้ในช่อง Impediment และหากมีการช่วยเหลือกันเพื่อแก้ไขอุปสรรคนั้นๆ แล้วก็เอาปากกาขีดทับไปเพื่อเป็นสัญลักษณ์ว่าถูกแก้ไขไปแล้ว

ดังนั้น Daily Scrum ของวันที่ 3 – วันที่ 5 ของ Sprint ก็กระทำการแบบเดียวกันกับของ Daily Scrum วันที่ 2

ประเมิน ประมาณ และปรับ

Daily Scrum นั้นเป็นพิธีกรรมที่มีประโยชน์มากๆ มิใช่เพียงมายืนๆ กันแล้วตอบ 3 คำถามแบบนกแก้วนกขุนทองเพราะคนที่อุปโลกน์ตัวเองขึ้นมาเป็น ScrumMaster หรือ Agile Coach ต้องให้ความสำคัญด้วย สำหรับผมเอง Daily Scrum เป็นพิธีกรรมที่ช่วยให้ทีมพัฒนาและส่งมอบซอฟต์แวร์ รวมทั้ง Product Owner ได้หยุดแป๊ปเพื่อ

  • ประเมิน แผนงานทั้งหมดของ Sprint นั้นว่าจะยังสามารถส่งมอบ PBI ที่รับใน Sprint นั้นได้ทั้งหมดหรือไม่ ถ้าไม่สามารถจะส่งมอบได้ครบทุก PBI ก็สื่อสารไปที่ Product Owner ทันที
  • ประมาณ ปริมาณงานที่สามารถทำให้เสร็จได้ภายในหนึ่งวันเพื่อให้ในแต่ละวันมีความคืบหน้า และทำให้แผนงานของ Sprint นั้นยังคงได้ตามที่ตกลงกับ Product Owner
  • ปรับ ระหว่างลงมือพัฒนาเพื่อส่งมอบในแต่ละวันจะมีเรื่องราวต่างๆ เกิดขึ้นนั้นกระทบกับแผนงานในแต่ละวันหรือไม่ และกระทบกับแผนงานในการส่งมอบใน Sprint นั้นๆ หรือไม่ หากกระทบก็คิดเพื่อปรับแผนงานเลยทันที

ดังนั้น Sprint Backlog ถือเป็นทรัพย์สินที่ทรงคุณค่า และทรงพลังมากในการดำเนินพิธีกรรม การบริหารจัดการโครงการ นะจ๊ะ

กระจกเงา

หน้าที่หนึ่งของโค้ชคือการเป็นกระจกสะท้อนเพื่อให้โค้ชชี่ได้เห็นว่าตนเองเป็นเช่นไร ยังสามารถพัฒนาตนได้อย่างไร และเมื่อเขาพร้อมเราก็ค่อยๆ พาเขาเดินทางจากจุดหนึ่งไปยังอีกจุดหนึ่งได้ ดังนั้นส่วนตัวผมเองอย่างที่บอกไปข้างต้นแล้วว่า การงานพื้นฐานอาชีพ ของผมส่วนหนึ่งคือบริหารจัดการโครงการ และบุคคลากร ดังนั้นผมค่อยข้างให้ความสำคัญกับการวางแผน และเมื่ออุปโลกน์ตนขึ้นเป็น Agile Coach แล้วนั้น การสร้างทีมพัฒนาและส่งมอบซอฟต์แวร์ที่มีคุณลักษณะที่เรียกว่า Self-Managing Team นั้น โดยผมอ้างอิงจากหนังสือชื่อ Leading Teams: Setting the Stage for Great Performances ที่บอกคุณลักษณะของ Self-Managing Team ไว้ 3 ข้อคือ

  1. ทีมสามารถวิเคราะห์ วางแผน และกำหนดงานเองได้ว่าจะต้องทำอะไรบ้าง
  2. ทีมสามารถ Monitoring (ยังหาคำไทยสวยๆ ไม่ได้) และบริหารจัดการ ความคืบหน้าของการทำงานเองได้
  3. ทีมสามารถ Monitoring (ยังหาคำไทยสวยๆ ไม่ได้) และบริหารจัดการ กระบวนการทำงานเองได้ว่าจะปรับปรุงให้ดีขึ้นอย่างไร

ดังนั้นใน Scrum เอง พิธีกรรม Sprint Planning ทั้ง Part I และ Part II เป็นเรื่องของการวางแผนงานที่จะเกิดขึ้นใน Sprint นั้นๆ ดังนั้น ผมจึงออกแบบ Sprint Backlog + Visualization เพื่อเป็นกระจกสะท้อนช่วยสะท้อนให้ทีมเห็นตนเองในเรื่องของการวางแผนงาน และเพื่อนำสิ่งที่เกิดขึ้นทั้งหมดที่แปะบน Sprint Backlog กลับมาใช้เป็นเครื่องมือในการทำเรื่องของการพัฒนาทั้งทักษะ และกระบวนการในส่วนของ การวางแผนและบริหารจัดการโครงการ ของทีม

พึงระวังสำหรับ Agile Coach และ ScrumMaster 

เมื่อเราออกแบบ Sprint Backlog (Scrum) หรือ Task Board (Agile) ให้ทีมที่เรากำลังฝึกฝนเขาขึ้นมานั้น เราจะต้องอธิบายให้ทีมเข้าใจด้วยว่า Sprint Backlog ที่เราออกแบบมาให้นั้นใช้งานอย่างไร และ Visualization มีประโยชน์กับเขาอย่างไร เพื่อส่งมอบการดูแล และปรับปรุงพัฒนา Sprint Backlog ต่อไปโดยทีมพัฒนา และส่งมอบซอฟต์แวร์เอง

ย้ำเตือนอีกรอบว่า สิ่งที่ผมพล่ามมานั้นมาจากประสบการณ์บวกกับสิ่งที่สังเกตเห็นจากการทำงานของทีมว่าต้อง เสริม เพิ่ม และเติม ทักษะอะไรบ้าง จึงออกแบบ Sprint Backlog ออกมาหน้าตาแบบข้างตน

ดังนั้น จงเสพอย่างมีสติ อย่าใจร้อน ทดลองใช้งาน โดยใช้จังหวะของผมเพื่อตามหาจังหวะของตนเองในการเป็นผู้นำทางจิตวิญญาณการพัฒนาซอฟต์แวร์แบบคล่องตัว

วันอังคารที่ 29 มีนาคม พ.ศ. 2559 เวลา 09:31 น.
สาทร กรุงเทพมหานคร

 

 

 

 

 

Categories: Sprint Backlog

Shu Ha Ri และ Kokoro » « เชิญชวนไปแตะขอบฟ้าที่งาน Agile Singapore 2016

2 Comments

  1. ถามหน่อยสิคระ
    1. ว่าบอรดสีขาว แบ่งช่องการเขียนยังไงบ้าง
    2. ทำไม to do list สำหรับวันนี้ (daily) ไม่เปนไปตาม PBI ที่ทาง product owner ได้กำหนด prioritize ว่าเรื่องไหนต้องทำก่อน-หลัง หรือ นี่คือการแตกงานย่อยจาก PBI ของแต่ละวันอีกที

    รบกวนอธิบายเพิ่มเติมให้หน่อยนะค่ะ

    • 1. บอร์ดสีขาวนั้นเป็นอีกรูปแบบของ PBI ที่ใช้ครับ โดยแบ่งช่องออกเป็น 2 ส่วนคือ Customer Visible และ Customer Invisible ในรายละเอียดจะเขียนเป็น Blog ให้อีกทีครับ

      2. To-Do List ใน Blog นี้ ผมออกแบบให้เป็น Task ต่างๆ ที่ทีมจะต้องทำในแต่ละวัน โดย PBI คือสิ่งที่อยู่บนบอร์ดสีขาวครับ

Leave a Reply

Your email address will not be published.

*

Copyright © 2017 สกรัม หนึ่ง สอง สาม ปลาฉลามขึ้นบก

Theme by Anders NorenUp ↑