ATDD เป็นหนึ่งใน Agile practices ที่ทำให้ requirements และ test cases กลายเป็นสิ่งที่แยกกันไม่ออก กล่าวคือ ATDD สร้าง requirements จากข้อมูลที่ใช้ในการ test โดย test นั้นสามารถประมวลผลโดยคอมพิวเตอร์ได้
ลักษณะเด่นๆ ของ ATDD
- Common understanding เป็นการสร้างความเข้าใจที่ตรงกันให้กับทีมและลูกค้า โดยการใช้ตัวอย่างในการแสดง requirements
- Ubiquitous language ใช้ภาษาที่ให้ความหมายเดียวกันในการสื่อถึงสิ่งเดียวกัน ภาษาที่ใช้ในการเขียน test cases และ requirements เป็นภาษาเดียวกัน ทำให้ง่ายต่อการตีความและการทำความเข้าใจ
- Executable requirements/examples Living documentation เป็นการสร้าง requirements ที่ไม่ได้เป็นเพียงกระดาษแต่สามารถประมวลผลโดยคอมพิวเตอร์ได้
- มีชื่อเรียกอื่นๆ อีกมากมายเช่น story test driven development, behavior driven development, executable specifications, specification by example
ATDD cycle
ATDD มีการทำงานเป็นแบบวนซ้ำ ซึ่งประกอบด้วย 3 ขั้นตอน Discuss Develop และ Deliver
ATDD cycle
Discuss
เป็นขั้นตอนของการถกเถึยงถึงปัญหาหรือ Feature ที่นำมาจาก Product backlog เพื่อหา Solution โดยทีมทั้งหมดจะร่วมกันหาวิธีการแก้ปัญหาที่ดีที่สุด ขั้นตอนนี้ช่วยเพิ่มความเข้าใจและคำศัพท์ที่ใช้ร่วมกันเพื่อสื่อความหมายเดียวกัน ร่วมถึงมีการกำหนดตัวอย่างที่ชัดเจนสำหรับ Solution เพื่อใช้ในการสร้างเป็น test cases ซึ่งสามารถประมวลผลโดยคอมพิวเตอร์ได้ต่อไป
Develop
ตัวอย่างที่กำหนดไว้ในขั้นตอน Discuss จะเป็นตัวช่วยและแนะแนวทางในการพัฒนา Feature โดยในระหว่างพัฒนา Feature ก็สามารถสร้าง automated test cases สำหรับ Feature นั้นในเวลาเดียวกัน ซึ่งทั้งทีมต้องร่วมกันรับผิดชอบการ automation ร่วมกัน และในตอนท้ายสุดเมื่อทุก test cases ผ่าน เป็นอันเสร็จขั้นตอน
Deliver
ขึ้นตอนการส่งมอบงานคือการแสดงการทำงานของ Feature นั้นให้กับทุกๆ Stakeholders และทำการ execute test cases กับ Feature ที่เสร็จแล้วเป็นยืนยันว่า Feature นี้ทำงานตรงตามความต้องการของลูกค้าดังที่ได้ตกลงกันในช่วง Discuss หากได้รับคำแนะนำหรือข้อคิดเห็นก็ให้นำไปพิจารณาในช่วง Discuss ครั้งต่อไป
เราได้ลองใช้ ATDD และ Robot Framework มาตั้งแต่ปี 2011 ทำใ้ห้ Product ของเรามีคุณภาพมากยิ่งขึ้น กล่าวคือ ทีมได้ร่วมกันสร้าง Executable requirements จาก Robot Framework และตั้งเวลา run automatic testing ทุกๆ ชั่วโมง โดยส่งผลการ test ไปยังทีมเพื่อตรวจสอบหากมี test cases ที่ไม่ผ่าน ในตอนเริ่มต้นของ Feature ทุกๆ test cases จะไม่ผ่านแต่เมื่อการพัฒนาดำเนินไป จำนวน test cases ที่ไม่ผ่านจะลดลงและ test cases ที่ผ่านจะเพิ่มขึ้นเรื่อยๆ จนท้ายที่สุด test cases จะผ่านทั้งหมด ซึ่งเป็นการสิ่นสุดการพัฒนา
ATDD นอกจากจะทำให้ testing ครอบคลุม requirements ทั้งหมดแล้ว เรายังได้ประโยชน์จากการ automation testing โดยทำให้ Regression testing สามารถทำได้อย่างรวดเร็ว ทำให้ค้นพบข้อผิดพลาดของ Feature เร็วขึ้น ทำให้การแก้ไขทำได้ง่ายและรวดเร็วยิ่งขึ้น
ข้อมูลเพิ่มเติม
Bridging the Communication Gap book by Gojko Adzic: http://acceptancetesting.info
Robot Framework: http://robotframework.org
ATDD with Robot Framework article by Craig Larman and Bas Vodde: http://a-tdd.org
ATDD with Robot Framework demo: http://code.google.com/p/atdd-with-robot-framework
Web testing demo with Robot Framework: http://bit.ly/rf-web-test-demo
วันนี้เอาใจเป็นพิเศษสำหรับคนที่ชอบเล่นเกมส์ หลายๆคนเวลาเข้าคอร์ส Certified Scrum master คงทราบดีว่า ครูผู้สอนจะทำให้เราเห็นวิธีการทำงานแบบ Scrum โดยใช้เกมส์หลายๆ รูปแบบ วันนี้ได้มีโอกาสช่วย Alexey Krivitsky แปลเกมส์ที่เขาและเพื่อนๆ คิดขึ้น เพื่อให้ Scrum coach ใช้ในการจำลองการทำงานแบบ Scrum
เกมส์
ระยะเวลา, จำนวนผู้เล่น, อุปกรณ์
เกมส์นี้ได้รับการพิสูจน์แล้วว่าสามารถปรับให้ตรงกับความต้องการของวิทยากรและจำนวนที่แตกต่างของผู้อบรม
ด้านล่างนี้เป็นการอธิบายเกมส์แบบ”มาตรฐาน” แต่คุณควรจะดัดแปลงใช้เพื่อให้เหมาะสมกับความต้องการเฉพาะของคุณ.
ระยะเวลา: 100-120 นาที
-
100 นาที – เมื่อทีมใช้เทคนิคการประเมินอย่างรวดเร็ว
-
120 นาที – เมื่อทีมใช้ Planning poker หรือเครื่องมือการประเมินอื่นๆ
จำนวนผู้เล่น: 4-25 คน
-
ขนาดที่เหมาะที่สุดคือ 2-3 ทีม ทีมละ 4-6 คน (โดยรวม 8-18 คน)
-
สามารถเพิ่มผู้เล่นได้โดยเพิ่ม Scrum masters
ตัวต่อ LEGO: ตัวต่อ LEGO 1 กล่องสำหรับทีม 4-6 คน
- ผมใช้ “Basic Brick Set #6177”#
- 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 คือช่วยทีมในการบันทึกข้อตกลงเกี่ยวกับความต้องการ และการออกแบบเพื่อใช้ในการตรวจสอบการส่งมอบงาน
ข้อ เสียที่ผมเคยมีประสบการณ์คือ Tester จะคอยสังเกตุคุณภาพของ LEGO มากกว่าการสร้าง LEGO แต่เนื่องจากเป้าหมายของเกมคือการเรียนรู้โดยการทำจริง ผมจึงสนับสนุนให้ทุกคนได้มีส่วนร่วมในการสร้าง LEGO มากกว่าการเผ้าดู
ไ่ม่จำเป็นต้องมีผู้สังเกตการณ์
ผมคิดว่าเกมส์นี้จะเล่นอย่างสนุกเมื่อไม่มีผู้สังเกตุการณ์ ผู้สังเกตุการณ์อาจทำให้การเล่นสนุกน้อยลง มิฉะนั้นผมอยากที่จะได้ฟังเรื่องราวดีๆ เกี่ยวกับผู้สังเกตการณ์จากคุณ.
สิ่งที่ต้องสังเกตุ
พฤติกรรม
จากการสังเกตุของผมพฤติกรรมที่ผู้เล่นแสดงออกขณะเล่นเกมส์จะแสดงให้เห็นถึงพฤติกรรมหรือนิสัยในการทำงานจริง ภายใต้ความเครียดหรือความกดดันคนจะมีแนวโน้มที่แสดงนิสัยตามธรรมชาติของเขา
เกมนี้ถูกออกแบบมาอย่างเจตนาเพื่อจะให้เครียดระดับหนึ่ง ดังนั้นจึงอาจจะมีการเปิดเผยนิสัยที่ไม่ดีที่อาจเป็นอันตรายเมื่อนำ Scrum ไปใช้จริง จุดประสงค์ของผมในฐานะวิทยากรคือการชี้ให้ทีมเห็นถึงข้อเสียนั้นและให้ทีมเรียนรู้และระวังในสิ่งที่อาจจะเกิดขึ้น
วิธีการสื่อสาร
ระวัง :”ผู้จัดการ”,”เผด็จการ”,”เสียงดัง”และวิธีการที่คล้ายคลึง การสื่อสารเป็นสิ่งที่สำคัญที่สามารถนำมาสรุปในตอนท้ายและเป็นหัวข้อสำหรับการ coaching ส่วนตัวสำหรับแต่ละบุคคล
กระบวนการที่ไม่ถูกต้อง
คอยเฝ้าดูในกระบวนการที่ทีมอาจจะทำไม่ดีเท่าที่ควร ตัวอย่างเช่น ระหว่าการพูดคุยเกี่ยวกับความต้องการ ทีมอาจจะไม่ตั้งคำถามมากเท่าที่จำเป็น โดยส่วนใหญ่แล้วทีมจะมีปัญหานี้หรืออาจจะมีปัญหานี้ในโปรเจกต์จริง จึงควรนำมาวิเคราะห์สรุปให้ทีมเห็นได้ชัดภายหลังการเล่นเกมส์
ลำดับขั้นของเกมส์
การจำลองนี้แบ่งเป็น 3 ขั้นตอน: ก่อนการเล่น, ระหว่างเล่น, และ หลังการเล่น หรือช่วงสรุป
ก่อนการเล่น
-
จัดการทีมงาน
-
กำหนดกระบวนการ
-
Project chartering
-
สร้าง Backlog
-
ประเมินงาน
ระหว่างเล่น
-
วางแผน Sprint
-
ดำเนิน Sprint
-
ตรวจสอบ Sprint
หลังการเล่น
-
วิเคราะห์สรุป
ก่อนการเล่น: จัดการทีมงาน
ใช้เวลา 5 นาที
ไม่มีเหตุผลใดที่ขั้นตอนนี้ไม่สามารถเป็นส่วนหนึ่งของเกมส์ – กระบวนการเรียนรู้เพื่อแสดงให้เห็นถึง self-organization ในการปฏิบัติจริงปกติผมจะให้ทีมจัดการจับกลุ่มกันเอง 4-6 คนและจัดสรรพื้นที่การทำงานของกลุ่ม กิจกรรมนี้เป็นกิจกรรม warm-up ที่ดีเพราะว่าอาจต้องมีการย้ายโต๊ะและทำความสะอาด
ก่อนการเล่น: Project Chartering
ใช้เวลา 10 นาที. ขณะนี้คุณเล่นเกมมา 5 นาทีแล้ว.
เนื่องจากวิทยากรเล่นเป็น Product Owner ผมจำเป็นต้องแจ้งข้อความดังต่อไปนี้:
-
ทีมงานทั้งหมดจะสร้างผลิตภัณฑ์เพียงหนึ่งเดียว – พวกเขาจะไม่ได้แข่งขันกัน พวกเขาจะทำงานให้กับผู้ผลิตเดียวกัน
-
ผลิตภัณฑ์คือเมืองที่มีคุณลักษณะเฉพาะ
-
องค์ประกอบอาคารหลักเป็น LEGO แต่สามารถใช้อุปกรณ์อื่นๆ เสริมได้
-
ผมเป็นคนตัดสินใจหลักของผลิตภัณฑ์ – มันเป็นเมืองของผม
-
ผมจะมีส่วนร่วมในกระบวนการพัฒนาโดยจะตอบคำถามและให้ข้อเสนอแนะ
ทำกิจกรรมนี้แบบร่วมกันทำ แบบลงเรือเดียวกันจะเป็นวิธีที่ดี
เป้า หมายของผมคือต้องแน่ใจว่าทีมได้ฝึก Scrum โดยการสร้าง “ผลิตภัณฑ์” ด้วย LEGO คำถามที่ต้องคิดคือจะทำอย่างไรจึงจะทำสองหน้าที่ Product Owner (ผู้ซึ่งไม่ใช่เจ้าของกระบวนการ) และวิทยากร (ผู้ซึ่งต้องสนใจในการดำเนินการด้วย Scrum).
ผมพยายามทำหลายวิธี:
-
การเปลี่ยนหมวก – อธิบายกฏของ Scrum ให้ทีมฟังผมระบุอย่างชัดเจนว่าขณะนี้ผมเป็น Product Owner หรือวิทยากรเพื่อไม่ให้เกิดความสับสน
-
เล่นเป็น Product Owner อ่อนหัด – ให้ทีมขาย Scrum กับผม บ่อยครั้งที่ผมเล่นเป็น Product Owner ผู้ซึ่งไม่มีความรู้มากนักเกี่ยวกับ Agile หรือ Scrum เมื่อผมได้อธิบายเกี่ยวกับเมืองของผม ผมจะให้ทีมออกแบบกระบวนการที่เหมาะสม
ส่วนตัวผมชอบวิธีที่สองมากกว่า เนื่องจากจะช่วยขยายการเรียนรู้จากชั้นเรียนและให้ผู้อบรมฝึกปฏิบัติ Agile อย่างชัดเจน
ก่อนการเล่น: การสร้าง Backlog
ใช้เวลา 15 นาที ขณะนี้คุณได้เล่นเกมส์ 15 นาทีแล้ว.
เมื่อคุณได้ร่างกฏและตกลงเกี่ยวกับขั้นตอนการทำงาน ขั้นตอนต่อไปคือการบอกคุณสมบัติของเมือง ปกติผมจะบอกคุณสมบัติของเมืองโดยใช้ sticky notes ติดไว้ที่กระดาน
โดยปกติจะมีรายการดังต่อไปนี้:
-
ตึกหนึ่งชั้น (หลายๆ ตึก โดยใช้หนึ่ง sticky note ต่อหนึ่งตึก)
-
ตึกสองชั้น (หลายๆ ตึก)
-
ร้านค้า
-
โรงเรียน
-
โบสถ์
-
โรงพยาบาล
-
อนุบาล
-
ที่จอดรถประจำทาง
-
สี่แยก (สามารถใช้การวาดรูปได้)
-
สวนสาธารณะ (สามารถใช้การวาดรูปได้)
-
แม่น้ำ (สามารถใช้การวาดรูปได้)
-
สะพาน
รายการบางอย่างสามารถใช้การวาดรูปได้แล้วจึงใช้ LEGO วางข้างบน. คุณสามารถใช้ความคิดสร้างสรรค์เพื่อสร้างเมืองให้สนุกมากกว่าการสร้างเมืองแบบง่ายๆ เมื่อตอนที่พวกเราเริ่มเล่นเกมส์นี้กับทีมผู้ก่อตั้งเราสร้าง“silicon village” แน่นอนว่าเราต้องสร้างรายการบางอย่างเช่น ศูนย์การแสดงด้วย iPad (เพื่อใช้แสดงจอภาพ), บริเวณสำหรับทำงานร่วมกันในเมือง, ตึกที่มีระบบความปลอดภัยสูงสำหรับ web servers, และอนุสาวรีย์สำหรับวีรบุรุษ (อนุสาวรีย์แฟนซี). มันสนุกมากๆเลย!
ในขณะที่ทำ backlog นั้นผมก็อธิบายสิ่งที่ผมคิดในแต่ละรายการอย่างสั้นๆ ว่าอาจมีลักษณะเช่นไร และผมพยายามที่จะตอบคำถามต่างๆในภายหลัง
ก่อนการเล่น: การประเมินงาน
ใช้เวลาไม่เกิน 20 นาที ขณะนี้คุณอยู่ในเกมส์ 30 นาทีแล้ว.
การประเมินเป็นขั้นตอนที่ยากที่สุด
ผมอาจจะ:
-
ไม่มีการประเมิน (เช่นเดียวกับที่ agile guru แนะนำ)
-
ประเมิณอย่างรวดเร็วและง่าย
-
ใช้เวลานิดหน่อยเพื่อฝึก planning poker
RT @RonJeffries: “ทุกๆปีมีเทคนิคการประเมินใหม่ๆเกิดขึ้น. แนวคิด Agile ที่แท้จริงจะยกเลิกขั้นตอนการประเมิน.” – @agilemanager [YES!]
เนื่องจากระยะเวลาที่เรามีผมตัดสินใจเลือกใช้วิธีการประเมิณที่ง่ายที่สุดหรือ poker.
เทคนิคที่รวดเร็วที่สุด – swimlane sizing
ผมได้เรียนรู้วิธีการนี้มาจาก www.theagilepirate.net. โดยผมทำในแบบฉบับที่ง่ายที่สุด ดูจากภาพข้างล่าง จาก triangulation concept# และ swimlane sizing# เราสร้างคอลัมน์ตาม story sizes (1 2 3 5 8 13 ถ้าคุณชอบ Fibonacci – การใช้หลักวิทยาศาสตร์นิดหน่อยเป็นสิ่งที่ดีเสมอ), และให้ผู้อบรมย้าย stories ไปยังคอลัมน์ที่แสดงขนาด story เราสามารถทำเป็นกลุ่มหรือทำร่วมกันทุกคน
Figure 1: Swimlanes for group estimations
เราสามารถทำกิจกรรมนี้อย่างเงียบๆ ถ้ากลุ่มมีสมาชิกจำนวนมาก และมากเกินกับด้านหน้ากระดาน ผมจะขอให้แต่ละทีมที่จะส่งสมาชิกมาเป็นคู่ ทำต่อไปเรื่อยๆจนทุกคนได้มีโอกาสสัมผัสกับกระดาน เมื่อเสร็จแล้วให้กลุ่มคิดว่าการประเมินนี้ “ดีพอ” หรือยัง และพวกเขาต้องการจะเริ่มทำงานจริงแล้วหรือยัง
Planning poker กับหลายทีม
การใช้ planning poker# กับหลายๆทีมจำเป็นที่ต้องตกลงขนาดของ story กับทุกทีมก่อนการ ตกลงเรื่องขนาดทำได้ง่าย: เลือกรายการที่เล็กและง่ายแต่ไม่ง่ายเกินไปและให้ ขนาด “2” ปกติแล้วทุกคนจะตกลงที่จะใช้สองกับตึกชั้นเดียว อีกวิธีการหนึ่งคือการใช้ขนาดของ t-shirt# (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
ขณะนี้คุณอยู่ในเกมส์ 50 นาทีแล้ว.
(และยังไม่มีการสร้างอะไรเลย! มันพิสุจน์ให้เห็นหรือยังว่าการประเมินมันช่างเสียเวลาซะจริงๆ?)
เมื่อ stories ได้รับการประเมินแล้วคุณสามารถย้ายมันจาก Swimlanes Wall กลับไปที่ Backlog เนื่องจากเราต้องการทำให้ sprint planning เห็นได้อย่างชัดเจนเราจึงสร้าง Planning Wall แบบพิเศษเพื่อรวม plans ของแต่ละทีมในทุกๆ sprints ในเกมส์.
Figure 2: Multi-team Planning Wall, before planning sprint #1
Figure 3: Multi-team Planning Wall, inside sprint #2
เราจำกัดเวลา Sprint planning สามนาทีโดยให้ทีมนำ stories ใส่เข้าไปยังบล๊อก sprint ของตนเมื่อแต่ละทีมเสร็จแล้วให้ถามทีมว่ารู้สึกกดดันมากเพียงพอกับ plans เพื่อที่จะทดลองหรือยัง!
ระหว่างเล่น: Sprinting
จะใช้เวลา 7 นาที
เราชอบ sprints ด้วยความยาว 7 นาที เพราะเป็นเวลาที่เพียงพอที่จะสร้างหลายรายการโดยคนหลายคนทำงานร่วมกันและโดยไม่มีเวลาปรับเปลี่ยนรายการเหล่านั้นมากเกินไป
เพื่อให้แน่ใจว่านักเรียนจะมีความเครียดและความกดดันมากพอ เราจะแสดงเครื่องจับเวลาขนาดใหญ่ที่มองเห็นได้จากโน้ตบุ๊คหรือจอโปรเจคเตอร์่ :
Figure 4: ที่จับเวลาจาก www.online-stopwatch.com – เครื่องจับเวลามีหลายรูปแบบและสามารถใช้แบบไม่มีอินเตอร์เนตได้
ระหว่างเล่น: ทบทวน
จะใช้เวลา 5 นาที
เมื่อหมดเวลาผมจะต้องแน่ใจผู้อบรมหรือผู้เล่นหยุดการสร้างจริงๆ และเริ่มต้นสร้างความต้องการ :”เมืองของฉันเป็นอย่างไร” จากการสังเกตุพบว่าทีมเริ่มสร้างเมืองตาม stories ซึ่งแสดงสิ่งแวดล้อมของเมืองหลังจาก sprint ที่สอง โดยส่วนใหญ่ไม่มีใครคิดเกี่ยวกับการแสดงสิ่งแวดล้อมของเมืองหลังจาก sprint แรก ฟังดูคุ้นๆไหมครับ
ฉันมักจะได้คำติระหว่างวิเคราะห์สรุปว่าผมเล่นเป็น Product owner ที่ใจดีแบบไม่ เคยเห็นมาก่อน อย่างไรก็ตามโดยส่วนใหญ่แล้วไม่มีผลงานของทีมใดได้รับการยอมรับหลังจาก sprint แรก เพราะหลังจากที่ผมแสดงอาคารของผม ผม”ได้ตระหนักถึง”:
-
ผมชอบสมมาตร
-
“ทุกที่มีสีเดียวกัน”หมายถึง”สีทึบของอาคาร แต่แตกต่างกันสำหรับแต่ละอาคาร”
-
อาคารมีทั้งขนาดเล็กเกินไป, ขนาดใหญ่เกินไปหรือมีความหลากหลายมากเกินไป
-
หน้าต่างชั้นที่แตกต่างกันไม่เรียงตรงกัน
-
<หาเหตุผลของคุณเอง>
รายการที่ยังไม่เสร็จจะถูกนำกลับไปที่ Backlog การวางแผนการทำงานที่เหลือสามารถทำได้ แม้ว่าเราจะไม่ค่อยมีการปรับปรุงค่าการประเมิน
เมื่อ stories เป็นที่ยอมรับ, กราฟ Burndown จะได้รับการปรับปรุงโดย PO, ผู้ที่จะประกาศอย่างชัดเจนและดังว่า Release นี้จะต้องเสร็จภายในสาม sprints และตอนนี้ก็ดูเหมือนว่าเราจะไม่สามารถสำเร็จ stories ทั้งหมดได้
เราสามารถใช้เวลาบางส่วนใน retrospective meeting เพื่อหารือว่า “เราจะทำอย่างไรให้ดีขึ้นใน sprint ต่อไป”
ระหว่างเล่น: Release Cycle
sprint แรกส่วนใหญ่จะไม่ประสบความสำเร็จ แต่เราไม่ควรเสียเวลามากเกินไปกับการถกเถียงเกี่ยวกับความล้มเหลวของ sprint แรก เราควรกลับไปเริ่มที่ Sprint Planning
เราเรียนรู้ว่า การสร้าง 80% ของ Backlog ที่มีคุณภาพดังที่คาดการณ์ไว้ใช้เวลาเฉลี่ยสาม sprints ดังนั้นการเล่นแบบครบวงจรมักจะมีลักษณะเช่นนี้:
-
Sprint #1
-
วางแผน – 3 นาที
-
ดำเนินการ – 7 นาที
-
ตรวจสอบ – 5 นาที
-
-
Sprint #2
-
วางแผน – 3 นาที
-
ดำเนินการ – 7 นาที
-
ตรวจสอบ – 5 นาที
-
-
Sprint #3
-
วางแผน – 3 นาที
-
ดำเนินการ – 7 นาที
-
ตรวจสอบ – 5 นาที
-
รวม : 45 นาที
ตั้งแต่การเตรียมการเล่นเราใช้เวลาประมาณ 1 ชั่วโมง (เริ่มจากการเริ่มต้นไปจนถึงการประเมิน backlog ) sprints ใช้เวลา 45 นาที จะใช้เวลาประมาณ 15 นาที สำหรับการวิเคราห์ะสรุป โดยรวมแล้วเกมส์จะใช้เวลาทั้งหมด 120 นาที
เมื่อได้ฝึกปฏิบัติและได้รับความช่วยเหลือจากวิทยากรร่วมเป็น Scrum Master ก็สามารถทำได้เร็วขึ้นเล็กน้อย
ภายหลังการเล่น: วิเคราะห์สรุป
หลังจากทำการตรวจสอบ 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 สำหรับองค์กรขนาดใหญ่
ผมสามารถที่ใช้การจำลองด้วย Lego กับผู้เล่นถึง 100 คน โดยแบ่งเป็น 12 ทีม ซึ่งสร้าง 4 เมืองไปพร้อมๆกัน วิธีการนี้้ต้องใช้ตัวต่อ Lego เป็นจำนวนมากแต่ก็ถือได้ว่า เป็นวิธีการที่ดีเพื่อแสดงการใช้ Scrum ในระดับองค์กรขนาดใหญ่ การจำลอง ในระดับองค์กรขนาดใหญ่สมควรกล่าวถึงในบทความแยกต่างหากเพื่อครอบคลุมกฏและข้อกำหนดต่างๆ
คุณมีรูปแบบการจำลองที่แตกต่างออกไปไหมครับ เล่าให้เราฟังด้วย
เราอยากได้ยินเรื่องราวและการจำลองในแบบของคุณ
โปรดร่วมกับเราที่ www.lego4scrum.com และส่งอีเมลถึงเราบอกเล่าความคิดของ
คุณมาที่ info@lego4scrum.com
บทความฉบับเต็มภาคภาษาไทยจะสามารถ download ได้ที่ Scrum simulation with LEGOv2.0-Thai ถ้าพบข้อผิดพลาดหรือมีข้อสงสัยใดๆ ติดต่อเราได้ครับ
Agile manager คือใคร ตำแหน่งนี้ไม่มีอยู่ในตำราไหนทั้งนั้น ในที่นี่ Agile manager หมายถึงผู้ที่ผลักดันให้องค์กรเปลี่ยนวิธีการทำงานมาเป็นแบบ Agile และเป็นผู้จัดการทีม Agile ต่างๆที่มีอยู่ในองค์กรให้ทำงานอย่างมีประสิทธิภาพตามหลักการของ Agile วันนี้ขอพูดถึงข้อควรปฏิบัติสำหรับ Agile manager ซึ่งเป็นหัวข้อที่ Jurgen Appelo นำมาถกเถียงใน Open spaces ที่ ALE 2011 ที่ Berlin หลังจากที่พวกเราและผู้ร่วม Session คนอื่นๆ อย่างน้อย 30 คนได้ถกเถียงกัน Jurgen Appelo ได้สรุปไว้ดังต่อไปนี้
- เข้าร่วม Daily scrum meeting – ส่วนตัวแล้วคิดว่า Agile manager ไม่ต้องร่วมตลอดก็ได้ค่ะ แต่ควรหาโอกาสเข้าร่วมบางครั้ง
- เข้าร่วม Sprint demo และตั้งคำถามอย่างน้อยหนึ่งข้อเพื่อแสดงถึงความสนใจในงานของทีม
- ทานอาหารกลางวันร่วมกับทีมและ/หรือ Scrum master เป็นประจำเพื่อสอบถามถึงความคิดเห็นของทีมต่อการทำงาน
- จัดให้มีการพูดคุยอย่างอิสระกับทีมต่างๆ และภาคธุรกิจทุกหกสัปดาห์ เพื่อเป็นการแลกเปลี่ยนความคิดเห็นระหว่างทีมและกับภาคธุรกิจ
- จัดให้มี Workshop เกี่ยวกับเทคนิคการนำ Agile มาใช้และข้อควรปฏิบัิติ
- นำหลักการ Agile มาใช้กับการทำงานอื่น เช่นการใช้ Backlog หรือ Story
- ห้ามเปลี่ยนแปลง Backlog ที่ที่มได้วางแผนงานไว้แล้ว
- ทำตัวเองให้ว่างช่วงเช้าเพื่อจะได้ใช้เวลาเดินดูการทำงานของทีมและช่วยแก้ปัญหาหากทีมพบปัญหาในการทำงาน
- จัดให้มีและร่วม Standup meeting ทุกสัปดาห์กับ Product owners และ Business Analyst และภาคธุรกิจ
- เก็บข้อมูลการพูดคุยกับสมาชิกเพื่อเก็บประวัติ ปัญหาและข้อซักถามของแต่ละคนในทีมต่างๆ
- จัดให้มี Community เกี่ยวกับข้อควรปฏิบัติสำหรับการจัดการภายในองค์กร
- จัดให้มีการให้ Feedback แบบ 360 องศา จากทุกๆคนในทีม เพื่อนำข้อคิดเห็นมาปรับปรุงองค์กรและการทำงาน
- ลดการใช้ Email เพื่อสื่อสารและหันมาใช้การพูดคุยแบบเผชิญหน้า
- ให้ทีมมีส่วนร่วมในการ Recruiting เพื่อให้ได้คนที่ทีมคิดว่าทำงานร่วมกันได้
- ติดตามดูผลงาน (ในที่นี้หมายถึง Application ที่ทีมสร้างขึ้น) ของทีมเป็นประจำ
- ร่วมใน Retrospective meeting ของทีม
ยังมีข้อปฏิบัติอื่นๆ ที่ได้ถูกแนะนำระหว่าง session แต่ส่วนใหญ่จะคล้ายคลึงกับข้อแนะนำที่ได้ยกมาในที่นี้ หลักการใหญ่คือ Agile manager ต้องเข้าถึงทีม รับฟังความคิดเห็นของทีมทั้งทางตรงและทางอ้อม เพื่อนำความคิดเห็นเหล่านั้นมาปรับปรุงการทำงานของทีมและภายในองค์กร อีกทั้งยังต้องให้ความรู้กับองค์กรในการก้าวไปสู่การทำงานแบบ Agile ที่เหมาะสมและเข้ากับองค์กรของคุณ หวังว่าคงเป็นประโยชน์ต่อผู้ที่เป็น Agile manager ได้นำไปลองใช้เผื่อจะทำให้การผลักดันไปสู่องค์กรแบบ Agile อย่างประสบความสำเร็จนะคะ
Retrospective meeting
คือการให้ทีมมองกลับไปว่าระหว่าง Sprint มีอะไรที่ดีที่ทีมควรทำต่อไป หรือสิ่งไม่ดีที่ควรปรับปรุง ตัวอย่างเช่น
ข้อดีของ Sprint ที่ผ่านมา
- Story ที่เลือกมาใน Sprint นี้เสร็จตรงตามเวลา
- Scrum ตรงเวลาและไม่นานเกินไป
- มีการ Demo ให้ Tester ดู การทำงานของ Feature ใหม่ ก่อนที่ Tester จะทำการ test
ข้อเสียของ Sprint ที่ผ่านมา
- มีเวลาเตรียมตัว Sprint demos น้อยเกินไป
- Developer ไม่ได้ test feature ก่อนส่งให้ Tester ทำให้มี Defects หรือ Bugs เยอะ
ข้อควรปรับปรุง
- หยุด Develop และ Test หนึ่งวันก่อนวัน Sprint demos เพื่อให้ทุกคนในทีมทำการเตรียม Software และ Hardware สำหรับ Sprint demos หนึ่งวันเต็มๆ
- Developer ต้อง test อย่างน้อย Positive test cases ก่อนส่งให้ Tester
ความสำเร็จเป็นสิ่งที่ดีที่สุดในการสร้างทีม
ทีมจะมีความรู้ึสึกเป็นทีมมากขึ้นเมื่อได้ร่วมสร้างความสำเร็จร่วมกัน Retrospective meeting เป็นอีกหนทางหนึ่งในการสร้างความกลมเกลียวภายในทีม โดยการให้ทีมได้รับรู้ถึงความสำเร็จหรือข้อดีต่างๆ ที่ทีมได้ร่วมสร้างระหว่าง Sprint ทุกคนสามารถนำเสนอข้อดีต่างๆ โดยทีมต้องเห็นพ้องกับข้อดีร่วมกัน
เปิดใจเพื่อการปรับปรุงทีม Scrum
หัวใจของ Retrospective meeting คือการเปิดใจและร่วมปรับปรุงทีมไปด้วยกัน ทีม Scrumจะไม่มีการปรับปรุงให้ดีขึ้นถ้าทีมไม่เปิดใจบอกถึงข้อเสียต่างๆ ที่เกิดขึ้นภายในทีม ปัญหาต่างๆควรนำมาถกเทียงกันใน Retrospective meeting เพื่อร่วมกันแก้ปัญหา ไม่ใช่เพื่อที่จะกล่าวโทษหรือหาผู้ทำผิด ทุกคนในทีมสามารถนำข้อเสียที่ควรปรับปรุงมาถกเถียงได้ แต่บ่อยครั้งที่ไม่มีใครกล้าจึงเป็นหน้าที่ของ Scrum master ที่จะเป็นผู้นำใน Retrospective meeting โดยจะนำข้อเสียต่างๆ ที่ Scrum master เห็นระหว่าง Sprint มาถกเถียงกันในทีม และให้ทีมเสนอว่าควรปรับปรุงอย่างไร โดยทั้งทีมควรเห็นพ้องต้องกันในการปรับปรุงเพื่อให้ทุกคนในทีมร่วมปฏิบัติ Scrum master ต้องไม่กำหนดข้อปฏิบัติใดๆ ในการปรับปรุงแต่ Scrum master สามารถร่วมเสนอวิธีการเพื่อปรับปรุงและให้ทุกคนในทีมร่วมตัดสินใจว่าจะปฏิบัติตามข้อเสนอหรือไม่
จดบันทึกผลของ Retrospective meeting เสมอ
ข้อดี ข้อเสีย และข้อเสนอเพื่อปรับปรุงต่างๆ ควรมีการจดบันทึกไว้ และทุกๆครั้งที่มี Retrospective meeting ทีมควรเปิดดูผลของ Retrospective meeting ก่อนหน้านี้เพื่อตรวจสอบว่าทีมได้ปรับปรุงตามข้อเสนอจาก Retrospective meeting ครั้งก่อนหน้านี้หรือไม่ หากทีมมีข้อเสียซ้ำๆเดิม ทีมจะได้เห็นและตระหนักถึงสิ่งที่เป็นปัญหาและควรปรับปรุงให้จริงจังมากยิ่งขึ้น
Retrospective meeting มีความสำัคัญมากที่สุดรองจาก Sprint demos เลยทีเดียว เพราะเป็นการประชุมที่ให้โอกาสทีได้ปรับปรุง Scrum ให้ดีขึ้นดังนั้นเราควรแน่ใจว่า Retrospective meeting มีขึ้นประมาณ 30 นาที – 2 ชั่วโมง ตอนสิ้นสุด Sprint เสมอ
แบ่งปันประสบการณ์กับทีมอื่นๆ
ผลของ Retrospective meeting เป็นแหล่งสะสมประสบการณ์ความรู้ของแต่ละทีม ซึ่งแต่ละทีมมีประสบการณ์ที่แตกต่างดังนั้นการแลกเปลี่ยนประสบการณ์ต่างๆ จะช่วยพัฒนา Scrum ให้กับทีมอื่นๆภายในองค์กรได้เป็นอย่างดี
สิ้นสุด Sprint ด้วย Free time
มาถึงตอนนี้เราก็สิ้นสุด Sprint อย่างเป็นทางการตาม Scrum methodology ถ้าใครอยากลองทบทวนการใช้ Scrum ตั้งแต่เริ่มต้นก็ลองกลับไปอ่านที่ เริ่มโปรเจกต์ด้วย Scrum ตอนที่ 1 ก่อนที่จะเริ่ม Sprint ใหม่ อย่าลืมให้เวลากับทีมได้ทำอย่างอื่นสัก 0.5-2 วันดูนะคะ เพื่อให้สมองปลอดโปล่ง มีไอเดียใหม่ๆ ใน Sprint ถัีดไป
Post นี้เป็น Post สุดท้ายของ Scrum แล้วใ้้น Series ต่อไปจะเล่าเกี่ยวกับ Acceptance Test Driven Development (ATDD)
เมื่อสิ้นสุด Sprint ทีมจะนำเสนอผลการทำงานของ Sprint ให้กับ Product owner และผู้เกี่ยวข้องต่างๆ ทราบ การนำเสนอผลงานนี้เรียกว่า Sprint demos (demonstration) ประโยชน์ที่ได้รับโดยตรงของ Sprint demos คือ การได้แสดงความคืบหน้าของ Project และแสดงการทำงานของ Features ต่างๆ ให้กับผู้เกี่ยวข้องทราบ ซึ่งโดยปกติ Features ที่ได้รับการพัฒนาจะมีความถูกต้องตามความต้องการของ Product owner อยู่แล้วเพราะ Product owner มีส่วนร่วมใน Sprint โดยตลอด แต่ระหว่างการพัฒนาอาจมีรายละเอียดบางอย่างที่ขาดหายไป Product owner สามารถตรวจสอบในรายละเอียดระหว่าง Sprint demos และแจ้งให้ทีมทราบเพื่อนำไป Develop ใน Sprint ถัดไป
เตรียมตัวก่อน Sprint demos
Sprint demos เป็นเครื่องมือการ Marketing ของทีม ดังนั้นทีมจึงควรมีการวางแผนและซ้อมการ Demo ให้เป็นไปอย่างราบรื่น ไม่มีปัญหาทางเทคนิกต่างๆ ระหว่าง demo ปัญหาทางเทคนิคที่เคยพบระหว่าง Demo เช่น VM crash , browser cached ข้อมูลเก่า หรือ เครื่องที่ใช้ Demo ไม่มีโปรแกรมที่จำเป็นสำหรับการ Demo เป็นต้น ปัญหาเหล่านี้สามารถหลีกเลี่ยงได้ถ้าทีมทำการเตรียมเครื่องมือต่างๆก่อน Demo จากประสบการณ์พวกเราขอแนะนำให้ใช้เวลา 1 วันก่อน Sprint demo เพื่อตระเตรียม Software และ Hardware สำหรับการ demo รวมทั้งประชุมกันในทีมว่าใครจะรับผิดชอบ Demo ส่วนไหน แต่ละ Story ควรมีการออกแบบการ Demo ไว้ตั้งแต่ช่วง Sprint planning แล้วจึงไม่ควรเป็นปัญหาว่าจะ Demo อย่างไร เพียงแต่ควรที่จะซ้อม Demo ภายในทีมอย่างน้อยหนึ่งครั้งก่อน Demo จริง สุดท้ายอย่าลืมส่ง invitation ให้กับบุคคลที่เกี่ยวข้องกับ Project ทั้งหมดก่อน Sprint demo อย่างน้อยหนึ่งวันเพื่อให้มีผู้ฟังมากเท่าที่จะมากได้ แต่ Product owner ต้องร่วม Sprint demos เสมอ ถ้า Product owner ไม่สามารถร่วมได้ ควรย้ายวัน Sprint demo
ทำ Sprint demo ให้สนุกและเข้าใจง่าย
Sprint demo นับได้ว่าเป็นส่วนที่ตื่นเต้นที่สุดของ Scrum เพราะเป็นการแสดงผลงานต่อสาธารณะชน ถึงแม้ว่าผู้ร่วม Sprint demo ส่วนใหญ่จะมีีส่วนเกี่ยวข้องใน project ไม่ด้านใดก็ด้านหนึ่ง แต่ก็อาจไม่ทราบในรายละเอียดทุกส่วน ดังนั้น Sprint demo ควรทำให้ผู้ฟังเข้าใจใน Story และ Features ต่างๆ ในรายละเอียด โดยทีมควรนำเสนอในรูปแบบที่สนุกและเข้าใจง่าย ทำให้ผู้ฟังสามารถคิดตามและติดตามไปตลอด Sprint demo การนำเสนออาจเป็นในลักษณะบอกเล่าเรื่องราวหรือสมมุติเหตุการณ์ตาม Story และให้ทีมงานแสดงวิธีใช้ระบบเพื่อตอบสนองต่อเหตุการณ์ดังกล่าว และเปิดโอกาสให้ผู้ฟังได้ซักถามข้อสงสัยต่างๆระหว่าง Sprint demo เสมอ เพื่อให้ผู้ฟังเข้าใจอย่างแท้จริง
กระชับ Sprint demos
Sprint demos ไม่ควรจะยาวเกินหนึ่งชั่วโมง เพราะผู้ฟังจะรู้สึกเบื่อ ทีมควรนำเสนอในสิ่งสำคัญเช่น Business values และการทำงานหลักของ features ไม่ต้องลงรายละเอียดปลีกย่อยจนเกินไป รายละเอียดปลีกย่อยผู้สนใจสามารถตรวจสอบได้จาก Test cases ของ Story นั้นๆ
ระหว่าง Sprint demos จะมีการถกถึงปัญหาและข้อเสนอแนะต่างๆ เกี่ยวกับ Features ทีมควรทำการบันทึก feedback ต่างๆเหล่านั้นเพื่อปรับปรุงใน Sprint ถัดไป
ตอนแรกคิดว่า Post นี้จะเป็นตอนสุดท้ายสำหรับ Scrum แต่คงต้องต่อไปอีกหนึ่งตอนเพื่อ Retrospective meeting โดยเฉพาะ อย่าลืมติดตามอ่านนะคะ
เมื่อปีที่แล้วเพื่อนร่วมงานของเราได้มีโอกาสไปสัมนาที่ Software Development Conference (SDC) 2010 เขานำเทคนิคการพัฒนาคุณภาพ Source code ให้ดีึขึ้นด้วย Lottery meeting ลองมาดูกันนะคะว่ามันคืออะไร
Lottery meeting ให้หลักง่ายๆ ที่ว่าคนเราชอบวิจารณ์คนอื่น หาข้อเสียของคนอื่นแต่เมื่อหาข้อเสียเจอแล้วเราควรหาวิธีการเพื่อไม่ให้ข้อเีสียนั้นเกิดขึ้นอีก Lottery meeting ชื่อก็บอกอยู่แล้วต้องมีการจับฉลากแน่นอน กติกาก็มีอยู่ว่า ให้ทำฉลากชื่อ Developer ทุกคนแล้วให้ Developer หนึ่งคนจับชื่อขึ้นมาหนึ่งชื่อ Developer ที่ถูกเลือกสามารถที่จะเลือก Source code ของใครก็ได้มาหนึ่งโปรแกรม ถ้าเป็น java ก็เลือกมาสักหนึ่ง Class เสร็จแล้วให้ทุกคนร่วมกันวิจารณ์ Source code นั้นว่าเขียนถูกต้องหรือไม่ ส่วนใหญ่สิ่งที่จะถูกวิจารณ์คือ
- ความสมบูรณ์ของ Java doc
- การประกาศตัวแปร และ methods
- การ handle exception
- การ log
- ความซับซ้อนของ methods
- Source format
- Logic
จุดประสงค์หลักของ Lottery meeting คือเพื่อกำหนดแนวทางการเขียนโปรแกรมของทีมให้เป็นไปในทางเดียวกัน โดยให้ทุกคนร่วมกันกำหนดข้อปฏิบัติเพื่อหลีกเลี่ยงข้อเสียต่างๆ ใน Source code ที่เลือกขึ้นมาในแต่ละสัปดาห์ หรือทำตามข้อดีที่พบใน Source code นั้นๆ ตัวอย่างเช่น Source ที่เลือกมาสัปดาห์นี้มีการประกาศตัวแปรต่างๆ กระจายไปทั่ว Class ทำให้ยากต่อการอ่าน ดังนั้นทีมจึงตกลงว่า ตัวแปรต่างๆต้องอยู่ด้านบนของ Class เท่านั้น เป็นต้น จุดมุ่งหมายคือต้องการให้ Source code ง่ายต่อการอ่านและทำความเข้าใจ การที่ทุกคนมีส่วนร่วมในการกำหนดข้อปฏิบัติต่างๆ จะช่วยให้ทุกคนไม่รู้สึกถูกบังคับให้ใช้กฏ แต่ Developer จะทำตามเพราะเห็นถึงความสำคัญและเป็นข้อกำหนดที่ตนเองร่วมตกลงด้วย
Lottery meeting ยังเป็นแหล่ง share knowledge ให้กับ Developer อื่นๆ ได้รู้ถึง Logic หรือเทคนิคที่ Developer อื่นๆนำมาใช้ในส่วนงานอีกด้วย
ในช่วงท้ายของ Lottery meeting ทีมควรสรุปแนวทางปฏิบัติที่ได้ว่ามีอะไรบ้าง เพื่อให้ทุกคนในทีมเข้าใจตรงกันและนำไปปฏิบัติ ข้อกำหนดต่างๆ ในแต่ละสัปดาห์ควรเขียนรวมไว้ในที่ที่ Developer สามารถเห็นได้ง่าย เพื่อเป็นการเตือนความจำอีกทางหนึ่ง
เราควรจัด Lottery meeting อย่างสม่ำเสมอ สัปดาห์ละหนึ่งครั้ง ครั้งละหนึ่งชั่วโมง เพื่อให้ Developer ซึมซับกับข้อกำหนดต่างและเปลี่ยนแปลงพฤติกรรมการเขียนโปรแกรมไปทีละน้อย
เริ่มต้นวันแรกของ Sprint บางคนอาจจะงงไม่รู้ว่าจะเลือกงานไหนมาทำดี อยากแนะนำให้เลือก Task จาก Story ที่สำคัญมากที่สุดก่อน เพื่อให้ทีมได้ออกแบบหรือแก้ไขปัญหาที่สำคัญตั้งแต่เริ่มต้น ทั้งนี้เพื่อหลีกเลี่ยงปัญหาที่อาจเกิดในตอนท้าย Sprint ซึ่งอาจเป็นผลให้ไม่สามารถสำเร็จตาม Sprint goal ได้
เพิ่มความสนุกกับการทำงานด้วย Co developer
เราใช้หลักการเดียวกับ Pair programming คือ แต่ละงานจะมีผู้รับผิดชอบสองคนคือ Developer และ Co developerโดยทั้งสองจะร่วมกันระดมความคิดออกแบบและแก้ไขปัญหา และอาจรวมไปถึงร่วมกันเขียนโปรแกรมด้วย การมี Co developer ได้ประโยชน์หลายอย่างเช่น มีการแบ่งปันและเรียนรู้ประสบการณ์ระหว่าง developer และกระจายความรู้เกี่ยวกับงานนั้นไม่ให้ยึดติดกับคนๆ เดียว อีกทั้งยังเพิ่มคุณภาพของงานเพราะงานเกิดจากคนสองคนร่วมกันคิด และที่สำคัญคือทำงานสองคนสนุกกว่าทำงานคนเดียวแน่นอนค่ะ การหา Co developer ก็สามารถทำได้ง่ายๆ โดยถามระหว่าง Scrum ว่ามีใครสนใจทำงานนี้ด้วยกันไหม หรือเขียนไปที่ chat หากมีการใช้ Chat ภายในทีม
Update backlog ทุกวัน
Update backlog ทุกวัน
ทุกครั้งที่เริ่มต้นและสิ้นสุด Task เราควร update สถานะงานเสมอ เพื่อให้ทีมรู้ว่า Task นี้ได้มีผู้จับจองและเริ่มทำงานแล้ว หรือถ้างานเสร็จแล้ว Tester ก็สามารถตรวจสอบความถูกต้องและเปลี่ยนสถานะเป็น Verified เมื่อการตรวจสอบเสร็จสุด เราควร update สถานะของ Task ก่อน Scrum ทุกวัน เพราะระหว่าง Scrum ทีมจะเปิด Sprint backlog ดูสถานะหรือภาพรวมของ Sprint ดังนั้นการ update backlog จึงเป็นสิ่งสำคัญเพื่อให้มีข้อมูลที่ทันสมัยอยู่เสมอ
Scrum ที่เก่าเวลาเดิม
สถานที่และเวลาของ Scrum ได้กำหนดไว้ตั้งแต่ Sprint planning ดังนั้นสมาชิกทุกคนภายในทีมควรตั้ง Alarm เตือนสำหรับ Scrum ทุกวัน เพื่อให้ทุกคนไป Scrum พร้อมเพียงกัน ปกติเวลา Scrum จะเป็นเวลาระหว่างวันเช่น บ่ายโมงหรือใกล้เที่ยง แต่จริงๆแล้วไม่มีกฏกำหนดตายตัว ขอให้เป็นเพียงเวลาที่ทุกคนในทีมเห็นสมควร หากสมาชิกในทีมทำงานคนละ Timezone ก็ยิ่งต้องเลือกเวลาที่เป็นเวลาทำงานของทุก Timezone เช่น Scrum ตอน 3 pm ตามเวลาในไทยเพื่อให้ทีมไทยและทีมสวีเดน(10 am) Scrum ร่วมกันได้
Scrum มีจุดประสงค์เพื่อรายงานสถานะการทำงานของแต่ละคนในทุกๆวัน โดยมีคำถาม 3 ข้อที่ Scrum master จะต้องถามสมาชิกทุกคน
- จาก Scrum ครั้งที่แล้วจนถึงตอนนี้ ทำงานอะไรเสร็จบ้าง
- หลังจาก Scrum จนถึงวันพรุ่งนี้ จะทำงานอะไร
- มีปัญหาอะไรคิดว่าอาจทำให้ไม่สามารถทำงานดังกล่าวเสร็จ ต้องการความช่วยเหลือจากใครไหม
Scrum with online sprint backlog
ทีม Scrum ทุกวันและปกติจะใช้เวลาไม่นานประมาณ 15-20 นาที โดยทุกคนในทีมจะต้องยืนล้อมกันและตอบคำถามสามข้อดังกล่าว Scrum ไม่ใช่การรายงานสถานะเพียงอย่างเดียวแต่ยังเป็นที่แลกเปลี่ยนข้อมูลและให้การช่วยเหลือภายในทีมด้วย โดยใครที่มีคำถามหรือปัญหาที่ต้องการคำแนะนำจากสมาชิกคนอื่นภายในทีมก็สามารถนำขึ้นมาพูดได้ใน Scrum แต่ไม่ควรจะใช้เวลานานเกินไป ถ้าปัญหาดังกล่าวต้องการการถกในรายละเอียดควรจะทำหลังจากเสร็จสิ้น Scrum แล้วเพื่อไม่รบกวนเวลาของผู้ที่ไม่เกี่ยวข้อง
ในกรณีที่มีผู้ทำงานอยู่ในสถานที่อื่น เราก็สามารถใช้ Video conference software เป็นอุปกรณ์ช่วย ย้ำว่าควรจะเป็น Video ไม่ใช้แค่เสียงเพื่อให้ง่ายต่อการสื่อสารระหว่าง Scrum
ตอนต่อไปจะเป็นตอนสุดท้ายสำหรับ Scrum โดยจะพูดถึง Sprint demo และความสำคัญของ Retrospective meeting
มาอีกครั้งสำหรับการจัดลำดับหนังสือเกี่ยวกับ Agile แต่คราวนี้เป็นรายชื่อหนังสือที่ได้รับความนิยมในปี 2011 Jurgen Appelo จัดลำดับโดยวัดจาก average rating และจำนวน rating จาก Amazon.com และ Goodreads.com
ถ้ามีน้องนักศึกษาคนไหนสนใจอยากได้หนังสือฟรีจากรายชื่อหนังสือข้างบนนี้ ลอง Post มาที่นี่่ได้นะคะ ทางเราจะจัดเป็นของขวัญสำหรับปีใหม่นี้ จำนวนจำกัดนะคะ
เมื่อวานได้มีโอกาสนั่งคุยกับเพื่อนที่ทำงานที่ Ericsson Sweden สิ่งที่น่าสนใจอันนึงที่อยากแชร์ให้ทุกคนฟังคือ Innovation day
Innovation day เป็นวันที่บริษัทให้พนักงานทุกคนหยุดทำงานประจำของตัวเอง และให้เลือกทำอะไรก็ได้ที่ตนเองสนใจและอยากลองศึกษาแต่ไม่มีมีเวลาได้ทำในเวลาทำงานปกติ และเมื่อสิ้นสุดวันหัวหน้างานจะเข้ามาสอบถามถึงสิ่งที่เราได้ศึกษาและแนวคิดต่อยอดหรือแผนการนำไปใช้ในอนาคต จริงๆแล้วแนวคิดของ Innovation day ได้มีใช้กันในหลายบริษัทเช่น Google โดยบริษัทเน้นให้พนักงานมีความคิดสร้างสรรและนำความคิดนั้นมาพัฒนาเป็น Product มากมายที่เราใช้ๆ กัน
หลังจากที่ฟังแล้วก็ทำให้นึกถึงเพื่อนคนหนึ่งที่เคยถามว่า มีอะไรต้องทำบ้าง เมื่อสิ้นสุด Sprint โดยปกติทีมควรจะมี Sprint demo และ Retrospective meeting ก่อนที่จะมี Sprint planning เพื่อเริ่มต้น Sprint ถัดไป แต่มีสิ่งหนึ่งที่เราควรทำก่อนที่จะเริ่ม Sprint ใหม่คือ หยุด Scrum ในที่นี่หมายถึง ทีมควรจะได้พักอย่างน้อยครึ่งวันหลังจากสิ้นสุด Sprint เพื่อให้สมองได้ปลดปล่อย คิดเรื่องอื่นบ้าง การทำงานกับเรื่องเดียวเป็นระยะเวลาต่อเนื่องทำให้ไม่มีความคิดใหม่ๆ เกิดขึ้น สิ่งที่พวกเราทำตอนสิ้นสุด Sprint คือพวกเราจะทำในสิ่งที่เราอยากทำในเวลาครึ่งวันหรือบางทีก็เต็มวัน ซึ่งเหมือนกับ Innovation day คือให้อิสระกับทีมในการศึกษาอะไรใหม่ๆ ที่น่าสนใจ เช่น ลอง Set up Git repository หรือลองเขียน Android app เล่นๆสักอัน ถ้ามีหลายคนสนใจในสิ่งเดียวกันก็อาจทำเป็นทึมก็ได้ค่ะ ก็สนุกกันไปอีกแบบ ปัญหาส่วนใหญ่คือ บางคนไม่รู้จะทำอะไรดี อันนี้เป็นสัญญาณของการทำงานมากเกินไปจนไม่ได้มองสิ่งใหม่ๆ ที่เกิดขึ้นรอบตัว ลองใช้เวลานี้ในการอ่านข่าว Update เทคโนโลยีที่มีเกิดขึ้นใหม่ บางทีคุณอาจจะเจอสิ่งที่ชอบและสนใจอยากลองเรียนรู้มากขึ้นก็ได้ สิ่งที่ไม่ควรลืมหลังจาก Innovation day คือเราควร present สิ่งที่เราได้ศึกษาให้กับทั้งทีมทราบเพื่อเป็นการ Share ความรู้และอาจนำไปซึ่งการนำความรู้นั้นไปใช้ต่อยอดได้อีกด้วย
การที่ทีมได้พัก Scrum นี้เป็นสิ่งช่วยให้การเริ่มต้นใหม่ของ Sprint ถัดไปมีความสนุกและกระตือรือร้นมากขึ้น ถ้าจะให้เห็นภาพก็ลองนึกถึงนักวิ่งที่ต้องวิ่งตลอดเวลาไม่ได้พัก ทำให้เหนื่อยล้าและไม่รู้สึกสนุก แต่ถ้าได้ัพักสักนิดพอเริ่มวิ่งใหม่มันจะมีแรงขึ้นมาอีกเยอะค่ะ ลองเอาเทคนิคนี้ไปใ้ช้กันดูนะคะ
เมื่อสุดสัปดาห์ที่ผ่านมา แอบไปเห็นลายชื่อหนังสือเกี่ยวกับ Agile development ที่ Jurgen Appelo ทำไว้เมื่อปี 2008 เขาคัดเลือกโดยจำนวน Reviewer และ Average rating ใน Amazon จำนวน google hits และ Jolt award ดูจากปีที่ทำรายชื่อหนังสืออาจจะเก่าไปสักหน่อย แต่หนังสือส่วนใหญ่ยังเป็นที่แนะนำให้อ่านสำหรับผู้เิริ่มต้น Agile นะคะ
1: Robert C. Martin
Agile Software Development: Principles, Patterns and Practices
2: Martin Fowler
Refactoring: Improving the Design of Existing Code
3: Mike Cohn
Agile Estimating and Planning
4: Mike Cohn
User Stories Applied: For Agile Software Development
5: Andrew Hunt, David Thomas
The Pragmatic Programmer: From Journeyman to Master
6: Alistair Cockburn
Agile Software Development: The Cooperative Game (2nd Edition)
7: Craig Larman
Agile and Iterative Development: A Manager’s Guide
8: Kent Beck
Extreme Programming Explained: Embrace Change (2nd Edition)
9: Jim Highsmith
Agile Project Management: Creating Innovative Products
10: Paul Duvall, etc.
Continuous Integration: Improving Software Quality and Reducing Risk
11: Mary Poppendieck, Tom Poppendieck
Lean Software Development: An Agile Toolkit
12: Ken Schwaber
Agile Project Management with Scrum
13: Ken Schwaber, Mike Beedle
Agile Software Development with Scrum
14: Alistair Cockburn
Crystal Clear: A Human-Powered Methodology for Small Teams
15: Venkat Subramaniam, Andy Hunt
Practices of an Agile Developer: Working in the Real World
16: Kent Beck
Test Driven Development: By Example
17: Johanna Rothman
Manage It!: Your Guide to Modern, Pragmatic Project Management
18: James Shore, Shane Warden
The Art of Agile Development
19: Ron Jeffries, etc.
Extreme Programming Installed
20: Esther Derby, etc.
Agile Retrospectives: Making Good Teams Great
หนังสือภาษาไทยเกี่ยวกับ Agile ก็พอเห็นอยู่บ้างใน se-ed แต่ยังไม่มีโอกาสได้อ่านค่ะ เลยไม่รู้ว่าดีหรือเปล่า ถ้าใครเคยได้อ่านแล้ว แนะนำกันด้วยนะคะ
