ที่มาของ scrum
Scrum in Research?
ทำรีเสิร์ชว่องไว โดยใช้ Scrum Framework (ได้รึเปล่า?)
ตอนที่ 1 Scrum มันคืออิหยังวะ?
หากคุณเป็นคนคร่ำหวอดในวงการซอฟต์แวร์ ธุรกิจ หรือ Startup ก็คนคงจะคุ้นเคยกับคำว่า Scrum ซึ่งเป็น framework ในการบริหารทีมเพื่อเพิ่มประสิทธิภาพการทำงานอย่างสูงสุด มาบ้างแล้ว แต่หากคุณเป็นนักวิชาการก้นแล็บอย่างแอด ก็อาจจะได้แค่เกาเหม่งอย่างงงๆ
แอดสารภาพเลยว่า เคยได้ยินคำว่า Scrum มานานแล้ว แต่คิดมาตลอดว่ามันเป็นหนึ่งใน buzzword ที่พวก Startup เค้าใช้กัน และมันคงใช้อะไรไม่ได้กับวงการวิจัยที่ธรรมชาติของงานนั้นคาดการณ์ได้ยาก
แต่เมื่อไม่นานมานี้ วารสาร Nature เขียนบทความเรื่องการใช้ Scrum ในการบริหารกลุ่มวิจัยในมหาลัย [1] จึงจุดประกายให้แอดเกิดความสนใจที่จะหาความรู้ขึ้นมาอย่างจริงๆจังๆเสียที ว่าไอเจ้า Framework นี้มันคืออะไรกันแน่ แล้วทำไมใครๆก็บอกว่ามันสามารถเพิ่มประสิทธิภาพในการทำงานของทีมหลายเท่าทวิคูณ
การทำงานโดยใช้ Scrum นี้มีท่ีมาจากงานวิจัยของศาตราจารย์ชาวญี่ปุ่น Hirotaka Takeuchi และ Ikujiro Nonaka ตั้งแต่ปี 1986 ซึ่งศึกษาเบื้องหลังความสำเร็จของอุตสาหกรรมหนักในญี่ปุ่น โดยเฉพาะ Toyota ซึ่งเป็นบริษัทที่มีสามารถประกอบรถได้รวดเร็วและปัญหาน้อยกว่าบริษัทตะวันตกหลายเท่าตัว อาจารย์ทั้งสองเสนอว่า การทำงานของ Toyota นั้นมีลักษณะคล้ายๆกับทีมรักบี้ ที่พนักงานทุกคนรับผิดชอบในผลงานร่วมกันไม่เกี่ยงว่าใครต้องทำหน้าที่เฉพาะอะไร หรือใครเป็นนายเป็นลูกน้อง ไม่สักแต่ว่าทำของตัวเองเสร็จแล้ววางมือ แต่ต่างช่วยกันสอดส่องดูแลงาน ทำให้งานสำเร็จลุล่วงไปได้อย่างรวดเร็ว อาจารย์จึงเรียกวิธีการทำงานแบบนี้ว่า Scrum ซึ่งเป็นศัพท์ของกีฬารักบี้ [2]
ไอเดียนี้ถูกนำมาต่อยอดให้เกิดเป็นระบบการทำงานที่ชัดเจนขึ้นโดย Jeff Sutherland และ Ken Schwaber และนำไปใช้พัฒนาวงการ software developer จนสามารถเพิ่มประสิทธิภาพในการสร้างสรรค์ซอฟต์แวร์ใหม่ๆอย่างก้าวกระโดด กลายเป็น framework ที่สำคัญของวงการ IT และยังลามไปถึงวงการอื่นๆ จนถูกนำไปประยุกต์ใช้ในบริษัทใหญ่ๆหลายบริษัท เช่น Adobe, AMD, American Express, BBC, CNN, Google, IBM, Microsoft, Nokia, ฯลฯ [3]
Scrum นั้น ถูกคิดค้นขึ้นเพื่อฉีกกฎการวางแผนงานแบบ “Waterfall” ซึ่งก็คือการวางแผนงานแบบเป็นสายพาน มีหัวหน้างานที่สั่งงาน ทีมแต่ละทีมรับผิดชอบเฉพาะงานของตัวเองให้เสร็จ แล้วก็โยนให้ทีมถัดไปจัดการต่อกันไปเป็นทอดๆ เช่น ถ้าบริษัทต้องการพัฒนาซอฟต์แวร์ใหม่ ทีม developer ทำหน้าที่พัฒนาโค้ดจนเสร็จ ส่งต่อให้ทีมต่อไปทดสอบโปรดักส์ ทดสอบเสร็จแล้วก็หมดหน้าที่ จึงส่งต่อให้ทีมขายนำไปขายลูกค้า ปรากฎว่าผลลัพธ์ส่วนใหญ่ของการวางแผนแบบนี้คือ ขายไม่ได้ เพราะว่างานมักจะไม่ตอบโจทย์ความต้องการของลูกค้า หรือไม่ก็ใช้เวลาพัฒนาสินค้านานเกินไป กว่าจะทำเสร็จ ลูกค้าก็ไม่อยากได้แล้ว ทำให้เวลาของทีม กว่า 80% สูญไปกับการทำงานที่ไม่ได้ผลลัพธ์
หลักการของ Scrum คือการสร้างทีมขนาดเล็ก (ไม่เกิน 10 คน) ที่มีความคล่องตัวสูง และต้องมีลักษณะสำคัญ 4 อย่าง คือ “มุ่งเป้า” “เชี่ยวชาญ” “อิสระ” และ “โปร่งใส”
“มุ่งเป้า” คือ การที่ทั้งทีมทำงานเพื่อจุดมุ่งหมายเดียวกัน ไม่ได้รังแต่จะสร้างความก้าวหน้าให้ตัวเอง แต่คำนึงถึงเป้าหมายร่วมของทีมเป็นสูงสุด ผลงานที่ดีนั้นไม่ได้เกิดจากสมาชิกคนใดคนหนึ่ง แต่มาจากความร่วมมือกันของทุกคน
“เชี่ยวชาญ” สมาชิกในทีมจะต้องสามารถทำหน้าที่ได้ครบถ้วนและครอบคลุมถึงตั้งแต่ต้นจนจบงาน และสามารถทำงานแทนกันได้ถ้าจำเป็น ซึ่งแปลว่าทุกคนจะต้องรู้และเข้าใจหน้าที่ของทั้งตนเองและสมาชิกในทีม
“อิสระ” นั้นหมายถึงทุกคนทำงานได้โดยไม่ต้องรอรับคำสั่ง ไม่ต้องรออนุมัติ เพราะทุกคนรู้หน้าที่ของตัวเองเป็นอย่างดี การลด middle management ลง นำไปสู่การทำงานเอกสารไร้สาระที่น้อยลง จึงเพิ่มประสิทธิภาพในการทำงานขึ้นอย่างชัดเจน
“โปร่งใส” ทุกคนรู้ว่าสมาชิกต้องทำอะไร ก้าวหน้าไปถึงไหนแล้ว และได้ผลอย่างไร การเปิดเผยข้อมูลอย่างโปร่งใสเป็นการลดคอรัปชั่น ลดการเล่นพรรคเล่นพวกในระบบ เมื่อระบบสามารถตอบแทนคนได้อย่างเป็นธรรม ทำให้คนมีกำลังใจในการทำงานขึ้น จึงพลอยไปเพิ่มประสิทธิภาพในการทำงานด้วย
เพื่อสร้างทีมให้มีลักษณะเชิงนามธรรม 4 ข้อข้างต้น Scrum จึงออกแบบ framework ภาคปฎิบัติไว้ดังนี้
1. ก่อนเริ่มโครงการ ทุกคนรวมตัวกันในที่ประชุมเพื่อทำความเข้าใจเกี่ยวกับเป้าหมายของงานให้ตรงกัน หลักสำคัญที่สุดของ Scrum คือทุกคนที่เกี่ยวข้องต้องช่วยกันวางแผนการทำงาน เพราะทุกคนมีส่วนร่วมในการสร้างความสำเร็จของทีม จากนั้นเลือกสมาชิกในทีม 1 คน เป็น Product owner ผู้ทำหน้าที่คอยดูแลให้ผลงานออกไปในทิศทางที่ตกลงกัน และ อีก 1 คนเป็น Scrum Master ผู้ดูแลติดตามให้งานดำเนินไปตามแผน และลูกทีมทุกคนที่เหลือเป็นผู้ดำเนินงานทั่วไป
2. สร้าง Product Backlog หรือลิสต์ของงานที่ต้องทำเพื่อให้โครงการประสบความสำเร็จ และเรียงลำดับตามความสำคัญจาก “มากไปน้อย” ข้อนี้สำคัญมาก ทีมที่ไม่รู้จัก prioritize งาน มักจะเสียเวลาไปกับการแก้ปัญหาที่ไม่ได้สลักสำคัญ ทีมต้องแสดงความเป็นไปได้ของ feature หลักของงานก่อน แล้วค่อยแก้ feature รองที่ตามมา
3. ประเมิน Load งาน ซึงคือเวลาที่ต้องใช้ในการทำงานแต่ละข้อ การประเมิน load เป็นค่าสัมบูรณ์นั้นยาก แต่ประเมินเป็นค่า relative นั้นง่าย ดังนั้น เราอาจจะให้งานแต่ละข้อเป็นเลขใน Fibonacci series เช่น 1, 2, 3, 5, 8, 13, … งานไหนที่ว่ายาก ก็เอาค่าสูงๆไป หรือง่ายทำได้แป๊บเดียว ก็เอาค่าต่ำๆไป งานที่สำคัญที่สุด อาจจะไม่ใช่งานที่ยากที่สุดเสมอไป
4. รวบงานที่ลิสต์ไว้แล้วแบ่งเป็นกลุ่ม ทีมจะไม่พยายามทำงานทั้งหมดพร้อมๆกัน แต่จะเลือกทำงานที่สำคัญที่สุดส่วนหนึ่งในระยะเวลาจำกัดก่อน เช่น ตั้งเป้าที่จะทำงานข้อที่ 1-3 ใน 1 เดือน ช่วงงานแบบนี้เรียกว่า Sprint โดยเป้าหมายแต่ละ Sprint คือทีมจะต้องมีผลงานที่จับต้องได้ วัดผลได้ ผลงานที่ได้ไม่ต้องเลิศเลอเหมือนเตรียมส่งลูกค้า แต่ต้องเป็นผลงานที่ใช้งานได้ในระดับต้น เพื่อให้ทั้งทีมและลูกค้าสามารถให้ feedback กับทิศทางของงานได้ ผลงานแบบนี้เรียกว่า Minimal Viable Product (MVP)
5. ระหว่างการทำงาน ทีมจะต้องมีการตอกบัตรรายงานให้ทุกคนในทีมทราบว่าตัวเองทำอะไรไปแล้ว กำลังจะทำอะไร และมีปัญหาอะไรไหม โดยต้นแบบของ Scrum ในวงการซอฟต์แวร์นั้น การตอกบัตรหรือ Daily Scrum นี้ควรเกิดขึ้นทุกวัน แต่ประชุมแค่สั้นๆ ไม่เกิน 15 นาที การประชุมนี้ทำให้ทีมรับรู้ปัญหาที่เกิดขึ้นได้รายวัน และสามารถแก้ปัญหาได้ทันท่วงที ไม่ปล่อยให้คาราคาซัง ทำให้งานเดินต่อไปได้อย่างรวดเร็ว
6. พอครบ Sprint แล้วก็มานั่งรีวิวกัน เพื่อหาข้อสรุปว่างานที่ทำไปเป็นไปตามแผนที่วางไว้ตั้งแต่แรกหรือไม่ MVP มี feedback อย่างไร ระบบการทำงานมีข้อขาดตกบกพร่องอะไรไหม และต้องมีการแก้แผนงานใหม่หรือไม่ แล้ว load งานที่สามารถทำได้ในแต่ละ Sprint คือเท่าไร ค่า load ที่ทำได้ต่อ Sprint นั้นทำให้เราสามารถคะเนความเร็วในการทำงานของทีมของเราได้ และสามารถประมาณการณ์ได้ว่างานเราจะเสร็จจริงๆเมื่อไร
7. นำข้อสรุปที่ได้จาก Sprint ก่อน ไปเป็นข้อมูลในการพัฒนา Sprint ใหม่ แล้ววนลูป ข้อ 4 ใหม่ต่อไปจนกว่างานจะเสร็จ ยิ่ง Sprint มากเท่าไร load งานก็จะเหลือน้อยลง และสามารถคำนวณเวลาที่จะทำงานเสร็จได้อย่างเที่ยงตรงมากขึ้น จนสุดท้าย ทีมมักจะพบว่าสามารถทำงานได้อย่างมีประสิทธิภาพเพิ่มขึ้นมากกว่าการทำงานแบบเดิมๆ หลายเท่าตัว
อ่านดูแล้วก็จะพบว่า ไอเดียของ Scrum นั้นไม่ได้ซับซ้อนมาก และมีลักษณะ Iterative จึงดูน่าจะเหมาะกับงานวิจัยต่างจากการวางแผนแบบ Waterfall (ผ่าน Gantt chart) แต่หากจะนำ framework แบบนี้มาใช้กับวงการวิจัยบ้าง จะต้องมีการแก้ไขอย่างไรบ้าง แอดจะเขียนต่อในตอนต่อไปละกัน
มีใครลองใช้ Scrum ในรีเสิร์ชแล้วบ้าง มาเล่าสู่กันฟังบ้างนะ
ตอน 2: https://www.facebook.com/…/a.164033331039…/424270941682445/…
#นักวิจัยไส้แห้ง
[1] Pirro, L. How agile project management can work for your research, Nature Career Column, 2019 https://www.nature.com/articles/d41586-019-01184-9
[2] Sutherland, J. Scrum: The Art of Doing Twice the Work in Half the Time (Random House Business, 2015).
[3] Firms using Scrum
https://docs.google.com/…/1fm15YSM7yzHl6IKtWZOMJ5vHW9…/edit…
รูป flow diagram จาก devbridge.com
business flow chart 在 Business processes — Flow charts - Pinterest 的推薦與評價
Apr 4, 2014 - The examples of business process diagrams - flow charts are drawn using the ConceptDraw DIAGRAM. - ... <看更多>