หลากหลายทีม ครบวงจร และมุ่งเน้นที่ผลิตภัณฑ์การจำลอง Scrum ด้วยตัวต่อ Lego

สามารถดัดแปลงนำไปใช้สอน Agile framework อื่นๆที่ใช้่แนวการทำงานแบบทวนซ้ำ( Iteration based) .

บทความต้นฉบับตีพิมพ์เมื่อ กุมภาพันธ์ 2552 เขียนโดย Alexey Krivitsky

บทความฉบับปัจจุบันตีพิมพ์เม่ือ ตุลาคม 2554 info@lego4scrum.com

การเผยแพ่รเอกสารอยู่ภายใต้ลิขสิทธิ์ Creative Commons Attribution 3.0 Unported License

1

คำนำทำไมต้องเป็นการจำลองด้วยตัวต่อ LegoAcknowledgement รูปแบบการจำลองเวอร์ชั่นปัจจุบันลิขสิทธ์WEB COMMUNITY

เกมส์ระยะเวลา, จำนวนผู้เล่น, อุปกรณ์บทบาท

Product OwnerScrum MastersสมาชิกในทีมTesters – ไ่ม่จำเป็นต้องมีผู้สังเกตการณ์

สิ่งที่ต้องสังเกตุพฤติกรรมวิธีการสื่อสารกระบวนการที่ไม่ถูกต้อง

ลำดับขั้นของเกมส์ก่อนการเล่น: จัดการทีมงานก่อนการเล่น: Project Charteringก่อนการเล่น: การสร้าง Backlogก่อนการเล่น: การประเมินงาน

เทคนิคที่รวดเร็วที่สุด – swimlane sizingPlanning poker

ระหว่างเล่น: Sprint Planningระหว่างเล่น: Sprintingระหว่างเล่น: ทบทวนระหว่างเล่น: Release Cycleภายหลังการเล่น: วิเคราะห์สรุป

รูปแบบการเล่นการเพิ่มความผันผวน

Scrum คุณมีรูปแบบการจำลองที่แตกต่างออกไปไหมครับ เล่าให้เราฟังด้วยขอบคุณครับ!

2

Lego ตลอดระยะเวลาหลายปีที่ผ่านมาผมได้เข้าร่วมการฝึกอบรมเกี่ยวกับ Scrum มากมาย ทั้งหลักสูตรที่ได้รับการรับรองและที่ไม่ได้รับการรับรอง หลักสูตรเหล่านั้นล้วนมีการจำลองที่แตกต่างกัน แต่ผมก็คิดเสมอว่าน่าจะมีการจำลองที่ดีกว่า รายการข้างล่างนี้เป็นสิ่งที่ผมคิดว่าเกมส์สำหรับจำลอง Scrum อย่างน้อยควรจะมีคุณสมบัติดังต่อไปนี้ 1. BACKLOGS

มากกว่า แบบกำหนดรายละเอียดขั้นตอนให้ปฏิบัติตาม

เราต้องการที่จะเริ่มเกมส์ด้วย Backlogs แบบเปิด ซึ่งเป็นการเชื้อเชิญการทำงานร่วมกันระหว่างลูกค้าและทีมงาน วิทยากรสามารถเตรียม Backlogs แต่ Backlogs ไม่ควรเป็นแบบปิดหรือระบุรายละเอียดชัดเจนดังตัวอย่างเช่น “ทำขั้นตอนนี้แล้วต่อด้วยขั้นตอนนั้น” เพราะมันคล้ายกับการควบคุมและการออกคำสั่งให้ปฏิบัติตาม เราต้องการที่จะสอนและแสดงความสัมพันธ์ระหว่างลูกค้าและทีมในรูปแบบที่แตกต่าง2.

micromanagement ตอนย่อยๆ ดังนั้น ฺBacklogs หรือคำแนะนำในการเล่นไม่ควรที่จะเป็นลำดับขั้นตอนของงานแต่ควรเป็นการให้วิสัยทัศน์หรือภาพใหญ่ของผลิตภัฒฑ์ที่ทีมกำลังจะสร้าง 3.

