ต่อเนื่องจากเรื่อง scrum board ติดเรื่อง burndown chart ที่ทีมผมใช้เอาไว้ว่ามีหลักการคิดยังไง
วิธีการทำ Burndown chart มีหลายวิธี วิธีที่ทีมผมเลือกใช้ เป็นวิธีที่มองว่าทำง่ายเข้าใจง่าย และใช้ติดตาม progress ได้ดี
แต่ก่อนจะถึง Burndown chart ต้องอธิบายก่อนว่า Planning poker ที่ผมใช้นั้น จะใช้เป็นจำนวนวันที่ใช้ทำ task จริงๆ มิใช่การใช้ point เหมือนหลายๆท่าน ทีมผมมองว่าาการคิดเป็นวันเลยมันตรงตัวดี ไม่ต้องคำนวน ไม่ต้องคิดมาก เข้าใจง่าย คนมาใหม่อธิบาย 1 นาทีก็เข้าใจแล้ว
Burndown chart ก็มีองค์ประกอบง่ายๆ คือ แกนของจำนวนชั่วโมงของ Task กับ timeline ของ sprint ว่าแต่ละวันเหลือเหลืออีกกี่ชม.
สูตรการคำนวนก็ง่ายๆครับ ทีมผมให้ความสำคัญกับ Story ที่ทำมากกว่า ความสุขของพนักงาน (555+) เพราะมองว่า priority หลักคืองาน ความสุขของพนักงานลองลงมา (พูดเล่นนะ) วิธีการคือ เลือก Story ที่ต้องการให้เสร็จภายใน sprint นี้ขึ้นมาตาม priority แตก Task ประเมินวัน จากนั้นเอาจำนวนวันที่ได้มาหารกับจำนวนวันของ sprint ซึ่งทีมผมใช้ sprint ละ 10 วันได้เป็นสูตรง่ายๆคือ
Focus Factor = (จำนวนชม.ของ task/จำนวนคน) / จำนวนวันของ sprint
เช่น
sprint นี้หลังจากประเมิน task แล้ว ใช้เวลา 21 วัน มีคนอยู่ 3 คน ก็จะใช้ focus factor ทั้งหมดเป็น (21/3) / 10 = 70% แต่คนเราต้องมีเวลาทำกิจกรรมอื่นๆด้วยก็บวกเพิ่มอีก 10% เป็น buffer ซึ่งจะได้เป็นมี focus factor ทั้งหมด 80% สำหรับ sprint นี้
เมื่อก่อนเคยมีอยู่ครั้งหนึ่งได้ focus factor 120% แปลว่าหากจะทำงานให้เสร็จจริงต้องทำ OT นั่นเอง 555+ แต่ผมเลือกเพิ่มวัน sprint แทนครับ
วิธี track งานก็ง่ายๆครับ แค่นับจำนวนชม.ที่เหลือที่อยู่ในส่วนของ Not Check out + Check out + Next ก็จะได้สามารถ plot graph ได้แล้ว ซึ่งไม่ต้องคำนวนใดๆเลย
ตัวอย่างตามภาพ (แอบเอา sprint ปัจจุบันมาใช้ซะเลยขี้เกียจนั่งเทียน 555+)
Burndown chart
จากภาพแสดงให้เห็นถึง progress ของงานใน sprint วันที่ 1-12 เป็นระยะเวลา 2 สัปดาห์ โดยจะ plot graph ในทุกๆวันที่ทำ scrum meeting ตอนเช้า โดยจะ plot graph ของเมื่อวานนี้ ซึ่งจะเห็น progress ของงานว่าแต่ละวันจะเหลืองานอีกกี่ชม.
ในวันที่ 9 เกิดเหตุการณ์ว่ามี requirement พิเศษที่มี priority สูงมากและต้องทำจึงเกิด unplan task ขึ้นมา 5 tasks แต่เนื่องจากเป็น story ที่ไม่ยากประกอบกับทำ performance มาดีจึงไม่กระทบกับ plan มากนัก วันรุ่งขึ้นก็สามารถดึง graph ให้ลงมาอยู่บนแกนได้ตามเดิม
ง่ายไหมเอย?
ไม่แน่ใจว่าจะเกี่ยวกับ topic นี้หรือเปล่า แต่ในทีมเจอปัญหาคำว่า “เสร็จ” ของแต่ละคนมันไม่เหมือนกันอ่ะครับ ต้องมารีเวิิร์คใหม่หลายรอบกว่าจะเสร็จแบบจริงๆ บางทีก็ต้องลำบากคนอื่นในทีมอีก
พอมีการกำหนดเวลา มักเจอปัญหาแบบนี้อ่ะครับ
“เสร็จ” มีไม่เหมือนกันได้ด้วยเหรอ?
หมายถึงคุณภาพงานหรือเปล่าเอย…
แล้วประโยคที่ว่า “พอมีการกำหนดเวลา มักเจอปัญหาแบบนี้อ่ะครับ” แปลว่าปกติทำงานแบบไม่มีกำหนดเวลาหรือเปล่าครับ?
การทำงานต้องตั้งเป้าหมาย
เวลา เป็นหนึ่งในเป้าหมายที่ต้องมี
เสร็จของทุกคนต้องเหมือนกันค่ะ ถ้ามี test มาคลุม ถ้า code เขียนแล้วผ่าน test หมด ก็แสดงว่าเสร็จ ดังนั้นเราต้องออกแบบ test ให้ครอบคลุมกับ requirement ก็จะทำให้รู้จุดเสร็จของงาน ตรงจุดเดียวกันค่ะ
estimate แบบใช้ “เวลา” เพียงอย่างเดียว มีปัญหากับการประเมิญงานระยะยาวหรือเปล่าครับ หมายถึงการ estimate ล่วงหน้าไกลๆ เช่นทำ release plan/milestone plan เป็นต้น
ยังไม่เคยมีครับ ประเด็นคือไม่ค่อยทำ estimate ไกลๆมากๆ หากมีก็จะตัดแบ่งเป็น phase ย่อยๆ phase หนึ่งใช้เวลาประมาณ 1-3 sprints
ผมอ่านเรื่อง story point ในหนังสือชื่อ Agile Estimating and Planning ผมเข้าใจว่า การนำ story point มาใช้ ก็เพื่อ estimate “ขนาด”ของ user story ให้สามารถบอกได้ว่า ถ้า user story หนึ่งเราเคย plan ไว้ว่าจะใช้เวลาเท่านี้ แต่พอทำงานจริงกลับใช้เวลามากกว่า ก็แสดงว่า user story อื่นที่มี story point (ขนาด) เท่ากัน ก็น่าจะใช้เวลามากกว่าที่ plan ไว้เหมือนกัน …
ในหนังสือยกตัวอย่างเรื่องการไปทานอาหารในร้านอาหารที่เราไม่เคยไปกิน ผมขอยกตัวอย่างให้เข้ากับบ้านเรา … เอาเป็นเกาเหลาข้าวเปล่าละกัน … โดยปกติก็จะมีแบบธรรมดากับพิเศษ จากประสบการณ์ผมเองจะสั่งพิเศษเสมอ เพราะถ้าสั่งธรรมดา มันไม่อิ่มครับ … สมมตุว่าเราไปเจอร้านเปิดใหม่ ผมไม่รู้ว่าธรรมดาหรือพิเศษมันจะมีขนาดไหน แต่จากประสบการณ์ที่ผ่านมา ถ้าจะให้อิ่มต้องพิเศษ แน่นอนว่ามันก็อาจจะมากกว่าหรือน้อยกว่าที่คิดก็เป็นได้ แต่อย่างน้อยผมก็มีตัววัดจากประสบการณ์ที่ผ่านมาพอที่จะให้เรา estimate “ขนาด” ได้ว่า ธรรมดาไม่น่าจะอิ่มนะ ขอพิเศษไว้ก่อน … (นั่นเป็นแนวทางในการกำหนดขนาดหรือ story point ให้กับ user story)
เช่นเดียวกันกับ story point เมื่อเริ่มแรกเราเจอ user story เราจะไม่รู้เลยว่า user story แบบนี้เราควรใช้เวลาเท่าไหร่จึงจะทำเสร็จ เพราะฉะนั้นก็เลยมีตัววัด 2 ตัว คือ “ขนาด” ของ user story และ “เวลา” ที่จะ implement story ที่มีขนาดนั้นให้ “เสร็จ” (Done Done!; design, code, test, deliver for that story)
การกะ”ขนาด”ของ user story คิดว่าน่าจะทำได้ไม่ยาก เช่น user story “แสดงรายการสินค้า” กับ “แสดงรายชื่อลูกค้า” น่าจะมีขนาดพอๆ กัน สมมตุว่าให้ user story ทั้ง 2 อันเป็น 30 point ส่วน story อื่นที่มี CRUD ก็อาจจะให้เยอะหน่อยซัก 50 point เป็นต้น (ที่ให้หลัก 10 เพราะถ้ามี story ที่มีขนาดระหว่างกลางของ 4 กับ 5 จะได้ไม่ต้องกำหนดเป็น 4.5 หรือมาปรับ point กันใหม่ให้วุ่นวาย กำหนดเป็น 45 ไปเลย)
สมมุติว่าผม plan เวลาของ story แรกไว้ 3 วัน แต่ทำจริงกลับใช้เวลาถึง 4 วันจึงเสร็จ เพราะฉะนั้นก็เป็นไปได้ที่ story ที่ 2 ที่มี story point เท่ากันก็น่าจะใช้เวลา 4 วันจึงจะเสร็จเหมือนกัน ส่วนจะ 4 วันจริงหรือไม่ เมื่อจบ story ที่ 2 (หรือทำการ retro แล้ว) ก็น่าจะสรุปได้ว่าที่ story point ขนาดนี้ เราใช้เวลาจริงเท่าไหร่ ยิ่งมีประสบการณ์มากขึ้น การกำหนด “ขนาด” และ “เวลา” ก็จะใกล้เคียงกับเวลาที่ใช้จริงมากขึ้นเรื่อยๆ
เพราะฉะนั้น ความสำคัญของ story point ไม่ได้อยู่ที่ตัว point ที่ assign ให้ user story แต่ความสำคัญอยู่ที่การใช้บอกความสัมพันธ์เกี่ยวกับขนาดของ user story เพื่อประเมินเวลาที่ใช้ในการ implement นั่นเอง (The raw value we assign is unimportant. What matters are the relative values.)
ส่วน burn down chart ก็เป็นกราฟ x,y ของ story point เทียบกับ work day สำหรับแต่ละ iteration เพื่อ estimate ว่า ใน 1 iteration ทีมเราสามารถทำงานให้จบได้กี่ story point เช่น ทีมเราสามารถทำได้ทั้งหมด 20 story point ต่อ 1 iteration การเลือก user story ก็ต้องเลือก story ที่มี point รวมไม่เกิน 20 point นั่นเอง (ตามลำดับ priority ของ user) ถ้า user story ไหนไม่เสร็จ point ที่เก็บได้จะเป็น 0 (take all or nothing) ต้องไปโปะใน iteration หน้าแทน
ด้วยวิธีนี้ ก็น่าจะช่วย estimate overall ของ project ให้เห็นภาพได้ชัดเจน คล้ายๆ กับ Gantt chart นะ เพราะถ้า story หนึ่งใช้เวลามากกว่าที่คิด ที่เหลือก็น่าจะ shift ตามไปหมดจาก story point ที่ relate กัน
มีใครใช้ story point แนวนี้ในการ estimate และวัดความคืบหน้าของ project รึเปล่าครับ เพราะที่ผ่านมาผมก็ไม่เห็นประโยชน์ของการ estimate ด้วย story point จนได้มาอ่านหนังสือเล่มนี้ครับ
ผมใช้ครับ และไม่คิดจะกลับไปใช้อย่างอื่น แล้วจะมาลองเล่าให้ฟังนะครับ
ถ้าแบบนี้โปรแกรมเมอร์ทีมนี้ก็มีความสามารถเท่ากันหมด? มีปัญหาเรื่องการประเมินประสิทธิภาพของทีมหรือเปล่าคะ? แต่จริงๆ แบบนี้ก็ดีเหมือนกันนะคะ เพราะเก๋มาแอบคิดว่า การให้ point เนี่ย บางทีถ้าเรากำหนดพลาด มีปัญหาเรื่องความยุติธรรมในทีมอีก ถ้าทุกคนได้รับสิ่งตอบแทนในการทำงานเท่ากัน
แต่ก็แอบคิดอีกว่า ถ้าไม่กำหนด point ตามความสามารถของคนที่ทำงาน อาจจะทำให้แรงจูงใจในการทำงานลดลงก็ได้ เพราะจะไม่เห็นค่าความสามารถที่สูงขึ้นของตัวเอง
Anyway, เก๋เห็นวิธีที่คุณ bomber ใช้ ง่ายจริงๆ ค่ะ ง่ายกว่าของเก๋เยอะเลย และคิดว่าได้ผลเหมือนกันด้วยในระยะนี้เพราะว่า point ที่เก๋คิดตอนนี้ อยู่บนพื้นฐานที่ว่าทุกคนทำงานได้เท่ากัน เลยมี point เท่ากัน 555+ ดังนั้น เอาตัวแปร point หรือ เวลา มาคิด ก็คงไม่ต่างกันในกรณีของเก๋ค่ะ แถมของคุณ bomber ง่ายกว่าอีก
เรียกว่าเข้าใจงานไม่เท่ากันดีกว่าครับ คนเก่งไม่ได้แปลว่าจะทำเร็วเสมอไป คนที่เคยทำงานนี้อยู่ก่อนแล้วอาจจะทำได้เร็วกว่าก็ได้
เวลาทำ planning poker บาง task มักมีเสียงแตกแยกกัน เช่น บางคนให้ 1/2 day บางคนให้ 1 day บางคนก็ให้ 3 day หากออกมาในรูปนี้แสดงว่ามีคนที่เข้าใจงานที่ต้องทำมากกับคนที่ไม่เข้าใจเลย
ประเด็นคือเราต้องการให้ทุกคนสามารถหยิบได้ทุก task ดังนั้นวันที่ให้ต้องใกล้เคียงกันมากๆ ดังนั้นเมื่อเกิดเหตุการณ์แบบนี้ แต่ละคนต้องอธิบายว่าทำไมถึงให้วันที่ต่างกัน เมื่ออธิบายกันจนเข้าใจแล้ว ค่อยเล่น poker ใหม่ ทำไปเรื่อยจนกว่าจะได้วันที่ใกล้เคียงกัน
คุณค่าของความสามารถ ผมว่าไม่ได้อยู่ที่ point หรอกครับ อยู่กับว่าทีมและหัวหน้าแสดงว่าเห็นคุณค่าเขาหรือเปล่าต่างหาก
การทำ sprint demo ช่วยได้มากนะครับเป็นเวทีที่ทำให้คนได้แสดงความสามารถ
sprint demo มันคือะไรคะ??????????????? (สงสัยมาก 55+)
Sprint Demo คือทุกครั้งที่จบ Sprint เราจะมี Working software ออกมาใช่ไหมครับ ทีมผมจะจัดให้ Developer มา Proudly Present ผลงานของตัวเอง ว่าแต่ละส่วนทำขึ้นมาได้อย่างไร ใช้เทคนิควิธีการอย่างไร
คือใน Agile เราจะไม่ค่อยเน้นเรื่อง Design เพราะส่วนใหญ่ก็จะแค่ คิดๆ คุยๆ ทำๆ มีไอเดียวิธีการอะไรก็แลกเปลี่ยนกันคุยกันแล้วทำเลย อย่างมากก็วาดใส่เศษกระดาษ
Sprint Demo จะเป็นโอกาศอันดีที่จะเอาเทคนิคและไอเดียต่างๆที่ใช้ เอามา Present ให้ทั้งทีมตัวเองและทีมอื่นๆได้ฟัง คำว่า present คือต้องเตรียมตัว present อย่างจริงจังนะครับ มี slide มีเอกสารประกอบ วาดรูปพร้อมแสดง demo software ที่ทำออกมาได้จริงๆ ประโยชน์คือ ได้แชร์ความรู้, ได้แสดงความสามารถ, ได้ฝึกการ present, ได้ภูมิใจกับผลงานตัวเองที่ทำ การทำ sprint demo จะสนุกมากครับ developer จะตั้งใจทำงานมากขึ้นมาก เพราะอยากอวดความสามารถตัวเองให้ทีมตัวเอง และทีมอื่นๆได้เห็น ผลงานจะมีคุณภาพขึ้น งานจะมีเทคนิคใหม่ๆตลอดเวลา design งานก็จะดีขึ้นตาม
ที่สำคัญเราจะได้ เอกสาร design ของงานจาก present ที่ทำด้วยครับ อิอิ
โอ้วววววววววววววววว
เจ๋งมากเลยค่ะ!!! ดูดี มีประโยชน์ เก๋จะจำไปใช้บ้างนะคะ ขอบคุณค่ะ ^^
idea Sprint Demo นี่เจ๋งมากครับ!
อย่างหนึ่งที่ได้จาก Agile คือการเตือนให้เรานึกออกว่าจริงๆแล้วเขียนโปรแกรมมันสนุก Sprint Demo เข้ากับประเด็นนี้ได้พอดีเลย
ถ้าเป็นทีมที่คนในทีมมีความถนัดต่างกันไปคนละด้าน เช่นบางคนเก่งปั้น domain model บางคนปั๊มหน้าจอได้ไว กรณีแบบนี้ทำ ถ้า planning game ทำโดยอิงความสามารถตัวเอง อย่างไรก็จะได้ task ที่ point ไม่เท่ากันหรือเปล่าครับ?
ครั้งแรกที่ประเมิน ก็จะไม่เท่ากันและแตกต่างกันมาก บางคนให้ 1/2 วัน บางคนให้ 3 วัน สิ่งสำคัญคือการคุยกัน Scrum board ทุกคนต้องหยิบได้ทุก Task ดังนั้นทุกคนต้องเข้าใจ Task และงานที่ต้องทำ คนที่ให้ 1/2 วันต้องอธิบายให้คนให้ 3 วันเข้าใจว่าแนวทางการทำ task นี้ทำอย่างไร อธิบายจนกว่าจะเข้าใจ พอให้ประเมินอีกรอบ ก็อาจจะกลายเป็น 1/2 วัน กับ 1 วันแทน ซึ่งก็จะใกล้เคียงกันแล้ว ทีนี้ก็จะดูเสียงส่วนใหญ่แล้วว่าให้เวลาเท่าไร ถ้าส่วนใหญ่ 1/2 วัน task นี้ก็จะถูกใส่ว่าใช้ 1/2 วัน
พอมาพูดประเด็นนี้ ก็คิดมาได้อีกอย่าง สมมติว่าในทีมมีความถนัดต่างกัน (ไม่เอา domain กับ GUI แบบตัวอย่างนี้นะคะ เพราะอันนี้มันเป็นไปได้และก็ไม่แปลก) เช่น คนนึงถนัดคิวรี่ข้อมูล คนนึงรู้ business คราวนี้พอจะทำงานแต่ละงานใน story ก็ต้องอาศัยคนอย่างน้อย 2 คนจึงจะทำให้ story เสร็จ
หากเป็นไปตามประเด็นนี้ สงสัยว่า
1. มันยัง agile อยู่ไหม? ถ้ายัง agile อยู่ อ่าน ข้อ 2 และ 3 ต่อค่ะ
2. หากเราแบ่งงานจนกระทั่งทั้งสองคนอาจจะทำแยก story กันได้ (แต่เอาจริงๆ คิดว่าไม่น่าจะแยกได้ แต่อยากสมมติไปก่อนนะคะ) แบบนี้จะคิด point อย่างไร (เพราะมันเป็น point ของลักษณะงานที่แตกต่างกัน) และหากไม่คิด point แต่คิดเป็นเวลาแทน จะเกิดปัญหาหรือไม่
3.หากใน story นั้นสรุปว่าต้องใช้คนมากกว่า 1 คนจริงๆ เราจะคิด point อย่างไร และหากคิดเป็นเวลาแทน จะเกิดปัญหาหรือไม่ และจริงๆ มันเป็นไปได้ไหม ที่ 1 story จะถูก assign ให้คนมากกว่า 1 คนเพื่อจะจบ story เดียวกันนั้น
ทราบดีว่า no silver bullet แต่ก็อยากได้ best practice เช่นกัน ^^
เอ…ถามกลับนะครับ ปกติไม่แตก story ให้กลายเป็น task หรือครับ?
แต่ผมก็สงสัยอยู่ดีว่า คนเขียน query เขียน business logic ไม่เป็น? คนเขียน business เป็นเขียน query ไม่ได้เหรอครับ? เพราะปกติแล้วคน 2 คนนี้ก็ต้องทำได้ทั้งคู่เพียงแต่อาจจะถนัดแต่ละส่วนต่างกัน เวลาแตก task ก็ต้องคุยกัน ทั้ง 2 คนก็จะเข้าใจว่ามันต้องทำอย่างไรบ้าง และถ้าพอถึงเวลาทำแล้วติด ก็คุยกันได้อยู่ดีนิ
ส่วนบาง task ก็เป็นไปได้ที่ต้องใช้ 2 คนทำเพราะมันยากมาก หากใช้คนเดียวทำอาจจะเกิดการผิดพลาด คือ ต้อง pair กันนั่นเอง task แบบนี้ประเมินว่าใช้เวลา 3 วันแต่ใช้ 2 คน ก็คิดง่ายๆ ว่ากลายเป็น 6 วันนั่นเอง แต่ task card จะเขียนว่า 3 วัน x 2 คน และเวลาทำ burndown จะถูกนับเป็น 6 ชม. สำหรับ task นี้ แต่อย่างไรก็ดี task นี้ต้องเสร็จใน 3 วัน
ตอนนี้ผมเองยังไม่ได้ลอง burndown chart เลย แต่อยากมากๆ พี่ช่วยอธิบาย chart รูปตัวอย่างได้มั้ยครับ ผมงงตรงที่เราจะได้อะไรจาก ตรงนี้บ้างหน่ะครับ
หลักๆแล้วก็จะทำให้เห็น progress ภายใน sprint ว่ามีความคืบหน้าแค่ไหนเป็นไปตามเกณฑ์ที่ควรจะเป็นหรือไม่
- ถ้า graph ไล่ตามเส้นแกนอยู่เรื่อยๆ แสดงว่าปลอดภัยดี
- ถ้าต่ำกว่าแกนแสดงว่า progress เร็วกว่าที่ประเมิน
- ถ้าอยู่สูงกว่าแกนแปลว่าอันตรายอาจจะเสร็จไม่ตรงเวลา
แกน x คือ timeline ตั้งแต่วันที่เริ่ม sprint จนจบ sprint
แกน y คือ จำนวนเวลาที่ใช้ใน sprint ขึ้นอยู่กับว่าภายในทีมมีกี่คน เช่น sprint 1 มี 10 วัน คนทำ 4 คนก็จะมีเวลาทั้งหมดเป็น 10 วัน x 3 คน = 30 วัน เป็นต้น
แต่เราก็ไม่ได้ใช้เต็ม 30วัน x 8ชม = 240 ชม. คือปกติเราต้องทำงานอื่นๆหรือมีช่วงเวลาพักด้วย ดังนั้นจะมีช่วงเวลาทำงานจริงๆประมาณ 80% เรียกว่า focus factor ดังนั้นเวลาที่จะใช้ทำ project จริงๆอยู่ที่ 240 x 80% = 192 ชม คิดเป็น 24 วัน
ฺิburndown ที่ผมใช้อยู่จะเป็นการ track ทั้ง release ที่ประกอบด้วยหลายๆ iteration ครับ แต่ใน iteration นั้นก็จะใช้แต่ story board แทน ผมใช้เป็น story point เพราะได้รับวิชามาจาก Ben Scherrey และ Mike Cohn ปัญหาที่เจอคือ ไม่สามารถใช้ทั้งทีม vote point ก่อนทั้ง release ได้ เพราะจะใช้เวลานานเกิน เลยใช้วิธีให้ lead estimate release แต่ team estimate iteration แทน กะว่าจะเข็นเป็น blog ถัดไปครับ