ScrumMaster in Action (Day 2) – DISC Model and Scrum Pregame

จากที่พอเข้าใจเรื่อง Agile และ Scrum ไปบ้างแล้วในวันแรก หน้าที่ของ Scrum Master จะต้องทำงานร่วมกับคนทุกฝ่ายมากเป็นพิเศษ ต้องมีทั้งศาสตร์และศิลป มันย่อมเป็นเรื่องที่ค่อนข้างยากยิ่งเมื่อเราโตมาจากสายเทคนิคอล (ที่ขึ้นชื่อว่าคุยกับคนไม่รู้เรื่องอยู่แล้ว) ดังนั้น ในช่วงเช้าของการสัมนาวันที่สอง พี่หนุ่มจึงเชิญอาจารย์ภคพร สุขศิริ  หรือ อ.น้ำตาล อินโนเวท เพื่อสอนคอร์ส “อ่านคนให้รู้ใจ ด้วย DISC”

DISC Model เป็นหนึ่งในเทคนิคที่จะทำให้เรารู้จักตนเองและเข้าใจผู้อื่นได้ง่ายขึ้น

เทคนิคนี้คิดค้นโดยนักจิตวิทยาชื่อ Dr. William Moulton Marston ที่เขาได้แบ่งคนออกเป็น 4 ประเภทหลัก ซึ่ง อ. น้ำตาล มีแบบทดสอบให้เราทำ 30 ข้อ และเมื่อทำเสร็จแล้ว จะรวมคะแนนว่าเรามีประเภทไหนสูงที่สุด (โดยถ้ามีประเภทอื่นๆใกล้เคียงมาก ก็ให้คิดว่าเราเป็นคนประเภทนั้นผสมด้วย) และอาจารย์ก็ได้อธิบายถึงลักษณะในคนแต่ประเภทให้ฟังอย่างละเอียด ผมฟังไปฟังมาก็ค่อนข้างตรงกับประเภทที่ตนเองเป็นอยู่เลยทีเดียว

ซึ่งในแต่ละประเภท จะมีลักษณะ คือ

1. D – Dominance
   คนประเภทนี้จะมีลักษณะ Active ไฟแรง มีความกระตือรือร้น ตรงไปตรงมา ชอบการแข่งขัน ถ้าเป็นผู้นำประเภท D ก็จะเป็นพวก ผู้นำแบบสั่งการ (Commanding) เด็ดเดี่ยว (Resolute) และเป็นผู้บุกเบิก ทำสิ่งใหม่ๆ (Pioneering) เช่น สตีฟ จอบส์
2. I – Influence
   คนประเภทนี้จะมีลักษณะคุยเก่ง เป็นมิตร มองโลกในแง่ดี ชอบหว่านล้อม และก็เชื่อคนง่าย ถ้าเป็นผู้นำประเภท I ก็จะเป็นพวก สร้างพลังใจ สร้างแรงกระตุ้น (Energizing), เป็นผู้บุกเบิก ทำสิ่งใหม่ๆ (Pioneering) และเป็นมิตร เข้าถึงได้ง่าย (Affirming)
3. S – Steadiness
   คนประเภทนี้จะมีลักษณะสุขุมรอบคอบ ใจเย็น เป็นนักฟังนักคิด ใจดี มีความพยายามสูง (ที่ปรึกษาผู้นำทั้งหลายในโลกมักเป็นคนประเภทนี้) ถ้าเป็นผู้นำประเภท S ก็จะเป็นพวก ให้การสนับสนุน ไว้วางใจ ร่วมมือกันทำงาน (Inclusive), อ่อนน้อมถ่อมตน (Humble) และเป็นมิตร เข้าถึงได้ง่าย (Affirming) เช่น มหาตมา คานธี
4. C – Conscientiousness
   คนประเภทนี้จะมีลักษณะละเอียดรอบคอบ เน้นความถูกต้อง มีระบบระเบียบในชีวิต ใช้เหตุผลในการตัดสินใจ ถ้าเป็นผู้นำประเภท C ก็จะเป็นพวก เชี่ยวชาญในงานที่ทำ (Deliberate), อ่อนน้อมถ่อมตน (Humble) และเด็ดเดี่ยว (Resolute)

ดังนั้น ถ้าเราเข้าใจว่าตัวเราเป็นเป็นแบบไหน เราจะได้พัฒนาตนเองในด้านที่ด้อยได้อย่างถูกทาง  ซึ่งวิธีการที่จะพัฒนาคือ การทำตรงข้ามกันของด้านที่ตนเองเป็นอยู่ นั่นคือ

• คนเป็น D จะต้องพัฒนา S เพิ่ม
• คนเป็น I ต้องพัฒนา C เพิ่ม
• คนเป็น S ต้องพัฒนา D เพิ่ม
• คนเป็น C ต้องพัฒนา I เพิ่ม

คนหนึ่งคนสามารถเป็นได้หลายประเภทผสมกัน อย่างของผมได้ทั้ง I S C ซึ่งก็ค่อนข้างแม่นพอสมควร ดังนั้น ผมควรต้องพัฒนาความโหดแบบ D เสริมเข้าไป

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

