แปลเนื้อหามาจาก scrumprimer.org เพื่อให้คนไทยอ่านทำความเข้าใจเรื่อง scrum ที่เป็น framework หนึ่งของ agile ได้ง่าย และเร็วขึ้น

เจ๋งกว่า Traditional Development

ขออธิบายเรื่อง Traditional development ก่อน คือมักจะมีปัญหาเรื่องส่งงานไม่ตรงเวลา หรือ การตอบสนองต่อการเปลี่ยนแปลงที่ช้าเกินไป มีการคาดการณ์ล่วงหน้าที่มากเกินไป (ซึ่งเป็นข้อเสีย) และขั้นตอนการทำงาน ตั้งแต่การ plan จนถึง test ใช้ไม่ได้กับในยุคปัจจุบันที่ความเปลี่ยนแปลงเป็นไปอย่างรวดเร็ว เพราะว่ามัน มี feed back ช้า และเก็บข้อมูลจากประสบการณ์การใช้งานจริงช้าเกินไป อีกทั้งทำให้คืนทุนยาก เนื่องจากกว่า software จะเสร็จโลกเราก็เปลี่ยนไปมากแล้ว เหตุก็มาจากการที่มองไม่เห็นภาพรวม และภาพจริง มองไม่เห็นว่าอะไรที่ต้องปรับปรุง ไม่มีความยืดหยุ่น แถมยังสร้างความเสี่ยงทั้งทาง technical และ business อีกต่างหาก

จริงๆมันมีทางออก ก็คือ การมีทีมที่ทำงานได้หลายอย่าง (cross functional) บวก การทำงานที่เป็นรอบระยะเวลาสั้น เพื่อให้ส่งมอบงานได้เร็ว ซึ่งมันเป็นสิ่งที่มีมานานมากแล้ว แต่ว่าไม่ได้รับความนิยมเหมือนอย่าง traditional model เท่านั้นเอง

Scrum packages ได้ผ่านมาพิสูจน์มาแล้ว ว่าเป็น concept การพัฒนา software ที่เรียบง่ายมาก ประกอบไปด้วย ทีมที่ทำงานแทนกันได้ ทำงานได้หลากหลาย, มีความสามารถในการบริหารจัดการตัวเองได้, ทำงานด้วยรอบการพัฒนาสั้นๆและ feedback ได้อย่างรวดเร็ว, พร้อมรับความเปลี่ยนแปลงได้ โดย concept นี้จะช่วยเพิ่มความคล่องตัวในการทำงานและการ feed back ทั้งยังทำให้เริ่มคืนทุนได้อย่างเร็ว และลดความเสี่ยงได้อีกด้วย

Scrum คืออะไร

Scrum เป็น development framework ที่คาดหวังว่าต้องมี cross-functional team (ทีมงานที่ทำงานได้มากกว่าหนึ่งอย่าง หรืองานมากกว่าหนึ่งแบบ) ที่พัฒนา software/project เป็นรอบๆ เพื่อให้เนื้องานที่ออกมาเพิ่มขึ้นเรื่อยๆ โดยมีรูปแบบการทำงานเป็นวงรอบเรียกว่า Sprint ซึ่งมีข้อกำหนดให้วงรอบต้องไม่นานเกินกว่า 4 สัปดาห์ (โดยทั่วไปอยู่ที่ 2 สัปดาห์) ทำงานต่อเนื่องไม่มีการพักระหว่างรอบ sprint หรือมองว่า Sprint มันคือ timebox (คาบเวลา) ที่มีกำหนดวันจบเอาไว้อย่างชัดเจนเพื่อให้ปริมาณงานอ้างอิงได้ว่าทำงานได้จนจบหรือไม่เมื่อหมดคาบเวลานั้น โดยไม่มีการต่อคาบเวลาออกไปเป็นอันขาด เรามักจะเริ่มต้นด้วยช่วงเวลาประมาณหนึ่ง เช่น 2 สัปดาห์ แล้วใช้กันไปสักพักจนกว่าเราจะสามารถพัฒนาและปรับตัวได้ ถึงจะมีการลดเวลาใน sprint ลงเพื่อให้ได้งานออกมาที่เร็วขึ้น

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

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

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