เกมส์นี้สามารถเล่นได้กับการฝึกอบรมที่มีผู้อบรม 20 คนขึ้นไป ซึ่งจะเป็นผลให้มีการแบ่งผู้อบรมเป็นทีม นี่เป็นโอกาสดีที่ใช้สำหรับฝึกทักษะการทำงานร่วมกันระหว่างทีม การกำหนดให้ทีมทำงานร่วมกันจะต้องทำโดยเจตนาเพราะถ้าไม่มีกฏการเล่นที่

3

เฉพาะเจาะจงทีมจะแข่งขันกันโดยธรรมชาติ 4. Agile

ข้อมูลต่างๆที่วิทยากรกำหนดให้ทีมทำการรวบรวม จะต้องเป็นข้อมูลที่เป็นประโยชน์ต่อทีมอย่างชัดเจนเพื่อใช้วัดประโยชน์ของ Agile เพราะเกมส์จำเป็นจะต้องสอนผู้อบรมในการเป็นเจ้าของขั้นตอนการทำงานต่างๆ 5.

เกมส์จะต้องถูกออกแบบให้ผู้เล่นสามารถเล่นได้หลายๆครั้ง โดยแต่ละครั้งจะต้องมีการสรุปว่าได้เรียนรู้อะไรจากการเล่นและปรับปรุงในการเล่นครั้งต่อไป

Acknowledgement ในช่วงต้นปี 2552 Mykola Gurov ผู้ซึ่งช่วยให้ผมได้ตระหนักถึงความสำคัญของตัวต่อ LEGOs ว่าเหมือนเป็น “API”1 . ภายหลังในปีเดียวกันผมได้สร้างเกมส์รุ่นแรกช่ือว่า “LEGO เพื่อการจำลอง SCRUM แบบขยาย” หลังจากที่ได้ถกเถียงความคิดกับ William Wake, Jurgen De Smet, Yves Hanoulle และ Xavier Quesada Allue. หลังจากได้เผยแพร่ครั้งแรกที่ Scrum Alliance website ผมได้รับ Emails ชื่นชมมากมายสำหรับงานชิ้นนั้น ผมขอใช้โอกาสนี้ขอบคุณทุกคนที่ได้ติดต่อผมเพื่อแบ่งปันความคิดเห็นและประสบการณ์เมื่อใช้การจำลองนี้ Gerry Kirk, Tim Yevgrashyn, Steve Rogalsky, Andriy Yevtushenko, Geoff Watts, Laurent Godé, Radu Davidescu, Martine Devos, Jo Newcombe Cook, Jakob Frandsen Martin Muntzing, Ola Ellnestam, Dusan Kocurek, Danny (Danko) Kovatch, Gustavo Quiroz, Jukka Lindström, Eduardo Bregaida, Nathaniel Cadwell. ขอบคุณเป็นพิเศษสำหรับ Robin Dymond และ Sergey Dmitriev ที่ได้อนุญาติผมใช้เกมส์นี้ในคอร์ส Certified Scrum Master ของพวกเขา

หลังจากบทความฉบับแรกได้รับการตีพิมพ์ในปี 2552 มีวิทยากรจำนวนมากได้ทด1Not sure what “API” means? Check out http://en.wikipedia.org/wiki/Application_programming_interface 4

ลองเล่นเกมส์นี้ เป็นผลให้รูปแบบการจำลองในเวอร์ชั่นปัจจุบันได้รับการปรับปรุงจากการสังเกตและข้อคิดเห็นที่ได้รับจากผู้ทดลองเล่น

ผลงานชิ้นนี้อยู่ภายใต้ลิขสิทธิ์ Creative Commons Attribution 3.0 Unported License

This license lets others distribute, remix, tweak, and build upon your work, even commercially, as long as they credit you for the original creation. This is the most accommodating of licenses offered. Recommended for maximum dissemination and use of licensed materials.

WEB COMMUNITY เราตัดสินใจสร้างเว็บไซต์เพื่อเป็นแหล่งข้อมูลและเป็นสถานที่เพื่อทำงานร่วมกันของผู้ที่สนใจสอน Scrum ด้วยตัวต่อ LEGO www.lego4scrum.com - หนึ่งในโครงการที่กำลังดำเนินอยู่คือการแปลบทความนี้เป็นภาษาต่างๆของโลก คุณสามารถตรวจสอบสถานะล่าสุดและช่วยเราแปลบทความได้ที่เว๊บไซต์ เราชื่นชมในการร่วมแรงของคุณ

