Agile: an Alternative Software Development

ไปอบรมมาค่ะ เรื่อง Agile: an Alternative Software Development ได้ความรู้อีกเยอะ และเคยเขียนถึง Agile ไว้น้อยนึงตอนที่ไปงาน Thailand SPIN 2012 แล้วก็ไม่ได้เคยเขียนถึงอีกเลย เพราะเห็นว่ามีอยู่เยอะแยะแล้วตามเน็ต ทั้ง Agile Manifesto ทั้ง 4 ข้อ และ Agile Principle 12 ข้อ

ซึ่งแม้หัวข้ออบรมจะเป็นเรื่อง Agile แต่ practice ที่ทำให้ workshop เป็น Scrum ก็เลยได้ Scrum มาด้วย จึงขอสรุป scrum แบบสั้นสุดๆ ไว้ เนื่องจากคงยังไม่มีโอกาสได้ใช้อีกนาน เอาไว้ระลึกในภายหลังละกันค่ะ

โดยทฤษฎี Scrum จะทำให้เกิด
- Transparency ทำให้เกิดความโปร่งใส ไม่ใช่แค่ทำให้เกิดความยุติธรรมนะค่ะ ตามที่เราเข้าใจความโปร่งใสจะทำให้เกิดความคล่องตัว รู้ว่าใครทำอะไรอยู่ สถานะงานอยู่สถานะไหน ทำให้เกิดการแก้ไขความล่าช้า หรือปัญหาที่เกิดได้อย่างรวดเร็ว
- Inspection ทำให้มีการตรวจสอบงานกับเป้าหมายได้ง่าย เห็นว่างานที่ทำตรงกับเป้าหมายที่ลูกค้าต้องการหรือเปล่า มีการตรวจสอบปัญหา และอุปสรรคเป็นระยะๆ
- Adaptation ทำให้ทีมได้ปรับตัวได้รวดเร็ว ถ้ามีข้อผิดพลาด ก็จะผิดพลาดแค่เพียงเล็กน้อย สามารถแก้ไขได้รวดเร็ว

Scrum team ประกอบด้วย 3 กลุ่มบทบาท
1. Product owner 1 คน เป็นตัวแทนทางธุรกิจของสินค้านั้นๆ เป็นคนกำหนดว่าอะไรที่ทำให้เกิดกำไร อะไรสำคัญกว่าอะไร ซึ่งสิ่งที่ PO หรือ Product owner ทำกับ Product backlog โดยการจัดลำดับความสำคัญ, แบ่งขนาดของ item (หรือ user story), ประเมินขนาดของแต่ละ story เรียกว่า Backlog grooming
2. Development team 3 - 9 คน ถ้าน้อยไป อาจจะมีปัญหาเรื่องทักษะ, ความรู้ ในการทำงานให้สำเร็จ ถ้ามากไป จะทำให้เกิดปัญหาเรื่องการสื่อสารไม่ทั่วถึง และความซับซ้อนในการจัดการคน ลักษณะของคนในทีมมีดังนี้

• Self-organizing team
• Cross-functional team
• No titles
• No sub-team

3. Scrum master 1 คน เป็นคนดูแลให้มีการนำ Scrum มาใช้ตามวัตถุประสงค์ที่ถูกต้อง สร้างความเข้าใจในการทำกิจกรรมของ Scrum

Scrum Artifact
1. Product backlog

• Feature - มาจาก Product owner
• Technical work - เป็นงานดูแล Infrastructure ทั้งหมด งานส่วนนี้จะมาจาก Development team
• Bug - มาจาก Product owner หรือ Development team
• Knowledge acquisition - เป็นงานในการศึกษาหาความรู้ เพื่อให้สามารถทำงานให้สำเร็จ ซึ่งมาจาก Development team

2. Sprint backlog

เป็นส่วนหนึ่งของ Product backlog ที่จะต้องทำให้เสร็จในแต่ละรอบการทำงาน ซึ่งเป็นงานที่ มีรายละเอียดชัดเจนพอที่ Development team จะนำไปทำได้

Scrum Events
การทำงานในแบบ Scrum จะแบ่งออกเป็นรอบเล็กๆ เพื่อให้ได้งานที่เสร็จสมบูรณ์เป็นชิ้นเล็กๆ  (Potentially shippable product) โดย 1 รอบจะเรียกว่า 1 Sprint ซึ่งในแต่ละ Sprint จะเป็นเวลาเท่าๆ กัน (time-box) เป็นการจำกัดเวลาในแต่ละรอบ และประกอบไปด้วยกิจกรรมต่างๆ ที่กำหนดเป็น time-box เช่นเดียวกัน ดังนี้
1. Sprint planning ใช้ 8 ชั่วโมงสำหรับ Sprint ที่ยาว 1 เดือน

