อาทิตย์ก่อน ผมมีโอกาสได้ฟังการแชร์ประสบการณ์ของจอมยุทธสองท่าน คนหนึ่งคือ พี่หนุ่ม แห่งสยามชำนาญกิจ ผู้สอน 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 ที่ผมคงไม่ค่อยเห็นได้บ่อยนัก และต้องกลับมาคิดต่อเพื่อถามตัวเอง ว่ามีอะไรบ้างที่ต้องทำ ต้องรู้มากขึ้น เพราะหลังจบวันนั้น รู้สึกตัวเองเล็กกระจิ๊ดเดียว

หนังสือเล่มนี้ใช้ภาษาอ่านไม่ยาก คนทั่วไปอ่านได้ เหมือนกำลังฟังลุง 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

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

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

ในเรือหนึ่งลำจะมีฝีพายอยู่ห้าคน
ฝีพายทำหน้าที่พายส่งเรือให้เคลื่อนที่
มีนายหัวเรือหนึ่งถึงสองคน
เป็นคนดูทิศทาง และวางแผน (Direction and Strategy)
มีนายท้ายเรือหนึ่งคน
เป็นคนคุมหางเสือ ตามทิศที่หัวเรือบอก (Management)

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

ฝีพายดูเหมือนจะสบายที่สุด
แต่เปล่าเลย
ฝีพายเป็นตัวแปรสำคัญ ที่จะทำให้พ้นวิกฤติในแต่ละแก่ง
ยิ่งแก่งแรงมากเท่าไหร่
ฝีพายต้องส่งเรือไปให้แรงที่สุด
เพื่อให้เรือเหินจนพ้นจุดวิกฤติไปได้
เหล่าฝีพายจะทำแบบนั้นได้ก็ต่อเมื่อ
ต้องเรียนรู้วิธีการพายที่ถูกต้องเหมือนกัน (Knowledge, Practice and Experience)
ต้องออกแรงเสมอกัน และจ้วงน้ำที่มีจังหวะพอกัน

และเมื่อเข้าใกล้แก่ง
จะมีคนหนึ่งคอยส่งจังหวะ
เพื่อให้ฝีพายทุกคนจ้วงน้ำพร้อมกัน
เมื่อกระทบคลื่น ไม่ว่าใครจะหกคะเมนตีลังกาอยู่บนเรือ
ก็ต้องรีบกลับเข้าตำแหน่ง แล้วจ้วงต่อเพื่อให้เรือไม่เสียการทรงตัว

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

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

ตั้งใจจะเขียนเรื่องล่องแก่ง
แต่พอใส่ภาษาอังกฤษเข้าไปเท่านั้นแหละ
ผมว่าการล่องแก่ง เป็นการละลายพฤติกรรม
และสอนเรื่อง Team Work ได้ดีกว่าไป Outing
ที่เล่นเกมส์บ้าๆบ้อๆ อะไรก็ไม่รู้อีกนะ…

ปล. ก่อนจะกระโจนเข้าใส่ โปรดศึกษาข้อมูลและสภาพร่างกายให้ดีก่อนการตัดสินใจ ตกน้ำตกท่า เป็นอะไรขึ้นมา เดี๋ยวผมจะซวย ฮ่าาา

—-
กรุงเทพ
23 Jul 2016

ผมพบว่าปัญหานี้อยู่รอบตัวเรา และผลกระทบมันก็มีอยู่ แต่ต่างกันแค่ระยะเวลาที่ใช้ กับความสำคัญของเรื่องที่จะต้องตัดสินใจ ถ้าในระดับชาติ อาจยกตัวอย่างได้ว่า ประชาชนต้องการให้รัฐบาลป้องกันน้ำที่กำลังไหล่บ่ามาท่วมชุมชนของพวกเขา แต่รัฐบาลและนักวิชาการกำลังทะเลาะกันเรื่องทฤษฎีป้องกันน้ำ เช่น จะใช้ถุง Big Bag หรือ น้ำดันน้ำ อะไรก็ว่ากันไป กว่าจะตัดสินใจได้ ประชาชนก็จทน้ำไปเรียบร้อยแล้ว หรือเรื่องบางเรื่องก็ถูกยืดเยื้อไว้ หรือภาษาชาวบ้านเรียกว่าการดอง เช่น การสร้างถนนในบางเส้น ที่อาจไปทับที่ของผู้ใหญ่หรือทับที่ป่าบางส่วน จะลุยต่อก็เจ็บตัว จะไม่ทำก็โกงกินไม่ได้ สุดท้าย ก็ดองไว้เหมือนเดิม (อาจจะอีกตัวคือโฮปเวล) ซึ่งผมว่าประเทศเราเห็นชัดเจน เพราะด้านหนึ่งหลังชนฝาเรื่องโกงกินจึงจำเป็นต้องสร้าง แต่อีกด้านหนึ่งเจอการขัดขาเพราะจับได้หรืออะไรก็ว่าไป แล้วก็เกิดการดองเกิดขึ้น

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

ต่อให้มี Decision making theory, Change Management, Risk managment หรืออะไรก็ตามที่ช่วยทำให้วางแผนวิเคราะห์กับสิ่งที่จะเกิดในการตัดสินใจในแต่ละอย่าง สุดท้ายแล้ว เมื่ออยู่ในโลกความเป็นจริง และกับคนหมู่มากที่ล้วนมีอำนาจ มีเงิน เชื่อมั่นในตัวเองสูง ทุกอย่างที่กล่าวมาอาจถูกมองข้ามไป

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

แต่ทั้งนี้ทั้งนั้นผมก็ไม่ได้บอกให้รีบด่วนตัดสินใจ หรือให้ไม่ต้องคิดมากเพื่อจะตัดสินใจนะ เพียงแค่อยากให้เข้าใจว่า “ไม่มีอะไร perfect แต่ก็ต้องมีแผนรับมือกับความบกพร่อง”

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