, , เกมส์นี้ได้รับการพิสูจน์แล้วว่าสามารถปรับให้ตรงกับความต้องการของวิทยากรและจำนวนที่แตกต่างของผู้อบรม ด้านล่างนี้เป็นการอธิบายเกมส์แบบ"มาตรฐาน" แต่คุณควรจะดัดแปลงใช้เพื่อให้เหมาะสมกับความต้องการเฉพาะของคุณ. ระยะเวลา: 100-120 นาที

● 100 นาที - เม่ือทีมใช้เทคนิคการประเมินอย่างรวดเร็ว ● 120 นาที - เม่ือทีมใช้ Planning poker หรือเครื่องมือการประเมินอื่นๆ

จำนวนผู้เล่น: 4-25 คน

● ขนาดที่เหมาะที่สุดคือ 2-3 ทีม ทีมละ 4-6 คน ( 8-18 คน)● สามารถเพิ่มผู้เล่นได้โดยเพิ่ม Scrum masters

5

ตัวต่อ LEGO: ตัวต่อ LEGO 1 กล่องสำหรับทีม 4-6 คน

● ผมใช้ “Basic Brick Set #6177”2 ● 4 กล่องสำหรับ 20 คน

เครื่องเขียน: แพคเกตมาตรฐานการฝึกอบรม

● สติ๊กเกอร์, กระดานที่มีกระดาษกราฟแบบพลิกได้, ปากกามากร์เกอร์● Planning poker cards (อาจจะทำเองก็ได้)

ห้อง: โต๊ะ 1 ตัวสำหรับทีม 4-6 คน

● พื้นที่ว่าง ( โต๊ะหรือบนพื้น) สำหรับผลิตภัณฑ์ที่ประกอบกันตอนท้าย

Product Owner วิทยากรเล่นเป็น Product owner โดยมีจุดประสงค์เพื่อแสดงพฤติกรรม ความต้องการ และความคาดหวังของ Product owner และพฤติกรรมของทีมที่ Product owner ชอบและไม่ชอบ

Scrum Masters เกมส์นี้สามารถเล่นได้โดยไม่ต้องมีผู้เล่นเป็น Scrum Masters บางครั้งผมจะเชิญวิทยากรร่วมมาเป็น Scrum Master หรืออาจจะให้ทีมเลือก Scrum Masters เองภายในทีม. การมี Scrum Master ที่มีทักษะในการอำนวยความสะดวกให้กับทีม และเน้น Process การทำงาน หรือการมีวิทยากรที่เล่นในบทบาทของภาคธุรกิจจะทำให้เกมส์เล่นเป็นธรรมชาติและเหมือนจริง

ผู้อบรมเป็นสมาชิกในทีม

Testers – คุณสามารถมี Tester ในทีมได้แต่ไม่บังคับ หน้าที่ของ Tester คือช่วยทีมในการบันทึกข้อตกลงเกี่ยวกับความต้องการและการออกแบบเพื่อใช้ในการตรวจสอบการส่ง

2 Visit the online LEGO store: http://shop.lego.com/en-US/LEGO-Basic-Bricks-Deluxe-6177 6

มอบงาน ข้อเสียที่ผมเคยมีประสบการณ์คือ Tester จะคอยสังเกตุคุณภาพของ LEGO มากกว่าการสร้าง LEGO แต่เนื่องจากเป้าหมายของเกมคือการเรียนรู้โดยการทำจริง ผมจึงสนับสนุนให้ทุกคนได้มีส่วนร่วมในการสร้าง LEGO มากกว่าการเผ้าดู

ผมคิดว่าเกมส์นี้จะเล่นอย่างสนุกเม่ือไม่มีผู้สังเกตุการณ์ ผู้สังเกตุการณ์อาจทำให้การเล่นสนุกน้อยลง มิฉะนั้นผมอยากที่จะได้ฟังเรื่องราวดีๆ เกี่ยวกับผู้สังเกตการณ์จากคุณ.

