Quickly, but not hurry ของคุณ Thor Verapat, CTO InnovestX

• Be quick, but don’t hurry
• อะไรต้องทำ ต้องใช้เวลาดำเนินการ ทำได้ก่อน ก็ใส่ backlog และทำในโปรเจ็คเลย เช่น security, compliance ไม่ใช่งานส่วนของการ deliver
• hurry คือ การเร่งๆ รีบ ไม่ต้องรู้ ไม่ต้องคิด ทำไปก่อน ค่อยไปแก้เอาดาบหน้า .. ขึ้นงานได้จริง แต่ทีมเครียด จบไม่สวย
• Quick culture อย่าหวังว่ามาจาก top to down, ต้องเริ่มจาก down to top โดยมีคนเริ่มทำ practice ก่อน
• Discovery จะทำให้เกิด realistic plan
• pacing บางอย่างเกิดจาก hurry ไม่ใช่ good speed แล้วทีม mamagement/po เข้าใจว่า ก็เคยทำได้ด้วย pace นี้ ก็ควรใช้เวลาเท่าเดิมสิ, แต่จริงๆ เขาไม่รู้ว่ามันขาดตกอะไรหว่างทางไป หรือต้องเหนื่อยอะไร ตอนที่ hurry
• เอา DoD มาช่วย (ช่วย clarify task) เพื่อลดแผนแบบ hurry
• Pause spint for Stability, performance, security
• Pitching ระดับบอร์ดให้ project priority – ควรนำเสนอ value, risk
• การเมือง กับการล็อบบี้ คือ เรื่องเดียวกัน
• deliver, implement ให้ดูทิศทางลมด้วย
• การเมือง ไม่เกี่ยวกับ deliver ช้าหรือเร็ว

ส่วนอีกเซสชัน เรื่องจาก Agile สู่ AI โดย Palo IT

อันนี้พูดกว้างไปนิด ยืดหน่อย รู้ว่าเขาใช้ Copilot เขียน requirement, test case, code, document, design ซึ่งอันนี้ก็ลองทำเองและค้นคว้าอยู่แล้ว แต่สิ่งที่รู้เพิ่มเติมคือ สิ่งที่ผมกำลังทำ เรียกว่า Context Engineering นี่เอง

ช่วงบ่ายเข้าเซสชันเดียวคือ Facilitate Scrum from Hell ของคุณนา คุณกวง

ทั้งเรื่อง ให้ผู้ฟังมาทำ 2 กิจกรรม เช่น สลับทำ facilitate daily standup คนละ 3 นาที ให้เวลาน้อยไป ไม่ค่อยอิน เลยไม่ได้อะไรเท่าไร

บ่ายสาม ฟ้าเริ่มครึ้มเบยกลับบ้านดีกว่า กลัวฝนตก

จบการสรุป #ATH2025 ปีนี้

ขอบคุณทีมงานที่จัดงานดีๆ และสปอนเซอร์ทั้งหลายด้วยฮะ

• Software จะออกหรือไม่ออก อยู่ที่คนสร้าง ไม่ใช่อยู่ที่ process, แต่ process มีไว้ให้เดินตาม
• ใช้ Document คือ evidence ในการส่งมอบ ถูกต้องแล้วใช่ไหม?
• Agile ส่วนมาก มาลงที่ IT ก่อน แต่แผนกอื่นจะทำไหมไม่รู้ และอาจไม่ได้ทำ
• คนทำงานในบริษัทที่ทำ Agile นอกเหนือจาก IT ทุกคนควรเข้าใจ technology และหลักการ Agile ไว้บ้างเพื่อเข้าใจกัน
• ปัญหาที่พบคือ บัญชี,ISO,CMMI ทีม จะ adapt มาใช้ Agile อย่างไร ซึ่งทีมเหล่านั้นคุณควรไปคิดเอง เพราะคุณคือ expert ด้านนั้น ควรต้องทำเองได้
• ให้คิดตั้งโจทย์ว่า จะทำอย่างไรเพื่อให้ avoid delayed และถูกต้องตาม requirement
• กำหนด timebox ไว้ แม้ความจริงมี change มาตลอด แต่ก็ไปปรับ scope กันไป
• ไม่ถามว่า Agile คืออะไร ทำอย่างไร แต่ถามว่าอะไรคือประโยชน์ที่เราจะได้ถ้าทำ Agile?
• Agile ควรเอามาทำกับ developer ที่ Maturity นะ ไม่ใช่ทุกคนที่จะทำด้วยได้
• จะเอา Agile มาใช้ คนทำ เขาทำได้เร็วไหม เขายอมเปลี่ยนไหม, ไม่เข่นนั้นคนกลางเหนื่อย
• ไม่ใช่ถามว่า งานแบบไหนเหมาะกับทำ Agile, ให้ถามว่า คนแบบไหนไม่เหมาะกับทำ Agile
• Self Management เริ่มจาก การเดินมาบอกทีมว่าปัญหาคืออะไร สถานะงานถึงไหน
• ทุก sprint ต้องมี goal เสมอ (เป้าเดียว และส่งมอบคุณค่าอะไร)
• รับคนเข้ามา 1เดือนแรก ถ้าไม่คลิกกัน เรียก feedback แล้วให้ออก
• คำว่า toxic ต้องถามว่าผลลัพธ์เป็น toxic ที่ดีไหม (เช่น คนทำงาน alert จัด แต่มี Sense of ownership)

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

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

ยุทธจักรของ Coach

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

ซึ่งการโค้ชไปให้ถึงเป้าหมาย ก็แบ่งได้ 2 แบบ

• โค้ช เพื่อ พาคนที่ต้องการไปเป้าหมาย, ไปให้ถึงเป้าหมายของเขา
• โค้ช เพื่อ พาคนไปให้ถึงเป้าหมายของเรา

ดังนั้น ผู้ที่รับการโค้ช (Coachee) จะต้องมีความอยาก มีความต้องการไปให้ถึงเป้าหมายก่อน หรือเห็นประโยชน์ก่อน ถึงจะเริ่มต้นโค้ชได้

คำว่า Agile Coach จะเรียกได้ว่า โค้ชเพื่อทำให้คนๆ หนึ่ง ที่ต้องการ เก่งในการทำงานในแบบ Agile ก็ว่าได้

ดังนั้นการโค้ชแต่ละครั้ง Coach จะมีสิ่งที่เรียกว่า Gap to Goal

