Story Points กำลังบอกอะไรเรา?

Story Point คืออะไร?
ทำไมต้องมี Story Point?
Story Point เป็นส่วนหนึ่งของ Agile หรือเปล่า?
.
.
ความมหัศจรรย์ของเลขฟีโบนักชี 1 1 2 3 5 8 13 21 34 55

ภาพที่ 1 ตัวเลขลำดับ Fibonacci numbers (ที่มา https://www.mathsisfun.com)

ความสัมพันธ์ของกับการนำเลขฟีโบนักชีมาสร้างเป็นสี่เหลี่ยมเพื่อหาค่าพื้นที่ดังภาพ ทำให้เกิดความสัมพันธ์หนึ่ง ที่เรียกว่า อัตราส่วนทอง

ภาพที่ 2 การจัดเรียงสี่เหลี่ยมจัตุรัสที่มีความยาวด้านเท่ากับจำนวนฟีโบนักชี

ที่มา https://www.ted.com/talks/arthur_benjamin_the_magic_of_fibonacci_numbers?language=th#t-270607

สัดส่วนสี่เหลี่ยมผืนผ้าทองคำ หรือ อัตราส่วนทอง (golden ratio) ที่เราสามารถพบได้ในธรรมชาติ ทั้งสิ่งมีชีวิต และไม่มีชีวิต อาทิเช่น

มหาวิหารพาร์เธนอน (Parthenon)

เป็นที่น่าสนใจที่พบว่า สถาปัตยกรรมที่เรารู้จักกันดีอย่างมหาวิหารพาร์เธนอน (Parthenon) มีขนาดกว้าง 30.9 เมตร ยาว 69.5 เมตร (101.4 × 228.0 ฟุต) เมื่อนำขนาดของวิหารนี้มาคำนวณเป็นอัตราส่วน จะพบว่าเป็นอัตราส่วนทองคำ

ภาพที่ 3 มหาวิหารพาร์เธนอน (Parthenon)

ที่มา https://th.wikipedia.org/wiki

เกลียวในเปลือกของหอยนอติลุสหรือหอยงวงช้าง

อัตราส่วนระหว่างเส้นผ่านศูนย์กลางของเกลียวรอบเปลือกหอยนอติลุส

ภาพที่ 4 เกลียวในเปลือกของหอยนอติลุส

ที่มา http://www.reurnthai.com/index.php?topic=6355.75

เมล็ดดอกทานตะวัน

การจัดเรียงตัวเป็นเกลียว แต่ละเกลียวจะตรงกับเลขฟีโบนักชี จำนวนเมล็ดที่อยู่ในเกลียว ที่หมุนตามเข็มนาฬิกามีอัตราส่วนเท่ากับอัตราส่วนทองคำ “phi”

ภาพที่ 5 การจัดเรียงตัวเป็นเกลียวของเมล็ดดอกทานตะวัน

ที่มา http://cdipthailand.com/media/kunena/attachments/760/golden2.jpg

โมนาลิซ่า(Mona Lisa)

สี่เหลี่ยมผืนผ้าทองคำที่ปรากฏอยู่บนใบหน้าและส่วนต่างๆของ โมนาลิซา ซึ่งเป็นภาพวาดที่มีชื่อเสียงมากที่สุดรูปหนึ่งของโลก ที่วาดขึ้นโดย เลโอนาร์โด ดา วินชี 

ภาพที่ 6 โมนาลิซ่า(Mona Lisa)

ที่มา https://d3ii8mlq8d5cne.cloudfront.net/blog/monalisa.jpg

Special Thank and reference : https://www.scimath.org/article-mathematics/item/7583-2-1-618
.
.
.
การ Estimating techniques ใน Project Management มีอยู่ 4 วิธีด้วยกัน

1. Analogous estimating
เป็นวิธีการเปรียบเทียบโดยใช้ข้อมูลจากโปรเจคก่อนหน้าและทำการเปรียบเทียบ วิธีนี้คิดได้เร็วแต่ไม่แม่นยำ

2. Parametric estimating
เริ่มแม่นยำมากกว่า Analogous เพราะเริ่มใช้การคำนวนเชิงปริมาณ (Quantitatively based) แต่ต้องมีข้อมูลของโปรเจคก่อนหน้าด้วย ยกตัวอย่างเช่นพื้นที่ทาสีบ้านหลังนี้ประมาณ 100 ตร.ม. โปรเจคที่แล้วใช้เวลา 1 วันทาได้ประมาณ 20 ตร.ม. ก็นำไปไปคิดคำนวณคร่าวๆได้ จะใช้เวลาทั้งหมดประมาณ 4 วัน

3. Three-point estimating
เป็นวิธีการ Estimating บนพื้นฐานความไม่แน่นอน มีความแม่นยำขึ้นอยู่กับการประเมินสถานการณ์ในเรื่องนั้นๆ โดยมีสูตรการคำนวณดังนี้

(O + 4M + P) / 6

O = Optimistic | มองในแง่ดี

M = Most likely | ปกติ

P = Pessimistic | มองในแง่ร้าย

ยกตัวอย่างเช่น ถ้าต้องใข้เวลาในการทาสีภายนอกในช่วงฤดูฝน
O(แง่ดี) = 2 วัน | M(ปกติ) = 3 วัน | P(แง่ร้าย) = 5 วัน
(2 + 4x3 + 5) / 6 = 3.16 วันโดยประมาณ

4. Bottom-up estimating
เป็นวิธีการที่แม่นยำที่สุด โดยแบ่งเป็น Activitiy ย่อยๆ แล้ว Sum up จากล่างขึ้นมาข้างบน แต่ใช้เวลาในการทำ Estimating นานๆกว่าจะได้ผลลัพธ์
.
.
.
จากประสบการณ์ในการเป็น Project Manager มา 7 ปี ถึงแม้ว่าจะใช้ Techiniques ด้านบนทั้งหมดก็ตามในแง่การพัฒนาซอฟแวร์ก็ไม่มีทางที่จะส่งมอบโครงการได้ตรงกับ Baseline ที่วางไว้ตั้งแต่แรก เพราะปัจจัยที่เกิดขึ้นมันเยอะกว่านั้นมาก ยกตัวอย่างเช่น ประสบการณ์และความเชี่ยวชาญของผู้ทำการ Estimating, ลักษณะของตัวโครงการที่มีความซับซ้อนต่างกัน,  Estimator เป็น Senior คนทำงานเป็น Junior, โปรเจคระยะเวลานาน Knowledge loss ไปกับ Turn over ของคนในโครงการ
.
.
.
Poker Planning ไม่ได้เป็นส่วนหนึ่งของ Agile หรือ Scrum...แต่เป็นเครื่องมือที่ช่วยในการ Estimate งานที่จะทำในแต่ละ Sprint เพื่อให้คนในทีมเห็นภาพเดียวกันและสามารถในการแบ่งงานที่มันใหญ่ๆ ออกมาเป็นงานย่อยๆ เพื่อลดความเสี่ยงในระหว่างการ Development และเพื่อแสดงความคืบหน้าการพัฒนาออกมาอยู่อย่างสม่ำเสมอ
.
.
โดยตัวเลข Fibonacci เป็นตัวเลขที่เราไว้ใช้เปรียบเทียบ Relative size ระหว่าง User stories ช่วยให้ทีมเข้าใจปริมาณงานได้ง่ายกว่า เพราะอย่าลืมว่าการที่เรา Adopt Scrum มาใช้งานเรากำลังอยู่บนสถานการณ์ที่กึ่งๆ known - unknown การที่เรา Estimate โดยมีความคิดที่ว่าต้องการความแม่น 100% มันอาจจะใช้ระยะเวลานานมาก และไม่คุ้มกับ Effort ที่ใข้ในการ Estimate รวมถึงความเสี่ยงที่จะเปลี่ยนได้เสมอ เพราะถ้าทุกคนได้แสดงความคิดเห็นและครบถ้วน 360 องศาต่อ User Story นั้นๆ เพื่อหา Accurate ก็เพียงพอแล้วสำหรับที่จะเริ่มนำ User story เข้าไปใน Sprint
.
.

.
.
Relative VS Absolute Sizing

จากรูปลองคิดดูนะครับถ้าเราไม่เห็นฉลากที่ติดข้างขวดและเราไม่มีความรู้มาก่อนเลยว่าขวดในภาพปริมาตรเท่าไร เราจะหาตัวเลข 750ml, 1,000ml, 1,500ml ด้วยวิธีการอะไร? ระยะเวลาเท่าไร?

.

.

ในการทำ Planning ของ Scrum เราจะใช้ Poker Planning ซึ่งในไพ่จะประกอบไปด้วยตัวเลข Fibonacci เป็นตัวแบ่งปริมาณงาน ตามตัวเลข Fibonacci จากน้อยไปมาก 1,2,3,5,8,13,21

วิธีการเล่น Poker Planing 

1. เตรียม User story ที่จะเข้าไปทำใน Sprint เริ่มแรกทีมอาจจะต้อง Define ตัวเลขขึ้นมา 1 ตัวหนึ่งที่ให้ทุกมีภาพเดียวกัน ที่ทั้งทีมจะทำ User story นี้ให้สำเร็จ 

ยกตัวอย่างเช่น User story : Fix Typo หน้าจอ Login 

ทุกคนในทีมตกลงร่วมกันว่าถ้าจะทำ User story นี้ให้สำเร็จมันคือตัวเลข 1

2. เมื่อได้ Story Point ตุ๊กตาไว้แล้ว เราจะเริ่มนำเล่น Poker Planning โดยเริ่มจาก User story จริง 

PO จะเป็นคนอธิบายขอบเขตของ User story ที่เราเรียกว่า SOW(Scope of work) รวมถึงเปิดโอกาสให้ทีมได้ซักถามข้อสงสัย เมื่อสมาชิกทุกคนเข้าใจขอบเขตของ User Story ทั้งหมดแล้ว

Scrum Master จะเริ่มพาทุกคนยกไพ่ในรอบแรก โดยก่อนเริ่มยกไพ่ Scrum Master จะทวนตัวเลขที่สมาชิกร่วมกัน Define ไว้ตั้งแต่ต้น ว่าในทีมตกลงร่วมกันว่า User story เรื่องนั้นคือ 1 ให้ลองเปรียบเทียบกับ User Story นี้ว่า Effort ที่เราจะทำให้งานเสร็จเป็นกี่เท่า มากกว่า หรือน้อยกว่า หรือเท่ากับ Story Point ตั้งต้น หลังจากสิ้นเสียงทวนคำบอกเล่า ทุกคนจะยกไพ่ Fibonanci ตามตัวเลขที่ทุกคนคิดไว้ 

Scrum Master จะถามทีละคนว่าทำไมถึงให้ Story Point 5 หรือ 3 หรือ 8 เพราะอะไร ทำไมอีกคนให้ Story Point เท่านั้นเพราะอะไร ไล่ไปจนครบทุกคน เพื่อให้ทุกคนได้แชร์มุมมองของตัวเองและรับฟังในมุมมองความเห็นของเพื่อนๆด้วย เพราะอย่าลืมว่าสมาชิกใน Development team คือทีมที่เป็น Cross Functional หมายความว่าทุกคนมีบทบาทหน้าที่และความสามารถและมาทำงานร่วมกันในฐานะทีมเพื่อให้งานสำเร็จด้วยกัน As a team

3. Scrum Master จะพาทุกคนเล่น Poker planning อีก 2 รอบ รวมทั้งหมด 3 รอบ โดยที่รอบที่ 3  Scrum Master ก็จะเลือกตัวเลขที่เป็นเสียงส่วนใหญ่ หรือบางครั้งอาจจะเป็นเลขเดียวกันหมดก็ได้

(ถ้าตัวเลขที่ได้ออกสูงเช่น 13, 21 มีความเสี่ยงว่าจะไม่สามารถทำให้จบได้ใน Sprint นั้น Scrum Team อาจจะเริ่มถามทีมว่าต้องการแบ่ง User Story นั้นหรือไม่ ถ้าทีมตกลงที่จะทำการแบ่งก็จะทำการ Vote Story Point กันใหม่อีกครั้ง)

4. เมื่อทีมมี User story ที่ได้รับการ Vote Story Point ประมาณหนึ่งแล้ว ทีมจะคุยกันและตัดสินใจที่จะเลือก User Story เข้า Sprint 

ยกตัวอย่างเช่น ทีม ตกลงดึงเข้า 5 User Stories (1-5) เข้าไปทำใน Sprint.

User Story#1 : 3

User Story#2 : 5

User Story#3 : 5

User Story#4 : 13

User Story#5 : 2

Total Story Point = 28

เราเรียก ผลรวมของ Story point ในแต่ละ Sprint ว่า Velocity

User Story#6 : 8

User Story#7 : 8

.

.

.

ประโยชน์ที่ได้จากการทำ Planning โดยใช้ Poker Planning

1. สมาชิกทีมได้แชร์มุมมองการทำงานของตัวเอง เพื่อนได้รับฟังมุมมองความรู้ในอีกด้านนึง ทำให้เกิด Knowledge sharing ระหว่างคนในทีม และข้อดีอีกอย่าง ทุกคนจะได้ก็ได้มีมุมมองร่วมกัน เข้าใจกันและกันมากขึ้น

2. ทุกคนในทีมช่วยกันหาความเสี่ยงในความรู้ความสามารถของแต่ละคนบน User story นั้นๆ

3. ทุกคนเข้าใจ User story เป็นภาพเดียวกัน หรือจะเรียกว่ามีเป้าหมายเดียวกันในระดับ User story ก็ได้

4. Velocity ของทีม มีส่วนในการทำ Forecast Planning ของ Product/Project นั้น

5. ช่วยให้ PO เข้าใจในมุมมองทางฝั่ง Development Team

6. ช่วยให้ Development Team เข้าใจมุมมอง Business และมีความรู้ใน Business มากขึ้นทีละนิด รวมถึงปลูกฝังความเป็นเจ้าของต่อ Product (Sense of ownership)

ทิ้งไว้ท้ายสุด

Working Software หนึ่งใน Agile Principle ที่บอกว่าให้มองผลลัพธ์ของตัว Software มากกว่าเอกสารที่แสดงแผนงานที่แม่นยำหรือ Project Status ที่บอกว่า Green, Green, Green แล้วเมื่อถึงเวลาส่งมอบเป็น Red

Hofstadter’s Law บอกไว้ว่า "Humans suck at estimating things."
Parkinson's Law บอกไว้ด้วยว่า "งานที่เสร็จจะขยายระยะเวลาไปตามเวลาที่กำหนด"

Quote คมๆ จากเพื่อน Somkiat.cc

"ที่ผ่านมานั้น เราทำการ Estimate มามากมาย และพบว่าส่วนใหญ่มันไม่ได้ช่วยเหลืออะไรเราเลย แต่เราก็พยายามหาวิธีการ Estimate ให้มันแม่นยำ มันหมายความว่าอะไร !!"