จากการสังเกตุของผมพฤติกรรมที่ผู้เล่นแสดงออกขณะเล่นเกมส์จะแสดงให้เห็นถึงพฤติกรรมหรือนิสัยในการทำงานจริง ภายใต้ความเครียดหรือความกดดันคนจะมีแนวโน้มที่แสดงนิสัยตามธรรมชาติของเขา เกมนี้ถูกออกแบบมาอย่างเจตนาเพื่อจะให้เครียดระดับหนึ่ง ดังนั้นจึงอาจจะมีการเปิดเผยนิสัยที่ไม่ดีที่อาจเป็นอันตรายเมื่อนำ Scrum ไปใช้จริง จุดประสงค์ของผมในฐานะวิทยากรคือการช้ีให้ทีมเห็นถึงข้อเสียนั้นและให้ทีมเรียนรู้และระวังในสิ่งที่อาจจะเกิดขึ้น

ระวัง :"ผู้จัดการ","เผด็จการ","เสียงดัง"และวิธีการที่คล้ายคลึง การสื่อสารเป็นสิ่งที่สำคัญที่สามารถนำมาสรุปในตอนท้ายและเป็นหัวข้อสำหรับการ coaching ส่วนตัวสำหรับแต่ละบุคคล

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

7

การจำลองนี้แบ่งเป็น 3 ขั้นตอน: ก่อนการเล่น, ระหว่างเล่น, หลังการเล่น ก่อนการเล่น

● จัดการทีมงาน● กำหนดกระบวนการ● Project chartering● สร้าง Backlog● ประเมินงาน

ระหว่างเล่น

● วางแผน Sprint ● ดำเนิน Sprint ● ตรวจสอบ Sprint

หลังการเล่น

● วิเคราะห์สรุป

: ใช้เวลา 5 นาที ไม่มีเหตุผลใดที่ขั้นตอนนี้ไม่สามารถเป็นส่วนหนึ่งของเกมส์ - กระบวนการเรียนรู้ เพื่อแสดงให้เห็นถึง self-organization ในการปฏิบัติจริงปกติผมจะให้ทีมจัดการจับกลุ่มกันเอง 4-6 คนและจัดสรรพื้นที่การทำงานของกลุ่ม กิจกรรมนี้เป็นกิจกรรม warm-up ที่ดีเพราะว่าอาจต้องมีการย้ายโต๊ะและทำความสะอาด

: Project Chartering ใช้เวลา 10 นาที. ขณะนี้คุณเล่นเกมมา 5 นาทีแล้ว. เนื่องจากวิทยากรเล่นเป็น Product Owner ผมจำเป็นต้องแจ้งข้อความดังต่อไปนี้:

1. ทีมงานทั้งหมดจะสร้างผลิตภัณฑ์เพียงหนึ่งเดียว - พวกเขาจะไม่ได้แข่งขันกันพวกเขาจะทำงานให้กับผู้ผลิตเดียวกัน

2. ผลิตภัณฑ์คือเมืองที่มีคุณลักษณะเฉพาะ3. องค์ประกอบอาคารหลักเป็น LEGO แต่สามารถใช้อุปกรณ์อื่นๆ เสริมได้4. ผมเป็นคนตัดสินใจหลักของผลิตภัณฑ์ - มันเป็นเมืองของผม

8

5. ผมจะมีส่วนร่วมในกระบวนการพัฒนาโดยจะตอบคำถามและให้ข้อเสนอแนะ ทำกิจกรรมนี้แบบร่วมกันทำ แบบลงเรือเดียวกันจะเป็นวิธีที่ดี เป้าหมายของผมคือต้องแน่ใจว่าทีมได้ฝึก Scrum โดยการสร้าง “ผลิตภัณฑ์” ด้วย LEGO คำถามที่ต้องคิดคือจะทำอย่างไรจึงจะทำสองหน้าที่ Product Owner (ผู้ซึ่งไม่ใช่เจ้าของกระบวนการ) และวิทยากร (ผู้ซึ่งต้องสนใจในการดำเนินการด้วย Scrum). ผมพยายามทำหลายวิธี:

1. การเปลี่ยนหมวก – อธิบายกฏของ Scrum ให้ทีมฟังผมระบุอย่างชัดเจนว่าขณะนี้ผมเป็น Product Owner หรือวิทยากรเพื่อไม่ให้เกิดความสับสน