• Competency (สมรรถนะ)
  • Knowledge (ความรู้) – ในสิ่งที่จะทำ
  • Skill (ทักษะ) ที่ก่อให้เกิดผลสำเร็จ
  • Attribute (คุณลักษณะ) ที่เป็นแรงขับดันให้แสดงออกเป็นพฤติกรรมไปสู่ผลสำเร็จ
• Mindset (วิธีคิด)
• Solution Tools (เครื่องมือ)

อาจารย์ปกรณ์โยงไปถึงเรื่องของก้อนน้ำแข็งใต้น้ำ (Iceberg) ว่าถ้า Coach ไม่เก่งหรือประสบการณ์ไม่ถึง จะเห็นแค่ Feeling (ความรู้สึก), Thinking (ความคิด) ของ Coachee

แต่ถ้า Coach เก่งๆ หรือมีประสบการณ์สูง จะดำดิ่งลงไปเห็น Belief (ความเชื่อ), Value (คุณค่า) ของ Coachee

ซึ่ง Coach ที่จะรู้ลงไปส่วนก้นบึ้งของ Coachee ได้, Coach จะต้องเป็นผู้ฟังที่เก่ง และ Coach จะทำให้ Coachee ที่รู้สึกแย่มีพลัง ได้จากการฟัง

Coach จะพยายามทำให้ Coachee ทำในสิ่งที่เขาคิด ดังนั้น Coach เองจะต้องไปตัดสินว่าสิ่งที่เขาคิดนั้นผิดหรือถูก

แต่นอกจากเป็นนักฟังที่ดีแล้ว Coach จะต้องเป็นนักเล่าที่ดีด้วย โดย จะเล่า 2 แบบ

• Story Telling : โดยเล่าเรื่องราวของตนเองหรือที่รู้มา โดยเป้าหมายเพื่อให้ผู้ฟังหยิบไปเทียบกับเหตุการณ์ของเขา และเอาไปทำได้ โดยวิธีการนี้ผู้ฟังมักเกิดความประทับใจ แต่อาจจะเอาไปคิดต่อไม่ได้ และนำไปทำต่อไม่ได้
• Story Coaching : โดยเล่าเหตุการณ์ โดยมีเป้าหมายเพื่อให้ผู้ฟังสามารถหยิบไป mapping ไปกับเรื่องของเขา และเอาไปทำได้

ซึ่งในขั้นแรก Coach จะต้องทำให้เขารู้ว่าเขาอยากจะเก่งขึ้น ดีขึ้น ผ่าน Story Telling หรือ Story Coaching เล่าให้ Coachee เกิดแรงบันดาลใจ (Metaphor)

และ Coach จะเป็นกระจกเงาเพื่อสะท้อน (Reflect) ให้กับ Coachee โดยผ่านการตั้งคำถาม ทั้งนี้ การถาม จะ ถามเพื่อให้เขาเห็น มิใช่ ถามเพื่อให้เราเห็น

ดังนั้น Coach ที่ดีจะ Reflect เพื่อให้เขาเห็นประเด็นได้เอง แต่ถ้า Reflect แบบชี้ประเด็นให้เขาเห็น จะเป็นในรูปแบบของพี่เลี้ยง (Mentor)

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

ถ้าถามแบบโค้ช จะถามเพื่อค้นหา (Exploration) เพื่อให้ Coachee เขาหาวิธีการแก้ปัญหานั้นๆได้ด้วยตนเอง แต่ถ้าถามแบบพี่เลี้ยง จะถามเพื่อวิเคราะห์ (Analysis) ร่วมกัน และหาวิธีการแก้ปัญหานั้นๆ ร่วมกับ Coachee

มาถึงตรงนี้ อาจารย์ปกรณ์ ได้วาดตารางเปรียบเทียบระหว่าง Coach, Mentor, Facilitator ให้เห็นความแตกต่าง ซึ่งค่อนข้างชัดเจนมากๆ ครับ

อาจารย์ปกรณ์ ได้อธิบายเพิ่มเติมว่า

• Coach จะมี Empathy คือ เราเข้าใจปัญหาเขา
• Mentor จะมี Sympathy คือ เราเข้าใจปัญหาเขา และเราเข้าไปช่วยแก้ รับมาเป็นปัญหาเรา

ซึ่งด้วยตารางเปรียบเทียบด้านบน จึงทำให้เราพอจะเห็นภาพชัดเจนขึ้นและแนวปฏิบัติว่าการเป็นโค้ชควรทำแบบใด

ยุทธจักรของ Agile

มาถึงช่วงที่พี่หนุ่มอธิบายเรื่องของ Agile ซึ่งได้เปิดด้วยการอธิบายความหมายของคำว่า Agile และประวัติความเป็นมาของแต่ละ Process ที่ถูกคิดขึ้นมา จนมาถึงจุดที่บุคคล 17 ท่าน ได้คุยหาจุดเหมือนในแต่ละ Process ที่ตนเองได้คิด ทดลอง และปฏิบัติซ้ำๆ จนประกาศเป็น Agile Manifesto โดยมี 4 Values และ 12 Principles (ซึ่งในรายละเอียด ผมเคยไว้ใน ScrumMaster in Action (Day 1) แล้ว เนื้อหาประวัติก็จะคล้ายกัน)

แต่มี Slide หนึ่งที่พี่หนุ่มได้สรุปให้เห็นภาพชัดเจนมากขึ้น ว่า

• Agile คือ วัฒนธรรมสำหรับการทำงาน ไม่ใช่ตำแหน่ง
• Agile ใช้การทำงานแบบเป็นรอบ (Iterative and Incremental)
• Agile ขับเคลื่อนจากคุณค่าของงานชิ้นนั้น (Value)
• Agile ทำให้ทีมสามารถส่งมอบคุณค่าของงานชิ้นนั้นได้บ่อยๆ เพื่อได้รับการ feedback ได้บ่อยๆ
• Agile คือการทำงานร่วมกันของทุกฝ่าย
• Agile ให้ความเคารพต่อผู้คน
• Agile ต้องเปิดเผยในสิ่งที่ทำ และเข้าใจ และเห็นในคำว่า “งานเสร็จ” ร่วมกัน
• Agile ต้องมุ่งมั่นที่จะปรับปรุงตัวเอง ทีม กระบวนการ ต่อเนื่องไปเรื่อยๆ
• Agile จะต้องใช้ Automation เช่น Automated Testing, CI/CD เพื่อลดงานและให้เกิดความเร็ว

จากนั้นพี่หนุ่มได้อธิบายการทำงานเป็นรอบๆ โดยเทียบกับกระบวนการพี่อาจารย์ปกรณ์และทุกคนน่าจะทราบดี นั่นคือ PDCA Cycle โดย 1 รอบกระบวนการ เท่ากับ 1 Sprint

