Agile Software Development ตอนที่ 7.2 – Release / Sprint Planning Meeting
สําหรับตอนที่แล้วเป็นเรื่อง Story Point ซึ่งมันเป็นแค่จุดเริ่มต้นของเส้นทางที่เราจะเดินไปเท่านั้น Story Point ช่วยให้เรากําหนดขนาดของ Requirement (อาจจะเป็น Feature หรือ Use Case ก็แล้วแต่ลักษณะของ project หรือ product ที่เราจะพัฒนา) นอกเหนือจากการประมาณการด้วยเวลาตัวเดียว ทําให้เราสามารถนํามาใช้ประเมิน Velocity ของทีมได้ในกรณีที่การวางแผนและประมาณการนั้นไม่สอดคล้องกับความเป็นจริง เพราะไม่ว่าเวลาที่ประเมินจะมากจะน้อยยังไง ขนาดของ requirement ก็เท่าเดิมอยู่ดี
ก่อนไปต่อ…
ขอฝากสิ่งที่จะต้องระวังเกี่ยวกับ Story Point ด้วย ก็คือ
- เมื่อ Requirement เปลี่ยนไป ขนาดของ story point อาจจะไม่เท่าเดิม เพราะฉะนั้นเมื่อมีการเปลี่ยนแปลง requirement อย่าลืมประเมิน Story Point ใหม่ด้วย
- การวางแผน จะขึ้นอยู่กับ Story Point พอสมควร ส่วนใหญ่การประเมิน Story Point จะพลาด ก็ต้องอาศัยประสบการณ์ครับ พยายามดู detail และ case ต่างๆ ที่อาจจะเกิดขึ้นกับ requirement เหล่านั้นด้วย เพราะบางกรณีอาจจะทําให้ Story Point กลายเป็นคนละเรื่องกันเลย
- ในบทความตอนนี้ คุณจะพบอีกหลายจุดที่มีผลกระทบกับ story point ให้นำเรื่องเหล่านั้นมาใช้ทุกครั้งที่ประเมิน story point และ velocity นะครับ
Release Planning Meeting
หลังจากที่ได้รายการของ Product Backlog แล้ว คราวนี้เราก็จะมาวางแผนกันแล้วว่า ทั้ง project ใช้เวลากี่เดือน จะมีกี่ Sprint (iteration) และจะ track งานกันยังไง
Velocity
จากบทความที่แล้ว เราได้ story point และ estimated day (หรือ ideal day) ของแต่ละ requirement มาแล้ว คราวนี้ เราก็มาวางแผนกัน หลักการนั้นง่ายมากครับ คือ
- เอา requirement มาเรียงลําดับตาม priority
- กําหนดช่วงของ Iterationการกําหนดช่วงของแต่ละ iteration นั้น อย่ากําหนดอย่าให้ยาวหรือสั้นเกินไป เพราะถ้ากําหนดไว้สั้น เช่น 1 week (5 business day) งานมันจะเร่งเกินไป เพราะทุกๆ Sprint จะต้องทีการ review และ retrospective meeting แต่ถ้านานเกินไป ปริมาณงานที่ทําต่อ Sprint ก็จะมากเกินไป เช่น 2 เดือนต่อ Sprint เมื่อมีความผิดพลาด เราต้องแก้งานที่ทํามา 2 เดือนให้ถูกต้อง แบบนี้มันไม่ Agile ครับช่วงเวลาที่เหมาะสมจะอยู่ที่ประมาณ 2 – 4 สัปดาห์ ส่วนใหญ่จะกําหนดที่ 1 เดือนตามปฎิทิน เพราะฉะนั้น ใน 1 iteration เราจะมีเวลาอยู่ที่ประมาณ 20 – 22 วันทํางาน (หักวันหยุดสุดสัปดาห์และวันหยุดนขัตฤกษ์) ซึ่งมันจะไม่เร็วและไม่ช้าจนเกินไป
- จากนั้นก็เอา Product Backlog มาดูว่า ในแต่ละ Sprint นั้น The Team จะเก็บ Product Backlog ได้เสร็จกี่ข้อสมมตุว่า แต่ละ backlog มีขนาด 3 story point เท่าๆ กัน เราประเมินกันคร่าวๆ ว่า the team สามารถเก็บไดซ้ก 7 ข้อ เพราะฉะนั้นstorypointทั้งหมดที่น่าจะเก็บได้คือ 7 x 3 = 21 story point นั่นคือเบื้องต้น เราจะได้ Estimated Velocity ของทีมเท่ากับ 21 ครับตอนที่ประเมิน story point เราประเมินเวลาไว้ด้วย อย่าลืมว่าเวลาที่เราประเมินนั้น เป็นเวลาของ developer 1 คนทํา backlog ข้อนั้นจนเสร็จ เช่น story point = 3 ใช้เวลา 5 วันเสร็จ ให้ลองเอาจํานวนเวลาของ backlog ที่เราวางแผนไว้มารวมกัน แล้ว หารด้วยจํานวนของสมาชิกใน the team ดูซิว่ามันเกินเวลาของ sprint หรือไม่ เช่น
- เราประเมินว่า sprint แรกน่าจะเก็บได้ 7 product backlog
- แต่ละ backlog ประเมินไวว่าใช้เวลา 5 วัน เพราะฉะนั้น ถ้า developer คนเดียวทํา น่าจะใช้เวลา 7 x 5 = 35 /man/day
- แต่เรามีสมาชิกของ the team 3 คน เราก็เอา 3 หาร เพราะฉะนั้น 35 / 3 = 12 วัน (ปัดเศษบวกไป 1 วัน)
- แสดงว่า the team น่าจะเก็บงานได้มากกว่านี้ ก็เอา backlog เพิ่มเข้ามาอีก จนกว่าจะลงตัวที่จํานวนวันใน sprint นั้นๆ ซึ่ง Velocity ของทีมอาจจะมากขึ้น หรือลดลงครับ
เป็นไง พอจะเห็นภาพหรือเปล่าครับ สิ่งที่ต้องระวังก็คือ ในระหว่างที่ประเมิน ideal day ของแต่ละ backlog นั้น คุณจะต้องประเมินเวลาที่ใช้ตามสภาพการทํางานจริง เช่น คุณทํางานวันละ 8 ชั่วโมง แต่อย่าลืมว่าคุณไม่ได้นั่งทํางานตลอดเวลา คุณอาจจะต้องรับสายลูกค้า ตอบ email ไปประชุมโน่น นั่น นี่ … เพราะฉะนั้นเวลาประเมินจํานวนวัน อย่าลืมบวกเรื่องนี้เข้าไปด้วย ไม่งั้นเวลาทํางานจริง มันจะใช้เวลามากกว่าที่วางแผนไว้ เค้าเรียกว่า Under-Estimated ไง แต่ถ้าเผื่อมากไปก็กลายเป็น Over- Estimated แต่ส่วนใหญ่จะ under ซะมากกว่า
ขอย้ําว่า การวัด velocity นั้น วัด “ทั้งทีม” ด้วย “story point” ครับ เราทํางานเป็นทีม จะไม่มีการวัดแยกแต่ละคน ถ้ามีปัญหาก็มีกันทั้งทีม ช่วยกันแก้ทั้งทีม รับผิดชอบกันทั้งทีมครับ ไม่งั้นจะเรียกว่า The Team ได้ยังไงละ
เมื่อเราได้ Velocity คร่าวๆ คราวนี้เราก็แค่เอา Product Backlog ทั้งหมดมาวางเรียงลําดับตาม Priority แล้วแบ่ง backlog เหล่านั้นออกเป็น Sprint โดยแต่ละ Sprint อย่าให้จํานวน Story Point เกินจาก velocity เพราะอย่าลืมว่าส่วนใหญ่เราจะทําไม่ทันอยู่แล้ว เพราะฉะนั้นให้เหลือช่องเอาไว้หายใจบ้าง แต่อย่าเหลือช่องเยอะนะครับ เดี๋ยวมันจะนานเกินไป project จะไม่เสร็จเอา เราก็พอจะบอก Product Owner ได้แล้วว่า เราน่าจะใช้เวลาประมาณกี่เดือน (กี่ Sprint) งานจึงจะเสร็จครับ
แล้วเราจะรู้ได้ยังไงว่าที่เราประเมินนั้นจะถูกต้อง เราอาศัยเครื่องมือการติดตามง่ายๆ ที่เรียกว่า Burn-Down Chart ครับ ส่วนการปรับปรุงตัวเลขให้ตรงกับความเป็นจริง เราจะมาทํากันตอน Retrospective Meeting ตอนจบแต่ละ Sprint ครับ
Sprint Planning Meeting
เมื่อเราได้ข้อมูลมาแล้ว ต่อไปเราก็จะต้องเอา requirement ทั้งหมดมาแตกเป็น task เพื่อแบ่งงาน รวมทั้งม้องทํา chart เพิ่ม 2 chart เพื่อติดตามงานและวัด velocity ของทีมจริงๆ กันละ
Burn-Down Chart
เมื่อเราได้จํานวนวันใน Sprint นั้น และจํานวน Story Point แล้ว เราก็เอามาวาดเป็นกราฟครับ โดยกราฟนี้จะมี 2 แกนในแนวตั้งและแนวนอน แนวตั้งนั้นคือจํานวน story point ที่เราประเมินว่าจะเก็บได้ ส่วนแนวนอน คือ จํานวนวันใน Sprint นั้นๆ ตามรูปครับ
เส้นตรงที่ตัดจากแกนตั้งมายังแกนนอน เป็นเส้นจากการคาดคะเนว่า ถ้าทุกวันเราสามารถทํางานเสร็จได้ตามแผน จํานวน story point ควรจะลดลงทุกวัน เราเรียกว่า estimate burn-down ส่วนเส้นสีแดงคือ actual burn-down จะเป็นเส้นที่บันทึกความคืบหน้าในระหว่าง sprint ว่าเราเก็บ story point ได้ตามแผนหรือไม่ โดย plot กราพทุกวัน ถ้าเส้นอยู่ด้านขวาของเส้น estimate แสดงว่าเราเก็บ point ได้น้อยกว่าที่วางแผนไว้ แต่ถ้าเส้นตกลงมาต่ํากว่า แสดงว่า เราวางแผนแบบ over- estimate ครับ
เวลานําไปใช้จริง แทบทุกทีมละครับ ที่เส้น burn-down จะไม่ตกลงที่ 0 คือใน Sprint รอบแรกๆ นั่นเป็นเพราะเราไม่มีประสบการณ์ในการใช้ Scrum มาก่อน เพราะฉะนั้นในตอนที่จบแต่ละ sprint จึงต้องมี retrospective meeting เพื่อปรับค่าเหล่านี้ไงครับ อันนั้นค่อยว่ากันในตอนต่อไป
ในระหว่างที่กำลังประชุม Sprint Planning ให้คุณก็วาดลงบน A4 แล้วเอาไปแปะบนผนังในจุดที่ทุกคนมองเห็นได้ (รวมทั้งหัวหน้าด้วย) มันจะเป็นทั้งแรงกระตุ้นและแรงกดดันที่ดีที่ทําให้เห็นความคืบหน้าของงาน และจะได้ไม่ต้องทําเอกสาร นั่งประชุม หรือเสียเวลาอธิบายให้หัวหน้าเชื่อว่า ตอนนี้งานไปถึงไหนแล้ว พี่อยากรู้ พี่ก็เดินไปดูตรงโน้นเองเลยครับพี่ ^_^
Burn-down Chart 1 แผ่น จะใช้กับ Sprint ปัจจุบันเท่านั้น เมื่อจบ Sprint อย่าทิ้งนะครับ ให้เก็บ Story Point ที่ได้ ไปใช้ประเมิน Velocity ของ Sprint ถัดไป และเก็บไว้อ้างอิงความก้าวหน้าของทีมครับ
Requirement <> Task
รูปแบบหนึ่งของ Scrum ที่แตกต่างจากกระบวนการพัฒนาซอฟท์แวร์ที่ผ่านๆ มา ก็คือ การแบ่งงานกันทํา สังเกตุว่า เราเอา Story Point มาวัดความคืบหน้าของงาน ซึ่ง Story Point นั้น ได้มาจาก Product Backlog หรือ Requirement ไม่ใช่ task … แล้วมันต่างกันยังไงละ? … ต่างกันมากเลยครับ
เมื่อก่อนเวลาแบ่งงานกันทำ ผมจะทำแบบนี้ครับ คือ เมื่อออกแบบได้ประมาณหนึ่งแล้ว เราก็จะแบ่งงานกันทํา ส่วนใหญ่ก็จะแบ่งงานกันตามความสามารถของแต่ละคน รุ่นใหญ่หน่อยก็เอา core ยากๆ ไปทํา รุ่นพี่ก็เอาส่วนหน้าจอหลักๆ ไป เด็กๆ ทํา report แล้วสุดท้ายก็เอามารวมกัน หรือไม่ก็แบ่งเป็น module ไป เช่น คุณเอา inventory ไปนะ คุณเอา AR กับ AP ไป ส่วนผมเอา GL ไป เสร็จแล้วเอามารวมกัน … ปัญหาที่ตามมาก็คือ
- ถ้าทุกส่วนไม่เสร็จ มันคือไม่เสร็จเลย
- ถ้าบางคนเสร็จก่อน อีกคนไม่เสร็จ ถ้ามาช่วยทํา ก็จะเจอไสตล์การเขียนที่ไม่เหมือนกัน ช่วยกันไม่ค่อยจะได้ หรือไม่ก็ตามไม่ทัน เพราะเค้าเริ่มทํากันมานานแล้ว เข้าไปตอนท้ายๆ ก็ช่วยอะไรไม่ได้มาก
- ต้องรอคนที่ทํามาแก้ จึงจะแก้ได้ เพราะกลัวว่าจะไปวาง bug แทนที่จะไปแก้งานให้เค้า (ที่จริงขี้เกียจไล่ code น่ะ -_-!)
ถ้าคุณเอาวิธีการแบ่งงานแบบเดิมๆ มาใช้กับ Scrum … ภาพแรกที่จะพบใน Burn-Down Chart ก็คือ Burn-Down WALL (ผนัง) คือแทนที่เส้นจะค่อยๆ ตกลงมา มันจะไม่ตกเลย จะถึงท้ายๆ ของ sprint มันจึงตกฮวบลงมา เพราะทุกคนเสร็จหมดแล้ว ภาพก็เลยออกมาเหมือนฝาผนังแทน
แต่ในกรณีที่แย่ที่สุด คือ ทุกคนทําไม่เสร็จ แม้จะเหลืออีกนิดเดียวก็ตาม แต่ไม่เสร็จคือไม่เสร็จนะครับ เพราะฉะนั้น เมื่อไม่เสร็จ story point ก็จะไม่ลด เมื่อไม่ลด คุณก็ต้องขยับจํานวนวันของ sprint สุดท้าย คุณก็วัด velocity ไม่ได้อยู่ดี และ ข้อมูลใน sprint ก็จะไม่มีประโยชน์ในที่สุด
Done Done Definition
เชื่อไหมครับว่า ในการพัฒนา software นั้น คําว่า “งานเสร็จ” หรือ done นั้น แต่ละคนมีนิยามคนละเรื่องกันเลย ผมขอไม่ยกตัวอย่างละ แต่ว่าใน Agile Software Development นั้น คําว่า done ต้องหมายความว่า software นั้นพร้อมหรือแทบจะนําใช้งานจริงได้แล้ว ในกรณีที่ต้องมี user manual ถ้ามันยังไม่ได้ทํา ก็ยังไม่ถือว่างานเสร็จ เห็นไหมครับว่าต่างกับที่เราคุ้นเคยมากเลยทีเดียว
คําถามก็คือ เราแบ่ง requirement ออกเป็น product backlog แต่ละข้อ แล้ว Done Definition ของแต่ละ backlog ละคืออะไร … คําตอบก็เหมือนกับย่อหน้าที่ผ่านมา ก็คือ ในภาพใหญ่มีอะไรที่ต้องประกอบกันเป็น software package ที่จะต้องส่งมอบ ในภาพย่อย เราก็จะต้องมีส่วนต่างๆ ที่เกี่ยวข้องกับภาพย่อยเหล่านั้นให้ครบถ้วน จึงจะถือว่าเสร็จครับ ผลที่ตามมาคือ story point และ ideal day ที่คุณประเมินไว้ข้างต้นนั้น ครอบคลุมเรื่องเหล่านี้หรือไม่? ถ้าไม่ครอบคลุม กลับไปประเมินใหม่ตอนนี้เลยครับ ^_^
แต่ในบางกรณี เราทําแบบนั้นไม่ได้ทั้งหมด ในกรณีนี้อย่างน้อยที่สุด backlog ที่ถือว่าเสร็จแล้ว จะต้องมีการ test แล้ว และ test จะต้องผ่านด้วย ทั้งการ test แบบเดี่ยวๆ การ test เมื่อ integrate กับส่วนที่เสร็จแล้วก่อนหน้านี้ หรือกรณีที่เป็น app บน mobile ต้องผ่านการ test กับอุปกรณ์จริงแล้วเท่านั้น เป็นต้น จึงจะถือว่าเสร็จจริงๆ
เพราะฉะนั้นก่อนที่จะลงมือทํา ขอให้ทีมตกลงกันก่อนครับว่า Done หมายความว่าอะไร แบ่งเป็นข้อๆ เลยครับว่าต้องมีอะไรบ้าง หนึ่ง สอง สาม แล้วเอา check list นั้นมาดูว่าผ่านหมดหรือไม่ ข้อมูลเหล่านี้จะต้องถูกนําไปประกอบกับการ estimate และประเมิน velocity ครับ ไม่งั้นเราจะ estimate พลาดอยู่ตลอดครับ … และ … เป็นอีกครั้งที่คุณต้องกลับไปแก้ Story point ครับ … คุณประเมิน Stroy Point โดยเอา Done Definition เข้าไปร่วมประเมินด้วยรึเปล่าครับ?
Scrum the Backlog
เมื่อการแบ่งงานเป็น module แล้วแบ่งๆ กันไปทํา มันเกิดปัญหา burn-down wall เราก็ต้องเปลี่ยนวิธีการทํางานใหม่ แบบนี้ครับ เนื่องจาก backlog แต่ละข้อคือ requirement ให้เรา
- เอา requirement แต่ละข้อนั้น แบ่งออกเป็นงาน หรือ task ที่เราต้องทําเพื่อให้ product backlog ข้อนั้นกลายมาเป็น software จริงๆ
- ช่วยกันเขียน test case ออกมาว่า ต้อง test อะไรบ้างก่อนลงมือเขียน code
- แต่ละคนช่วยกันทํา (รุม scrum) task เหล่านั้นให้เสร็จไปเลย
- ถ้าใครเสร็จงานของตัวเอง ให้ไปช่วยงานของคนอื่นทันที
- ถ้าตัวเองไม่เหลือ code ให้เขียน รีบไปช่วย test
- ทำจนกว่าจะไม่เหลือ task ที่ต้องทำใน Done Definition
ถ้าทําแบบนี้ requirement ข้อหนึ่งๆ ใช้เวลาไม่นานมากครับ อย่าเกี่ยงว่างานนี้ไม่ใช่สิ่งที่ตัวเองถนัด เพราะใน Scrum ไม่แบ่ง role ทุกคนเป็นสมาชิกของ The Team จำได้ไหมครับ … บางคนบอกว่า ผมทำ Graphic ไม่เป็น อืมมม … ไม่อยากทำเป็นบ้างเหรอครับ … หรือถ้าไงๆ ก็ไม่ได้ งั้นก็ไป test นะ test เป็นใช่ไหม ^_^
คําถามที่มักจะเจอก็คือ มันจะไม่เสียเวลามากกว่าเดิมหรือ คําตอบคือ ในช่วงเริ่มต้นจะเสียเวลามากกว่าเดิมครับ เพราะคุณไม่เคยทํางานแบบนี้ บางคนที่ทํางานเร็ว จะทํางานช้าลง เพราะต้องทำส่วนอื่นมากขึ้น ต้อง test มากขึ้น พูดมากขึ้น แต่สิ่งที่ได้คือ knowledge จะ share มากกว่าเดิมครับ ทุกคนจะส่วนร่วมกับงานแทบทุกส่่วน แต่เมื่อทําไประยะหนึ่ง เมื่อทุกอย่างเข้าที่เข้าทาง คุณจะพบว่าภาพรวมของ project มันไปได้เร็วกว่าต่างคนต่างทําครับ เพราะคุณไม่ต้องเสียเวลามานั่งรําลึกเมื่ออีกคนเกิดปัญหา ไม่ต้องเสียเวลามานั่งไล่ code
นานๆ เมื่อต้องไปช่วยคนอื่น และไม่ต้องหายใจทิ้งไปวันๆ เพื่อรองานของคนอื่นที่ยังทําไม่เสร็จ และ (โดยอุดมคติที่ต้องทำให้ได้ …) ไม่มีคนนั่งเฉยๆ โดยอ้างว่าช่วยแก้ไม่ได้เพราะตัวเองไม่ได้เขียน … ประสิทธิภาพโดยรวมจึงต่างกันครับ และที่สําคัญ เมื่อเสร็จ 1 backlog … burn-down จะลดฮวบลง The Team จะรู้สึกเลยว่า เออ งานคืบหน้าแบบจับต้องได้จริงๆ นะ เพราะเห็นกันจะๆ และได้ที่เสร็จแล้วเนี่ยะ run ได้ด้วยนะเออ ^_^
ในกรณี Product Backlog ข้อไหนที่ไม่เสร็จ เราจะไม่นับ Story Point เมื่อจบ Sprint นะครับ ย้อนกลับไปดู Done Definition ครับ… ไม่เสร็จคือโชว์ไม่ได้ ใช้จริงไม่ได้ เพราะฉะนั้น ห้ามขยายวันของ Sprint ออกไปเด็ดขาด ไม่เสร็จก็ตัดออกไปเลย แล้วเอา Backlog ข้อนั้นไปรวมกับ Sprint ถัดไป แต่ประเมิน Story Point ใหม่ โดยดูจากปริมาณงานที่เหลือ แล้วนําไป plan Release ใหม่ เพราะเมื่องานเก่าทําไม่เสร็จ งานที่ยังไม่ได้ทําก็ต้องล่าช้าแน่นอน เพราะฉะนั้นเราจะบอกได้ทันทีตั้งแต่ Sprint แรกๆ เลยว่าสิ่งที่เรา plan ไว้นั้นคลาดเคลื่อนขนาดไหน ที่เหลือก็ค่อยๆ ปรับกันไปโดยใช้วิธีการเดิมๆ นี่แหละครับ ค่อยๆ ทํา ค่อยๆ แก้กันไป
Task Board
ในระหว่างที่กําลังประชุม Sprint Planning Meeting นอกจาก Burn-down Chart แล้ว เราจะมีเครื่องมืออีก 1 ตัวสําหรับ track งาน คือ Task Board ครับ เอากระดาษแปะบนผนังซักด้านหนึ่งของห้องทำงาน แล้ววาดออกมาอันใหญ่ๆ เลย แบบนี้ครับ
เราแบ่ง column ง่ายๆ ตาม state ของแต่ละ Product Backlog โดยใน column แรก คุณเขียน Product Backlog ลงไป 1 แผ่น ต่อ 1 ข้อ แล้วระบุ Story Point และ Estimated Day ของ backlog ข้อนั้นลงไปด้วย จากนนั้ ใน column “Planned” ให้เอากระดาษ post-it (ในรูปใช้สีเขียว) เขียน Task ทจี่ ะต้องทําเพื่อ implement software ให้ได้ตาม requirement ข้อนั้น 1 task ต่อ 1 แผ่น … ใน Scrum จะเรียก Task เหล่านี้ว่า Sprint Backlog ครับ
เมื่อเริ่มทํางาน ใครต้องทํางานไหน ก็เอางานของตัวเองไปแปะในช่อง “In Progress” แล้วเขียนชื่อตัวเองลงไปด้วย เมื่อเสร็จแล้ว ต้อง test ก็เอาไปแปะไว้ใน Testing ครับ
ส่วนกระดาษสีเหลือง ผมเพิ่มเติมลงไปให้ คือ Test Case ครับ บ่อยครั้งที่การ test ถูกละเลยไปและงานส่วน test มักจะไม่ได้ถูก track ด้วย ไม่ยากเลยครับ ให้มองว่าการ test ก็คือ task ของ backlog ข้อนั้นๆ ด้วย เมื่อเริ่ม implement ให้ใส่ test case ลงไปด้วย เพื่อจะได้รู้ว่า backlog ข้อนี้ต้อง test เรื่องอะไรบ้าง case ไหนบ้าง นึกอะไรออกก็ใส่ลงไปเลย ยิ่ง test เยอะยิ่งดี อย่ารอจน programmer เขียนเสร็จแล้วค่อยเขียน test case นะครับ เพราะถ้าไปเขียนตอนนั้น มันไม่ทัน อย่าลืมว่าถ้า test ไม่เสร็จ จะไม่ถือว่า backlog ข้อนั้นเสร็จ เพราะฉะนั้น เขียน test case จาก requirement ไปพร้อมๆ กับตอนเขียน task นั่นแหละครับ ด้วยวิธีการนี้ ทีม test และทีม develop จะทำงานร่วมกันอย่างใกล้ชิดโดยไม่แบ่งเป็นคนละทีมอีกครับ
การทำ Sprint Planning Meeting จะทำทุกครั้งก่อนเริ่ม Sprint นั้นๆ นะครับ เพราะเป็นไปได้ที่ Velocity และ Burn-Down Chart มันไม่เป็นไปตามแผน เราก็ต้องมาปรับแผนกัน เพื่อให้แผนใกล้เคียงกับความเป็นจริงทุกๆ ครั้งที่ Sprint ครับ
Conclusion
ก่อนจะจบ บางคนอาจจะคิดว่า นี่แหละคือสิ่งที่ต้องการ แล้วลงมือทําเลย อย่าเพิ่งใจร้อนครับ มันมีอะไรมากกว่านั้นอีกนะ และบางคนอาจจะรู้สึกตงิดๆ ว่า มันจะเอาไปใช้จริงได้เหรอ … ผมขอบอกตรงๆ เลยครับ ไม่ใช่ว่ามันใช้ได้หรือไม่ได้หรอกครับ ที่จริงแล้วมัน “ไม่พอ” ต่างหาก
ปัญหาอย่างหนึ่งก็คือ ข้อมูลทั้งหมดที่เอามาวางแผนนั้น มันเบลอมาก มันเหมือนพยายามมอง product สุดท้ายโดยที่มีม่านหมอกมาปกคลุม เทคนิคที่ผมนํามาใช้ประกอบก็คือ การร่าง screen คร่าวๆ เพื่อบอกว่า product ที่ได้จะมี screen ยังไง user ใช้งานยังไง วาดด้วยมือนี่แหละครับ โดยระหว่างทําไป ก็ตรวจสอบความถูกต้องไปมา คือ cross check ไปเรื่อยๆ ว่าหน้าจอนี้ครอบคลุม requirement มั้ย แล้ว requirement นี้ต้องมีหน้าจอยังไง กดตรงนี้ อะไรโผล่ เป็นต้น จากประสบการณ์ของผม ถ้ามี screen, mock up หรือ prototype เมื่อไหร่ งานมักจะไปได้คล่องเสมอ … บางคนอาจจะบอกว่า อ้าว งั้นทํา mock up ก็พอมั้ง … ผมขอไม่ตอบนะครับ ถ้าอ่านมาตั้งแต่ตอนแรกๆ คุณน่าจะรู้คําตอบนี้อยู่แล้ว
ยิ่งถ้ารู้เรื่อง UML และ OOA&D ด้วยแล้ว เราสามารถนําความรู้เหล่านั้นมาประกอบกับการใช้ Scrum และ Agile ได้ดียิ่งขึ้นด้วย เพราะแนวทางการวิเคราะห์และออกแบบของ OOA&D ประกอบกับ UML บวกกับ Agile จะทําให้ภาพของ screen ที่เราร่างออกมาคร่าวๆ นั้น ตรงใจ user มากที่สุดโดยที่จะช่วยให้ไม่ทําให้ requirement มันหลุดไป อีกทั้งยังทําให้เราสามารถเก็บรายละเอียดพร้อมทั้ง design ไปในเวลาเดียวกันได้อีกด้วย … เรื่องนี้เป็น Topic ใหญ่ครับ จบจากเรื่อง Agile แล้ว ถ้ามีโอกาสคงได้มาเล่าให้ฟังเป็นตอนต่อๆ ไป ครับ
ขอฝากไว้ว่า ไม่ว่าเราจะเลือกใช้ process แบบไหนก็แล้วแต่ แต่สุดท้ายผู้ที่นําไปใช้ก็คือคนเรานี่เอง และคนเรานี่แหละจะเป็นตัวแปรหลักที่ทําให้มันสําเร็จหรือล้มเหลว ปัจจัยหลักก็อยู่ที่การทํางานร่วมกันอย่างมีประสิทธิภาพและความเป็นมืออาชีพ Agile เน้นให้แต่ละคนต้องทํางานอย่างมีวุฒิภาวะ ทั้งงานตัวเองและงานของทีม ถ้าสมาชิกในทีมมีทัศนะคติตรงกันข้ามกับที่ว่ามา ก็ลืมไปได้เลยครับ อย่าเสียเวลาทําเลย เพราะฉะนั้น ประเมินก่อนนําไปใช้นะครับว่า องค์กรหรือทีมของคุณ มีสภาพแวดล้อมเหมาะสมที่จะทําให้ Agile เกิดได้รึเปล่า
ในตอนต่อไป ผมจะพูดถึง Stand up Meeting, Sprint Review Meeting, และ Sprint Retrospective Meeting ครับ ที่จริงถึงตอนนี้คุณก็พอจะเอาแนวทางพวกนี้ไปทดลองกับ project เล็กๆ ได้แล้ว แต่ meeting ทั้ง 3 ตัวที่จะพูดถึงนั้น มันจะเป็นส่วนที่ทําให้ Agile สมบูรณ์ตาม Agile Principle และ Manifesto ครับ แล้วเจอกันครับ ^_^
ขอบคุณครับที่แบ่งปันความรู้และประสบการณ์ออกมาเป้นบทความที่ยอดเยี่ยมมาก
รออ่านบทความต่อไปอยู่นะคะ เขียนแล้วอ่านเพลินดีค่ะ ขอบคุณมากๆ เลยค่ะ
Leave your response!
ป้ายกำกับ
หมวดหมู่
Blogroll
เรื่องล่าสุด