Skip to main content

ทำงานด้วยหลักการ Agile - Scrum Framework ด้วยทีมที่จำกัด หรือคนเดียวจะทำอย่างไร

Kongvut Sangkla

Table of contents

Intro​

สวัสดีครับ วันนี้อยากจะแชร์มุมมองการทำงานด้วย Agile Framework ซึ่งเป็นหลักการทำงานประเภทหนึ่ง แต่สงสัยไหมว่าทำงานก็ต้องมีหลักการ (framework) การทำงานด้วยเหรอ ? ก็เพราะจะได้มีขั้นตอน กระบวนการ และการวัดผลได้

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

Scrum Work Process

Scrum Work Process from (https://www.mimeo.com/blog/three-reasons-scrum-master-certified/)

Agile Framework​

TL; DR; Agile Framework คือหลักการบริหารโปรเจคงานแบบหนึ่ง โฟกัสที่รอบการทำงาน ที่เรียกว่า Sprint โดยโฟกัสความคืบหน้าตามรอบระยะเวลา เพื่อให้ลูกค้าจะได้ผลงานตามรอบของระยะเวลา และปรับแก้ไขข้อผิดพลาดได้อย่างรวดเร็ว เพื่อให้ตรงกับความต้องการลูกค้า

คำศัพท์​

  • Sprint คือรอบของการทำงาน (cycle) โดยการกำหนดรอบขึ้นอยู่กับเราเองหรือทีม ส่วนใหญ่รอบจะเป็น 1-4 สัปดาห์ เช่น 1 Sprint = 2 สัปดาห์
  • Product Owner คือผู้ที่เป็นเสมือนลูกค้า หรือตัวแทนลูกค้า
    • เขียน Product backlog items
    • เขียน User Story ใช้อธิบาย Product
    • จัด Backlog ที่เขียนไว้ใส่ใน Sprint เพื่อเรียงลำดับงาน ก่อน-หลัง ที่อยากจะเห็นในแต่ละ Sprint
  • Product backlog คือรายการลิส (items) ความต้องการของ Product หรือ Requirement Specification (งานที่ยังไม่ได้ทำ)
    • มอง Product เป็นงาน 1 ส่วนของโปรเจค (module)
    • 1 Product ประกอบด้วยหลาย Items
    • 1 Item ประกอบด้วยความหมายและผลลัพธ์ที่ต้องการ
  • Scrum Team คือทีมที่ลงมือทำงานกัน
    • ไม่แบ่งว่าใครทำหน้าที่อะไร
    • ทุกคนสามารถทดแทนกันได้เสมอ
    • ช่วยกันประเมิน Story Point ของ Backlog (อารมณ์เหมือนช่วยกันให้คะแนนความยากง่ายของงาน)
  • Scrum Master คือผู้ที่คอยประสานงานระหว่าง Scrum Teams กับ Product Owner
    • คอยดูแล Process ของ Framework
    • จัดการ Scrum Board
    • จัด Sprint Planning Meeting
    • จัด Daily Scrum Meeting
  • Story Point คือการกำหนดคะแนนความยากของงาน ซึ่งก็จะสัมพันธ์กับระยะเวลาที่ทำงานนั้น ๆ เช่น
    • 0.5 story point
    • 1 story point
    • 2 story point
    • 3 story point
    • อื่น ๆ
    • แต่ต้องทำความเข้าใจก่อนว่า Story Point คือ คะแนนความยากของงาน เท่านั้น! ย้ำว่าเท่านั้น ไม่ได้หมายถึงระยะเวลาของการทำงาน
  • Sprint Planning Meeting คือการประชุมกันก่อนเริ่มแต่ละ Sprint ผู้มีส่วนร่วมได้แก่
    • Scrum Team
    • Scrum Master
    • Product Owner
  • Sprint Review ผู้มีส่วนร่วมได้แก่
    • Scrum Team
    • Scrum Master
    • Product Owner
  • Sprint Retrospective ผู้มีส่วนร่วมได้แก่
    • Scrum Master
    • Scrum Team
    • Product Owner [optional]

ขั้นตอนการทำงานแบบ Agile​

Imgur

Scrum Board from (https://www.zoho.com/sprints/what-is-a-scrum-board.html)

  1. Product Owner เขียน Product backlog
  2. Sprint Planning Meeting
  3. นำ Product backlog มาแยกเป็น Tasks ย่อย ๆ
  4. ให้คะแนน Story Point ของแต่ละ Task
  5. Scrum Team แบ่ง Backlog task กันทำ
  6. Daily Scrum Meeting
  7. Sprint Review
  8. Sprint Retrospective

การวัดผลการทำงาน​

การวัดผลอย่างง่ายของการทำงานแบบ Agile คือการดูผลจากกราฟ Burn Down Chart

Burn Down Chart

Burn Down Chart from (https://worldofagile.com/blog/burn-down-chart/)

กราฟนี้บอกอะไร ? (แกน y คือจำนวน Tasks หรือ Story Point ที่ยังเหลืออยู่ / แกน x คือจำนวนวัน)

ความสัมพันธ์นี้สามารถอธิบายได้ว่า ยิ่ง Story Point ลดลง -> ระยะเวลาการทำงานก็จะลดตาม นั่นก็หมายความว่า

  • Estimated Work (สีแดง) เส้นที่บอกว่างานควรเสร็จตอนไหน
  • Actual Work (สีน้ำเงิน) เส้นที่บอกว่าครบกำหนดวันที่ควรเสร็จแล้ว แต่ Story Point ยังเหลือ (งานไม่เสร็จทันที่ควรจะเป็น)

ดังนั้นปัญหานี้อธิบายได้ 2 อย่างคือ

  • มีบางช่วงที่ทำงานล่าช้า
  • มีคนที่ทำงานเก่งกว่าเพื่อนในทีม โดยที่คนอื่น ๆ ยังทำไม่เสร็จ

ทีนี้เราก็จะเห็นแล้วว่า ช่วงไหนที่งานลดลงช้า-เร็ว ก็ต้องมาดูว่าเป็นเพราะอะไร แล้วก็ปรับแก้ไข

ข้อดีของการทำงานแบบ Agile​

  • ทุกฝ่ายแฮปปี้ ลูกค้าได้ เห็น product เร็วขึ้น (ไม่ต้องรอจนถึง final product)
  • มีช่วงเวลาให้ปรับแก้ไข requirement
  • ส่วน Developer ก็แฮปปี้ เพราะเห็นเลยว่าในแต่ละ sprint มีงานอะไรจะต้องทำบ้าง
  • สามารถจัดแจงการทำงานให้เหมาะสมได้ งานก็จะไม่ overload
  • ทุกคนในทีมเข้าใจ product เหมือนกัน สามารถทดแทนการทำงานกันได้
  • Product ออกมาเร็ว ถึงแม้จะไม่ใช่ Final Product แต่ก็สามารถเอาไปใช้งานหรือทำให้ลูกค้าเห็นภาพได้ดีมากขึ้น
  • สามารถติดตามการทำงาน และประเมินผลการทำงานได้อย่างมีประสิทธิภาพ

ข้อเสียของการทำงานแบบ Agile​

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

ตารางสรุป​

#ProcessActorsMonoDetail
1Product Owner เขียน Product backlogProduct Ownerเป็น PO และรับ Requirementsเขียน Epic, เขียน User Story, เขียน Backlog และเรียงลำดับ Backlog ว่าอยากเห็นอะไรก่อนหลัง *สามารถเขียน Blacklog ทิ้งไว้ หรืออะไรที่นึกออกไว้ก่อนก็ได้
2Sprint Planning MeetingProduct Owner, Scrum Master, Scrum Teamทำความเข้าใจ Requirements และกำหนดผลลัพธ์ที่อยากเห็นก่อนเริ่มแต่ละ Sprint ก็จะต้องมีการคุย/วางแผนกันระหว่าง Product Owner — Scrum Master — Scrum Team เพื่อให้เข้าใจตรงกันทั้งในเรื่องของ Requirement และการทำงานว่า ผลลัพธ์สุดท้ายใน Sprint นั้นจะต้องได้อะไรออกมา (ในจุดนี้การออกแบบระบบจะถูกทำโดย Scrum Team โดยมี Scrum Master เป็นคนตัดสินใจชี้ขาดว่าโอเคหรือไม่โอเค)
3นำ Product backlog มาแยกเป็น Tasks ย่อย ๆScrum Teamย่อย task จาก BacklogScrum Team จะหยิบเอา Backlog แต่ละ card มาแตกออกเป็น task ย่อย ๆ ว่ามีอะไรต้องทำบ้าง
4ให้คะแนน Story Point ของแต่ละ TaskScrum Teamให้คะแนน Story Pointช่วยกันประเมิน Story Point
5Scrum Team แบ่ง Backlog task กันทำScrum Teamเลือก Task ที่ต้องการทำก่อนAssign task ให้สมาชิกในทีม หรือสมาชิกในทีมอยากเลือก task เองก็ได้เช่นกัน
6Daily Scrum MeetingScrum Teamทุก ๆ 24 ชม. บันทึกข้อความไว้ว่าเราเมื่อวานทำอะไรไปบ้าง ติดปัญหาอะไร วันนี้จะทำอะไรทุก ๆ 24 ชม. Scrum Team จะมี Daily meeting โดยจะรวมตัวคุยกัน ทุกวัน ใช้เวลาไม่นาน ว่าเมื่อวานทำอะไรไปแล้วบ้าง ติดปัญหาอะไรหรือเปล่า (ถ้าติดก็จะได้ช่วยกันหาทางออก เช่น อาจจะให้ใครเข้าไปช่วยตรงจุดนั้น) แล้ววันนี้จะทำอะไรต่อ (บางครั้งเรียก Stand-up meeting)
7Sprint ReviewProduct Owner, Scrum Master, Scrum Teamประเมินผลลัพธ์ว่าตรงตามที่ต้องการหรือไม่เมื่อจบรอบ Sprint แล้ว SM, ST ส่งมอบงานกับ PO อาจจะมีการคุยเกี่ยวกับปัญหาของ Product (backlog) จากนั้น PO ก็จะไปส่งมอบ หรือนำเสนองานกับลูกค้า และเก็บ Feedback กลับมา
8Sprint RetrospectiveScrum Master, Scrum Teamทบทวนการ Sprint ที่ผ่านมา ปัญหา หรือการให้คะแนน Story Pointเป็นการคุยกันระว่าง ST กับ SM โดยหาก Sprint Review มีไว้เพื่อการพูดคุยเพื่อปรับปรุงตัวโปรเจกต์หรือโปรดักต์ Sprint Retrospective ก็อาจจะมีไว้เพื่อการปรับปรุง "กระบวนการทำ Scrum" ซึ่งอาจเกี่ยวข้องไปถึงการทำงานของสมาชิกแต่ละคน รูปแบบการสื่อสาร กระบวนการ เพื่อให้การทำ Scrum มีคุณภาพดีขึ้นในรอบ Sprint ถัดไป

References​

ช่วยบริจาคสำหรับค่ากาแฟ
Loading...