และจะมีเพิ่มเติมนิดหนึ่งว่า ขั้นตอนที่ทำ (Do) ก็จะมีกระบวนการ PDCA ย่อยๆ อยู่ในนั้นด้วย ซึ่งจะเกิดขึ้นในระดับวัน (Daily Scrum)

ซึ่งถ้าไม่ใช้คำว่า Agile แต่พูดถึงในการทำงานจริงๆ พี่หนุ่มได้เขียนไว้ประโยคหนึ่งที่พอจะเข้าใจได้ง่ายกว่า คือ

Business Value is Deliver Incrementally
in Timeboxed Cross-Discipline Iterations

อันนี้ผมลอง map กับ PDCA เองว่า ถ้าพูดแบบจับต้องได้ คือ เรา Plan เพื่อตอบโจทย์ Business Value โดยใช้ Cross Functional Team เป็นผู้ Do และมีการ Deliver งานบ่อยๆ เพื่อให้เกิดการ Check และมี Feedback ที่เร็ว และ Adjust ปรับปรุงได้ ภายใน Timeboxed ที่กำหนด จากนั้นค่อยไปเริ่มชิ้นงานใหม่

ซึ่งสามารถใช้ได้ทั้งในระดับ Project, Feature และ Task เลยครับ

สรุปความเป็น Agile Coach

ดังนั้น ถ้าว่ากันแล้ว Agile Coach คือ โค้ชเพื่อทำให้คนๆ หนึ่ง ที่ต้องการเก่ง Agile ได้ เก่งในการทำงานในแบบ Agile

โดยสิ่งที่ Agile Coach จะต้องทำ แบ่งหน้าที่เป็น 40% Agile Expert และ 60% Behaviour Scientist

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

อาจเพราะผมไม่ได้เข้ามาร่วมทีมสัมนาของบริษัทหลายครั้ง พบว่าเทคนิคการเล่าเรื่องของพี่หนุ่มเปลี่ยนไป ฟังเพลิน เหมือนประวัติศาสตร์ ที่มันมี Timeline และการเชื่อมโยงเหตุการณ์ กับหัวข้อต่างๆ เลยอยากจั่วหัวบล็อกว่า A Brief History of Agile ดูเข้าท่าดี (ล้อชื่อหนังสือ A Brief History of Time และรำลึกถึง Stephen Hawking ผู้เขียน)

ประเด็นที่ถูกเปิดตอนเริ่มคลาสคือปัญหาเรื่องการศึกษาของไทย และความหมายของคำว่า Agility ผ่านการตั้งคำถามว่า ถ้าสิบโมงเช้าได้โจทย์ต้องเปลี่ยนระบบคิดเงินจาก VAT 7% มาเป็น 10% และต้องเสร็จภายในบ่ายสอง .. กระบวนการและระบบของเราสามารถทำแบบนั้นได้หรือไม่?

จากนั้นเล่าที่มาว่า ได้มีบุคคล 17 คน ทำการประกาศ Agile Manifesto โดยมี 4 Core Values และ 12 Principles ซึ่งบุคคลเหล่านั้นได้กลั่นจากประสบการณ์ที่ตนเองประสบมา ต้องบอกว่าบุคคลเหล่านั้นไม่ใช่ตาสีตาสานะครับ แต่เป็นระดับคนที่คิด Framweork ต่างๆ เช่น Scrum, DSDM, XP, Crystal Clear เป็นต้น

ในไทยเองมีความเข้าใจผิดเกี่ยวกับ Agile พอสมควร เช่น Agile ไม่ต้องทำเอกสาร, Agile เปลี่ยนแปลงได้ตลอดเวลา, Agile ทำให้ไวขึ้น ซึ่งถ้าฟังแบบนี้ ทาง Business ก็ชอบใจและอยากมุ่งไปทำกันหมด แต่แท้จริงแล้ว มันมีรายละเอียดมากกว่านั้น ถ้าจะทำให้เกิดได้ ซึ่งพี่หนุ่มได้ยกตัวอย่าง เช่น ..

1. Individuals and interactions over processes and tools
   การทำงานที่เกิดจากการทำเป็นทีม ซึ่งต้องมีคนจากหลาย Skill มารวมกัน สามารถทำทุกอย่างเองได้ ทีมดูแลกันเองได้ และถูก Dedicate ออกมาเพื่อทำงานๆหนึ่งโดยเฉพาะ
2. Working software over comprehensive documentation
   ซึ่ง Source Code ก็เป็นเอกสารเช่นกัน แต่ไม่ให้ความสำคัญ มันเลยไม่เป็นมิตรกับคนอ่านทุกคนเท่าไร หรือแม้แต่คนเขียนเอง (Human Readable) ตัวอย่างเช่นการตั้งชื่อ Function ควรอธิบายถึงพฤติกรรม ว่าใส่อะไรเข้าไป ทำอะไร และได้อะไรออกมา
3. Customer collaboration over contract negotiation
   ปัญหาของ SDLC เดิม (Waterfall) คือ พอเริ่มจากเก็บ Requirement > Analyst > Design … กว่าจะได้เห็นของที่พอใช้ได้อีกทีก็ตอน Test ซึ่งกินเวลานานมาก จึงต้องทำให้กระบวนที่ทำอย่างไรให้ทำ SDLC ครบตามเดิม แต่ย่อเวลาให้สั้นลง จึงสับออกมาเป็น เห็นของบ่อยๆในทุกระยะ หรือที่เราเรียกว่า Iteration ดังนั้นเมื่อลูกค้าเห็นของได้เร็วขึ้นและบ่อยขึ้น กระบวนการ Change และทำงานร่วมกันก็จะบ่อยขึ้นตามมา (แต่เรารู้ได้ก่อน) ผสมกับ Requirement เดิมที่ต้องนำทั้งหมดมาจัดความสำคัญใหม่ และทุกครั้งที่จบ Iteration ของที่ได้จะต้องใช้ได้และโตขึ้นเรื่อยๆ หรือที่เรียกว่า Incremental
4. Responding to change over following a plan
   จากผลของข้อ Customer collaboration ทำให้เกิดการคุยกัน ทำงานร่วมกัน และมีปรับปรุงตลอด ดังนั้นข้อนี้ก็จะเกิดขึ้นโดยอัตโนมัติ