2. เล่นเป็น Product Owner – ให้ทีมขาย Scrum บ่อยครั้งที่ผมเล่นเป็น Product Owner มีความรู้มากนักเกี่ยวกับ Agile หรือ Scrum เมื่อผมได้อธิบายเกี่ยวกับเมืองของผม ผมจะให้ทีมออกแบบกระบวนการที่เหมาะสม

ส่วนตัวผมชอบวิธีที่สองมากกว่าเนื่องจากจะช่วยขยายการเรียนรู้จากชั้นเรียนและให้ผู้อบรมฝึกปฏิบัติ Agile อย่างชัดเจน

: Backlog ใช้เวลา 15 นาที ขณะนี้คุณได้เล่นเกมส์ 15 นาทีแล้ว. เมื่อคุณได้ร่างกฏและตกลงเกี่ยวกับขั้นตอนการทำงาน ขั้นตอนต่อไปคือการบอกคุณสมบัติของเมือง ปกติผมจะบอกคุณสมบัติของเมืองโดยใช้ sticky notes ติดไว้ที่กระดาน โดยปกติจะมีรายการดังต่อไปนี้:

● ตึกหนึ่งชั้น (หลายๆ ตึก โดยใช้หนึ่ง sticky note )● ตึกสองชั้น (หลายๆ ตึก)● ร้านค้า● โรงเรียน● โบสถ์● โรงพยาบาล● อนุบาล● ที่จอดรถประจำทาง● สี่แยก ( รถใช้การวาดรูปได้)

9

● สวนสาธารณะ (สามารถใช้การวาดรูปได้)● แม่น้ำ (สามารถใช้การวาดรูปได้)● สะพาน

รายการบางอย่างสามารถใช้การวาดรูปได้แล้วจึงใช้ LEGO วางข้างบน.

คุณสามารถใช้ความคิดสร้างสรรค์เพื่อสร้างเมืองให้สนุกมากกว่าการสร้างเมืองแบบง่ายๆ เม่ือตอนที่พวกเราเริ่มเล่นเกมส์นี้กับทีมผู้ก่อตั้งเราสร้าง“silicon village”. แน่นอนว่าเราต้องสร้างรายการบางอย่างเช่น ศูนย์การแสดงด้วย iPad (เพื่อใช้แสดงจอภาพ), บริเวณสำหรับทำงานร่วมกันในเมือง, ตึกที่มีระบบความปลอดภัยสูงสำหรับ web servers, และอนุสาวรีย์สำหรับวีรบุรุษ (อนุสาวรีย์แฟนซี). มันสนุกมากๆเลย!

ในขณะที่ทำ backlog นั้นผมก็อธิบายสิ่งที่ผมคิดในแต่ละรายการอย่างสั้นๆ ว่าอาจมีลักษณะเช่นไร และผมพยายามที่จะตอบคำถามต่างๆในภายหลัง

: ใช้เวลาไม่เกิน 20 นาที ขณะนี้คุณอยู่ในเกมส์ 30 นาทีแล้ว. การประเมินเป็นขั้นตอนที่ยากที่สุด ผมอาจจะ:

1. ไม่มีการประเมิน (เช่นเดียวกับที่ agile guru )2. ประเมิณอย่างรวดเร็วและง่าย3. ใช้เวลานิดหน่อยเพื่อฝึก planning poker

RT @RonJeffries: " . Agile ." - @agilemanager [YES!]

เนื่องจากระยะเวลาที่เรามีผมตัดสินใจเลือกใช้วิธีการประเมิณที่ง่ายที่สุดหรือ poker.

– swimlane sizing ผมได้เรียนรู้วิธีการนี้มาจาก www.theagilepirate.net. ที่สุด ดูจากภาพข้างล่าง

10

จาก triangulation concept3 swimlane sizing4 story sizes (1 2 3 5 8 13 Fibonacci - เสมอ), และให้ผู้อบรมย้าย stories ไปยังคอลัมน์ที่แสดงขนาด story เราสามารถทำเป็นกลุ่มหรือทำร่วมกันทุกคน เราสามารถทำกิจกรรมนี้อย่างเงียบๆ

Figure 1: Swimlanes for group estimations

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

Planning poker การใช้ planning poker5 story

