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 ไว้ประมาณนี้ครับ

โชคดีที่พี่หนุ่ม จาก สยามชำนาญกิจ เปิดคอร์ส “3 Days Workshop ScrumMaster in Actions with Prathan D.” ให้กับทางทีม KBTG ของธนาคารกสิกรไทย และมีเก้าอี้เพิ่มให้นิดหน่อย ก็เลยใคร่อยากไปรู้บทบาทที่แท้จริง และไปเพื่มความรู้เรื่อง Agile, Scrum ประดับความรู้เดิมอันน้อยนิดด้วย

(รูปภาพจาก Facebook – Prathan Dansakulcharoenkit)

วันแรกที่ได้เรียน คือเรื่อง คุณค่า 4 ประการและหลักปฏิบัติ 12 ประการของการพัฒนาซอฟต์แวร์แบบแอไจล์  (The 4 Values and 12 Principles of the Agile Manifesto) พี่หนุ่มเล่าถึงที่มาของเหตุการณ์ที่มีคน 17 คน แถลงการณอุดมการณ์แห่งแอจไจล์ 4 ข้อ จากนั้นอธิบายทีละข้อว่า ถ้าจะทำเหล่านี้ได้ ก็มีหลักการให้ปฏิบัติ 12 ประการ อาจจะทำไม่ครบก็ได้ แต่อยู่ที่เราจะหยิบนำข้อไหนไปประยุกต์ใช้กับทีมและองค์กรให้เกิดผลแบบแอจไจล์