แต่ทั้งนี้ 4 Core Values ยังจับต้องไม่ได้ ต้องไปดูที่ 12 Principals เพิ่มเติมว่า หลักปฏิบัติมีอะไรบ้าง ตรงนี้ เป็นความท้าทายอย่างหนึ่งของผู้นำไป Implement เพราะจะทำอย่างไรล่ะ ที่จะเชื่อมโยงแต่ละข้อเข้ากับ Practice และทำให้เกิดผลได้ ยกตัวอย่าง เช่น

ข้อ 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
ดังนั้น Software ต้องเป็นชิ้นเล็กๆ ขยับขยาย เปลี่ยนแปลง นำเข้า นำออก เพื่อส่งมอบได้ตลอดเวลา เช่น ต้องเขียนด้วย OOP เป็นต้น ทั้งนี้ จะได้ Software แบบนั้น นอกจากต้องมีการวางสถาปัตยกรรมที่ดี ยังต้องรู้จักการจัดสรรงานที่ดีด้วย เพื่อให้ Software ที่ส่งมอบได้บ่อยๆนั้น สามารถใช้งานได้จริงด้วย

ข้อ 5 Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
การทำงานแบบ Agile จะไม่เร็วในทันที แต่กลับช้าลงกว่าเดิมด้วย เพราะต้องจูนคนในทีมให้เข้าใจกัน Skill มีพอเพื่อทำงานออกมาได้ ดังนั้นต้องมี Practice ต่างๆ เพื่อปรับทีม, ถ้าเทียบการทำ SDLC แบบเก่า เหมือนการวิ่งผลัด ที่ต่างคนต่างวิ่ง และส่งไม้ต่อ บางคนช้า บางคนเร็ว แต่สุดท้ายต้องดูที่เวลารวม แต่กระบวนการที่ต้องทำงานเป็นทีม เหมือนคนผูกขาวิ่งไปด้วยกัน แรกๆจะขัดๆ ช้าๆ แต่พอทำบ่อยๆ ก็จะเข้าขากันได้

ข้อ 7 Working software is the primary measure of progress.
จะต้องทำให้เป็น Iterative & Incremental เพื่อให้ส่งงานได้บ่อย เห็นงานได้ไว และใช้งานได้จริง

ข้อ 9 Continuous attention to technical excellence and good design enhances agility.
ข้อนี้สำคัญ เป็นเรื่องทางเทคนิคอลที่จะทำส่งเสริมให้เกิดข้อต่างๆ ซึ่งมี 4 ข้อพื้นฐานที่ควรทำได้ คือ

1. Source Code Management
2. Coding Standard
3. Automate Build
4. Automated Test

ซึ่งทั้งหมดนี้ในต่างประเทศทำเป็นเรื่องปกติ แต่ในไทยยังไม่ได้ใช้กันมากนัก

จาก 4 Core Values และ 12 Principals นี้ คุณ Alistair Cockburn ได้สรุปให้เข้าใจออกมาเป็น 4 ข้อ เป็น The Heart of Agile

Photo: http://alistair.cockburn.us/Rediscovering+the+Heart+of+Agile

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

และหลังจากเต็มอิ่มกับทฤษฎีและได้เห็นแนวทางคร่าวๆผ่านเกมส์ จึงได้ให้อาจารย์เริ่มลงงานจริง ด้วยการบอกโจทย์ ว่าเราต้องการทำระบบ e-Wallet ซึ่งให้อาจารย์ลองคิด Feature กันเองด้วยเครื่องมือ Fishbone และให้เขาเลือกหยิบมาทำ 1 Feature ก็คือ การโอนเงิน

จากนั้นนำเรียงให้เห็น Business Flow และทำการกำหนด Test Case ตัวอย่างขึ้นมา คือเคสโอนเงินจากบุคคลหนึ่งไปยังบุคคลหนึ่งได้สำเร็จ โดยให้อาจารย์เขียน Test Data ขึ้นมาด้วยในการใช้ตรวจรับ ซึ่งสิ่งที่เราได้ทั้งหมดเป็นส่วนของ Customer Visible ในเครื่องมือที่ชื่อว่า A-DAPT Blueprint นั่นเอง

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

หนังสือเล่มนี้ใช้ภาษาอ่านไม่ยาก คนทั่วไปอ่านได้ เหมือนกำลังฟังลุง Ron บ่นๆ ไปเรื่อยๆ เพื่อปูพื้นฐานและปรับทัศนคติ ใครอ่านที่ผมสรุปไว้และสนใจอยากลองหาฉบับเต็มมาอ่าน ลองดูได้จากลิงค์นี้ครับ The Nature of Software Development: Keep It Simple, Make It Valuable, Build It Piece by Piece

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

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

ค้นหาคุณค่าซอฟต์แวร์ของคุณให้เจอ

เจ้ายอดพีระมิดในรูปนั่นหละ คือสิ่งที่เราต้องค้นหามันให้เจอ ว่าคุณค่าของซอฟต์แวร์เราคืออะไร ซึ่งคุณค่า (Value) ที่ว่า คือ สิ่งที่เราต้องการในงานชิ้นนี้ (What you want) ซึ่งเป็นได้หลายกรณี ตั้งแต่แบบจับต้องได้คือ เงิน ไปจนถึงจับต้องไม่ได้ อย่าง เสียงหัวเราะ ความสุข ความสะดวกสบาย

การทำให้เกิดคุณค่า จะเริ่มจากส่วนล่างสุดของพีระมิด ไล่เรียงขึ้นมา โดยเริ่มจาก…

• Guiding – ทีมทำงานต้องเข้าใจว่าอะไรคือสิ่งที่พวกเขาจะต้องทำ เราต้องการอะไร คุณค่าของงานคืออะไร เรามีทรัพยากร เช่น เครื่องมือ เวลา ฯลฯ อย่างไร
• Organizing – ใช้ความสามารถของทีมให้มีประสิทธิภาพ และสร้าง Team มีการพัฒนาความชำนาญขึ้นไปเรื่อยๆ
• Planning – วางแผน ตัดงานเป็นชิ้นตามคุณสมบัติ (Feature) ลำดับความสำคัญตามสิ่งที่ต้องการ เพื่อให้ได้สาระสำคัญของงานนั้นออกมาก่อน
• Building – สร้างงานเป็นชิ้นๆ ตามคุณสมบัติ (Feature) เพื่อส่งมอบงานให้ได้บ่อยๆ สามารถเห็นความคืบหน้าได้เรื่อยๆ
• Slicing – ตัดคุณสมบัติออกเป็นงานให้เล็กที่สุด ที่จะทำให้ส่องมอบงานได้ไว และส่งงานได้ตลอดเวลา
• Quality – นำวิธีการต่างๆมาประยุกต์ใช้เพื่อสร้างงานให้มีคุณภาพอยู่ตลอดเวลา