• Part 1 - What can be done this Sprint? ซึ่ง Development team จะประชุมร่วมกับ Product owner เป็นส่วนที่ต้องตกลงกันว่าอะไรควรจะต้องทำก่อน เพราะอะไร อะไรมีความสำคัญกว่าอะไร
• Part 2 - How will the chosen work get done? เป็นการประชุมภายในของ Development team เพื่อทำ Work break down จากงานใน Part 1 ซึ่งมาจะสามารถประเมินงานแต่ละชิ้นได้หลายวิธี แต่จะต้องให้ทั้งทีมประเมินร่วมกัน และเห็นชอบร่วมกัน ซึ่งวิธีหนึ่งที่นิยมทำกันก็คือ Planning poker

2. Daily scrum เป็นการประชุมทุกวัน วันละ 15 นาที โดยหัวข้อการประชุมคือ

• What did I do yesterday?
• What will I do today?
• Do I see any impediment?

3. Sprint review ใช้เวลา 4 ชั่วโมงสำหรับ Sprint ที่ยาว 1 เดือน ประชุมร่วมกันระหว่าง Development team, Product owner และ Stakeholders ทั้งหมด เพื่อนำเสนองานที่ได้ทำมา ตอบคำถามจาก Stakeholders รับฟังความเห็น แจ้งปัญหาและอุปสรรค แจ้งความต้องการความช่วยเหลือหรือสนับสนุน

4. Sprint retrospective ใช้เวลา 3 ชั่วโมงสำหรับ Sprint ที่ยาว 1 เดือน เป็นการให้โอกาส Development team ได้ตรวจสอบตัวเอง สร้างแผนในการพัฒนาทีม และเป็นการเพิ่มคุณภาพให้กับทีมโดยปรับข้อกำหนดของ "Done" (definition of "Done") โดยจะประชุมกันคือ Good, Bad, Try และผลของการประชุม ก็คือใน Sprint ถัดไป ทีมจะปรับปรุงอะไร

จากรูปน่าจะชัดเจนที่สุดนะค่ะ


Reference:
Agile Manifesto
Agile Principle
Art of Project Management
Scrum Guide

Thailand SPIN 2013

พอดีได้มีโอกาสไปงานค่ะ ไปงานสัมมนาหลังจากไม่ได้ไปงานแบบนี้มานานมาก เพราะไปทีไรก็รู้สึกว่าไม่ได้อะไรเท่าไร แต่อยากบอกว่างานนี้เป็นงานที่คิดว่าคุ้มค่ะที่ไป ไม่เคยได้เจองานสัมมนา IT แบบเสวนาแบบนี้เลย แต่ต้องบอกว่าประทับใจค่ะ ได้อะไรมากกว่าที่คิด

และอยากแชร์บางอย่างที่ได้มาเอาไว้ค่ะ ในงานช่วงเช้ามี section ของการเสวนา Do and Don't ซึ่งจากที่ได้ฟังมาย่อยได้ดังนี้ค่ะ (ขออภัยที่ใช้ภาษาอังกฤษ เพราะว่าตอนจดมาภาษาอังกฤษมันพิมพ์ได้เร็วกว่า)

Requirement phase

- Don't collect requirement from template. หรือถ้าจะใช้ก็ต้องใช้อย่างเข้าใจค่ะ
- Find problem first before requirement.
- Don't use same practice in different project.
- Tester should involve in requirement at requirement phase (almost finish phase), don't wait until test phase
- Don't call it requirement, because customer will be afraid to commit.

Analysis phase

- Don't use much time - do analyse very short, because requirement will continuously change .
- Reuse design as much as you can.
- If testers are for testing function, don't ask technical specification.
- Don't design alone. Do it with all team, with tester, BA, PM, customer, etc.
- Don't over design.

Coding phase

- Don't forget unit test.
- Send test data to developer.
- Tester don't need to ask developer for any to-do check list.
- Do unit test or automated test at coding phase.
- Make developer and tester work together.

Test phase

- Do defect management.
- Do root cause management.
- Do video record.
- Do test case priority.

Deploy phase

- Don't wait to deploy production at last. beware load balancing or other environment change, etc.

Maintenance phase

- Revise test case from production incident.
- Log incident.
- Don't forget production life cycle, that should include maintenance.
- Don't relocate staff frequently.

ทั้งนี้เป็นการย่อยความของตัวเอง ถ้ามีผิดพลาดประการใด ขอรับไว้แต่เพียงผู้เดียวค่ะ

นอกจากนี้ ยังได้ความรู้เกี่ยวกับ Agile Principles ด้วย ซึ่งหลายคนก็อาจจะรู้แล้ว ก็ข้ามไปค่ะ

Agile principles

1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.

ซึ่งทั้งนี้วิทยากรแนะนำว่าสำหรับใครที่จะทำ Agile ให้ดูเรื่อง TDD (Test Driven Development) ให้ดีๆ ค่ะ และควรจะหา automated test tools เพราะว่าการทำ Agile จะต้องทำ regression test บ่อยมาก

Reference: 

Principles behind the Agile Manifesto