กลับมาต่อกันเรื่องของ Scrum

พี่หนุ่มให้ใช้ Mind Map เพื่อย้อนรอยไป Recap วันแรก ว่าได้เรียนถึงเรื่องอะไรบ้าง (ซึ่งใครยังไม่ได้อ่านตอนแรกของผม กลับไปอ่านได้ที่ ScrumMaster in Action (Day 1) – Introduce Agile and Scrum) จะอธิบายถึงประวัติและที่มาของ Agile, Scrum เพื่อให้เห็นภาพรวมทั้งหมด

Mind Map คือ แผนผังความคิด เวลาเราคิดอะไรได้ ก็โยนไปกองๆมันไว้ก่อน แล้วค่อยจัดกลุ่มว่าอะไรคือก้อนเดียวกัน อะไรเชื่อมโยงกัน (หาคำอธิบายเป็นทางการใน Google ต่อเองนะ)

จากนั้น พี่หนุ่มพาย้อนเวลากลับไปเรื่องของ SCRUM Development Process (1995) ว่าสมัยนั้น ได้แบ่ง Scrum ออกเป็น 3 ช่วง คือ

1. Pregame – ช่วงของการวางแผน
   1. Planing
   2. System Architecture/High Level Design
2. Game – ช่วงของการทำผลิตภัณฑ์
   1. Sprints (Concurrent Engineering)
   2. Develop (Analysis, Design, Develop)
   3. Wrap
   4. Review
   5. Adjust
3. Postgame – ช่วงปล่อยผลิตภัณฑ์เพื่อใช้งาน
   1. Closure