คุณค่าที่คุณคู่ควร (Value)

คุณค่า (Value)  คือ สิ่งที่เราทุกคนต้องการ (What you want) และในมุมมองของซอฟต์แวร์นั้น เราจะไดรับคุณค่าของมันก็ต่อเมื่อมีการส่งมอบคุณสมบัติ (Features) ของซอฟต์แวร์นั้นออกมา ไม่ว่าจะแบบจับต้องได้ อย่างการทำให้ประหยัดเงิน ประหยัดเวลา หรือจับต้องไม่ได้อย่างการช่วยสร้างความสะดวกสบายในชีวิต หรือทำให้ผู้ใช้ยิ้มได้ ดังนั้น ผู้เขียนจึงให้คำนิยามคำว่า Value คือ “What we want” 

ตามที่กล่าวไปข้างต้น คุณค่าของซอฟต์แวร์เริ่มมีหลังจากที่เราส่งมอบซอฟต์แวร์ไปแล้ว ดังนั้น การส่งมอบได้บ่อยๆ ก็เหมือนการส่งมอบคุณค่าให้ลูกค้าได้รับได้เห็นบ่อยๆ และสามารถพิจารณากันได้ทันทีว่า คุณค่าที่ส่งออกมา มันมีคุณค่าจริงๆไหม และที่กำลังจะทำต่อไป มันมาถูกทางแล้วหรือไม่ ซึ่งในภาษา Startup ใช้คำว่าทำ MVP (Minimum Viable Product) ขึ้นมาก่อน โดยจะมีหัวใจของซอฟต์แวร์ หรือฟีเจอร์ที่ที่เอาไปขายได้ ออกมาทดลองในตลาดก่อน

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

ดังนั้น การแยกชิ้นงานเป็นชิ้นเล็กๆ คือ การแยกตามคุณสมบัติ (Features) เช่น คุณสมบัติต้องกันฝนกันลมได้ สิ่งที่ส่องมอบคือ โครงสร้างภายนอกของรถ, หรือคุณสมบัติรถสามารถเคลื่อนที่ได้ สิ่งส่งมอบคือ โครงสร้างภายนอกที่ปรอกับใส่ล้อและสามารถเคลื่อนที่ได้ เป็นต้น

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

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

มุ่งสู่สิ่งที่ดีกว่า ด้วยแนวคิดการทำทีละฟีเจอร์ (Guiding)

แบบที่เรารู้ๆกัน โครงการ (Project) ทุกชิ้นจะต้องมีกำหนดเวลาเสร็จชัดเจนเสมอ (Deadline) และต้องการได้ของครบทุกอย่างตามที่สั่งด้วย แต่พอนำไปปฎิบัติจริง ก็มักไม่ได้ตามนั้น, เพราะอะไร?

เพราะ การวางแผนที่ใช้ในโครงการส่วนใหญ่มัก จะทำเป็นก้อนใหญ่ และตัดเฟสโดยแบ่งตามประเภทกิจกรรม (Activity-based phase) เช่น เริ่มจากการวิเคราะห์ (Analysis) เสร็จแล้วนำไปออกแบบต่อ (Design) และก็ไปเขียนโค้ด (Coding) บลาๆๆ ซึ่งถ้าทำแบบนี้กว่าจะไปถึงเฟสหลังๆ จะรู้ได้อย่างไรว่า จะไม่เกิดบั๊กในภายหลัง หรือมีการเปลี่ยนแปลงความต้องการช่วงกลางทาง  ซึ่งถ้าเกิดเรื่องเหล่านี้ขึ้นมา ก็แปลว่าเราจะไม่สามารถส่งมอบงานที่สมบูรณ์ทั้งหมดได้ใช่หรือไม่? … คำตอบคือ ก็ใช่..

และถ้าเปลี่ยนเป็นทีมส่งมอบงานออกไปได้บ่อยๆ เริ่มตั้งแต่การวางแผนเป็นชิ้นงานเล็กๆ แบบทีละฟีเจอร์ (Feature by Feature) จากนั้นค่อยนำเข้ากระบวนการ ออกแบบ เขียนโค้ด ทดสอบ เสร็จงานก็ปล่อยฟีเจอร์นั้นออกไปขาย และค่อยเริ่มทำฟีเจอร์ชิ้นต่อไป แบบนี้จะดีกว่าไหมครับ?

การทำทีละฟีเจอร์ นอกจากส่งมอบงานได้บ่อยๆ ทำให้ลูกค้าเห็นความเคลื่อนไหวของงานแบบที่จับต้องได้อยู่ตลอดเวลา ลูกค้าเอาไปใช้งานได้ทันที ส่วนตัวทีมพัฒนาเองก็ดูแลโครงการทั้งหมดง่ายขึ้นด้วย เพราะดูแลเป็นฟีเจอร์เล็กๆ ให้เสร็จไปทีละส่วน ก็จะ Win-Win กว่าไหม?

อ่านถึงตรงนี้ลองนึกย้อนกลับไปเทียบกับสิ่งที่ตัวเองกำลังทำ หรือกำลังสั่งให้ทีมพัฒนาทำอยู่ ว่ามันดีกว่าหรือแย่กว่ากัน?..

วิธีจัดการงานทีละฟีเจอร์ให้มีประสิทธิภาพ (Organizing)

บางครั้งงานชิ้นหนึ่งจำเป็นต้องใช้ความสามารถหลากหลายเพื่อมาทำ เช่น Dev/UX/UI ซึ่งการจัดทีมแบบ Skill-set หรือจับคนที่มีความสามารถแบบเดียวกันไปอยู่ด้วยกัน แม้จะง่ายกับการบริหาร  แต่ก็อาจไม่เหมาะสมกับงาน และทำให้งานเดินได้ช้าลง เพราะพวกเขาต้องสลับหมุนเวียน ละจากงานหนึ่งไปงานหนึ่ง ออกไปขอคำปรึกษาจากผู้รู้ภายนอกทีม เช่น ฝ่ายกราฟฟิก ต้องไปถามฝ่ายทำ UX และไปถามฝ่ายพัฒนาถึงความเป็นไปได้ จากนั้นค่อยกลับมาทำงานของตนเอง นั่นจะหมายถึงเวลาที่สูญเสียแบบเปล่าประโยชน์ (แม้จะดูเล็กน้อยก็ตาม)

