Agile & Scrum

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

Waterfall Process

Waterfall เป็นกระบวนการการพัฒนา Software แบบเดิม ซึ่งจะมีวัฎจักรในการพัฒนาระบบ Software Development Life Cycle ( SDLC ) โดยเริ่มจาก

Requirement : เป็นการเก็บข้อมูลจากลูกค้า แล้วทำการประเมินถึงความเป็นไปได้ รวมถึงการประเมินทรัพยากรที่ต้องใช้
Design : เป็นการออกแบบทั้ง Software และ Hardware ให้ตอบสนองต่อความต้องการของลูกค้าตาม Requirement ที่ได้รับ
Implement : เป็นการพัฒนาตามที่ได้ Design ไว้
Verification : เป็นการทดสอบเพื่อให้ทำงานได้ครบถ้วน มีประสิทธิภาพ และถูกต้องตาม Requirement
Maintenance : เป็นการบำรุงรักษาเพื่อปรับปรุงการทำงาน ป้องกันช่องโหว่ด้านความปลอดภัยต่าง ๆ รวมถึงเพิ่มประสิทธิภาพการทำงาน

Problem

ปัญหาที่เกิดขึ้นจากกระบวนการพัฒนา Software แบบเดิมด้วยWaterfall คือหากกำหนด Requirement ไม่ชัดเจนตั้งแต่แรก จะทำให้การพัฒนา Software เหมือนเริ่มทำใหม่ หากแยกเป็นปัญหาย่อย ได้แก่

Change Requirement : การเปลี่ยนแปลงความต้องการของลูกค้าในภายหลัง ซึ่งส่วนใหญ่จะเกิดจากผู้ใช้งานไม่รู้ว่าต้องการอะไร อันเนื่องมาจากมองภาพการทำงานของ Software ไม่ออก
Change Cost : การเปลี่ยนแปลงที่เกิดขึ้นมีต้นทุนสูง เนื่องจากกระบวนการพัฒนาเป็นแบบ Sequential Process ไม่ได้ถูกออกแบบมาให้รองรับการเปลี่ยนแปลง ซึ่งการเปลี่ยนแปลงแต่ละครั้งจะใช้ระยะเวลามาก ทำให้เกิดค่าเสียโอกาส
Change Time : การเปลี่ยนแปลงที่เกิดขึ้นใช้เวลาเพิ่มมากขึ้น ทำให้เสร็จไม่ทันตามระยะเวลาที่กำหนด จึงเกิดการตัดขั้นตอนในส่วนของการทดสอบ Testing Stage เพื่อให้ Project เสร็จทันตาม Deadline จนสุดท้ายไม่สามารถนำ Software ไปใช้ได้จริง

Agile

Agile เป็นปรัชญาในการทำงานไม่ใช่กระบวนการ ทำให้การนำ Agile มาใช้ในองค์กรไม่ใช่แค่การปรับกระบวนการเพียงอย่างเดียว แต่เป็นการปรับวัฒนธรรมขององค์กรด้วย หากไปดู Manifesto for Agile Software Development จะบอกแค่ว่า Agile ให้ความสำคัญกับ 4 อย่าง

Individuals & Interaction : เน้นการมีปฏิสัมพันธ์กับคน มากกว่าทำตามขั้นตอน
Working Software : เน้นการทำให้ Software สามารถใช้งานได้จริง มากกว่าการทำเอกสาร
Customer Collaboration : เน้นการทำงานร่วมกับลูกค้า มากกว่าการทำข้อตกลงกับลูกค้า
Responding to Change : เน้นตอบสนองต่อการเปลี่ยนแปลง มากกว่าให้เป็นไปตามแผนที่วางไว้

ส่วนกระบวนการพัฒนาด้วย Agile Framework ซึ่งก็มีหลายวิธีด้วยกัน แต่ที่ดูจะนิยมใช้กันมากที่สุด คงหนีไม่พ้น Scrum Framework