3 Triangulation and other concepts of Agile estimating and planning, by Mike Cohn http://www.mountaingoatsoftware.com/presentations/85-an-introduction-to-agile-estimating-and-planning 4 Swimlane Sizing – Complete & Fast Backlog Estimation http://theagilepirate.net/archives/109 5 Planning Poker is found by James Grening in 2002 and popularized by Mike Cohn: http://en.wikipedia.org/wiki/Planning_poker 11

การตกลงเรื่องขนาดทำได้ง่าย: เลือกรายการที่เล็กและง่ายแต่ไม่ง่ายเกินไปและให้ ขนาด “2” ปกติแล้วทุกคนจะตกลงที่จะใช้สองกับตึกช้ันเดียว อีกวิธีการหนึ่งคือการใช้ขนาดของ t-shirt6 (XS, S, M, L, XL) S-sized “2” poker. ผมอยากจะแบ่งปันเคล็ดลับช่วยการทำ planning poker กับหลายทีมให้สำเร็จ:

● สร้าง swimlanes wall (ดูจากรูปข้างบน)● ให้ทีมดึง stories ณทีละหนึ่งอัน● ให้ทีมใส่รายละเอียดของแต่ละ story เม่ือได้รายละเอียดชัดเจนจาก Product

Owner (เพราะทีมอื่นอาจเป็นผู้ทำ story นั้น).● สนับสนุนให้สมาชิกในทีมตั้งคำถามเพื่อไขข้อสงสัยต่างๆเกี่ยวกับ story เพื่อ

ช่วยในการกำหนดขนาด● เมื่อ story ถูกประเมินแล้ว เราจะย้าย story ไปไว้ที่กระดานเพื่อให้ทุกทีมได้

ใช้ประโยชน์กับข้อมูลใหม่ๆ● เมื่อทำการประเมินทุกรายการเรียบร้อยแล้ว ให้ทุกคนออกมาที่กระดานเพื่อ

ตรวจสอบและทำการเปลี่ยนแปลงเท่าที่จำเป็น ( การเปลี่ยนแปลงไม่ค่อยจำเป็น)

ถ้าทีมไม่มีความรู้เกี่ยวกับ planning poker เป็นการดีที่จะให้ทีมทดลองทำมันหนึ่งครั้งเพื่อให้คุณสังเกตว่าทีมสามารถใช้เทคนิคได้ถูกต้อง ปกติผมถามทีมให้เดา:

“ Guinness U.K?”

คำถามนี้ช่วยให้เราตั้งคำถามเก่ียวกับสถานที่และวันที่ซ้ือเบียร์ – เป็นคำถามที่ warm-up การประเมิณ story

เป็นที่น่าสนใจว่าทั้งเทคนิค swimlanes และ planning poker ประเมิน release planning แม่นยำในระดับเท่าที่จำเป็น ดังที่มันได้พิสูจน์แล้วโดย burn-down charts เป็นจำนวนร้อยๆ อัน

: Sprint Planning

6 T-shirt sizing http://blogs.msdn.com/b/oldnewthing/archive/2009/05/12/9605143.aspx 12

ขณะนี้คุณอยู่ในเกมส์ 50 นาทีแล้ว. ( ! เวลาซะจริงๆ?) เมื่อ stories ได้รับการประเมินแล้วคุณสามารถย้ายมันจาก Swimlanes Wall กลับไปที่ Backlog. เนื่องจากเราต้องการทำให้ sprint planning เห็นได้อย่างชัดเจนเราจึงสร้าง Planning Wall แบบพิเศษเพื่อรวม plans ของแต่ละทีมในทุกๆ sprints ในเกมส์.

Figure 2: Multi-team Planning Wall, before planning sprint #1

13

Figure 3: Multi-team Planning Wall, inside sprint #2

เราจำกัดเวลา Sprint planning สามนาทีโดยให้ทีมนำ stories ใส่เข้าไปยังบล๊อก sprint ของตน เมื่อแต่ละทีมเสร็จแล้วให้ถามทีมว่ารู้สึกกดดันมากเพียงพอกับ plans เพื่อที่จะทดลองหรือยัง!