ดังนั้น วิธีการแก้ปัญหาคือ สร้างทีมทีมีผู้รู้ในแต่ละเรื่องที่จำเป็นสำหรับฟีเจอร์นั้นๆ มารวมกัน หรือเรียกว่า Feature Team

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

ในกรณีที่เรามีผู้เชี่ยวชาญในแต่ละด้านไม่เพียงพอเพื่อจับไปลงทีม เราควรหาผู้ที่มีความรู้ (อาจไม่จำเป็นต้องถึงขั้นผู้เชี่ยวชาญก็ได้) และสร้างกลุ่ม Community of Practice ขึ้นมา โดยให้ผู้รู้คนนั้นสอนคนอื่นๆ ในส่วนที่มีความจำเป็นต้องใช้ทำงาน เช่น Database Community of Practice หรือ UX Community of Practice

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

ลุง Ron ทิ้งท้ายไว้อย่างสะกิดต่อมเซเลบลัมในสมองว่า “ผู้เชี่ยวชาญที่เราจ้างมาด้วยราคาสูง ไม่ใช่จ้างมาเพราะเขาเป็นผู้เชี่ยวชาญเท่านั้น แต่ควรจ้างเขาเพื่อสร้างให้คนอื่นเป็นผู้เชี่ยวชาญได้เช่นกัน” (A highly paid expert shouldn’t be highly paid just because she’s an expert. She should be highly paid because she is helping other people become experts.)

การวางแผนทำทีละฟีเจอร์ (Planning)

วิธีส่งมอบงานให้ได้เร็ว จะเริ่มจากการมองภาพใหญ่ของงาน ว่าหัวใจหลักของมันคืออะไรบ้าง จากนั้นค่อยย่อยออกเป็นฟีเจอร์เล็กๆ เพื่อให้ชัดเจนขึ้น (ทำ Work Breakdown) แต่ยังไม่ต้องลงรายละเอียดมากนัก จะเสียเวลาและสร้างความสับสน ให้เพียงแยกเป็นฟีเจอร์หลัก และลำดับความสำคัญที่สร้างคุณค่าให้กับซอฟต์แวร์ก็เพียงพอ

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

ลุง Ron บอกให้ลองปรับวิธีคิดใหม่ โดยประเมินเวลาและงบประมาณแบบเดิมนั่นแหละ แต่ให้วางแผนตัดชิ้นส่วนงานเป็นชิ้นย่อยๆ เพื่อพัฒนาแบบทีละฟีเจอร์ โดยไล่จากที่มีคุณค่ามากที่สุดออกมาก่อน จากนั้นส่งมอบงานออกมาเรื่อยๆ เพราะถ้ามันถึงที่สุดแล้ว เวลาหมด งบประมาณร่อยหรอ ไม่สามารถส่งมอบงานทั้งหมด แต่อย่างน้อยซอฟต์แวร์ก็ยังสามารถใช้งานฟีเจอร์หลักได้

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

(อ่านมาถึงตรงนี้ จู่ๆผมก็นึกถึงบริษัทที่ผมเคยทำงานด้วย, สมัยก่อนผมขึ้นต้นด้วยการอธิบายวิธีการเลย ผู้ใหญ่ไม่ต้องรู้หรอกว่ามันดีอย่างไร แต่มันดีนะ ให้ผมทำไปเถอะ เชื่อผม…. และแล้ว เขาก็ไม่ได้เห็นด้วยกับวิธี และไม่อนุมัติให้ทำ.. เพราะเราไม่ได้ตัดแบ่ง ทำ Pilot Team, Pilot Project ทดลองให้เขาดูก่อน)

การส่งมอบงานออกมาเรื่อยๆ แบบนี้ จะเรียกรอบส่งงานนี้ว่า Iterations หรือ Sprints, โดยฟีเจอร์ (Feature) ที่ส่งมอบ จะเรียกว่า Story ซึ่งการทำงานแบบนี้ จะต้องวางแผนอยู่ตลอดเวลา เพราะมีการปรับเปลี่ยนเรื่อยๆ ไม่สามารถวางแผนในครั้งแรกครั้งเดียวแล้วใช้ได้เลย (ย้อนกลับไปย่อหน้าบนๆ อีกเช่นกัน ว่าทำไมไม่ต้องลงรายละเอียดกับมัรเยอะ และทำไมเรามักมีปัญหาเมื่อแผนเปลี่ยน)

ลุง Ron บอกว่า ไม่แนะนำให้ทำเป็น Story ใหญ่ๆ, ไม่แนะนำให้แตกงานย่อยๆ ออกมาเป็น Task ที่มีแต่ด้านเทคนิค (Technical) เพราะฝั่งที่ไม่มีความรู้ด้านเทคนิคจะอ่านไม่เข้าใจเลย และอีกประเด็นคือ การแปลง Story ออกมาเป็นฟีเจอร์เล็กๆ จะใช้เวลาทำและเข้าใจง่ายกว่าเป็น Technical Task

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

ลุง Ron เตือนไว้ว่า ในขณะที่วางแผน อย่าไปใส่ความท้าทายให้เป้าหมาย (stretch goals) เช่น “ลองใส่เพิ่มไปอีก 1 ฟีเจอร์ซิ๊” การทำแบบนี้มันจะทำให้ทีมพยายามทำมันให้เสร็จ โดยที่พวกเขาต้องเร่งทำงานอื่นให้เร็วขึ้น ทดสอบน้อยลง โค้ดลดคุณภาพลง เพียงเพราะต้องหาเวลาเพื่อรับความท้าทายขึ้นอีกแค่ 1 ฟีเจอร์ และท้ายที่สุดเราอาจจะได้งานช้าลงเพราะทีมต้องกลับมาปรับปรุงโค้ดหรือแก้ Defect ที่เกิดขึ้นในภายหลัง

“ความกดดันเป็นสิ่งที่อันตราย พยายามลีกเลี่ยงมัน”

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

สร้างมันขึ้นมาทีละฟีเจอร์ (Building)

ประโยชน์ของการย่อยงานทำทีละฟีเจอร์ (Feature by Feature) ทีมและองค์กรจะได้เรียนรู้ และเห็นผลของงานได้เร็ว สามารถเปลี่ยนแปลง ปรับปรุง การทำงานและตัวงานได้ตลอดเวลา (หรือเรียกกันว่า False Fast, Learn Fast)

