เมื่อเรากำลังจะเข้าสู่ยุคของ ‘Agile’

หลายคนคงได้ยินคำว่า Agile กันมานานแล้ว.. แน่นอนครับมันเป็น methodology ของการทำงานที่ถือกำเนิดขึ้นตั้งแต่ปี 2001 นู่นน

เกริ่นก่อนว่าตอนนี้มีโอกาสได้มาช่วยงานในบริษัทของน้า โดยรวมแล้วงานส่วนใหญ่จะเป็น Application development (ทั้ง web และ mobile application) ด้วยความที่องค์กรมีขนาดไม่ใหญ่มาก ส่วนการทำงานก็เป็นแบบ waterfall model ทำให้เกิดปัญหาเรื่องของ ‘เวลา’

ปัญหา

ก่อนอื่นมาพูดถึงปัญหาของการทำงานแบบ waterfall model กันก่อน

Waterfall Model (ref: http://webdesign.tutsplus.com/articles/a-designers-introduction-to-agile-methodology--cms-23349)

เราคุ้นชินกับการทำงานที่เก็บ Requirement จากลูกค้ามาทั้งหมดก่อน -> นำมาวิเคราะห์แล้วก็ออกแบบว่าระบบควรจะเป็นยังไง ทั้งในส่วนของ technical และ user interface -> ลุยเขียนโค้ด -> ทดสอบระบบ -> เอาไปใช้งานจริง

ปัญหาที่เจอบ่อยๆ คือ

  • บางครั้งมีการเพิ่ม/เปลี่ยน requirement ในช่วงที่เราได้ออกแบบระบบไปแล้วหรือกำลังพัฒนาอยู่ ทำให้ scope งานเปลี่ยน เวลาที่ประเมินไว้ก็ต้องขยับขยายออกไป
  • บางครั้งพอ product ไปถึงมือลูกค้า ลูกค้าอยากให้เพิ่ม/ปรับเปลี่ยนบางอย่าง แต่ทีมเราขึ้น project ใหม่กันไปแล้ว คราวนี้ก็ต้องมาหาเวลาเพื่อแทรก task ของ project เดิมลงไป อันนี้ปัญหาใหญ่เลย developer จะหัวหมุนมาก เพราะต้องเปลี่ยนหัวไปมาระหว่าง project

เมื่อวันก่อนน้าก็เลยเสนอไอเดียเรื่องการนำ Agile เข้ามาประยุกต์ใช้ในบริษัท เลยได้มีโอกาสศึกษาอย่างจริงจังว่าไอวิธีการยอดฮิตเนี่ยมันเป็นยังไง มีอะไรดี ทำไมคนถึงใช้เยอะ

ก่อนอื่นเรามาทำความรู้จักกับ Agile กันก่อนดีกว่า
(คำเตือน: ผมไม่เคยทำงานแบบ Agile นะครับ ดังนั้นสิ่งที่จะกล่าวต่อไปนี้เป็นเพียงองค์ความรู้ที่ได้ศึกษามาจากหลายๆ source ในอินเทอร์เน็ต)

Agile คืออะไร

Agile คือโมเดลการทำงานแบบหนึ่งที่จะแบ่งการทำงานออกเป็น cycle ย่อยๆ ซึ่งเราจะเรียกแต่ละ cycle ว่า ‘sprint’.. โดยในแต่ละ sprint เราจะแบ่งออกเป็นสี่ process ได้แก่ Discover, Design, Develop และ Test

เมื่อจบหนึ่ง sprint เราจะได้ ‘Potential Shippable Product’ ซึ่งมันก็คือ product ชิ้นนึงที่สามารถใช้งานได้จริง เห็นผลลัพธ์ชัดเจน หรือถ้าระบบเราใหญ่มากๆ เจ้าตัว potential shippable product นี้ก็อาจจะเป็น feature หนึ่งในระบบของเราก็ได้

Agile Methodology (ref: http://webdesign.tutsplus.com/articles/a-designers-introduction-to-agile-methodology--cms-23349)

สำหรับการทำงานแบบ Agile นั้นเราจะมีคนที่เกี่ยวข้อง ดังนี้

  1. Product Owner
    คนนี้นี่ถือว่าเป็นตัวแทนของลูกค้า โดยมีหน้าที่เขียน ‘Product Backlog’ ซึ่งมันก็คือ requirement ทั้งหมดของ final product ว่าจะมี feature อะไรบ้าง แยกออกมาเป็น card ย่อยๆ / รวมถึงเขียน ‘User Story’ ซึ่งจะเหมือนการสวมหัวโขนให้กับตัวเอง เช่น ในฐานะของ user ฉันอยากจัดการกับสเตตัสที่ฉันโพสไปแล้ว เพื่อที่ฉันจะสามารถแก้ไขหรือลบสเตตัสที่ฉันไม่ชอบได้ (หลายคนอาจจะคุ้นเคยกับวิธีการเขียนแบบภาษาอังกฤษ ที่จะเขียนว่า As a … I want/need to … So that …)
  2. Scrum Master
    เป็นคนประสานงานระหว่าง Product Owner และ Scrum Team โดยในมุมนึงก็คือ กำแพงที่คอยปกป้องเหล่าสมาชิกใน Scrum Team อย่างเช่นในกรณีที่ requirement มันเยอะเกินไป หรือหนักเกินไป Scrum Master ก็จะต้องปฏิเสธ หรือขอเพิ่มระยะเวลาในการพัฒนาระบบ แต่ในอีกมุมนึง Scrum Master คือคนที่จะต้องคอยดูแล process การทำงานของทีม และรับผิดชอบต่อคุณภาพของ product ด้วย [มองมุมนึงก็น่าจะเหมือนกับเป็น project manager นั่นแหละ]
  3. Scrum Team
    นี่คือทีมที่จะลงมือพัฒนาระบบกัน (ส่วนใหญ่มีขนาดประมาณ 5–9 คน) โดยเราจะไม่แบ่งว่าใครต้องทำหน้าที่อะไร ดังนั้นทุกคนในทีมจะสามารถทดแทนกันได้เสมอ ซึ่งก็ถือว่าเป็นจุดแข็งอย่างนึงของการทำงานแบบ Agile / นอกจากนั้นสมาชิกในทีมจะต้องช่วยกันประเมินระยะเวลาให้แต่ละ task ว่าจะใช้เวลาในการ develop มากน้อยแค่ไหน (ซึ่งในการทำงานแบบ Agile มักจะใช้ตัวเลขสมมติที่เรียกว่า Story Point แทนการเขียนระยะเวลา เดี๋ยวเขียนอธิบายคร่าวๆ ข้างล่างละกัน)

โอเคมาต่อที่เรื่องของ Story Point กันแบบรวบรัด
อย่างที่ได้บอกไปว่า Story Point คือตัวเลขสมมติที่เราใช้แทนการระบุระยะเวลาในการพัฒนา โดยทาง Dan Chuparkoff (Group Manager ของ JIRA) ได้นำเสนอวิธีการให้คะแนน Story Point เอาไว้ตามรูปด้านล่าง

Story Point ‘cheating’ (ref: https://www.youtube.com/watch?v=NrHpXvDXVrw)

เค้าบอกกันว่าสิ่งที่ยากที่สุดอย่างนึงในการทำงานแบบ Agile ก็คือการ estimate time ว่าเราจะใช้เวลาในแต่ละ task เท่าไหร่..​ แต่พอเราได้ลองทำไปสัก 1–2 sprint เราจะเริ่มจับทางได้ละว่าแต่ละ task ควรให้ Story Point เท่าไหร่

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

  1. เขียน Product Backlog
    โดย Product Owner จะเป็นผู้เขียน feature ทั้งหมดที่อยากให้มีใน final product
  2. จัด Backlog แยกออกเป็นแต่ละ Sprint
    ก็ยังคงเป็นหน้าที่ของ Product Owner ที่จะเป็นคนแยกว่าอยากจะเห็น feature ไหนก่อน-หลัง โดยแยกออกไปใส่ในแต่ละ Sprint
  3. Sprint Meeting
    ก่อนเริ่มแต่ละ Sprint ก็จะต้องมีการคุย/วางแผนกันระหว่าง Product Owner — Scrum Master — Scrum Team เพื่อให้เข้าใจตรงกันทั้งในเรื่องของ Requirement และการทำงานว่าผลลัพธ์สุดท้ายใน Sprint นั้นจะต้องได้อะไรออกมา (ในจุดนี้การออกแบบระบบจะถูกทำโดย Scrum Team โดยมี Scrum Master เป็นคนตัดสินใจชี้ขาดว่าโอเคหรือไม่โอเค)
  4. แตก Backlog ออกเป็น task ย่อยๆ
    Scrum Team จะหยิบเอา backlog แต่ละ card มาแตกออกเป็น task ย่อยๆ ว่ามีอะไรต้องทำบ้าง
  5. Daily Scrum Meeting
    มันก็คือการที่ Scrum Team จะมารวมตัวคุยกันทุกวันว่าทำอะไรไปแล้วบ้าง ติดปัญหาอะไรหรือเปล่า (ถ้าติดก็จะได้ช่วยกันหาทางออก เช่น อาจจะให้ใครเข้าไปช่วยตรงจุดนั้น) แล้วจะทำอะไรต่อ
  6. Evaluation
    ทีนี้พอจบ sprint นึง เราก็จะต้องมาวิเคราะห์และประเมินผลการทำงานว่ามันโอเคหรือเปล่า โดยใช้วิธีง่ายๆ อย่าง burn-down chart (แกน y คือ จำนวน task หรือ Story Point ที่ยังเหลืออยู่ / แกน x คือ วันที่) ทีนี้เราก็จะเห็นแล้วว่าช่วงไหนที่งานลดลงช้า-เร็ว ก็ต้องมาดูว่าเป็นเพราะอะไร แล้วก็ปรับแก้ไข
Burndown Chart (ref: http://www.timberwolfconsulting.com/scrum/glance/artifacts/)

สรุปข้อดีของการทำงานแบบ Agile

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

อย่างที่บอกไปครับ ทั้งหมดที่พิมพ์มานี้มาจากการศึกษา source ในอินเทอร์เน็ตเท่านั้น ผมเองไม่ได้มีประสบการณ์การทำงานแบบ Agile มาก่อน ดังนั้นถ้ามีจุดไหนที่อธิบายได้ไม่ถูกต้อง หรืออยากให้คำแนะนำใดๆ จะยินดีมากครับ