: Sprinting จะใช้เวลา 7 นาที เราชอบ sprints ด้วยความยาว 7 นาทีเพราะเป็นเวลาที่เพียงพอที่จะสร้างหลายรายการโดยคนหลายคนทำงานร่วมกันและโดยไม่มีเวลาปรับเปลี่ยนรายการเหล่านั้นมากเกินไป เพื่อให้แน่ใจว่านักเรียนจะมีความเครียดและความกดดันมากพอเราจะแสดงเครื่องจับเวลาขนาดใหญ่ที่มองเห็นได้จากโน้ตบุ๊คหรือจอโปรเจคเตอร์่ :

14

Figure 4: ที่จับเวลาจาก www.online-stopwatch.com - เวลามีหลายรูปแบบและสามารถ

ใช้แบบไม่มีอินเตอร์เนตได้

: จะใช้เวลา 5 นาที เมื่อหมดเวลาผมจะต้องแน่ใจผู้อบรมหรือผู้เล่นหยุดการสร้างจริงๆ และเริ่มต้นสร้างความต้องการ :"เมืองของฉันเป็นอย่างไร" จากการสังเกตุพบว่าทีมเริ่มสร้างเมืองตาม stories ซ่ึงแสดงสิ่งแวดล้อมของเมือง หลังจาก sprint ที่สอง โดยส่วนใหญ่ไม่มีใครคิดเกี่ยวกับการแสดงสิ่งแวดล้อมของเมืองหลังจาก sprint แรก ฟังดูคุ้นๆไหมครับ ฉันมักจะได้คำติระหว่างวิเคราะห์สรุปว่าผมเล่นเป็น Product owner ที่ใจดีแบบไม่ เคยเห็นมาก่อน อย่างไรก็ตามโดยส่วนใหญ่แล้วไม่มีผลงานของทีมใดได้รับการยอมรับหลังจาก sprint แรก เพราะหลังจากที่ผมแสดงอาคารของผม ผม"ได้ตระหนักถึง":

● ผมชอบสมมาตร● " " " "● อาคารมีทั้งขนาดเล็กเกินไป, ขนาดใหญ่เกินไปหรือมีความหลากหลายมาก

เกินไป.● หน้าต่างช้ันที่แตกต่างกันไม่เรียงตรงกัน● < >

รายการที่ยังไม่เสร็จจะถูกนำกลับไปที่ Backlog การวางแผนการ ทำงานที่เหลือสามารถทำได้แม้ว่าเราจะไม่ค่อยมีการปรับปรุงค่าการประเมิน เมื่อ stories เป็นที่ยอมรับ, กราฟ Burndown จะได้รับการปรับปรุงโดย PO, ผู้ที่จะ

15

ประกาศอย่างชัดเจนและดังว่า Release นี้จะต้องเสร็จภายในสาม sprints และตอนนี้ก็ดูเหมือนว่าเราจะไม่สามารถสำเร็จ stories ทั้งหมดได้ เราสามารถใช้เวลาบางส่วนใน retrospective meeting เพื่อหารือว่า “เราจะทำอย่างไรให้ดีขึ้นใน sprint ต่อไป”

: Release Cycle sprint การถกเถียงเกี่ยวกับความล้มเหลวของ sprint แรก เราควรกลับไปเริ่มที่ Sprint Planning เราเรียนรู้ว่า การสร้าง 80% ของ Backlog ที่มีคุณภาพดังที่คาดการณ์ไว้ใช้เวลาเฉลี่ยสาม sprints ดังนั้นการเล่นแบบครบวงจรมักจะมีลักษณะเช่นนี้:

1. Sprint #1a. วางแผน – 3 นาทีb. ดำเนินการ – 7 นาทีc. ตรวจสอบ – 5 นาที

2. Sprint #2

a. วางแผน – 3 นาทีb. ดำเนินการ – 7 นาทีc. ตรวจสอบ – 5 นาที

3. Sprint #3

a. วางแผน – 3 นาทีb. ดำเนินการ – 7 นาทีc. ตรวจสอบ – 5 นาที

รวม : 45 นาที

ตั้งแต่การเตรียมการเล่นเราใช้เวลาประมาณ 1 ชั่วโมง (เริ่มจากการเริ่มต้นไปจนถึงการประเมิน backlog ) sprints ใช้เวลา 45 นาที จะใช้เวลาประมาณ 15 นาที สำหรับการวิเคราห์ะสรุป โดยรวมแล้วเกมส์จะใช้เวลาทั้งหมด 120 นาที เมื่อได้ฝึกปฏิบัติและได้รับความช่วยเหลือจากวิทยากรร่วมเป็น Scrum Master ก็สามารถทำได้เร็วขึ้นเล็กน้อย