ลักษณะการทำงานแบบนี้ มันเหมือนเราต้องทำซอฟต์แวร์ตัวเล็กๆหลายตัว เพื่อมาโปะกันไปเรื่อยๆจนได้สมบูรณ์ตามซอฟต์แวร์ภาพใหญ่ที่ต้องการ ดังนั้น การทำฟีเจอร์ตัวหนึ่ง จะยังคงต้องมีกระบวนการ Development Cycle ครบด้วย ตั้งแต่การวางแผน วิเคราะห์ ออกแบบ เขียนโค้ด ทดสอบ และเราจะเรียกกระบวนการที่ว่านี้เป็น 1 รอบการทำงาน (Iteration) ดังนั้นงานที่ได้ออกมาในแต่ละรอบจะเป็นงานที่ใช้ฟีเจอร์นั้นได้จริงๆ เอาไปโชว์ ไปขาย ไปใช้ได้ทันที

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

ในการทำงานแบบเดิม เราต้องรอจนถึงเฟส Test ถึงจะพบว่ามี Defect อะไรบ้าง ซึ่งมันอาจมีมากหรือน้อยจนทำให้ใช้เวลาเกินที่วางแผนไว้ แต่หากทำเป็นรอบและทุกรอบมีการ Test อยู่แล้ว เมื่องานทั้งหมดใกล้เสร็จ เราก็ไม่ต้องกังวลกับ Defect ก้อนโตในตอนท้าย (ผู้เขียนใช้คำว่า “nearly free of defects” คืองานเกือบจะไม่มีข้อผิดพลาดเกิดขึ้น)

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

แนวคิดแบบแนวตั้ง และสร้างเท่าที่จำเป็น  (Build Feature and Foundation in Parallel)

ฟีเจอร์ของซอฟต์แวร์ต้องมีโครงสร้าง (Foundation) ของซอฟต์แวร์ที่ดี, แต่สิ่งที่เราต้องคิดคือ จะทำอย่างไรให้ทั้งสองอย่างสมดุลและเสร็จไปพร้อมกันได้ ในเวลาที่จำกัด และเท่าที่จำเป็น

หากเรามัวแต่ไปทำโครงสร้างพื้นฐานของซอฟต์แวร์ เช่น ออกแบบ Framework สุดหรู, สร้าง Library ที่พร้อมใช้ทุกอย่าง แต่แล้วฟีเจอร์ต่างๆ ที่เป็นคุณค่าของซอฟต์แวร์ ไม่เสร็จ หรือเสร็จไม่ครบ แบบนี้ซอฟต์แวร์ของเราจะไปมีค่าอะไร เพราะมันใช้งานไม่ได้ตามที่ลูกค้าต้องการ

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

พัฒนาฟีเจอร์ออกมาเพื่อให้ใช้งานได้ก่อน โดยทำขึ้นมาอย่างง่ายๆ หรือที่เรียกว่า MVP – “Minimum Viable Product” จากนั้นค่อยกลับมาเก็บรายละเอียดให้ดีอีกครั้ง

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

การออกแบบที่ดี และไร้ข้อผิดพลาด (Bug-Free and Well Designed)

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

การมีข้อผิดพลาด (Defect) เกิดขึ้นตอนพัฒนา ซอฟต์แวร์มันทำให้เราประเมินได้ไม่ชัดเจนว่า ตอนนี้งานที่เหลือมีอะไร เพราะอาจสับสนว่าอะไรคืองานที่ต้องทำ อะไรคือ Defect ที่ต้องแก้ แล้วแบบนี้จะเรียกมันว่าเสร็จเพื่อส่งมอบได้ไหมเนี่ย เพราะข้อผิดพลาด (Defect) ทำให้เราประเมินเวลาไม่ได้ ไม่สามารถรู้ได้เลยว่าจะต้องใช้เวลาเท่าไรเพื่อหามัน ต้องแก้มัน และถ้าเราปล่อยไว้ มันก็จะกวนใจเราเรื่อยๆในรอบการทำงานถัดๆไป

ดังนั้น สิ่งที่ควรทำในการทำซอฟต์แวร์ คือ ต้องป้องกัน (Prevent) ไม่ให้เกิดข้อผิดพลาด มากกว่าการมาตามแก้ไขข้อผิดพลาดในภายหลัง (Fix)

สิ่งที่เราจะเริ่มทำคือ ทดสอบระบบด้วยการทดสอบระดับ Business ว่าสามารถใช้งานได้ตามที่ต้องการไหม หรือที่เราเรียกว่า Acceptance Test-Driven Development (ATDD) และค่อยต่อด้วยทดสอบระดับ Technical ด้วยวิธีการต่างๆ

ซอฟต์แวร์ของเราจะใหญ่ขึ้นเรื่อยๆ ตามจำนวนฟีเจอร์ที่เพิ่มและโค้ดที่เขียน ดังนั้นจะใช้เวลาและยากมากที่ต้องทดสอบทั้งหมดทุกครั้งหลังจบรอบการทำงาน (System Test, Integration Test) ดังนั้น ทีมพัฒนาควรทำ Automate Tests ให้ครอบคลุมทั้งระบบงาน หรือออกแบบทำไว้ตั้งแต่ก่อนพัฒนาระบบ หรือที่เรียกกันว่า Test-Driven Development (TDD)

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

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

ดังนั้น ในทุกรอบการทำงาน เพื่อให้ระบบเราสอดคล้องกับฟีเจอร์ใหม่ในรอบนั้นๆ ควรให้ความสำคัญถึงการทำ Refactoring Code ด้วย เพื่อไม่ให้เกิดความยุ่งยากซับซ้อนในรอบทำงานต่อๆไป

Test และ Refactor ทั้งสองอย่างนี้เป็นเรื่องสำคัญของการพัฒนาระบบแบบ Feature-by-Feature เพราะจะทำให้งานเรามีคุณภาพได้ตลอดเวลา เพื่อพร้อมส่งมอบงานให้ลูกค้าได้เสมอ

ส่งท้าย

จากที่สรุปมาให้อ่านทั้งหมด ผมสังเกตได้ว่า ลุง Ron Jeffrie มีคำที่พยายามย้ำอยู่เรื่อยๆไม่กี่คำ คือ คุณค่า (Value), ทีม (Team), การพัฒนาทักษะ (Learn), การทำงานเป็นรอบ (Iteration) และ การทำทีละฟีเจอร์ (Feature-by-Feature), การส่งมอบ (Shipable)

