Prerequisite: ก่อนอ่าน post นี้ ผู้อ่านควรทำความเข้าใจกับคำว่า user story ก่อนนะคะ ตามอ่านได้ที่นี่นะคะ กดเลย มองหน้าหาเรื่อง
ขั้นตอนหนึ่งของการสร้าง user story คือการให้ point หรือ คะแนน กับ story นั้น ว่าจะต้องใช้ effort กับมันมากแค่ไหน
คำถามที่ถูกถามบ่อย: แล้วเค้าทำกันยังงัย? รู้ได้งัยว่าเป็นคะแนนที่เหมาะสมแล้ว? แล้วใครเป็นคนทำ? บลาๆๆๆ
Planning poker เป็นวิธีการของการให้คะแนนกับ story เหมือนกับเล่นไพ่ โดยที่แต่จะคนจะได้รับแจก card ชุดหนึ่ง ถือไว้กับตัว โดยการ์ดนี้จะเรียงเลขไปตาม Fibonacci (0,1/2,1,2,3,5…) โดยเราจะนำแต่ละ story มาโหวตกัน ว่าคุณคิดว่า ควรจะให้คะแนนกับ story นี้เท่าไหร่
คำถาม: แล้วเราจะให้เท่าไหร่ดีล่ะ แนวคิดเป็นอย่างไร
คำตอบ:
โดยปกติแล้วนั้น ความหมายของตัวเลขคร่าวๆ คือ
0 = story ที่สร้างขึ้นเพราะกลัวจะลืมทำ แต่ไม่สำคัญเท่าไหร่
1 = story ที่สร้างขึ้นเพื่อ confirm ว่าเราจะทำอันนี้เสร็จแน่นอน เช่น เอา google calendar API มาแปะในหน้า page (ง่ายมาก แต่ต้องทำ)
2 = คะแนนเริ่มต้นของ story ที่เริ่มจะมีเรื่องมีราว แต่อาจจะไม่ซับซ้อนมาก
…
…
ยิ่งเลขเยอะ ก็เป็นสัญญาณว่า ต้อง split ออกมาให้ย่อยลง
ถ้าเป็นการ์ดเครื่องหมายคำถาม ? คือ คิดไม่ออกว่าจะเสร็จตอนไหน
การ์ดรูปถ้วยกาแฟ คือ พักเหอะว่ะ – -”
จริงๆ แล้ว มันไม่มีมาตรฐานที่แน่นอนของการให้คะแนน ส่วนใหญ่เราจะให้คะแนนโดยการเปรียบเทียบกับงานอื่นๆ แทนที่จะมานั่งคิดว่าสิ่งนี้ทำนานแค่ไหนจึงจะเสร็จ เพราะมันยากที่จะคิดมากกว่า เช่น งาน A ยากกว่า B ก็ ให้คะแนน A สัก 3 และ B สัก 2 ละกัน เป็นต้น (สำหรับเรื่องนี้ พี่แป๋มยกตัวอย่างการมองตึก ถ้ามองว่าตึกนี้สูงกี่ชั้น มันยากกว่าการมองกว่า ตึกนี้ สูงกว่าตึกข้างๆ เท่าไหร่ ครึ่งนึง หรือสองในสาม เป็นต้น)
คำถาม: แล้วทำไมต้องเรียงไปตาม fibonacci???
คำตอบ: เพราะไม่อยากมานั่งเถียงกันว่า story นี้ ควรได้คะแนน 7 หรือ 8 เพราะเลขที่ใกล้กันเกินไป ก็ทำให้มองไม่เห็นความต่าง
เตรียมพร้อมก่อนโหวต
อ่ะ คราวนี้ ตอนจะโหวต ทุกคนก็ต้องเข้าใจก่อนว่า story นี้ทำงานอย่างไร และมีคำถามอะไรที่สงสัยก็ถามไป ก่อนจะโหวตกัน เป็นช่วงเวลาที่ตื่นเต้นพอสมควร เพราะเราจะสงสัยตัวเองว่า เราจะโหวตเหมือนคนอื่นหรือเปล่าหนอ?? กลัวคิดบ้าๆ ไปคนเดียว 555
พร้อมจะโหวตแล้ว!!!
โชว์การ์ดของท่านขึ้นมาซิ ให้คะแนนกันเท่าไหร่บ้าง ????????
แต่ละคนจะโชว์การ์ดที่เลือกขึ้นมา (ด้วยความตื่นเต้น) เราก็จะได้ตัวเลขที่แต่ละคนคิด ซึ่งก็จะแตกต่างกันออกไป เราจะดูเสียงข้างมากเอา และคราวนี้ก็จะมาคุยกันค่ะ ว่าคนที่คิดต่างจากคนอื่น คิดอย่างไร ด้วยเหตุผลใดบ้าง และก็มาคุยให้จบที่ตัวเลขเดียวกัน
แล้วเราก็จะได้คะแนนสำหรับ story นั้น ไปอย่างเอกฉันท์ อย่างเป็นประชาธิปไตย ไม่มีเสื้อสีใดเลย!!
ประโยชน์ที่ได้คือ
1. ได้การ estimate ที่แม่นยำ เพราะมาจากคนหลายคนช่วยกันคิด
2. ทุกคนได้เข้าใจงานใน story นั้นอย่างแท้จริง และอาจจะทำให้เกิดการ split งานไป story อื่น หรือแก้ไขรายละเอียด ในขั้นตอนนี้
3. ตอนโหวตเสร็จ ก็จะได้รู้ว่า แต่ละคนเข้าใจตรงกันจริงหรือไม่ เพราะหากโหวตคะแนนแตกต่างกันมาก แสดงว่าอาจจะมีอะไรเข้าใจผิดก็ได้
4….. ใครคิดออกอีก ช่วยบอกด้วยได้ไหมคะ???
คราวนี้ การให้คะแนน story ก็ไม่อยากอย่างที่คิดแล้ว จริงไหมคะ? ^^
หากมีข้อสงสัย ติชม หรือมีอะไรเพิ่มเติม ก็รบกวนเลยนะคะ
มีภาพเหตุการณ์จริงมาฝาก เกิดขึ้นวันนี้เอง (18 March 2010)
Planning poker session ที่ Proteus ทำความเข้าใจก่อน vote
Pokers ของจริง ใช้จริง ที่ Proteus!!!
vote 2 points ให้กับ story เกี่ยวกับการส่งอีเมลล์อัตโนมัติไปยังผู้ใช้
เสริม(อีกแล้ว)จ้า
story point เป็นคะแนนความยาก ความซับซ้อนของ story นั้นๆนะครับ ไม่ใช่ “เวลา” ซึ่งปกติมันจะสัมพันธ์กันแต่จริงๆ มันคือคนละเรื่องเดียวกัน
เวลา estimate ให้คิดคลุมไปถึง definition ของ “done” สำหรับขบวนการเรา ซึ่งในนั้นย่อมไม่ได้มีแค่เราคนเดียวที่เกี่ยวข้อง มันอาจเกี่ยวกินไปถึงแผนกข้างเคียง
เพราะคำว่า done ของแต่ละองค์กรณ์ไม่เหมือนกัน (อันนี้ต้องนิยามและตกลงกันเอง) อาจจะเป็น integration test ผ่าน, acceptance test ผ่าน, QA approved, มี essential document หรือแม้แต่น้ำหมึกลายเซ็นต์ CTO ก็เป็นได้
บางเรื่อง code ง่ายแต่ test ยากก็มี เหตผลเพราะอะไรไว้เป็นอีกประเด็น จะเอาที่ระดับไหน extreme แค่ไหนคงต้องแล้วแต่สภาพองค์กรณ์กันไป แต่ขั้นต่ำมันต้อง executable, deployable ได้เป็นอย่างน้อย
เวลาคะแนน story point ออกมาเห็นต่างกันหลายช่วงตัวต้องเปิดใจรับฟังกันและกัน ทำใจเป็นกลางและระลึกถึงคำว่า “ทีม” และ “done” นั้นหมายความว่าอะไรเสมอ
คนที่มีสิทธิ์จะ estimate ได้คือคนที่ “ลงมือลงแรง” และคือคนที่ทำ agile ด้วยกันเท่านั้น เค้าเหล่านั้นคือคนที่เขียน code คนที่ทำ test คนที่ทำ graphic หรือคือคนที่เขียน document ก็เป็นได้ ส่วน manager,owner มีสิทธิ์แค่อธิบายให้รายละเอียด story และกำหนด priority เท่านั้น
สิ่งที่อยู่ใน sprint ของเราคือสิ่งที่เรา “ตั้งมั่น” ว่ามันจะถูกส่งมอบ
manager ไว้ใจให้เรา estimate เองแล้ว เรามีหน้าที่ตอบแทนความศรัทธานั้น
เพราะฉะนั้นพยายามไม่หลงประเด็น พึงระลึกไว้เสมอว่า “Estimation is not Negotiation” แยกประเด็นให้ขาด เราประเมินเพื่อจะวางแผน ตัวเลขที่ออกมามันควรสะท้อนความเป็นจริงเพื่อเราจะได้รับมือกันสถานการณ์ในอนาคต ถ้า dead line ทุกอย่างมัน fixed ไปหมด มันเป็นปัญหาของ manager ไม่ใช่ของเรา
เค้าอาจจะ repiority story ใหม่เพื่อให้เรื่องที่สำคัญจริงๆ มันอยู่บนสุด ตัดซอยฟีเจอร์ หา resource เพิ่ม หรือใช้ลมปากเสน่หาในการเจรจาก็ว่ากันไป
เรื่องพวกนี้มันเป็น skill set ที่เค้าต้อง(ควร)มีอยู่แล้ว อย่าลืมว่า ถ้าทุกเรื่องมันสำคัญมากเท่ากันหมด นั่นก็หมายความว่าจริงๆ แล้วไม่มีเรื่องไหนสำคัญเลยได้เหมือนกัน
=============
เสริมแต่พองามจ้า
estimate เพื่อสะท้อนความจริงนั่นคือจุดมุ่งหมายสูงสุด ถ้าข้อมูลมีความแม่นยำสูง มันไม่ยากเลยที่จะทำนายอนาคต
ผมคิดว่านิยาม story point ของแตละองค์กรคงไม่เหมือนกัน ตามหลักควรต้อง estimate ในแง่ ความเสี่ยง (risk) กับระยะเวลา (ideal time) บางเรื่องอาจยากที่จะออกแบบแต่ถ้าเจาะออกแล้วจะใช้เวลาทำแปีบเดียว ในขณะที่บางเรื่องรายละเอียดงานเยอะต้องใช้เวลาทำนาน
ปกติเรื่องที่โหวตแล้วมีความเสี่ยงสูง จะต้องนำมาโหวตใหม่อีกรอบ หลังจากที่มีการวิเคราะห์รายละเอียดให้มากขึ้น เช่นต้องมีการทำ dev tasking เพื่อแจงรายละเอียดที่ชัดเจนกว่า ที่ระบุไว้ใน narrative ที่ BA เขียน ปกติ tech lead จะมอบหมาย dev tasking ให้ักับ pair ที่มีประสบการณ์ หรือหลายๆกรณี ต้องไปคุยเพิ่มกับ user เพิ่ม
การ์ดใดๆไม่ควรนำไปทำ จนกว่าคนทำเข้าใจรายละเอียดเพียงพอว่าจะทำได้อย่างไร ดังนั้นการ estimate การ์ดที่ไม่เป็น high risk จึงเป็นการ estimate ตามเวลาเสียมากกว่าครับ
ขอบคุณที่ share ครับพี่
ผมว่าพี่ต้อง blog ที่นี้บ้างแล้วละ
ขอบคุณที่ share ครับพี่
ผมว่าพี่ต้อง blog ที่นี่บ้างแล้วละ
บลอกไปสองเรื่องแล้วนะ
ผมหมายถึงเรื่องนี้แบบละเอียดนะครับ ชอบ
ที่ทีมผมใช้กันอยู่ ตัวเลขหมายถึงเวลา อย่าง 1/2 หมายถึงครึ่งวัน 0 หมายถึงสามารถทำเสร็จได้ไม่เกิน 1 ชม.
และ Planning poker มีไว้สำหรับ Task โดย Task เกิดจากการนั่งวิเคราะ story ว่าต้องมี Task อะไรบ้างเช่น
1. setup database
2. coding core
3. coding ui
เป็นต้น
สมัยตอนที่ทีมผมเข้า CMMi assessment มีคำถามนึงที่น่าสนใจก็คือ ตัวเลขที่ developer แต่ละคนให้มานั้น ได้มาจากไหน และก็จะตอบกันว่า ได้มาจาก Historical Data คนที่ตั้งคำถามก็จะถามต่อว่า แล้วมีการเก็บ Historical Data ที่ไหน คำตอบก็คือ ไม่ได้เก็บครับ จากประสบการณ์ล้วนๆ
ซึ่ง point นี้ก็เป็น finding ตัวนึงเหมือนกัน
ผมว่า จริงๆแล้วการที่เราเก็บ historical data สำหรับงานแต่ละประเภท แล้วทำเป็นฐานข้อมูลเก็บไว้ มันก็พอจะช่วยได้เพิ่มเติมในการทำ estimation ของ developer ให้ได้ตัวเลขที่แม่นขึ้น เพราะว่างานของ developer แต่ละทีม น่าจะคล้ายๆกัน คงไม่ขนาดฉีกแหวกแนวไปมากจน historical data นั้นใช้ไม่ได้เลย
ใช่ค่ะ เห็นด้วยเลย สำหรับ planning poker นี้ ก็อาจจะมีการใช้ historical data มา brief ด้วยก็ได้ หรือถ้าอยู่ทีมเดียวกัน เคยทำงานด้วยกันอยู่แล้ว ก็จะง่ายขึ้น
แหล่มเลยครับ
เก็บ history คร่าวๆ ที่เคยทำมาไว้เช่นกัน เพื่อให้เวลาที่กำหนดหรือ vote มานั้นตรงกับความเป็นจริงมากยิ่งขึ้น
สำหรับ agile แล้ว story point ของ sprint ก่อนๆ คือ historical data ฉันดีเลยครับ
สูตรฟิสิกส์ความเร็ว V = S/t
ถ้าเรารู้ความเร็วเฉลี่ยของทีมเรา เราเอาไปทำนายต่อไปได้ทั้งในระยะสั้นและระยะยาวได้หลายคำถาม เช่น
เรายังเล่นตามกำหนดการอยู่หรือเปล่า?
โปรเจ็กต์ใหม่ถ้าใช้ทีมเดิมควรจะปิดได้ในกี่อาทิตย์?
sprint นี้ความเร็วดีกว่า sprint ที่แล้วมันเกิดอะไรขึ้น?
ถ้า track กันละเอียดว่าใครทำ story ไหนบ้างเราจะได้ความเร็วระดับบุคคลเลยทีเดียว กลายเป็น KPI วัด performance ที่ใช้ได้เลยครับ
ใช่ค่ะๆ เอาไปทำ burn chart ได้กราฟรายคนเลย
ถึงวัดเป็นรายคนได้ก็ไม่สมควรทำครับ ทางปฏิบัติไม่น่าจะวัดได้ด้วยซ้ำ เพราะทำงานเป็นคู่ และสลับคู่ตลอดเวลา
ที่บอกว่าไม่สมควรทำเพราะ การวัดผลควรวัดที่ผลงานรวม มิฉะนั้นแต่ละคนจะทำเพื่อให้ผลของตนดีกว่า โดยไม่มองภาพรวม ปัญหา local maxima/global maxima เป็นดาบสองคมเสมอ
น้องเก๋ล่า พี่ค่อนข้างเห็นด้วยกับพี่ SweetCorn ล่ะ เดี๋ยวหลังไมค์กันดีกว่า หุ หุ
การใช้ ความเร็ว (velocity) ระดับบุคคลมาวัด KPI นั้นเป็นดาบสองคมอย่างที่คุณ sweetcorn กล่าวไว้ครับ ถ้าวัดกันที่ใครเร็วสุดท้ายก็จะแข็งกันเร็วแทนที่จะช่วยเหลือกัน ถ้าจะนำ velocity มาใช้อยากให้เน้นว่ามันคือ team velocity จะเร็วจะช้าเราก็รับผิดชอบร่วมกัน สิ่งนี้มีผลทางด้านจิตวิทยาสูงเอาการนะครับ
ประโยชน์อีกอย่างของ story point / team velocity ที่ Ben มักจะพูดเสมอคือมันเป็นตัวป้องกันไม่ให้เกิด manager math ขึ้น คือการที่ manager มาคำนวนว่าโปรเจคนี้มี 6 คน estimate ว่าจะใช้เวลา 4 เดือน ฉะนั้นถ้าใส่เข้าไป 12 คน เทียบบัญญัติไตรยางค์แล้วก็จะเสร็จใน 2 เดือน แต่คนท้อง 3 คนไม่สามารถคลอดลูกได้ใน 3 เดือนฉันท์ใด ซอฟต์แวร์โปรเจคก็ไม่สามารถเทียบบัญญัติไตรยางค์ได้ฉันท์นั้น team velocity บอกได้ว่าทีมนี้จะช้าเวลากี่ iteration คร่าวๆ จะเสร็จ และ velocity นี้เป็นของคนในทีมนี้เท่านั้น ถ้ามีคนเพิ่มลดก็ต้องคิด velocity กันใหม่
ที่สำคัญมากอีกอย่างคือ velocity ใช้เป็นตัวบอกว่าใน iteration นี้จะรับ story แค่ไหน จะทำอะไรก่อนหลัง วันไหนเมื่อไหร่ เป็นสิ่งที่ self-organized team จะต้อง manage เอง ไม่จำเป็นจะต้องมากะเกณฑ์กันเป็นรายชั่วโมงรายวัน กล่าวคือกรุณาอย่างเอา velocity มาเทียบออกมาเป็น man-day (ใช้ manager math) เพราะถ้าจะทำอย่างนั้นก็อย่าใช้ velocity เลย
อีกอย่าง estimate ไม่ใช่ commitment นะครับ estimate เอาไว้ plan เมื่อ plan จบแล้วที่เหลือก็คือช่วยกันทำให้ดีที่สุดให้ได้ตามที่ estimate ไว้ ฉะนั้นระวังอย่าจมอยู่กับการ planning poker จนไม่มีเวลาทำงานจริง ต้องจัด balance ให้ดีด้วย
เอาภาพเหตุการณ์จริงที่บริษัทมา add เพิ่มค่ะ ดูได้ท้าย blog ^^
access denied
แก้ไขให้แล้ว ขอบคุณค่ะที่แจ้งให้ทราบ -/\-
เพื่อนผมตอนทำ Planning poker ด้วยกัน มันยกขึ้นมาสองใบ (1) กับ (1/2) -*-
โดน SCRUM (v.) รอบโต๊ะ
ประโยชน์ที่ผมได้จากการ estimate point ก็ คล้ายๆกับคุณ deans4j.wordpress.com
คือได้ team velocity ครับ สามารถนำมาคำนวณ คร่าวๆ ได้ ว่าจะต้องใช้ effort ในการจบ product ที่เลือกมาทำ โดยประมาณเท่าไหร
หาได้จาก sprint เดิมๆ ดูค่าเหวี่ยงต่างๆ ประกอบ ว่าทีม under/over estimate อะไรยังไง
ดู effort หน่วยเป็น ชม. ของ task ใน user story
ผมมีไฟล์ backlog อยากจะเอามาแชร์ แต่ไม่อยากแนบ link ในนี้ ครับ ทำยังไงดี