- Individuals & Interactions > Process & Tools
- Working Software > Comprehensive Document
- Customer Collaboration > Contract Negotiation
- Responding to Change > Following Plan
12 Agile Principles
- Customer Satisfaction
- Changing Requirement
- Frequent Delivery
- Measure of Progress
- Sustainable Development
- Close Cooperation
- Motivated Individuals
- Face-to-Face Conversation
- Technical Excellence
- Simplicity
- Self Organizing Team
- Regular Adaption
Sprint
- Sprint Planning
- Sprint Execution
- Spring Review
- Spring Retrospective
Other Note
Sprint Planning
Product backlog
ระยะเวลา Sprint
Team Member
Prioritization backlog
Sprint Goal
Sprint Backlog
User Story Brainstrom
Break Down to Task
Sprint Demo
- Sprint Planning
o Sprint Planning Meeting ไม่ควรเกิน 0.5 วัน
o Sprint 1: สร้าง Product Backlog / Project Backlog เพื่อรวมรายการความต้องการหลักๆ ทั้งหมดของ Project ซึ่งเป็นผลผลิตจากการวิเคราะห์ความต้องการที่ระบุไว้ใน Requirement specification เราสามารถเรียก Product backlog ว่า Project backlog ได้เช่นกัน
o ตัวอย่าง Product Backlog ประกอบด้วยข้อมูลดังนี้
Epic ID: ลำดับกลุ่ม User story
Epic Name: ชื่อของกลุ่ม User story
Epic Description: คำอธิบายเพิ่มเติมของกลุ่ม User story
User story: User story ของ Epic หนึ่งๆ
Size: ขนาดของ User Story เมื่อเทียบกับ User story อื่นๆ ใน Backlog เราใช้ Size เพื่อให้เห็นภาพว่า User story นี้ต้องการเวลาในการพัฒนามากน้อยเพียงใดเมื่อเทียบกับ User story อื่น
Status: สถานะของ User story ว่าได้ถูกนำไปพัฒนาแล้วหรือยัง สถานะมีค่าดังนี้
To Do ยังไม่มีการนำ User story ไปพัฒนา
Take ได้มีการนำ User story ไปพัฒนาแต่การพัฒนายังไม่เสร็จ
Done การพัฒนาเสร็จแล้ว
Team: ทีมที่พัฒนา
Comments: ข้อมูลเพิ่มเติมที่ทีมต้องการ note
เมื่อ Sprint planning เริ่มต้นผู้นำ Project จะต้องนำ discussion ให้ทุกคนได้เคียร์ขอสงสัยหรือความไม่เข้าใจเกี่ยวกับ Requirement ซึ่งจำเป็นอย่างยิ่งที่ Product owner (ลูกค้าหรือบุคคลที่ความเข้าใจธุรกิจและความต้องการของลูกค้า) ร่วม Sprint planning
หลังจากที่ทุกคนได้คลายข้อสังสัยและไม่มีข้อข้องใจเกี่ยวกับ Requirement แล้ว ทุกคนในทีมก็เริ่มเขียน User story ต่างๆ ที่ได้จากการวิเคราะห์จาก Requirements เขียนลงกระดานหรือ notepad และให้ทุกคนได้อธิบาย User story ที่ตนเขียน
สุดท้ายให้ทุกคนได้ร่วมกันจัดหมวดหมู่เข้า Epic และให้ความสำคัญของ Epic เพื่อบันทึกลง Project Backlog โดย Epic ที่สำคัญควรอยู่ด้านบนของ Backlog
ขั้นตอนสุดท้ายคือการกำหนด Size ของ User story โดยทุกคนร่วมกันกำหนด Size เริ่มจาก Epic ที่สำคัญที่สุด
หลังจากที่เราได้ Product backlog กันแล้ว พักเบรกการประชุมสัก 10 นาที ประชุมเกินสองชั่วโมง สมองไม่แล่นแล้ว พักคุยเรื่องเรื่อยเปี่อยสร้างความสัมพันธ์อันดีภายในทีมสักหน่อย
ขั้นตอนต่อไปเป็นกระบวนการกำหนด Sprint ซึ่งเป็นขึ้นตอนที่ต้องทำเหมือนๆกันในทุกๆ Sprint
ระยะเวลา Sprint ต้องกำหนดตั้งแต่เริ่มต้น
ระยะเวลา Sprint ที่แนะนำคือ 2-3 สัปดาห์
เมื่อสิ้นสุด Sprint ทีมจะต้องมี Sprint demo แสดงผลงานซอฟแวร์ที่ผลิตและลูกค้าสามารถใช้งานซอฟแวร์ได้
ระยะเวลาของ Sprint สามารถแตกต่างกันได้ในแต่ละ Sprint ในกรณีที่มีหลายทีมทำงานใน Project backlog เดี่ยวกัน ควรจะใช้กำหนดระยะเวลา Sprint เท่ากัน เพื่อมี Sprint demo ในวันเดียวกัน โดยทีมควรกำหนดเวลาและสถานที่ของ Sprint demo และส่ง email เชิญทุกคนที่เกี่ยวข้องโดยเฉพาะลูกค้า หรือ Product owner
แบ่งทีมใหญ่เป็นทีมย่อย
เมื่อได้ระยะเวลา Sprint แล้ว แบ่งทีมประมาณ 6 – 12 คน Scrum
แต่ละทีต้องมี Tester อย่างน้อย 1 คนเพื่อตรวจสอบคุณภาพก่อนสิ้นสุด Sprint และเลือก Scrum master 1 คน เพื่อเป็นผู้ช่วยเหลือและอำนวยความสะดวกให้กับสมาชิกในทีม
สมาชิกในทีมสามารถหมุนเวียนเป็น Scrum master ในแต่ละ Sprint ได้หากสามาชิกมีความเข้าใจใน Requirements เป็นอย่างดี
สมาชิกในทีมก็สามารถย้ายไปทีมอื่นได้เมื่อสิ้นสุด Sprint แต่ไม่สามารถย้ายไปทีมอื่นเมื่อ Sprint ได้เริ่มขึ้นแล้ว
Scrum เหมาะกับทีมขนาดเล็ก แต่สามารถมีหลายทีมทำงาน Product backlog เดี่ยวกัน โดยแต่ละทีมจะต้องตกลงกันว่าจะรับผิดชอบ Epic ใดบ้างใน Sprint นั้นๆ หรือถ้า Epic ที่สำคัญที่สุดมีขนาดใหญ่ หลายทีมอาจทำงานใน Sprint เดี่ยวกันแต่เลือก User story ที่ต่างกัน ถ้าจำได้ในตอนที่แล้วเราได้นำเสนอ Product backlog ซึ่งมีชื่อทีมที่รับผิดชอบแต่ละ User story
Product owner จะต้องจัดลำดับความสำคัญของ Epic เพื่อที่ทีมจะได้เลือก Epic/User story ที่สำคัญมาพัฒนาตามลำดับ
เมื่อแต่ละทีมได้เลือก Epic/User story สำหรับ Sprint นี้แล้ว แต่ละทีมสามารถแยกย้ายเพื่อไปสร้าง Sprint goal และ Sprint backlog เฉพาะกลุ่มของตนเองได้แล้ว
ต้องกำหนด Sprint goal เสมอ
สมาชิกของทีมจะต้องกำหนด Sprint goal ร่วมกันโดยกำหนดขอบเขต Functions ที่จะพัฒนา
ตัวอย่างเช่น ทีม A ได้เลือก User Authorization สำหรับ Sprint นี้ แต่ด้วยระยะเวลาและจำนวน Developer ไม่สามารถพัฒนาทุก User story ของ Epic นี้ได้จึงกำหนด Sprint goal ดังนี้ ผู้ควบคุมระบบสามารถสร้าง แก้ไข และ ลบ Role ได้ จาก Sprint goal นี้ทำให้รู้ว่า User story เกี่ยวกับการสร้าง User จะไม่ได้ถูกนำมาพัฒนาใน Sprint นี้
การสร้าง Sprint goal มีความจำเป็นต่อสามาชิกในทีมเพราะช่วยจำกัดขอบข่ายงานได้อย่างชัดเจนและเป็นตัวช่วยในการวัดความสำเร็จของ Sprint อีกด้วย
Sprint backlog - Copy from product backlog
Brain storm เพื่อให้ได้ User story ที่มีความละเอียดเพียงพอและครบตาม Requirements
User story ที่คัดลอกมาจาก Product backlog จะไม่ละเอียดพอที่จะทำการพัฒนาได้ ทีมสามารถ Brainstorm สร้าง User story ที่มีรายละเอียดมากยิ่งขึ้น
Sprint backlog - After brainstorm
การ Brainstorm นี้ก็ทำเหมือนกับตอนสร้าง Product backlog คือให้ทุกคนในทีมเขียน User story ลง Notepad แล้วอธิบายให้ทีมเข้าใจว่า User story ของตนเกี่ยวกับอะไรและยกตัวอย่างสถาณการณ์จริง หรือ Business requirement ที่ User story ตอบสนอง
Tester ในทีมจะมีประโยชน์อย่างมากในขั้นตอนนี้เพราะจะสามารถเชื่อมโยงระหว่าง Test case ต่างๆ กับ User story และช่วยทีมมั่นใจว่า Requirements ต่างๆ ได้ครอบคลุมโดย User story ทั้งหมด
เมื่อได้รายการของ User story แล้ว ให้ Product owner จัดลำดับความสำคัญและความครบถ้วนของ User story และทุกคนในทีมร่วมกันกำหนดขนาดของ User story แล้วบันทึกลง Sprint backlog
การกำหนดขนาด User story ใช้หลักการเปรียบเทียบระหว่าง User story ว่ามีความซับซ้อนมากน้อยกว่ากัน โดยไม่ต้องลงรายละเอียดเหมือน Story points จุดประสงค์เพียงต้องการให้เห็นถึงความใหญ่ของจำนวนงานทั้งหมดในมุมมองของทีม
หลังจากที่ได้ Sprint backlog ที่มีรายการ User story ทั้งหมดแล้ว ทีมสามารถตัดสินใจร่วมกันว่าสามารถพัฒนา User story ในระยะเวลาที่กำหนดได้หรือไม่ ถ้าไม่สามารถทำได้ ก็สามารถย้าย User story บางอันไปไว้ที่ Product backlog เพื่อพัฒนาใน Sprint ถัดไป
Product owner ต้องมีส่วนร่วมให้การตัดสินใจเสมอเพราะการย้าย User story กลับไปที่ Product backlog จะส่งผลกระทบให้ Functions บางอย่างเลื่อนระยะเวลาส่งมอบออกไป
Break down to tasks
Sprint backlog - final version after break down to tasks
เมื่อทีมได้ Sprint backlog ที่มั่นใจว่าสามารถทำเสร็จได้ภายใน Sprint นี้แล้ว ขั้นตอนต่อไปคือการ Break down to tasks หรือลงรายละเอียดในระดับงาน (Task) โดยแต่ละงานควรสามารถทำเสร็จได้ภายในหนึ่งวัน เพื่อให้ Developer สามารถรายงานผลความคืบหน้าในแต่ละวันได้
ในระหว่างที่ Break down to tasks นั้น ทีมควรตกลงร่วมกันว่าจะนำเสนอผลการพัฒนาของ User story นี้อย่างไรใน Sprint demo เพื่อให้ Developer ที่จะพัฒนา User story นี้ได้มีเป้าหมายไปในทางเดียวกัน
Sprint demo
จัดขึ้นทุกวันสิ้นสุด Sprint เพื่อนำเสนอผลการพัฒนาให้กับ Product owner และทีมต่างๆ อีกทั้งให้บุคคลต่างๆ ภายนอกทีมได้ร่วมแสดงความคิดเห็นและรับรู้เกี่ยวกับความคืบหน้าของ Project อีกด้วย
รูปแบบของ Sprint backlog มีลักษณคล้ายคลึงกับ Product backlog แต่จะมีรายละเอียดเพิ่มเติมมากขึ้นดังนี้
Task : งานของ User story
Status: สถานะของงาน
To Do ยังไม่มีการนำไปพัฒนา
Take อยู่ระหว่างการพัฒนา
Done การพัฒนาเสร็จแล้ว
Verified เมื่อ Tester ได้ตรวจสอบความถูกต้องเรียบร้อยแล้ว
Developer : ผู้พัฒนา
Co-developer : ผู้ร่วมพัฒนา ในกรณีที่ใช้ Pair programming approach หรือมีผู้ร่วมคิด Solution ของแต่ละงาน
กำหนดสถานที่และเวลาของ Scrum
ขณะนี้ทีมได้ Sprint backlog ที่สามารถทำงานได้แล้ว สิ่งสุดท้ายที่ต้องตกลงกันก่อนเสร็จสิ้น Sprint planning คือจะ Scrum กันที่ไหน และเวลาเท่าไร เพื่อเป็นการตกลงอย่างชัดเจนและทุกคนในทีมต้องร่วม Scrum ทุกวัน
Retrospective meeting
คือการให้ทีมมองกลับไปว่าระหว่าง Sprint มีอะไรที่ดีที่ทีมควรทำต่อไป หรือสิ่งไม่ดีที่ควรปรับปรุง ตัวอย่างเช่น
ข้อดีของ Sprint ที่ผ่านมา
Story ที่เลือกมาใน Sprint นี้เสร็จตรงตามเวลา
Scrum ตรงเวลาและไม่นานเกินไป
มีการ Demo ให้ Tester ดู การทำงานของ Feature ใหม่ ก่อนที่ Tester จะทำการ test
ข้อเสียของ Sprint ที่ผ่านมา
มีเวลาเตรียมตัว Sprint demos น้อยเกินไป
Developer ไม่ได้ test feature ก่อนส่งให้ Tester ทำให้มี Defects หรือ Bugs เยอะ
ข้อควรปรับปรุง
หยุด Develop และ Test หนึ่งวันก่อนวัน Sprint demos เพื่อให้ทุกคนในทีมทำการเตรียม Software และ Hardware สำหรับ Sprint demos หนึ่งวันเต็มๆ
Developer ต้อง test อย่างน้อย Positive test cases ก่อนส่งให้ Tester
ความสำเร็จเป็นสิ่งที่ดีที่สุดในการสร้างทีม
ทีมจะมีความรู้สึกเป็นทีมมากขึ้นเมื่อได้ร่วมสร้างความสำเร็จร่วมกัน
Retrospective meeting เป็นอีกหนทางหนึ่งในการสร้างความกลมเกลียวภายในทีม โดยการให้ทีมได้รับรู้ถึงความสำเร็จหรือข้อดีต่างๆ ที่ทีมได้ร่วมสร้างระหว่าง Sprint ทุกคนสามารถนำเสนอข้อดีต่างๆ โดยทีมต้องเห็นพ้องกับข้อดีร่วมกัน
หัวใจของ Retrospective meeting คือการเปิดใจและร่วมปรับปรุงทีมไปด้วยกัน ทีม Scrumจะไม่มีการปรับปรุงให้ดีขึ้นถ้าทีมไม่เปิดใจบอกถึงข้อเสียต่างๆ ที่เกิดขึ้นภายในทีม
ปัญหาต่างๆควรนำมาถกเทียงกันใน Retrospective meeting เพื่อร่วมกันแก้ปัญหา ไม่ใช่เพื่อที่จะกล่าวโทษหรือหาผู้ทำผิด ทุกคนในทีมสามารถนำข้อเสียที่ควรปรับปรุงมาถกเถียงได้
บ่อยครั้งที่ไม่มีใครกล้าจึงเป็นหน้าที่ของ Scrum master ที่จะเป็นผู้นำใน Retrospective meeting โดยจะนำข้อเสียต่างๆ ที่ Scrum master เห็นระหว่าง Sprint มาถกเถียงกันในทีม และให้ทีมเสนอว่าควรปรับปรุงอย่างไร โดยทั้งทีมควรเห็นพ้องต้องกันในการปรับปรุงเพื่อให้ทุกคนในทีมร่วมปฏิบัติ Scrum master ต้องไม่กำหนดข้อปฏิบัติใดๆ ในการปรับปรุงแต่ Scrum master สามารถร่วมเสนอวิธีการเพื่อปรับปรุงและให้ทุกคนในทีมร่วมตัดสินใจว่าจะปฏิบัติตามข้อเสนอหรือไม่
จดบันทึกผลของ Retrospective meeting เสมอ
ข้อดี ข้อเสีย และข้อเสนอเพื่อปรับปรุงต่างๆ ควรมีการจดบันทึกไว้ และทุกๆครั้งที่มี Retrospective meeting ทีมควรเปิดดูผลของ Retrospective meeting ก่อนหน้านี้เพื่อตรวจสอบว่าทีมได้ปรับปรุงตามข้อเสนอจาก Retrospective meeting ครั้งก่อนหน้านี้หรือไม่ หากทีมมีข้อเสียซ้ำๆเดิม ทีมจะได้เห็นและตระหนักถึงสิ่งที่เป็นปัญหาและควรปรับปรุงให้จริงจังมากยิ่งขึ้น
Retrospective meeting มีความสำคัญมากที่สุดรองจาก Sprint demos เลยทีเดียว เพราะเป็นการประชุมที่ให้โอกาสทีได้ปรับปรุง Scrum ให้ดีขึ้นดังนั้นเราควรแน่ใจว่า Retrospective meeting มีขึ้นประมาณ 30 นาที – 2 ชั่วโมง ตอนสิ้นสุด Sprint เสมอ
ผลของ Retrospective meeting เป็นแหล่งสะสมประสบการณ์ความรู้ของแต่ละทีม ซึ่งแต่ละทีมมีประสบการณ์ที่แตกต่างดังนั้นการแลกเปลี่ยนประสบการณ์ต่างๆ จะช่วยพัฒนา Scrum ให้กับทีมอื่นๆภายในองค์กรได้เป็นอย่างดี
สิ้นสุด Sprint ด้วย Free time
มาถึงตอนนี้เราก็สิ้นสุด Sprint อย่างเป็นทางการตาม Scrum methodology ถ้าใครอยากลองทบทวนการใช้ Scrum ตั้งแต่เริ่มต้นก็ลองกลับไปอ่านที่ เริ่มโปรเจกต์ด้วย Scrum ตอนที่ 1 ก่อนที่จะเริ่ม Sprint ใหม่ อย่าลืมให้เวลากับทีมได้ทำอย่างอื่นสัก 0.5-2 วันดูนะคะ เพื่อให้สมองปลอดโปล่ง มีไอเดียใหม่ๆ ใน Sprint ถัดไป
No comments:
Post a Comment