Scrum Framework

เป็นรูปแบบกระบวนการพัฒนาด้วย Agile หาก Agile เปรียบได้กับปรัชญาในการทำงาน Scrum ก็เปรียบได้กับการนำปรัชญามาใช้ ซึ่งภายใน Scrum Team จะประกอบไปด้วย

Product owner : เจ้าของผลิตภัณฑ์ รับผิดชอบการเพิ่มมูลค่าของผลิตภัณฑ์ ที่เกิดจากการทำงานของ Development Team
Development Team : ทีมพัฒนาผลิตภัณฑ์ รับผิดชอบการส่งมอบผลิตภัณฑ์ที่อาจเพิ่มขึ้นได้ในตอนท้ายของแต่ละ Sprint
Scrum Master : เป็นคนที่นำ Scrum มาปรับใช้ในการทำงานภายในทีม รับผิดชอบการส่งเสริมและสนับสนุนทีมในการใช้ Scrum ให้ถูกต้องตาม Scrum Guide

Scrum Event

ในกระบวนการพัฒนาจะถูกแบ่งรอบการทำงานออกเป็น Sprint โดยมีกรอบระยะเวลาในการทำงาน ภายในระยะเวลาไม่เกิน 1 เดือน ที่สามารถส่งมอบ Product Increment งานที่เสร็จในแต่ละ Sprint ซึ่งมีระยะเวลาในแต่ละ Sprint คงที่ตลอดการทำงาน โดย Sprint ใหม่จะเกิดขึ้นทันทีหลังจากทำการสรุป Sprint ก่อนหน้า ซึ่งในแต่ละ Sprint จะประกอบไปด้วย

Sprint Planing : เป็นการวางแผนการทำงานในแต่ละ Sprint ร่วมกันภายใน Scrum Team จะใช้เวลาไม่เกิน 8 ชั่วโมง โดยมี Scrum Master คอยดูแลให้สมาชิกภายในทีมเข้าใจวัตถุประสงค์ตรงกันของงานที่กำหนดใน Sprint Backlog จาก Product Backlog เพื่อให้บรรลุเป้าหมาย Sprint Goal รวมถึงควบคุมกิจกรรมภายในระยะเวลาที่กำหนด
Daily Scrum : เป็นการวางแผนการทำงานในแต่ละวัน ร่วมกันภายใน Scrum Team จะใช้เวลาไม่เกิน 15 นาที ในตอนเช้าก่อนเริ่มทำงาน เพื่อตรวจสอบ Progress ของงานใน Sprint Backlog และยังช่วยขจัดปัญหาและอุปสรรคที่ทำให้ไม่สามารถบรรลุเป้าหมาย Sprint Goal
Sprint Review : เป็นการตรวจสอบ Product Increment ตอนท้ายของ Sprint ร่วมกันภายใน Scrum Team จะใช้เวลาไม่เกิน 4 ชั่วโมง เพื่อตรวจสอบ Product Increment ก่อนส่งมอบ อาจมีการเปลี่ยนแปลง Product Backlog เกิดขึ้นด้วยหากมีความจำเป็น
Sprint Retrospective : เป็นการเปิดโอกาสให้สมาชิกภายในทีม ร่วมกันตรวจสอบและวางแผนปรับปรุงสำหรับ Sprint ถัดไป จะใช้เวลาไม่เกิน 3 ชั่วโมง

KPI & OKR

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

ทำได้ร้อยละร้อย

มันไม่ใช่การวัดผลแล้ว มันเป็นการนับจำนวนครั้งเฉย ๆ Count ธรรมดา สิ่งที่ต้องวัดคือ Performance ดีขึ้น ความพึงพอใจเพิ่มขึ้นอะไรแบบนี้

อ่านเพิ่มเติม : https://bit.ly/31RGpWD, https://bit.ly/32S5a6v, https://bit.ly/348c1ZO

Tagged: Agile, Scrum