ช่วงท้ายของ sprint ทีมจะมารีวิวงานร่วมกับ stakeholders (ตัวแทนลูกค้า,sale,AE) และโชว์ของว่าทำอะไรขึ้นมาให้เห็นบ้าง จากนั้น ก็จะมีการให้ความเห็น comment เพื่อใช้ในการปรับปรุงการทำงานของ sprint ถัดไป

Scrum จะเน้นที่ผลลัพท์ของเนื้องาน ที่เราเรียกว่า “เสร็จ” ถ้าหากเป็น software ก็คือ ระบบที่ทำงานได้ ทดสอบผ่านแล้วเรียบร้อย มีเอกสารประกอบการใช้งาน และสามารถ launch ได้(หรือพอที่จะเอาไปให้ลองใช้งานได้)

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

หน้าที่ต่างๆใน Scrum

หลักๆแล้ว จะมี 3 หน้าที่คือ Product Owner(PO), Team และ Scrum Master ทั้งหมดเรียกรวมกันว่า scrum team

Product Owner

ทำหน้าที่ สร้าง return on investiment (ROI) หรือทำให้คืนทุนให้เร็วทึ่สุด โดยจะทำหน้าที่กำหนด feature จัดเรียงความสำคัญของชิ้นงานทั้งหมด ตัดสินใจว่า งานไหนจะต้องทำก่อนหลังสำหรับ sprint ถัดไป รวมทั้งต้อง ตรวจสอบความสำคัญของงาน และปรับปรุงให้เหมาะสมกับสถานการณ์อย่างต่อเนื่องอีกด้วย

PO ต้องเป็นคนที่มีส่วนได้ส่วนเสียงาน product นั้นๆ แต่บางกรณีถ้าเป็นงานที่พัฒนาสำหรับใช้กันภายใน แม้ว่า PO ไม่ต้องรับผิดชอบกับ ROI ก็จริง แต่ก็ต้องรับผิดชอบกับสิ่งที่ได้จัดความสำคัญให้กับทีมงานได้ทำว่ามันมีความสำคัญมากหรือน้อยอย่างไรในทุกๆ sprint

การจัดเรียง เรามักจะจัดตาม “มูลค่า” ของงานนั้นๆ ซึ่ง คำว่ามูลค่า มันก็จะแตกต่างกันไปตามแต่ละงาน แต่ละ product แต่ทั่วๆไป มันจะเกี่ยวข้องกับความพึงพอใจของลูกค้า, เป้าหมาย, กลยุทธ์, ความเสี่ยงที่มากระทบ หรือ อื่นๆ บางกรณี PO กับลูกค้าอาจจะเป็นคนเดียวกันเลยได้ ซึ่งจะใช้ในกรณีระบบที่ใช้ภายใน แต่บางกรณี ลูกค้า ก็อาจจะหมายถึงคนเป็นล้านๆคนที่มีความต้องการแตกต่างกันมากมายไปหมด โดยอาจจะมองได้ว่า PO ก็คล้ายกับ Product Manager (PM) หรือ Product Marketing Manager (PMM) ในหลายๆบริษัทที่มีอยู่แล้วนั่นแหล่ะ แต่… PO แตกต่างจาก PM ที่เรารู้จักกัน ในประเด็น การทำงานร่วมกับทีม การจัดเรียงความสำคัญโดยประสานกับลูกค้าอย่างใกล้ชิด และการรีวิวงานที่ได้มาจากแต่ละ sprint นั่นเอง ที่ทำมากกว่าการส่งงานต่อเหมือนอย่างที่ PM ทำ

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

The Team (หรือเรียกว่า development team)