(รูปจาก http://www.scrum123.com/diary/why-we-must-adopt-agile/)

(รูปจาก http://www.scrum123.com/diary/why-we-must-adopt-agile/)

เมื่อมาถึงจุดนี้ เกิดถามคำถามหนึ่งที่ทุกองค์กรต้องกลับไปคุยกันว่า..

องค์กรมีความชัดเจนขนาดไหนที่จะใช้ Agile

และที่ทุกคนในงานบอกปัญหาของตัวเอง (Pain Point) ก็มักจะเหมือนๆกัน คือ

ปัญหาจากการแปรรูป (Transitions) ของเดิมที่มีอยู่ เพื่อไปใช้ Agile โดยที่คนภายในและภายนอกสามารถยอมรับได้

(ไม่ได้ใช้คำว่า เปลี่ยน หรือ Change เนื่องจากท่านเหล่านั้นไม่มีใครยก Agile ไปทำแทนของเดิมเลย)

เกร็ดเพิ่มเติมจาก พี่หนุ่ม

• ไม่มีเครื่องมือใดๆ มาแทนทักษะของคนได้
• คุณค่า ของ Agile 4 ข้อ และหลักปฏิบัติ 12 ประการ ไม่ได้บอกว่า “ทำอย่างไร” (How) แต่บอกว่า ทำแล้ว “จะได้อะไร” (Value)
• ใน Core Value ข้อ 2 ใช้คำว่า Documentation ไม่ได้หมายถึงเอกสาร แต่หมายถึง สิ่งที่ทำให้เป็นประจักษ์ ซึ่งจะใช้ รูปภาพ, Workflow, Use Case, Mind Map อื่นๆ ได้หมด
• หลักปฏิบัติข้อ 9-11 เป็นเรื่อง Development ที่เกิดขึ้นได้ยาก แต่ถ้ามี 4 ข้อเสริมเข้าไปด้วย จะทำให้เกิดขึ้นได้ นั่นคือ
  • Coding Standard
  • Version Control + Commit Code บ่อยๆ
  • Comprehensive Testing (หมายถึง Dev Team ก็ต้องทำ Unit Test ด้วยนะ)
  • Build Automation
• ถ้าจะทำ Core Values ทั้ง 4 ข้อ ต้อง
  • Build Skill – ให้ความสามารถและความเข้าใจใกล้เคียงกันทั้งทีม
  • ปรับจังหวะการทำงานของทีมให้ลงตัวทุกคน และเข้ากับ Process
  • เอา User ให้อยู่ใกล้กับทีม (พี่หนุ่มแนะนำให้นั่งห้องเดียวกัน)
  • บริการจัดการคิวงานให้ดี

(รูปภาพจาก Facebook – Prathan Dansakulcharoenkit)

แล้วจะใช้ วิธีการทำงาน (Methodology) ใดล่ะ ที่สอดคล้องกับแอจไจล์..

ในปี 1986 มีลุงชาวญี่ปุ่นสองคนชื่อ Hirotaka Takeuchi และ Ikujiro Nonaka ได้นำเสนอคำว่า “Scrum” ในบทความชื่อ “The New New Product Development Game” ซึ่งเขาบอกว่ามันเป็นรูปแบบของการพัฒนาผลิตภัณฑ์แบบใหม่ (Product Development) ที่สามารถเพิ่มประสิทธิภาพในการผลิตและมีความยืดหยุ่นด้วย

ลุงทั้งสองยกตัวอย่างวิธีการพัฒนาผลิตภัณท์ (The Development Process) จากบริษัทในญี่ปุ่นและอเมริกา ซึ่งแยกออกได้เป็น 3 ประเภท

(รูปภาพจาก https://hbr.org/1986/01/the-new-new-product-development-game)

บริษัทที่ใช้ Type A ตัวอย่างเช่นองค์การ NASA ที่เป็นสายการผลิตแบบต่างคนต่างทำ โดยที่ไม่ได้รู้ว่าแต่ละส่วนใครทำอะไร (Liner)

บริษัทที่ใช้ Type B เช่น Fuji-Xerox ที่มีการทำงานร่วมกันเฉพาะในส่วนที่เกี่ยวข้องกัน

และสุดท้าย บริษัทที่ใช้ Type C เช่น Honda และ Canon คือทำงานร่วมกันในหลายๆขั้นตอน

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

1. Built-in instability
2. Self-organizing project teams
3. Overlapping development phases
4. “Multilearning”
5. Subtle control
6. Organizational transfer of learning

ซึ่งลุงแนะนำว่า เราควรทำงานแบบที่ Honda ทำ เหมือนกับการเล่นรักบี้ ที่คนในทีมหลักๆ จะอยู่ตั้งแต่ต้นจนจบเกมส์ ทำหลายหน้าที่ร่วมกัน จนส่งลูกรักบี้ไปสู่จุดหมายได้

ต่อมา Ken Schwaber ได้ศึกษาหลักการของลุงชาวญี่ปุ่นสองคน และในปี 1995 เขาร่วมกับ Jeff Sutherland ได้เผยแพร่เอกสารชุดหนึ่งชื่อ SCRUM Development Process เพื่ออธิบาย วิธีการทำงานแบบสกรัม (Scrum methodology) โดยเล่าตั้งแต่รูปแบบของ Waterfall, Spiral และ  Iterative จนทำให้เกิดการพัฒนาเป็น Scrum ขึ้นมา (เป็นเอกสารลำดับแรก ที่พี่หนุ่มให้อ่านก่อนเข้าเรียนคอร์สนี้)

(รูปจาก http://www.jeffsutherland.org/oopsla/schwapub.pdf)

จากนั้น ได้มีเอกสาร The Scrum Guide เผยแพร่จากสองท่านนี้ออกมาเรื่อยๆ ตั้งแต่ 2011, 2013 จนเป็นเวอร์ชั่นล่าสุดคือ The Scrum Guide (July 2016) (เป็นเอกสารลำดับที่สองที่ควรอ่าน – Changes)

ที่ต้องบอกเล่าประวัติศาสตร์กันเป็นวรรคเป็นเวร เพราะ “Scrum Master” ควรจะต้องเป็น “Master of Scrum” คือ “ต้องรู้จักสกรัมเป็นอย่างดี” และอธิบายให้คนอื่นเข้าใจได้

แล้ว สกรัม คืออะไรล่ะ ในส่วนนี้ผมจับความจากพี่หนุ่มไม่ทัน แต่ขอแปลมาจากเอกสาร The Scrum Guide ที่ให้นิยามไว้ว่า เป็น “รูปแบบการทำงานที่ช่วยให้ทีมจัดการกับปัญหาที่ซับซ้อน โดยที่ยังส่งมอบงานได้อย่างมีประสิทธิภาพ สร้างสรรค์ และเกิดประโยชน์สูงสุด ” (Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.)

(ภาพจำลองของ Scrum ในปี 1995)

และก็ต่อด้วยประโยคแบบค่อนข้าง Abstract เล็กๆ คือ

• Scrum is Lightweight
• Simple to understand
• but Difficult to be master…

(ตัดฉากไปที่ความเงียบ และมีนกบินผ่านสามตัว)

ด้วยรูปแบบของ Scrum Methodology นี้เอง จึงทำให้มีผู้หยิบไปประยุกต์เพื่อให้ได้ Agile 4 ข้อ และเป็นไปตามหลักปฏิบัติ 12 ประการ

ถ้าสังเกตดีๆ จากภาพ Scrum Methodology, ช่วง Planing และ Closure ได้ยกตัวอย่างว่าใช้ Waterfall นะครับ (หรือจะใช้วิธีการใดก็ได้) ซึ่งค่อนข้างขัดแย้งกับความรู้หลายคนที่มักมอง Waterfall เป็นปีศาจทำโปรเจ็คล่ม เลยหันมาหาเทพเจ้า Scrum

ขอย้อนกลับไปอธิบาย Waterfall อีกครั้งว่า เราใช้มันครบหรือเปล่า

ซึ่งจริงๆ แล้ว Waterfall มันใช้งานได้ และมันก็ถูกใช้ทำงานมาตลอดในหลายอุตสาหกรรม จนมีบุคคลท่านหนึ่งชื่อ Dr. Winston Walker Royce (หรือ Dr. Royce) แกได้เจอปัญหาว่าเฟส Testing ของ Waterfall เป็นปัญหาเยอะที่สุด แต่พอสาวย้อนไปหาสาเหตุจริงๆแล้ว มันมาจากเฟส Coding  แล้วที่ Coding มันเพี้ยน ก็เพราะช่วงออก Software Requirement มันมีปัญหานั่นเอง

ซึ่ง Dr. Royce แกเลยปรับปรุง Waterfall ใหม่ จนปี 1970 แกได้ออกเอกสารชื่อว่า Managing the Development of Large Software Systems ซึ่งอธิบายการปรับปรุงของแกไว้ ตามภาพด้านล่าง

(รูปจาก http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf)

ซึ่งในปัจจุบันที่เราไปโวยวายว่า Waterfall ไม่ดี เพราะเราไม่ได้ทำเต็มรูปแบบของมัน ตามที่  Dr. Royce ได้ปรับปรุงไว้ (และดูเหมือนจะไม่มีใครสอนให้ทำด้วย) คือ

1. Program Design Comes First – เราควรออกแบบโปรแกรมตัวอย่าง (Phototype) ออกมาให้เห็นก่อน ซึ่งมันจะแทรกอยู่ระหว่างขั้นตอน Software Requirements phase และ Analysis phase ซึ่งในเอกสารของ Dr. Royce บอกว่า
   – ทำโดยดีไซน์เนอร์นะ ไม่ใช่โปแกรมเมอร์หรือนักวิเคราะห์ระบบ
   – ออกแบบการทำงานแต่ละส่วน ไม่ว่าจะเป็น processing, functions, data base, data base processing
   – เขียนมันออกมาเป็นเอกสารที่ทุกคนเข้าใจได้
2. Document The Design – เขียนเอกสารออกมาให้เข้าใจง่าย (Simple) และตกลงร่วมกันว่าจะใช้เป็นมาตรฐาน
3. Do it twice – คนทำงานและลูกค้า พิจารณาของที่ได้มาในข้อ 1 และ 2 เพื่อรีวิวและปรับปรุง จากนั้นทำขั้นตอนเดิมอีกรอบ เพื่อให้ได้ของตามต้องการ และจัดทำเป็นเอกสารกลับเข้าไปเพื่อทำงานในแต่ละขั้นตอนต่อไป
4. Plan, Control and Monitoring Testing – ทำแผน และก็เน้นเรื่องการทดสอบซะ เพราะมันเป็นจุดที่ทำให้เสียเงินเยอะที่สุด หากมีข้อผิดพลาด
5. Involve The Customer – นำเสนอข้อมูลของการผลิต และให้ลูกค้าได้ชมของ (อย่างเป็นทางการ) ก่อนที่จะส่งมอบไปให้เขาต่อไป (คงประมาณว่ายืนยันคำสั่ง และของที่ได้รับ)

(รูปภาพจาก Facebook – Prathan Dansakulcharoenkit)

กลับมาที่รายละเอียดของ Scrum

หลังจากได้เข้าใจที่มาและความหมายของ Scrum พี่หนุ่มจึงพาลงไปในรายละเอียดว่า Scrum ต้องประกอบด้วยอะไรบ้าง

โดย Scrum มีองค์ประกอบ 3 ประการ คือ

1. Iterative and Incremental – คือทำงานเป็นรอบ
2. Lean (TPS – The Toyota Production System) – คล่องแคล่ว
3. Timebox – มีกำหนดเวลาชัดเจน

โดยทีมที่ทำ จะเรียกว่า Scrum Team ซึ่งจะมี 3 บทบาท (Scrum Roles) คือ

1. Product Owner (PO) – เจ้าของงาน (ผลิตภัณฑ์)
   1. เป็นผู้รวบรวมไอเดีย หรือรับโปรเจ็ค เข้ามา จัดทำเป็น User Story และประสานกับทีมเพื่อให้ทีมทำ Product Backlog
   2. Product Owner ไม่มีหน้าที่เขียน Requirement, Product Backlog ยกเว้นเป็น Product ตัวเอง หรือสามารถทำเองคนเดียวได้, ซึ่งปกติแล้วจะต้องมีทีมช่วยกันทำ หรือ Development Team ช่วยทำ
   3. Product Owner ทำงานคนเดียวไม่ได้ ต้องมีทีม เพราะไม่มีใครรู้ดีทุกอย่าง บางอย่างต้องใช้ผู้เชี่ยวชาญ (Domain Expert) ในด้านนั้นๆ
   4. Product Owner เมื่อถึงเวลาให้จัดลำดับ Product Backlog เข้า Sprint ควรแนะนำให้เขาเรียงตาม Bussiness Value โดย Features ต่างๆ ให้อ้างอิงจาก Learn, Earn, Save ถ้าตอบไม่ได้ ให้พิจารณาร่วมกับ KPI ของบริษัทว่าทำแล้วตอบโจทย์ตัวไหนของธุรกิจไดบ้าง
   5. เทียบ Product Owner เหมือนเซียนหวย ที่กำลังจะลงทุน 80 บาท แล้วต้องได้สามล้านกลับมา คนเหล่านี้เขาต้องไปหาข้อมูลตามสำนักตามข่าวต่างๆ ถึงจะไปเลือกซื้อได้
2. Development Team (Team) – ทีมพัฒนางาน และส่งมอบงาน (ผลิตภัณฑ์)
3. Scrum Master (SM) – ผู้ดูแลทีม และให้ทีมดำเนินกิจกรรมต่างๆ จนบรรลุเป้าหมาย
   1. ไม่ใช่ ผู้จัดการ (Manager), ผู้จัดการโครงการ (Project Manager), หัวหน้าทีม (Team Lead), ตัวแทนทีม (Team Representative)
   2. Scrum Master จะเปรียบเสมือนหมาเลี้ยงแกะ และ Team เป็นแกะ ซึ่งหมาเลี้ยงแกะไม่จำเป็นต้องเข้าใจภาษาของแกะ แต่คุมให้เข้ากรอบที่ต้องการได้
   3. Scrum Master ต้องแยกเป็น Full Time Job เพราะมีหน้าที่ต้องดูแลทีมให้ทำงานได้
   4. Scrum Master ควรเข้าใจคน ตั้งแต่ระดับ Top Management ลงไปถึงคนทำงานระดับล่าง
   5. Scrum Master ไม่จำเป็นต้องตอบทุกคำถาม ในสิ่งที่ตนเองไม่รู้
   6. Scrum Master ต้อง Conduct, Train และ Coaching Team โดยจะมี 3 บทบาทหลักๆ คือ
      • สร้าง Product Owner ที่ทำงานได้ (Work Well) – ถ้าทำไม่ได้ Scrum Master ต้องทำให้ดูได้
      • สร้าง Development Team ที่ทำงานได้ – ถ้าทำไม่ได้ Scrum Master ต้องทำให้ดูได้
      • ปรับองค์กรให้เป็น Scrum (ถ้าต้องการเป็น Scrum ทั้งองค์กร)

(กราฟสรุปสิ่งที่ Scrum Master ต้องใช้เวลาและใส่ใจ)

ซึ่งสมมติว่าได้ทีม และ Requirement ของงานที่จะทำแล้ว จนแจกแจงเป็นชิ้นงาน  (Product Backlog Item) เสร็จแล้ว รูปแบบการทำงานของ Scrum ก็จะทำงานเป็นรอบ ซึ่ง 1 รอบ หรือเรียกว่า 1 Sprint โดยจะใช้เวลา Sprint ละ 5, 10, 15, 20 วัน แล้วแต่ทีมตกลงกันว่าเวลาใดสะดวก โดยพี่หนุ่มแนะนำจากประสบการณ์ว่าใช้เวลา 10 วัน กำลังดี ไม่มากและไม่น้อยไป

และในแต่ละ Sprint, ทีมจะต้องทำให้ครบ 6 กิจกรรม (Scrum Activities and Artifacts) ดังนี้

• Sprint Planning Part I – PO เลือกชิ้นงาน (Product Backlog Item) ที่จะให้ Team ทำใน Sprint โดยดึงงานออกมา พร้อมลำดับความสำคัญ
• Sprint Planning Part II – PO,Team ประเมินวิธีการทำของ Task ต่างๆ จนได้ออกมาเป็นข้อมูลที่พร้อมทำงาน ซึ่งจะเรียกว่า Sprint Backlog, รวมถึง PO และ Team ต้องตกลงสิ่งที่จะส่งมอบเมื่อจบ Sprint นี้ร่วมกัน (Potential Shippable Product Increment) หรือ อาจจะกำหนดเป็นนิยามของคำว่า “เสร็จสมบูรณ์ (DoD – Definition of Done)” ร่วมกันก็ได้
• Product Backlog Refinement – Team แปรรูป Product Backlog ให้เป็นชิ้นงานร่วมกัน
• Daily Scrum – Team,SM (และ PO) ประชุมร่วมกันทุกวัน เพื่ออัพเดทความคืบหน้า งานที่เสร็จ งานที่จะทำ ปัญหา
• Sprint Review – PO, Team รีวิวงานที่เสร็จใน Sprint ว่าเป็นไปตาม Potential Shippable Product Increment หรือ DoD ไหม
• Sprint Retrospective – Team, SM มองย้อนกลับไปในสิ่งที่ทำในรอบ Sprint ว่ามีอะไรดี ไม่ดี และต้องพยายามปรับปรุง
  • หลักการทำ Retrospective มี 5 ข้อ
    • มองกลับไปที่ตัว Product
    • มอง Process ที่ใช้อยู่
    • มอง Peoples (Team, Product Owner)
    • มอง Tools ที่ใช้อยู่
    • มอง Relationship ที่เป็น ทั้งภายในทีม และภายนอกทีม (Internal, External)

(รูปอธิบาย 3บทบาท 6กิจกรรม ของ Scrum)

โดยแปลงเป็นรูปสรุปสวยงาม จะได้ประมาณนี้

(รูปจาก http://scrumprimer.org/anime)

พี่หนุ่มคอยเพิ่มเติมเกร็ดต่างๆ Agile ระหว่างการสอนอยู่เรื่อยๆ ตามเท่าที่ได้จากประสบการณ์

• Agile บอกว่า Welcome Change แต่ไม่ได้บอก Manage Change แบบ Scrum, ITIL
• ทีมต้องมีความรู้สึกเป็นเจ้าเข้าเจ้าของ Product ที่ตนเองถือ
• Agile ไม่ใช้คำว่า “ใช้” ใช้คำว่า “ประยุกต์”
• ไม่มีคำว่า Full Agile เพราะอยู่ที่เราประยุกต์ให้เข้ากับองค์กร
• ให้เอาวิธีการทำงานเดิม (SDLC – Software Development Life Cycle) ปรับเข้าใช้กับหลักปฏิบัติ 12 ข้อ อย่าพยายามเอา SDLC ไปยัดลง 12 ข้อ

เกร็ดอื่นๆในส่วนของ Scrum

• รูปแบบการสร้าง Scrum Master ต้องพาเขาไปได้รับประสบการณ์จริง และประกบสอนไปเรื่อยๆ เพราะแต่ละคนมีพื้นฐานมาไม่เท่ากัน การเข้าใจและนำมาใช้ต่างกัน เสมือนที่ Padawan ต้องตามประกบ Jedi ในเรื่อง Star Wars
• อย่านำ Project ลูกค้ามาทดลองทำ Scrum
• Top Management ควร Support เพื่อให้งานลื่นไหล
• อย่าพยายามสร้าง Self-Organize Team แต่ให้สร้าง Self-Managing คือ
  • วิเคราะห์ + วางแผน + แตกงาน
  • Monitor + Manage Progress
  • Monitor + Manage Process
• ถ้าจะ Adapt Agile ให้เอาหลักปฏิบัติ 12 ข้อเป็นตัวตั้ง และสร้างทีม
• ในทุก Project ตัวที่ Fix มี 3 อย่าง คือ
  • Scope
  • เงิน
  • เวลา

จบวันแรก ปูทางภาพกว้างมาครบหมด อัดแน่นมาก แต่ก็เติมความรู้ Agile, Scrum เข้าหัวได้มากเช่นกัน พี่หนุ่มมักถามบ่อยๆตลอดการสอนว่า

แล้วยังอยากเป็น Scrum Master อยู่อีกไหม?

นั่นสิ ยังอยากเป็นอยู่อีกไหม?!! ไว้ไปเรียนต่อวันที่สอง..