> For the complete documentation index, see [llms.txt](https://www.saladpuk.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.saladpuk.com/basic/agile-methodology/agile-in-a-nutshell.md).

# Agile in a Nutshell

ในรอบนี้เราจะมาดูการทำ Agile แบบภาพรวมดูบ้าง ว่าถ้าเราเอา agile มาใช้แล้วมันจะช่วยจัดการโปรเจคเราได้ยังไง

{% hint style="success" %}
**แนะนำให้อ่าน**\
บทความนี้เป็นส่วนหนึ่งของบทความ [👦 Agile Methodology](https://saladpuk.gitbook.io/learn/basic/agile-methodology) หากเพื่อนๆสนใจอยากศึกษาการทำ Agile แบบเต็มรูปแบบก็สามารถกดลิงค์สีฟ้าๆเพื่อเข้าไปดูได้เลยนะ
{% endhint %}

{% hint style="info" %}
**อ้างอิง**\
บทความนี้ถอดความรู้มาจากวีดีโอตัวนี้ [Agile Product Ownership in a Nutshell](https://www.youtube.com/watch?v=502ILHjX9EE) ถ้าสนใจอยากดูตัวเต็มก็กดดูเอาได้เลยนะ
{% endhint %}

## 🤔 ทำ Agile แล้วดียังไง ?

ผมขอถอดความจากวีดีโอมาเล่าให้ฟังละกันจะได้เรียนรู้คำศัพท์ไปในตัวด้วย ซึ่งผมขอออกตัวไว้ก่อนว่า นิทานที่จะเล่านี้เพื่อให้เข้าใจภาพรวมเฉยๆนะ ซึ่งในการทำงานจริงของแต่ละอย่างมันจะผุดมาได้ยังไง เดี๋ยวมีอธิบายในบทความถัดไป ดังนั้นอย่าเสียเวลาไปฟังนิทานกันเลยละกัน

กาลครั้งหนึ่งในดินแดนอันไกลแสนไกล มีแมวน้ำกลุ่มหนึ่งเกิดมีไอเดียอยากได้แอพเจ๋งๆซักตัวนึงขึ้นมา โดยเราจะขอเรียกพวกมันว่า **Stakeholders** ละกัน

![](/files/-LsoYe15p3zpdZxyfcTZ)

และแน่นอนแมวน้ำกลุ่มนี้ส่วนใหญ่เขียนโปรแกรมไม่เป็นหรอก แต่เขาสนับสนุนเงินไปสร้างแอพเมพๆได้แน่นอน ดังนั้นเลยต้องมีแมวน้ำอีกตัวที่ชื่อว่า **Product Owner** หรือย่อสั้นว่า **PO** ที่ต้องคอยทำความเข้าใจว่าเหล่า stakeholders นั้นอยากจะได้อะไรกันแน่นั่นเอง

![](/files/-LsoMqKd13pKC9GWmouu)

ดังนั้น PO เลยเป็นคนที่จะมีภาพในหัวว่าโปรแกรมควรจะต้องทำอะไรได้บ้างนั่นเอง โดยที่สิ่งที่โปรแกรมจะต้องทำอะไรได้บ้าง เราจะเรียกมันว่า **User Story** ที่เป็นไอเดียผุดมาจาก Stakeholders และ PO นั่นเอง

![](/files/-LtrnLsmpUyoOIuvcq7s)

ซึ่งการที่จะทำให้แอพเทพๆนั้นเกิดขึ้นมาได้จริงๆ ก็จะตกเป็นงานของแมวน้ำอย่างเราๆ เหล่า **Developer team** นั่นเอง ที่จะคอยเอา user story มาแปลงเป็นโค้ดสืบไป

![](/files/-LuAMF3Z_C4pV4KUOxSl)

โดยปกติเหล่า Developer team ก็จะมีนัดหมายส่งงานที่ทำเสร็จเป็นรอบๆไป โดยถ้าเราเอา user story มานับเฉลี่ย เราก็จะรู้ว่า ในหนึ่งรอบทีมจะสามารถทำได้กี่ user story เลยทำให้เราสามารถคาดการณ์ได้ว่างานทั้งหมดจะเสร็จตอนไหนแบบคร่าวๆได้ ซึ่งเราเรียกมันว่า **Capacity** ของทีม

เช่น ในรูปด้านล่างทีมสามารถทำงานได้ 4-6 user story ต่อ 1 รอบในการส่งงาน

![](/files/-LncLQCSmQPkPnskYiTa)

แต่ปัญหาในการทำงานส่วนใหญ่คือทีมไม่รู้ว่าตัวเองสามารถทำงานได้กี่ user story ต่อ 1 รอบงาน เลยทำให้ส่วนใหญ่นั้นงานที่เข้ามาให้ทีมทำนั้นมันจะเยอะกว่าที่ทีมสามารถทำได้ตามรูปนั่นเอง ทำให้แต่ละรอบที่นัดส่งงานเหล่าแมวน้ำทั้งหลายเลยส่งงานได้ไม่ตรงตามที่สัญญาไว้งุย

![](/files/-LpvxaYXjRDyfnPMifzp)

จากที่ว่ามายังไม่ต้องไปถึง agile หรอก แค่คิดง่ายๆ**ตามหลักความเป็นจริง**ก็รู้แล้วว่า งานที่ทีมสัญญาว่าจะทำไม่ควรเยอะกว่าความสามารถที่ทีมทำได้นั่นเอง

เช่น จากตัวอย่าง ภายใน 1 รอบงานทีมควรจะเอาไปทำเฉลี่ยอยู่ที่ 5 user story งานนั่นเอง เราเรียกมันว่า **Work in progress (WIP)** เพราะมันจะได้ไม่มาก และ ไม่น้อยจนเกินไป ไม่มีใครได้นั่งอู้กดมือถือ หรือ ไม่เครียดทำงานยันเย็นทุกวันนั่นเอง

![](/files/-Luj7Haxb_LNL5_w7FzB)

ดังในในการทำงานจริง เราเลยต้องมีที่เก็บรวบรวมไอเดียทั้งหมดของงานไว้ ซึ่งเราเรียกมันว่า **Product Backlog (PB)** ซึ่งภายในนั้นก็อาจจะมีไอเดียที่ชัดเจนแล้วว่ามันคืออะไร หรือบางตัวอาจจะเป็นแค่ concept เท่านั้นก็ได้

![](/files/-M-VCpA8uREaeMsSY_tb)

คราวนี้ใน 1 รอบการทำงานทีมก็จะหยิบงานจาก Product Backlog มาทำโดยไม่ให้เกินความสามารถที่ทีมสามารถทำได้ต่อ 1 รอบงานนั่นเอง

![](/files/-M-wBRANcS4X77qYIBGy)

โดยทุกๆ 1 รอบงาน เราก็จะมาคุยกันว่างานตัวไหนที่มันมีมูลค่าและเร่งด่วนที่สุดในมุมของ Business เราก็จะเอามาทำก่อน และไอเดียบางเรื่องก็อาจจะไม่จำเป็นที่จะต้องทำแล้วก็สามารถเอาทิ้งไปก็ได้

![](/files/-LuFRpcxDp7lPwmVzpg3)

ซึ่งการเลือกว่าอะไรมีมูลค่าอะไรเร่งด่วน หรือ อะไรที่มันไม่ได้ใช้แล้ว มันไม่ใช่หน้าที่ของ developer มาเลือกนะ แต่มันจะต้องคุยกันให้เข้าใจทุกฝ่ายต่างหาก ดังนั้นมันจะต้องมีเวลาที่จะให้แต่ละฝ่ายได้มานั่งลงแล้วคุยกันว่าจะดำเนินการยังไงต่อนั่นเอง

![](/files/-Lpqa6m0ZG849lKXXQ7u)

จากที่ว่ามาโดยรวม **Developer team กับ PO** จะต้องเคลียให้เห็นเป็นภาพเดียวกันว่าจริงๆแล้วงานแต่ละตัวใน Product Backlog มันคืออะไร แล้วมันจะสามารถทำเสร็จได้ทัน 1 รอบการทำงานหรือเปล่านั่นเอง และงานที่จะเอาไปทำจะต้องเลือกเอาตัวที่มีความสำคัญในแง่ business ไปทำก่อนเสมอ ซึ่งปัจจัยในการเลือกนั้นจะต้องใช้ **Stakeholders** มาช่วยด้วยอีกทีนึง

และจากการที่ทีมทำงานเป็นรอบๆ เราก็จะสามารถเก็บสถิติของทีมออกมาได้ เช่น ถ้าเราเอาความสามารถที่ทีมทำ user story มาทำ เมื่อเทียบกับเวลา เราก็จะได้กราฟคร่าวๆเป็นแบบนี้

![](/files/-LoIIvwMROH3V8MkNBVQ)

ซึ่งถ้าเราเอาค่าประมาณการคร่าวๆมาวาดลงก็จะได้ออกมาราวๆนี้

![](/files/-Lpw21KDItLPtmfFJ6Fe)

จากกราฟเราก็จะสามารถหาคำตอบให้กับลูกค้าแบบคร่าวๆได้แล้ว เช่น

ถ้าลูกค้าถามว่า **features พวกนี้จะเสร็จเมื่อไหร่** ซึ่งคำถามแบบนี้เราเรียกว่า **Fixed scope** เราก็จะสามารถเอากราฟนี้มาตอบได้ว่า น่าจะเสร็จอย่างเร็วได้วันไหนและอย่างช้าไม่เกินวันไหนนั่นเอง

![](/files/-LsgIWfIE_fBWwex2c1N)

หรือถ้าลูกค้าถามว่า **ช่วงเวลานี้เราจะส่งอะไรให้เขาได้บ้าง** ซึ่งคำถามแบบนี้เราเรียกว่า **Fixed time** ซึ่งเราก็ยังใช้กราฟเดิมมาตอบคำถามได้ว่า อย่างดีที่สุดเราจะส่งอะไรให้เขาได้ และอย่างแย่ที่สุดเราควรจะส่งอะไรให้เขาได้นั่นเอง

![](/files/-LoInFH5k_5xYzadmzDf)

และแบบสุดท้ายคือถ้าลูกค้าทั้ง Fixed time และ Fixed scope มาเลย เราก็สามารถอธิบายความเป็นจริงให้ลูกค้าเข้าใจได้ว่าเรามีตัวเลือกให้เขายังไง เพื่อที่จะได้ของที่เขาต้องการนั่นเอง

## 🎥 วีดีโอที่สรุปบทความ

{% embed url="<https://www.youtube.com/watch?v=502ILHjX9EE>" %}

## 🎯 บทสรุป

นิทานเรื่องนี้สอนให้รู้เห็นแบบคร่าวๆว่า หัวใจหลัก 4 ข้อของการทำ agile นั้นจะ**เน้นไปที่เรื่องของคนและการทำงานร่วมกัน** เพื่อปรับให้ทุกฝ่ายได้เข้าใจสถานะการณ์ในปัจจุบัน และทำงานได้ตรงกับความต้องการที่มีมูลค่าและความเร่งรีบได้ถูกต้องนั่นเอง แต่ถ้าเราไม่คุยกัน ต่างฝ่ายต่างทำของตัวเองไป สุดท้ายแล้วเราก็จะได้เล่าให้ลูกหลานฟังต่อว่า อ๋อ Agile เหรอ เคยทำแล้วไม่เวิร์คหรอก

{% hint style="danger" %}
**ข้อควรระวัง**\
ในนิทานที่เล่าให้ฟังกับในการทำงานจริงนั้นมันมีหลายเรื่องที่ไม่ตรงกันเยอะอยู่ แต่ผมไม่อยากให้เพื่อนๆต้องไป งง ว่าอะไรคืออะไร เช่น story point, burn down chart บลาๆ แต่อยากให้เห็นภาพคร่าวๆก่อนว่าทำไมแต่ละฝ่ายต้องทำงานร่วมกัน และ ศัพท์ที่เราใช้เรียกกันบ่อยๆมีอะไรบ้างนั่นเอง
{% endhint %}