ทำหน้าที่ทำงานตามที่ PO สั่งมา โดยทีมจะเป็น “cross-functional” ก็คือทำงานได้หลากหลายแบบ ปกติควรจะประกอบด้วยคนที่มีความสามารถในด้านต่าง ที่สามารถตอบโจทย์ต่องานที่ต้องทำได้ และทำ”เสร็จ” แบบ “เป็นชิ้นเป็นอัน” ในแต่ละ sprint รวมทั้งสามารถ บริหารจัดการตัวเองได้ (self-organize, self-management) ซึ่งก็ต้องดูแลตัวเองได้ และ มีความรับผิดชอบเป็นคุณสมบัติที่ติดตัวของแต่ละคน โดยทีมจะเป็นคนกำหนดได้ว่าสามารถทำอะไรได้มากน้อยเท่าไรในแต่ละ sprint (เลือกมาจากสิ่งที่ PO ได้เรียงมาก่อนแล้ว) และทำอย่างไรที่จะไปให้ถึงเป้าหมายร่วมกัน

แต่ละคนในทีม จะเรียกว่า team member อ้อ มีสิ่งหนึ่งที่ต้องรู้ก็คือ ไม่มีชื่อตำแหน่งในแต่ละกลุ่มของ scrum เช่น ไม่มี Business Analyst , ไม่มี DBA, ไม่มี architect, ไม่มี team lead, ไม่มี UX designer, ไม่มี programmer บลาๆๆๆ เพราะว่าเป้าหมายมีแค่ว่า ทำอย่างไร ยังไงก็ได้ เพื่อให้งานเสร็จได้อย่างที่ได้ตกลงกัน

ดังนั้น ก็เลยมีแต่ team member ที่ไม่ได้แค่ต้อง cross-functional เท่านั้น แต่ต้องแสดงให้เห็นถึง การเรียนรู้ที่หลากหลายด้าน แม้ว่าแต่ละคนก็จะมีเรื่องที่ตัวเองเชี่ยวชาญเป็นพิเศษ แต่ก็ต้องเรียนรู้เรื่องอื่นๆด้วย ซึ่งแต่ละคนอาจจะมีความสามารถทาง 1 , 2 หรือสามด้านก็ได้ ซึ่งนั่นจะทำให้การทำงานเป็นอิสระและคล่องตัวมากขึ้นอีกด้วย เช่น คนที่เก่งเรื่องการออกแบบหน้าจอสำหรับผู้ใช้ สามารถมี skill รองก็คือ การทำ automate testing ได้ หรือบางคนที่เก่งเรื่องการเขียนเอกสารประกอบ ก็อาจจะช่วยเรื่องการ analysis กับ programming ก็ได้

จำนวนคนในทีม จะอยู่ที่ 7 คน มากหรือน้อยกว่านี้ไม่ควรเกิน 2 คน ตัวอย่าง กรณี product ที่เป็น software ทีมอาจจะมีคนที่เก่งเรื่อง analysis , development, testing, interface design, database design, architecture, documentation และอื่นๆ

The Team จะต้องสร้าง product และให้ idea ให้กับ PO ได้ว่าจะทำอย่างไรให้ออกมาดูดีที่สุด , ใน Scrum จะให้ประสิทธิภาพจากการทำงานได้มากที่สุด ถ้าสามารถให้ทีมทุ่มเททำงานเดียวได้ในแต่ละ sprint ไม่ควรทำให้ multi tasking ข้าม product หรือ project เพื่อลด cost of switching และทีมที่ลงตัวแล้ว จะสร้าง productivity ที่สูงมากดังนั้น ไม่ควรเปลี่ยน team member ถ้าไม่จำเป็น

สำหรับ Product group ที่ประกอบมาจาก ทีมหลายๆทีม แต่ละทีม ควรจะ focus feature ที่แตกต่างกัน โดยยังต้องให้ประสานงานแลกเปลี่ยนกันอย่างต่อเนื่อง ทั้งนี้ หากทีมไหนที่สามารถทำงานได้จบในทีมเดียวเลย ก็คือ ทำได้ทั้ง planning, analysis, programming และ testing เพื่อตอบความต้องการของลูกค้าในแต่ละงานได้ เราจะเรียกว่า “feature team”

The ScrumMaster

ทำหน้าที่ช่วยสอน และพยายามปรับเอา Scrum เข้ามาใช้เพื่อให้ตอบสนองต่อ Business Value โดยจะทำอะไรก็ตาม เพื่อช่วยเหลือ Team, PO, องค์กร ให้ประสบความสำเร็จให้ได้