ดังนั้น หัวใจหลักของการพัฒนาแบบ “The Nature Way” ที่ลุง Ron เอามาเสนอ เราต้องให้ความใส่ใจกับคำ 6 คำนี้แหละครับ ส่วนใครอ่านไปแล้วจะคิดต่อหรือหาความรู้เพิ่มเติม จากนั้นเอาไป Adapt & Implement กันอย่างไร ก็คงขึ้นอยู่กับแต่ละวัฒนธรรมองค์กร

ขอให้สนุกครับ

—

ที่มาของเนื้อหาและรูปภาพ จากหนังสือ The Nature of Software Development: Keep It Simple, Make It Valuable, Build It Piece by Piece เขียนโดย Ron Jeffries

2-3 ปีก่อน คุณ  Peter Skillman เคยเล่าในงาน TED ถึงปัญหาด้านการออกแบบ ที่เขาเรียกมันว่า “ปัญหามาสเมลโล (Marshmallow Problem)” ซึ่งคลิปนี้ คุณ Tom Wujec จึงเล่าถึงการนำปัญหานั้นไปทำเป็นเกมส์ในคลาสสัมนาต่างๆ โดยที่เขาเรียกมันว่า “Marshmallow Challenge” หรือ การแข่งขันกันสร้างตึกสูงที่สุดด้วยเส้นสปาเก็ตตี้ 20 เส้น มาร์ชแมลโลว์ 1 ก้อน และเทปกาว เชือก กรรไกร

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

Tom ได้เดินทางไปสอนการเล่นนี้ในหลายๆที่ทั่วโลก และพบว่า กลุ่มที่ทำความสูงได้มากสุด และรูปแบบแปลกตาด้วย ก็คือ “เด็กอนุบาล” (Kindergarten) ส่วนกลุ่มที่ทำความสูงได้ไม่ดีนัก คือ “นักศึกษาบริหารธุรกิจ”

ฟังดูแปลกๆดีนะครับ แต่เขาก็ให้เหตุผลว่า เพราะนักศึกษาบริหารธุรกิจถูกสอนมาให้ทำแผนที่ดีที่สุด จากนั้นค่อยลงมือทำ ซึ่งสิ่งที่เกิดขึ้น นักศึกษาใช้เวลาส่วนมากในการวางแผน ทำโครงสร้าง และเมื่อจะวางมาร์ชแมลโลว์บนยอดสุดก็ตอนที่ใกล้จะหมดเวลาเสียแล้ว… หรือที่เราเรียกว่า “เมื่อถึงเวลาวิกฤต” (It’s in crisis)

ส่วนวิธีการของเด็กอนุบาล คือ พวกเขาลงมือทำเลย โดยปักมาร์ชแมลโลว์ไว้บนสุดเสมอ เมื่อได้ลองทำหลายๆแบบ เขาจะเรียนรู้ไปเรื่อยๆว่า แบบไหนมีข้อดีข้อเสีย แล้วจึงปรับปรุงเป็นแบบใหม่ ทำซ้ำแบบนี้ไปเรื่อยๆ (iterative process)

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

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

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

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

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 อยู่อีกไหม?

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

ก่อนเริ่มทำงานใดๆ ให้เริ่มต้นด้วย
วิธีการคิด 4 ข้อ

1. ทำอะไร
2. ทำอย่างไร
3. ทำเพื่อใคร
4. ทำแล้วได้อะไร

เมื่อคิดวางแผนสิ่งใดได้แล้ว จึงเริ่มทำ ด้วย
6 หลักการในการทำงาน 

1. คิด Macro ทำ Micro
2. ทำเป็นขั้นเป็นตอน
3. ทำเรื่องยากให้เป็นเรื่องง่าย
4. ทำอะไรให้นึกถึงภูมิสังคมของที่นั้นๆ
5. การสื่อความ การประสานงาน และการบูรณาการ (Communication, Coordination, Integration)
6. ทำอะไรต้องมีผู้เป็นเจ้าของ

โดยทั้งหมดนี้ก็มีเพิ่มเติมอีก 3 ข้อ คือ
รู้ – รัก – สามัคคี 

1. รู้ คือ จะทำอะไรต้องไปศึกษาให้รู้จริง
2. รัก คือ จะทำอะไรต้องสร้างฉันทะกับสิ่งนั้นๆ
3. สามัคคี คือ ทำอะไรก็ให้ทำเป็นทีม ร่วมมือร่วมใจกันทำให้มีประสิทธิภาพ

ด้วยความรู้เท่าที่ผมมี ผมรู้สึกว่าพระองค์แนะนำแนวคิดการทำงานเป็นระบบในแบบตะวันตก ผสมกับปรัชญาการมองในตนเองแบบตะวันออกด้วย ซึ่งแนวคิดเป็นระบบ ค่อนข้างเห็นได้ชัดเจน (tangible) ตั้งแต่การทำเป็นขั้นตอน การศึกษาข้อมูล การกำหนดขอบเขตของงานของคน ส่วนนี้ผมคงไม่ขออธิบาย

แต่ในมุมที่เป็นปรัชญาตะวันออก ที่ต้องใช้ใจสัมผัส (intangible) อย่างเช่น ทำเรื่องยากให้เป็นเรื่องง่าย, ทำอะไรให้นึกถึงภูมิสังคมของที่นั้นๆ, การสื่อความ การประสานงาน, รู้ รัก สามัคคี ล้วนเป็นมุมที่ค่อนข้างอธิบายกำหนดเกณฑ์ เช่น คำว่าง่ายคืออะไร ระดับไหนถึงเรียกว่าง่าย..

ผมเห็นหลายคน รวมถึงหลายองค์กรมักจบด้วยการไปหาเกณฑ์จากที่อื่นมากำหนด ซึ่งจริงๆแล้ว สภาพแวดล้อม คน ตนเอง ล้วนต่างกันโดยสิ้นเชิง สุดท้ายอาจพาตนเองหรือองค์กรสบายเกินไป (comfort zone) หรือลำบากเกินไป (courage zone) โดยไม่รู้ประสิทธิภาพตนเอง (performance)

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

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

สุดท้าย ผมอยากเสนอครับ ให้เราเปิดใจมากๆ และเราสร้างมาตรฐานขึ้นมาใช้เอง แล้วก็กล้าๆที่จะใช้ ปรับปรุง ดัดแปลง ให้เหมาะสม เหมือนกับที่พระบาทสมเด็จพระเจ้าอยู่หัวฯ ทรงตรัสไว้ว่า “คิด Macro ทำ Micro” ซึ่งผมเดาว่า น่าจะมีความหมายเดียวกันกับแนวคิด “Agile” ที่กำลังฮิตในปัจจุบัน