(ภาพจาก http://www.jeffsutherland.org/oopsla/schwapub.pdf)

ถ้าเขียนออกมาสวยๆหน่อย ตามสไตล์พี่หนุ่ม จะเป็นแบบนี้

ที่เกริ่นมานี้ เพื่อใช้ปูทางไปสู่การอธิบายเชิงลึกในแต่ละขั้นตอนของ Scrum ในปัจจุบัน ผ่านการทำ Workshop จากโจทย์ที่ว่า “เว็บไซต์จองตั๋วเครื่องบิน”..

โดยเราจะเริ่มทำ Requirement จากการใช้เครื่องมือ Fish Bone Diagram แจกแจง Feature ที่ต้องมีในเว็บไซต์

“Fish Bone Diagram” หรือ “แผนผังก้างปลา” หรือภาษาทางการ “แผนผังสาเหตุและผล (Cause and Effect Diagram)” คือ แผนผังที่ใช้แสดงสาเหตุ (ตามซี่ก้างต่างๆ) ที่อาจทำให้เกิดปัญหา (หัวปลา) นั้น (หาคำอธิบายเป็นทางการใน Google ต่อเองนะ) ซึ่งเราเอาไปประยุกต์ใช้หลายๆแบบได้ และในที่นี้ เราเอามาประยุกต์ใช้กับการทำ Requirement

เมื่อได้ Feature มาทั้งหมดแล้ว เราจะแยกมันออกมาเป็น User Story เพื่อให้เห็นขั้นตอนที่ผู้ใช้ทำงานกับระบบ

“User Story” เป็นการอธิบาย Requirement ในรูปแบบ เรื่องราวของผู้ใช้  ซึ่งตามมาตรฐานจะมีการเขียนเป็นรูปประโยค เช่น “As a <role>, I want <goal/desire> so that <benefit>” (อ้างอิง wikipedia) เพื่อบอกว่า ใคร ทำอะไร แล้วจะได้อะไร (หาคำอธิบายเป็นทางการใน Google ต่อเองนะ), แต่ในที่นี้ เราไม่ได้ใช้ตามรูปประโยคนั้นนะครับ อย่าเพิ่งสับสน

(ภาพจาก https://www.slideshare.net/mikecohn/user-storiesforagilerequirementsndc2014)

อันนี้ลองแยก Feature และ User Story ออกมาให้ดูสัก 3 หัวข้อ เช่น

• Feature เลือกรูปแบบเที่ยว
  • User Story – ผู้ใช้ สามารถเลือกเที่ยวบินไปกลับได้
  • User Story – ผู้ใช้ สามารถเลือกเที่ยวบินแบบเที่ยวเดียวได้
• Feature การชำระเงิน
  • User Story – ผู้ใช้ สามารถชำระเงินผ่านบัตรเครดิต
  • User Story – ผู้ใช้ สามารถพิมพ์เอกสารชำระเงิน และไปชำระเงินที่เคาเตอร์ธนาคาร
  • User Story – ผู้ใช้ สามารถพิมพ์เอกสารชำระเงิน และไปชำระเงินที่เคาเตอร์ 7-Eleven
• Feature การเช็คอิน
  • User Story – ผู้ใช้ สามารถเช็คอินได้จากหน้าเว็บไซต์
  • User Story – ผู้ใช้ สามารถพิมพ์เอกสารการจอง เพื่อเช็คอินที่หน้าเคาเตอร์ที่สนามบิน

แต่ด้วยความที่เราต้องส่งมอบงานเป็นรอบ (Sprint) และจะต้องทำงานให้เห็นได้ด้วย ดังนั้น เราจะเลือกหยิบ Feature ที่สามารถประกอบเป็นการทำงานหลักๆ ขึ้นมาให้ได้ก่อน

แล้วงานหลักที่ว่ามันคืออะไรล่ะ?!

ถ้าย้อนกลับไปบทบาทของคนเป็น PO (Product Owner) ที่ผมเขียนไว้ในวันแรก เขาจะต้องจัดลำดับ Product Backlog เข้า Sprint โดยเรียงตาม Bussiness Value หรือพิจารณาร่วมกับ KPI ของบริษัทว่าทำแล้วตอบโจทย์ตัวไหนของธุรกิจไดบ้าง (ถ้า PO ทำไม่เป็น คนที่เป็น Scrum Master จะต้องพาเขาทำ)

ดังนั้น ถ้าจากโจทย์ คือ “เว็บไซต์จองตั๋วเครื่องบิน” และสมมติว่าผลการสำรวจการตลาดมีคนนิยมเดินทางไป-กลับ, ชอบชำระเงินด้วยบัตรเครดิต, และเช็คอินที่สนามบิน… Flow แรกที่เราจะทำออกมาให้ใช้งานได้เป็น Minimal Viable Product (MVP) คือ

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

จากนั้น เอา User Story ใน Feature ที่เลือก มาทำเป็น Product Backlog Item (PBI) โดยอาจจะแตกย่อยให้ละเอียดขึ้นอีกนิด จนได้เป็นกลุ่มของงานที่จะทำ หรือเรียกว่า Product Backlog (PB)  เช่น

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

เมื่อรู้แล้วว่า PBI ที่จะเกิดขึ้น มีอะไรบ้าง คราวนี้มาถึงการเรียงลำดับความสำคัญของงาน ซึ่งจะเป็นหน้าที่ของ PO ที่จะเข้ามาทำ

โดย PO อาจจะแตกย่อยเฉพาะงานที่สำคัญก่อน ส่วนงานยังไม่สำคัญยังไม่ต้องลงรายละเอียดมาก เอาไว้ไปย่อยในตอนที่จะหยิบให้ทีมทำ (สังเกตจากรูปที่พี่หนุ่มวาด จะมีงานเหนือเส้นสีแดง คืองานที่จะทำใน Sprint นี้ และมันแบ่งความละเอียดของของงานไว้เป็น 3 ระดับ ตามลำดับที่ทำก่อนหลัง)

จากนั้น ทีมจะหยิบ PBI เหล่านั้น เข้ามาทำงานใน Sprint โดยจะเรียกกลุ่ม PBI นั้นว่า Sprint Backlog และชิ้นงานในนั้นเรียกว่า Sprint Backlog Item

(พูดถึงเรื่อง Backlog พอดีไปเจอจากเว็บฝรั่งมา เข้าท่าดีครับ เลยขอเสริมไปนะ, ภาพจาก https://www.scrumalliance.org/community/articles/2014/november/csm-workshop-key-takeaways)

(เปรียบเทียบความต่างของ Product Backlog และ Sprint Backlog, ภาพจาก http://sharepointrun.com/scrum-managment-in-vso-part-i/)

เมื่อได้ Sprint Backlog แล้ว ทีมจะจัดการแปลงมันให้ออกมาเป็นชิ้นงาน และในขั้นตอนนี้ ทีมจะทำสิ่งหนึ่งที่เรียกว่า Product Backlog Refinement ที่เป็นการวางแผนการทำงานให้เป็นไปตามที่วางไว้สม่ำเสมอ และ/หรือ กับวางแผนที่จะทำใน Sprint ถัดๆ ไปด้วย

จากการกระทำข้างต้น สิ่งที่เราจะได้คือ

1. ทีมจะได้ Test Case (ก็แตก Case ได้ตาม User Story นั่นหละครับ) – นี่ไง! เป็นจุดเริ่มต้นของการทำ Test-driven development (TDD)
2. ทีมจะได้ชิ้นงาน (PBI) ที่ถูกเรียงลำดับมาให้ทำเรียบร้อย ไม่ต้องคิดเองเออเองว่าจะทำอะไรก่อนหลัง
3. ทีมจะได้โฟกัสทำงานเฉพาะ PBI ที่ถูกเลือกมาทำ (Sprint Backlog) เท่านั้น ไม่ต้องวอกแวก
4. ทีม, PO จะเห็นภาพของสิ่งที่จะส่งมอบในขั้นตอน Sprint Review ว่าระบบจะทำงานได้ตาม Flow นี้นะ ซึ่งใช้กำหนดเป็น Definition of Done (DoD) ร่วมกันได้เลย

ส่วน Feature และ Flow อื่นๆ ที่เรายังไม่ได้หยิบมาทำใน Sprint ทาง PO ให้ทำตามขั้นตอนข้างต้น จนได้ออกมาเป็น PBI ไปรวมไว้ใน Product Backlog เพื่อเอาไปใช้ทำใน Sprint ต่อๆไป

จบของวันที่ 2 ไว้ประมาณนี้ครับ