แน่ใจ??? ว่าที่ใช้อยู่ คือ Scrum ทำงานเป็น Sprint จริง ๆ ตอนที่สอง
ความเดิมจากตอนที่ 1 สามารถเสพได้จาก บทความนี้
แน่ใจ??? ว่าที่ใช้อยู่ คือ Scrum ทำงานเป็น Sprint จริง ๆ ตอนที่หนึ่ง
ไปกันต่อกับตอนที่ 2 ของ แน่ใจ??? ว่าที่ใช้อยู่ คือ Scrum ทำงานเป็น Sprint จริง ๆ
จาก Sprint ของ SCRUM Development Process ปี ค.ศ. 1995 ที่ในหนึ่งรอบการทำงานที่มีระยะเวลาหนึ่งสัปดาห์ ถึง สี่สัปดาห์ และในหนึ่ง Sprint ก็มีกิจกรรมต่าง ๆ ที่เกี่ยวข้องกับการพัฒนา ตรวจสอบ ทดสอบ เพื่อส่งมอบผลลัพธ์จากซอฟต์แวร์
การเดินทางของเวลาจากปี ค.ศ. 1995 มาสู่เอกสาร Scrum Guide ฉบับ July 2016 และเป็นฉบับที่ 5 จากทั้งหมด 6 ฉบับ (ณ ปี พ.ศ. 2565 ที่พล่ามอยู่ตอนนี้) นิยามความหมายของ Sprint ได้มีการเปลี่ยนแปลงไปพอสมควร
The Sprint จาก Scrum Guide ฉบับ July 2016
พล่ามที่จะเกิดขึ้นนี้อยู่ในบริบทของการพัฒนา ตรวจสอบ ทดสอบ เพื่อส่งมอบผลลัพธ์จากซอฟต์แวร์ ที่ต้องเกริ่นก่อนเพราะว่า Scrum Guide ตั้งแต่ฉบับแรกจนถึงฉบับนี้ ไม่ได้จำเพาะเจาะจงถึงการพัฒนา ตรวจสอบ ทดสอบ เพื่อส่งมอบผลลัพธ์จากซอฟต์แวร์เลย
ขยายความ The Sprint ออกมาจากประสบการณ์
The heart of Scrum is a Sprint, a time-box of one month or less …
กรอบระยะเวลาของ Sprint หนึ่งเดือน หรือน้อยกว่า โดยเอาเป็นว่าจากที่ทำมาซ้ำ ๆ ซาก ๆ
- Sprint ระยะเวลา 5 วัน ถ้าสมาชิกในทีมพัฒนาไม่แข็งแกร่ง เก๋า ประสบการณ์สูง ทักษะสูง และองค์ความรู้ ทั้งส่วนของการพัฒนา ตรวจสอบ ทดสอบ เพื่อส่งมอบผลลัพธ์จากซอฟต์แวร์ และ Business Domain (ขอใช้คำภาษาอังกฤษ เพราะยังหาคำแปลที่ใกล้เคียงไม่ได้) ก็ อย่า อย่า อย่า หาทำที่กำหนดให้มีระยะเวลา 5 วัน
- Sprint ระยะเวลา 10 วัน เป็นระยะเวลาที่นิยมใช้กันเป็นอย่างมาก ถ้าสำหรับมือใหม่หัดขับขยับมาบนเส้นทางสาย Agile Software Development โดยใช้ Scrum Framrwork เป็นเครื่องมือ ก็เป็นการเริ่มต้นที่ดีกับระยะเวลานี้ เพราะไม่สั้นเกินไป ไม่ยาวจนเกินไป รวมทั้งยังเป็นระยะเวลาที่ฝั่งลูกค้า หรือเจ้าของความต้องการยังรอไม่นานจนเกินไป ส่วนตัวชอบระยะเวลานี้เพราะเวลานับจำนวน Sprint ในแต่ละเดือนที่ผมมักจะเริ่มต้นเดือน หรือไม่ก็กลางเดือน ก็จะง่ายในการนับเพราะลงตามเดือนได้พอดิบพอดี
- Sprint ระยะเวลา 15 วัน เป็นระยะเวลาที่เคยลองแล้ว ส่วนตัวรู้สึกว่านานไปนิด และนับ Sprint ไม่สะดวกเท่าไร เพราะจะคร่อมเดือนไปมา
- Sprint ระยะเวลา 20 วัน ส่วนตัวรู้สึกว่านานไปที่หายไปจากลูกค้า เจ้าของความต้องการ หรือผู้สนับสนุน ที่จะได้พบ เจอ สื่อสาร และสาธิต
ระยะเวลาที่ผมมักจะใช้เริ่มต้นในการนำพาคือ Sprint ละ 10 วัน แต่ก็จะแอบซ่อม 5 วันไว้ข้างใน เพื่อเตรียมความพร้อมไว้สำหรับขั้นต่อไปของการปรับเวลาให้สั้นลง เพื่อส่งมอบผลลัพธ์จากซอฟต์แวร์ได้เร็วขึ้น
The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, usable, and potentially releasable product increment is created.
เลือกระยะเวลาต่อ Sprint เท่ากับกับ 10 วันแล้วนั้น ภายในระยะเวลา 10 วันนั้นสมาชิกทุก ๆ คนใน Scrum Team ต้องร่วมด้วยช่วยกันพัฒนา ตรวจสอบ ทดสอบเพื่อส่งมอบผลลัพธ์จากซอฟต์แวร์
ป.ล. Scrum Team = 1 x ProductOwner + 1 x DevelopmentTeam (+ 1 x Scrum Master)
ผมจัดสรรเวลาใน Sprint ตาม Events ของ Scrum ที่มีลงไปจะได้ออกมาว่า
ผมกำหนด
- วันที่หนึ่งของ Sprint เป็นวันจันทร์
- วันที่สิบของ Sprint เป็นวันศุกร์
- แต่วันเริ่มต้นทำงาน 09:00 น. และจบการทำงานที่ 18:00 น.
ดังนั้น
- วันที่หนึ่งช่วงเช้า กรอบเวลา 3 ชั่วโมง 09:00 น. — 12:00 น. ดำเนินพิธีกรรม Sprint Planning และได้แผนการทำงานใน Sprint ออกมาที่เรียกขานว่า Sprint Backlog
- คำว่า “during” ที่อยู่ในความอธิบายของ The Sprint ผมกำหนด เริ่มตั้งแต่ วันที่หนึ่งช่วงบ่าย จน ถึงวันที่เก้าเวลา 18:00 น.
- วันที่หนึ่งช่วงบ่าย 13:00 น. — 18:00 น. ก็เริ่มต้นด้วย Daily Scrum โดยการตั้งเป้าหมายของกรอบระยะเวลาที่มีช่วงบ่ายว่าจะดำเนินการอะไรบ้าง
- วันที่สอง ถึงวันที่เก้า ผมกำหนดกรอบระยะเวลา 10 นาที และเวลา 09:00 น. — 09:10 น. สำหรับดำเนินพิธีกรรม Daily Scrum ที่ตรวจสอบ วิเคราะห์ กำหนดเป้าหมายรายวัน และแผนงานรายวัน ที่จะทำให้ไปถึงเป้าหมายของ Sprint (Sprint Goal) ตามแผนงานใน Sprint Backlog
- วันที่สอง ถึงวันที่เก้า ตั้งแต่เวลา 09:30 น. — 18:00 น. คือช่วงกรอบระยะเวลาที่ดำเนินการพัฒนา ตรวจสอบ ทดสอบ เพื่อส่งมอบผลลัพธ์จากซอฟต์แวร์
- สิ่งที่ต้องส่งมอบออกมาภายในระยะเวลาของ วันที่หนึ่งช่วงบ่าย จน ถึงวันที่เก้าเวลา 18:00 น. ในบริบทของการพัฒนา ตรวจสอบ ทดสอบ เพื่อส่งมอบผลลัพธ์จากซอฟต์แวร์ คือ ซอฟต์แวร์ที่ใช้งานได้ ผ่านการทดสอบ ตรวจรับ นำไปทดลองใช้งานกับกลุ่มตัวแทนผู้ใช้งาน เก็บรวบรวมความคิด ความเห็น คำติ คำชม คำแนะนำ ข้อเสนอแนะ ความต้องการที่อาจจะนำมา เพิ่ม ลด ปรับ แก้ไข ซอฟต์แวร์
- ผมตีความออกมาแบบนั้นว่าต้องเป็น ซอฟต์แวร์ที่ใช้งานได้ ผ่านการทดสอบ ตรวจรับ นำไปทดลองใช้งานกับกลุ่มตัวแทนผู้ใช้งาน เก็บรวบรวมความคิด ความเห็น คำติ คำชม คำแนะนำ ข้อเสนอแนะ ความต้องการที่อาจจะนำมา เพิ่ม ลด ปรับ แก้ไข ซอฟต์แวร์ จาก The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, usable, and potentially releasable product increment is created.
- วันที่สิบ ช่วงเช้า กรอบระยะเวลาหนึ่งชั่วโมง กำหนด 10:00 น. — 11:00 น. เป็นพิธีกรรม Sprint Review
- วันที่สิบ ช่วงบ่าย กรอบระยะเวลาสองชั่วโมง กำหนด 13:00 น. — 15:00 น. เป็นพิธีกรรม Sprint Retrospective
- วันที่สิบ ช่วงบ่าย กรอบระยะเวลาสามชั่วโมง กำหนดให้ Development Team ดำเนินการสร้าง หรือปรับปรุงเปลี่ยนแปลงเอกสารเพื่อบันทึกการเปลี่ยนแปลงต่าง ๆ ที่เกิดขึ้นใน ซอฟต์แวร์ รวมถึงเรื่องอื่น ๆ เช่น การปรับไข Production Sourcecode และ Test Sourcecode ให้ดีขึ้น เป็นต้น
หากเสพมาจนถึงบรรทัดนี้ของการพล่าม ก็ขะขอย้ำอีกรอบว่า เป็นการพล่ามออกมาจากประสบการณ์ของผมเองที่ผ่านการทำซ้ำ ๆ ซาก ๆ พลาดพลั้งมาก็มาก จนตกผลึกออกมาตามที่พล่าม
ขยายความ และกำหนดให้ชัดเจนก่อนจะเริ่ม
เมื่อใดที่ตัดสินใจ และตกลงปลงใจว่าจะมาเดินในเส้นทางสาย Agile Software Development โดยเลือกใช้ Scrum ทำงานเป็น Sprint เป็นเครื่องมือ หรือยานพาหนะ แล้วนั้น
การขยายความ และกำหนดความชัดเจนว่า The Sprint นั้นเป็นอย่างไร เหมือนที่ผมพล่ามไว้ด้านบน โดยเฉพาะอย่างยิ่งสื่อสารออกให้ชัด พร้อมตัวอย่างว่า สมาชิกทุก ๆ คนของ Scrum Team นั้นจะต้องร่วมด้วยช่วยกันส่งมอบ ซอฟต์แวร์ ที่มีคุณสมบัติตรงกับที่เป็นตัวหนา ระหว่าง วันที่หนึ่งตอนบ่าย จนถึงวันที่เก้าเวลา 18:00 น.
The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, usable, and potentially releasable product increment is created.
และที่สำคัญมาก ๆ ที่ต้องกำหนดออกมาให้ชัดคือ Done, usable, and potentially releaseable product increment หรือคำไทย ๆ ผมขอใช้คำว่า คุณสมบัติของคำว่า เสร็จพร้อมเปิดให้ใช้งานจริง ๆ
ความน่ารักของเอกสาร Scrum Guide ก็สมกับชื่อว่า Guide คือ ไม่ได้บอกว่าถ้าในบริบทของการพัฒนา ตรวจสอบ ทดสอบ เพื่อส่งมอบผลลัพธ์จากซอฟต์แวร์นั้น Done, usable, and potentially releaseable product increment หรือ คุณสมบัติของคำว่า เสร็จพร้อมเปิดให้ใช้งานจริง ๆ
ผมขอยกมาสองตัวอย่างที่ผมใช้งานจริง ๆ มา
ตัวอย่างที่หนึ่ง
สร้างขึ้นมา และใช้ตอนที่ฝึกทีม SCK SEAL Team One เมื่อสามปีที่แล้ว โดยเรียกขานว่า Definition of Done (ไว้จะพล่ามเรื่อง Definition of Done ในเร็ว ๆ นี้อีกที)
การใช้งาน หากจะย้าย Product Backlog Item ยกตัวอย่างเช่น “ลูกค้าสามารถสั่งซื้อสินค้า ชำระเงินด้วยบัตรเครดิตสำเร็จ” จากช่อง Doing ไปที่ Done จะต้องผ่าน
- Code must be stored on single repository
- Professional quality code แบบ Human Readable
- Unit tested (all type of code) ต้องผ่านการทดสอบ 100% คือส่วนหนึ่งของ Functional Regression Tests Suite บนเครื่อง Local Machine ของ สมาชิกทุก ๆ คนใน Development Team
- Automation acceptance tested (all stories) ต้องผ่านการทดสอบ 100% คือส่วนหนึ่งของ Functional Regression Tests Suite บนเครื่อง Local Machine ของสมาชิกทุก ๆ คนใน Development Team
- Running and passing on Continuous Integration Server คือ Functional Regression Tests Suite ใน Continuous Integration Pipeline
- No known defects ต้องแก้ไข Defects ที่พบให้หมด และผ่านการทดสอบทั้งหมดใน Functional Regression Tests Suite
โดยทั้ง 6 ข้อ สมาชิกทุก ๆ คนใน Development Team ต้องเป็นผู้ดำเนินการ และรับผิดชอบทำให้ครบทุกข้อ
ข้อสุดท้าย Accepted by Product Owner ดำเนินการโดยผู้ที่อุปโลกน์ขึ้นมาเป็น Product Owner ใน Scrum Team และเมื่อข้อนี้ผ่านการตรวจรับจาก Product Owner
Product Backlog Item “ลูกค้าสามารถสั่งซื้อสินค้า ชำระเงินด้วยบัตรเครดิตสำเร็จ” จะถูกย้ายจาก Doing ไปยัง Done โดย Product Owner ย้ำว่า Product Owner เท่านั้นที่มีสิทธิ์ย้าย
เฮ้ย!!! Scrum Guide บอกไว้แบบนั้นหรือ ทำไมถึงหาไม่เจอ … ไม่ได้บอก ข้อกำหนดนี้ผมกำหนดขึ้นมาเอง เพราะ ในบริบทนี้ Product Owner ซึ่ง ณ ตอนนั้นเป็น ผม เป็นคนที่นำ Product Backlog Item “ลูกค้าสามารถสั่งซื้อสินค้า ชำระเงินด้วยบัตรเครดิตสำเร็จ” ดังนั้น ผมต้องเป็นคนที่มีสิทธิ์ตัดสินใจว่าผ่าน คุณสมบัติของคำว่า เสร็จพร้อมเปิดให้ใช้งานจริง ๆ หรือไม่
อย่างที่ย้ำ ไว้ว่า ทำให้ชัดเจน พร้อมตัวอย่าง
ตัวอย่างที่สอง
สร้าวขึ้นมา ณ ตอนที่ทีม SCK SEAL Team One เข้าไปรับจ้างพัฒนา ตรวจสอบ ทดสอบ เพื่อส่งมอบผลลัพธ์จากซอฟต์แวร์กับลูกค้า และเราก็เสนอไปให้กับลุกค้าว่าทีม SCK SEAL Team One จะขอใช้ คุณสมบัติของคำว่า เสร็จพร้อมเปิดให้ใช้งานจริง ๆ ตามนี้ กับแต่ละ Product Backlog Item
ตอนที่ 2 ของ แน่ใจ??? ว่าที่ใช้อยู่ คือ Scrum ทำงานเป็น Sprint จริง ๆ ผมพล่าม และพาลงไปดูการขยายความ The Sprint ของ Scrum Guide ฉบับ July 2016 ที่ส่วนตัวผมคิดว่าเป็นฉบับที่ดีในบรรดาทั้ง 6 ฉบับที่มีมา ณ เวลานี้
ขยายความ กำหนด และยกตัวอย่างออกมา เพื่อให้ สมาชิกทุก ๆ คนใน Scrum Team คือ Product Owner และ Development Team รวมถึงคนอื่น ๆ ที่เกี่ยวข้องโดยตรง และโดยอ้อม กับ การพัฒนา ตรวจสอบ ทดสอบ เพื่อส่งมอบผลลัพธ์จากซอฟต์แวร์ในรูปแบบ Agile Software Development โดยใช้ Scrum ทำงานเป็น Sprint ได้เห็นว่าจะเจอกับอะไรบ้าง
ผู้ที่ต้องให้ความรู้ ต้องพาทำ ต้องนำพา และต้องทำให้ดูเป็นตัวอย่างได้ ว่า The Sprint ของ Scrum Framework นั้นเป็นอย่างไร เมื่อนำมาใช้ในการพัฒนา ตรวจสอบ ทดสอบ เพื่อส่งมอบผลลัพธ์จากซอฟต์แวร์นั้นก็ คือ … (จงเติมคำในช่องว่าง)
ไม่ว่าแง่มุมไหนที่ได้จาก Scrum123 จะเหมือนหรือแตกต่างกันอย่างไร สำคัญที่สุดคือการนำไปปรับใช้ และส่งต่อประสบการณ์นั้นจากเราสู่เพื่อนพ้องน้องพี่ เพราะ การแบ่งปัน ก็คือ ความใส่ใจ
วันพฤหัสบดีที่ 19 สิงหาคม พ.ศ. 2564 เวลา 15:54 น.
ประเทศไทย