: 16

หลังจากทำการตรวจสอบ sprint รอบสุดท้ายแล้ว ทีมควรที่จะพักผ่อนระยะสั้น เพื่อเป็นการสงบอารมณ์ก่อนที่จะเข้าสู่ช่วงวิเคราะห์สรุป (ผมบอกคุณหรือยังว่าเกมส์นี้ออกแบบมาให้ผู้เล่นและวิทยากรเหนื่อย) เมื่อทีมกลับมารวมกันเป็นวงกลม เราจะเริ่มถกเถียงกับผู้อบรมทั้งหมดโดยใช้คำถามแบบเปิดดังต่อไปนี้:

● ผู้อบรบสังเกตเห็นอะไรบ้าง● รู้สึกอย่างไรกับทีม Scrum ● การทำงานดัวย Iteration ระยะสั้นเป็นอย่างไร● ความแม่นยำของการประเมินงานเป็นอย่างไร ● ถ้าเรามีโอกาสเล่นเกมส์อีกครั้ง เราจะทำอะไรให้แตกต่างออกไป● หน้าที่ของ Product Owner คืออะไร● รู้สึกอย่างไรเมื่อสิ้นสุด Sprint 1 แล้วเกือบทุกรายการจำเป็นต้องปรับปรุงใหม่

อีกครั้ง● Scrum Masters ทำอะไร

●คุณจะเปลี่ยนกลยุทธ์อย่างไรถ้าคุณรู้ว่า Product owner ไม่ว่างในช่วง sprints

● การสื่อสารระหว่างทีมงานไปอย่างไร พวกเข้าขึ้นต่อกันหรือไม่ พวกเขาแก้ไขปัญหาอย่างไร

● ผู้อบรมได้เรียนรู้อะไรบ้าง

เพื่อนที่ดีของผม (Askhat Urazbaev and Nikita Filippov) ได้ออกแบบเกมส์ที่มีลักษณะคล้ายคลึงกัน แต่ได้มีการเพิ่มความผันผวนเข้าไปในเกมส์ โดยใช้วิธีการสุ่มจำนวนผู้เล่นในแต่ละทีมและความซับซ้อน การเพิ่มความผันผวนทำได้ง่ายโดยหลังจาก Sprint planning ได้เสร็จสิ้นลงและก่อนที่จะเริ่มต้น Sprint ใหม่ ทีมงานจะโยนลูกเต๋าเพื่ิอทวีคูณ Story point ที่ได้วางแผนไว้ หรือทำให้สมาชิกในทีมบางส่วน"ป่วย"ในขณะที่ทีมงานที่เหลือจะต้องดำเนิณการตาม Sprint plan. จุดประสงค์ของการเพิ่มความผันผวนคือการชี้ให้ทีมเห็นความสำคัญของการร่วมมือกันเพื่ิอสมดุลงานระหว่าง sprints เพราะสถานะการณ์อาจจะแตกต่างกับตอนที่วางแผนไว้

Scrum 17

ผมสามารถที่ใช้การจำลองด้วย Lego กับผู้เล่นถึง 100 คน โดยแบ่งเป็น 12 ทีม ซึ่งสร้าง 4 เมืองไปพร้อมๆกัน วิธีการนี้้ต้องใช้ตัวต่อ Lego เป็นจำนวนมากแต่ก็ถือได้ว่าเป็นวิธีการที่ดีเพื่อแสดงการใช้ Scrum ในระดับองค์กรขนาดใหญ่ การจำลอง ในระดับองค์กรขนาดใหญ่สมควรกล่าวถึงในบทความแยกต่างหากเพื่อครอบคลุมกฏและข้อกำหนดต่างๆ

เราอยากได้ยินเรื่องราวและการจำลองในแบบของคุณ โปรดร่วมกับเราที่ www.lego4scrum.com คุณมาที่ info@lego4scrum.com

18

!

ขอให้ทำโปรเจกต์อย่างสนุกนะครัับ! Alexey Krivitskywww.lego4scrum.com

19