ScrumMaster ไม่ใช่ lead team หรือหัวหน้าทีม ไม่ใช่ตัวแทนของทีม หรือ project manager ที่ถูกต้องก็คือ ScrumMaster ทำหน้าที่ช่วยเหลือ และบริการทีมต่างหาก ก็จะคล้ายๆเป็น assistant/consult ของทีมด้วยซ้ำ หรือทำยังไงก็ได้ เพื่อ ลดสิ่งที่เข้ามารบกวน, ป้องกันทีมจากสิ่งที่จะมากระทบรอบๆตัวทั้งหมด และช่วยทีมสร้างแนวทางการทำงานที่ดีและถูกต้องอย่างที่ควรจะต้องเป็น โดยจะทำหน้าที่ สอน,โค้ช หรือแนะนำ PO, Team รวมไปถึงคนในองค์กร เพื่อให้มั่นใจได้ว่า ทุกๆคนในองค์กร ที่หมายรวมถึง PO และ management เข้าใจ หลักการณ์ และ แนวทางของ scrum รวมทั้งยังทำหน้าที่ปรับองค์กรไปสู่ความสำเร็จใน agile development ในขณะที่ก็ต้องป้องกันการขัดขวางจากสิ่งที่จะเข้ามากระทบ ไม่ว่าจะเข้ามากระทบต่อทีมหรือ PO ก็ตาม หรือทำให้เค้าเข้าใจและเลิกเข้ามายุ่งก็ได้เหมือนกัน นี่เป็นเรื่องสำคัญมาก ที่ ScrumMaster จะต้องตั้งใจทำ หรือ ทำอะไรก็เพื่อ ให้ ทีม หรือ PO ก้าวผ่านความยุ่งยากไปสู่ความสำเร็จให้ได้ โดยควรจะต้องมีคนที่ถูกกำหนดให้ทำหน้าที่ ScrumMaster โดยเฉพาะ แม้ว่าทีมทำงานจะมีขนาดเล็ก (หรือตอนที่เริ่มทำ scrum ที่ตัดทีมมาขนาดเล็กๆ เพื่อดูแลงานเล็กๆก็ตาม) ScrumMaster ที่เก่ง ต้องทำได้ดีในหลายอย่าง ไม่ว่าจะเป็น Engineering, Design, Testing, Product Management, Project Management แม้กระทั่ง Quality management

The ScrumMaster และ PO ไม่ควรเป็นคนเดียวกัน เพราะว่าแต่ละคนมีหน้าที่และเป้าหมายที่แตกต่างกัน การรวมเข้ามาเป็นคนเดียวกันจะทำให้เกิดความสับสน และ conflict ในการทำงาน สิ่งหนึ่งที่จะเจอได้ เมื่อรวมเป็นคนเดียวกัน ก็คือ micro-management ของ PO จะเป็นสิ่งที่ตรงกันข้ามกับ self-management ของ Team ซึ่ง ผลก็คือ คนนึงจะดูแลตัวเอง อีกคนจะพยายามไปยุ่มย่ามดูแลคนอื่น (เพราะ PO จะพยายามเอา micro-management ไปหักล้างการทำงานของ Team ในจังหวะที่ตัวเองแสดงตนเป็น scrum master) และนี่คือสิ่งที่แตกต่างจาก traditional manager โดยปกติ ScrumMaster ต้องไม่เป็นคนบอกคนอื่นให้ทำงาน หรือ สั่งงาน แต่จะต้องทำหน้าที่ในการสร้างกระบวนการทำงาน บริการ Team และพยายามสร้าง Team ให้บริหารงานด้วยตัวเองให้ได้ ถ้า ScrumMaster เคยทำหน้าที่บริหารทีมนั้นๆมาก่อน ก็จะต้องเปลี่ยนตัวเองนิดหนึ่ง เปลี่ยน mindset อีกหน่อยหนึ่ง เพื่อให้การทำงานเป็นไปอย่างที่ Scrum อยากให้เป็น

ทั้งนี้ ไม่มีตำแหน่ง Project manager ใน Scrum เพราะว่าไม่ได้มีส่วนไหนที่ต้องการ แต่ถ้ามี ก็จะต้องเปลี่ยนไปเป็นหนึ่งในสาม role อย่างที่เล่ามาแล้วข้างต้น แต่โดยทั่วไป ก็จะเป็น Team หรือไม่ก็ PO แต่ไม่ใช่ ScrumMaster เพราะว่า การที่ให้เป็น ScrumMaster แล้วสอนทีม ด้วยความรู้แบบ project manager จะทำให้เกิดความผิดพลาดตามมา ไม่ว่าจะเป็น เข้าใจ Scrum ผิดไปจากแนวทางที่ถูกต้อง,ผลการทำงานที่ขัดแย้งไปมา, ไม่แน่ชัดในอำนาจและหน้าที่ และอื่นๆ ที่จะประหลาดๆ แต่ บางครั้งคนที่เป็น project manager ก็อาจจะเป็น ScrumMaster ได้ แต่มันยากมากที่จะทำให้มั่นใจได้ว่า เค้าเปลี่ยนการทำงาน และกระบวนการคิดจากแบบเดิมๆมาเป็นแบบที่ถูกต้องได้ เพราะว่าต้องเปลี่ยนตัวเองหลายอย่าง ต้องปรับแนวทางการทำงานแบบ scrum อีกเยอะ รวมถึงการทำความเข้าใจและแยกแยะได้ว่า ทั้ง 2 role ทำงานต่างกันอย่างไร สิ่งที่จะเริ่มต้น และทำให้ถูกต้องได้ก็คือ ไปลงเรียน Scrum Alliance’s Certified ScrumMaster และสอบ Cert ให้ผ่านซะ ก็พอจะช่วยได้ในกรณีนี้

สิ่งที่นอกเหนือจาก 3 Role ที่กล่าวมาแล้วนี้ ก็จะมี stakeholder ที่จะช่วยสนับสนุนให้ ประสบความสำเร็จในหลายด้าน ไม่ว่าจะเป็นทั้ง product , manager , customer , end user โดย stakeholder บางคน ที่อาจจะเคยทำ functional manager อาจจะต้องเปลี่ยนแนวทางการคิด หรือทำ เพื่อให้เข้ากับ Scrum เช่น
– ช่วย support team โดยเคารพ แนวทาง และ ขั้นตอนปฏิบัติของ Scrum
– ช่วยลดสิ่งที่เข้ามากระทบ ไม่ว่าจะต่อ Team และ PO
– ช่วยให้คำแนะนำ และ บอกเล่าประสบการณ์

ใน scrum จะเปลี่ยนรูปแบบการทำงานแบบเก่า ซึ่งเรียกว่า “nanny” พี่เลี้ยง (สั่งงานให้คนทำงาน, ตรวจดูสถานะความคืบหน้าของงาน รวมทั้ง micro management ต่างๆ) ให้มาเป็น “guru” ผู้รู้ หรือ “servant” คนรับใช้ ของ Team (ให้คำแนะนำ, สอน, ป้องกันสิ่งรบกวน,ช่วยแก้ปัญหา,ให้ทักษะการบวนการคิด หรือ สอน skill development ให้กับสมาชิกในทีม) ในกระบวนการเปลี่ยนครั้งนี้ manager อาจจะต้องเปลี่ยนกระบวนการบริหารหลายอย่าง เช่น ตั้งคำถาม เพื่อให้ทีมไปหาแนวทางที่จะแก้ปัญหาออกมาให้ได้ มากกว่าที่จะเป็นคนนั่งสอนว่า ปัญหาแต่ละเรื่องจะต้องแก้อย่างไร

วันนี้ก็ได้ทำความรู้จัก PO , Scrum Master , The Team แล้ว เดี๋ยวพรุ่งนี้ จะเล่าเรื่อง Product Backlog ต่อ ซึ่งถือว่าเป็นจุดร่วมของ Scrum เลยล่ะ ถ้าอยากอ่านทั้งหมดที่แปลของ scrumprimer คลิกที่ tag ‘scrumprimer’ ที่ด้านล่างได้เลยนะครับ