เพิ่มประสิทธิภาพการทำงาน ด้วย Agile process

1. Agile คือ
แนวคิด (Mindset) และรูปแบบการทำงานที่เน้น "ความคล่องตัว" โดยการแบ่งงานใหญ่ให้เป็นชิ้นเล็กๆ แล้วส่งมอบงานอย่างรวดเร็วเป็นรอบๆ (Iterations) เพื่อรับคำติชม (Feedback) มาปรับปรุงได้ทันที

2. ความแตกต่างระหว่าง Waterfall และ Agile

• Waterfall ลักษณะการทำงาน Analysis > Design > Implementation > Testing > Deployment (Develop) > Release & Maintenance โดยตัว Product ที่ออกมา ลูกค้าจะได้เจอหลังจากจบ Process ทั้งหมด ซึ่งในบางครั้งอาจจะไม่ตอบโจทย์กับความต้องการของลูกค้าได้ โดยเวลาและต้นทุนไม่ได้ถูก Fix ไว้ ซึ่งหากลูกค้าต้องการเพิ่มอะไร ต้องมีการเพิ่มเวลาหรืออาจจะมีต้นทุนที่เพิ่มขึ้น

• Agile การย่อยการทำงานแต่ละรอบให้สั้นลงเป็น Sprint (sprint = รอบระยะการทำงานแต่ละรอบ) โดยแต่ละรอบจะมีการ Replan ซ้ำๆ เป็นการเทสไปทำไป เพื่อตอบโจทย์ความต้องการของลูกค้า และมี Value อะไรต่อลูกค้า ในแต่ละ Sprint ที่ได้จะไม่มีคำว่าผิดพลาดแต่จะเป็นการเรียนรู้ โดยสิ่งที่ได้แต่ละ sprint จะเป็น Knowledge และ Practice

3. ประวัติการทำงานของ Agile

1️⃣ Individuals and Interactions
ให้ความสำคัญกับ “คนและการสื่อสาร” มากกว่า “กระบวนการและเครื่องมือ”
➡️ ทีมที่คุยกันดี เข้าใจกัน แก้ปัญหาร่วมกัน สำคัญกว่าการยึดติดขั้นตอนหรือเครื่องมือมากเกินไป
2️⃣ Working Product
ให้ความสำคัญกับ “ผลงานที่ใช้งานได้จริง” มากกว่า “เอกสารที่ละเอียดมาก”
➡️ ลูกค้าอยากเห็นของที่ใช้ได้จริง เอกสารมีประโยชน์ แต่ไม่ควรทำจนลืมสร้างผลงาน
3️⃣ Customer Collaboration
ให้ความสำคัญกับ “การร่วมมือกับลูกค้า” มากกว่า “การต่อรองตามสัญญา”
➡️ คุยกับลูกค้าบ่อย ๆ ปรับตามความต้องการจริงไม่ใช่ยึดสัญญาเป๊ะจนแก้ไขอะไรไม่ได้
4️⃣ Responding to Change
ให้ความสำคัญกับ “การปรับตัวต่อการเปลี่ยนแปลง” มากกว่า “ทำตามแผนเดิมอย่างเคร่งครัด”
➡️ โลกเปลี่ยน ความต้องการเปลี่ยน Agile สนับสนุนให้ปรับแผนได้ตลอด

Agile Manifesto มี 12 Agile principle

1.Continuous delivery :ส่งมอบคุณค่าลูกค้าอย่างต่อเนื่อง
2.Welcome change : ความเปลี่ยนแปลงคือความได้เปรียบในการแข่งขัน
3.Delivery Frequenly :ควรทำให้ระยะเวลาระหว่างส่งมอบนั้นสั้นที่สุดเท่าที่เป็นไปได้
4.Work together Daily :ฝ่ายธุรกิจและนักพัฒนาต้องทำงานร่วมกันทุกวัน
5.Trust motivated Individuals : สมาชิกเข้าใจและมีจุดมุ่งหมายร่วมกันและไว้ใจกันในการทำงาน
6.Face to face communicate : การสื่อสารที่ดีที่สุดคือการพูดคุยแบบซึ่งหน้า
7.Working stuff = Progress : ผลิตภัณฑ์ที่ใช้งานได้จริงเป็นการวัดความก้าวหน้าของโครงการ
8.Sustainable Pace : สามารถรักษาอัตราความเร็วในการทำงา่นร่วมกันให้คงที่ไปได้ตลอด
9.High Standards=Agility : ความเป็นเลิศทางเทคนิคและงานออกแบบที่ดีอย่างต่อเนื่องช่วยเพิ่มความเป็น agile
10.Keep it simple : ความเรียบง่ายหรือศิลปะในการทำงานอย่างพอเพียงสำคัญอย่างยิ่ง เริ่มจากง่าย ๆใช้ได้จริงไม่ซับซ้อน
11.Self-Organising teams : งานที่ตอบโจทย์ลูกค้าได้ เกิดจากทีมที่บริหารจัดการตัวเองได้
12.Reflect and Adjust : ทีมต้องนำบทเรียนที่ผ่านมาเพื่อใช้พัฒนาความมีประสิทธิผลของทีม

4. Framework ของ Agile

คือ "ชุดเครื่องมือหรือระบบ" ที่นำแนวคิด Agile มาทำให้เป็นรูปธรรม

1. Scrum (ยอดนิยมอันดับ 1) เน้นการทำงานเป็นรอบสั้นๆ เรียกว่า Sprint (1-4 สัปดาห์) โดยมีบทบาทชัดเจน: Product Owner (PO): ตัดสินใจว่า "จะทำอะไร" (จัดลำดับความสำคัญของงาน) Scrum Master: คนคอยเคลียร์อุปสรรคและดูแลให้ทีมทำตามกระบวนการ Scrum Development Team: คนลงมือทำ (เช่น คุณที่เขียน Go) พิธีกรรมสำคัญ: Daily Stand-up (ประชุมเช้า 15 นาที), Sprint Planning, และ Sprint Retrospective (คุยกันว่ารอบที่ผ่านมามีอะไรต้องปรับปรุง)
2. Kanban เน้น "การไหลของงาน" (Flow) ไม่มีการแบ่งรอบเวลา (Sprint) เหมือน Scrum แต่จะเน้นจัดการงานที่กำลังทำอยู่ (Work in Progress - WIP) ไม่ให้เยอะเกินไป ใช้ Kanban Board (To Do -> Doing -> Done) เหมาะกับงานที่เข้ามาเรื่อยๆ เช่น งาน Support, Maintenance หรือทีมที่ต้องการความยืดหยุ่นสูง
3. XP (Extreme Programming) เน้นไปที่ "คุณภาพของโค้ด" แบบสุดโต่ง เหมาะมากสำหรับเหล่านักพัฒนา: Pair Programming: เขียนโค้ด 2 คนต่อ 1 จอ Test-Driven Development (TDD): เขียน Test ก่อนเขียนโค้ดจริง (ใน Go มี Testing Package ที่ดีมาก รองรับเรื่องนี้สุดๆ) Refactoring: ปรับปรุงโค้ดตลอดเวลา
4. Lean Software Development เน้นการ "ตัดส่วนเกิน" (Eliminate Waste) อะไรที่ไม่สร้างมูลค่าให้ลูกค้า ให้ตัดทิ้ง เพื่อให้ส่งมอบงานได้เร็วที่สุด
5. สำหรับองค์กรใหญ่ (Scaling Agile) เมื่อบริษัทมีทีมหลายสิบทีม เขาจะใช้ Framework ที่ใหญ่ขึ้น เช่น: SAFe (Scaled Agile Framework): การจัดการ Agile ระดับบริษัทใหญ่ๆ Spotify Model: แบ่งคนเป็น Squads, Tribes, Chapters และ Guilds (เน้นความเป็นอิสระของทีม)

5. หลักการส่งมอบ ผลิตภัณฑ์สู่ลูกค้า(Release product)
1.มีคุณภาพ (Quantity)ที่ดี
2.มีคุณค่าต่อผู้ใช้ (Value)
3.อาจจะมีข้อจำกัดได้แก่ ต้นทุน(Cost)|ทรัพยากร (Resource)|ระยะเวลา (Schedule)

6. หลักการส่งมอบ ผลิตภัณฑ์สู่ลูกค้า(Release product)
🔹 1. Roles (บทบาทหน้าที่)
1️⃣ Product Owner (PO)
ตัวแทนของลูกค้า / ธุรกิจ
กำหนดวิสัยทัศน์ของ Product
จัดลำดับความสำคัญของงาน (Product Backlog)
ตัดสินใจว่า “อะไรสำคัญที่สุด”
รับงาน/ไม่รับงาน (Accept / Reject)
📌 โฟกัส: คุณค่าทางธุรกิจ
2️⃣ Scrum Master
โค้ชและผู้ดูแลกระบวนการ Scrum
ช่วยให้ทีมเข้าใจและทำ Scrum ถูกต้อง
แก้อุปสรรค (Impediments)
ประสานงานกับคนนอกทีม
ปกป้องทีมจากสิ่งรบกวน
📌 โฟกัส: กระบวนการ + ทีม
3️⃣ Development Team
ทีมที่ลงมือทำงานจริง
พัฒนา ออกแบบ ทดสอบ
วางแผนงานใน Sprint
รับผิดชอบผลลัพธ์ร่วมกัน
ไม่มีหัวหน้าภายในทีม
📌 โฟกัส: ส่งมอบงานที่ใช้งานได้
🔹 2. Artifacts (สิ่งที่ใช้ใน Agile / Scrum)
1️⃣ Product Backlog
รายการงานทั้งหมดของ Product
เรียงตามความสำคัญ
เปลี่ยนแปลงได้ตลอด
ตัวอย่าง:ฟีเจอร์ใหม่ / แก้บั๊ก / ปรับ UX
2️⃣ Sprint Backlog
งานที่ทีมเลือกมาทำใน Sprint นี้
แยกเป็น Task ชัดเจน
ทีมเป็นเจ้าของ
3️⃣ Increment
ผลงานที่เสร็จสมบูรณ์ใน Sprint
ต้อง ใช้งานได้จริง
ผ่าน Definition of Done
🔹 3. Ceremonies (กิจกรรมหลัก)
1️⃣ Sprint Planning

📅 ต้น Sprint
เลือกงานจาก Product Backlog
วางแผนว่าจะทำอะไรบ้าง
กำหนดเป้าหมาย Sprint
2️⃣ Daily Scrum (Daily Stand-up)
📅 ทุกวัน (ไม่เกิน 15 นาที)
ตอบ 3 คำถาม:
เมื่อวานทำอะไร
วันนี้จะทำอะไร
ติดปัญหาอะไรไหม
3️⃣ Sprint Review
📅 ท้าย Sprint
Demo งานให้ PO / Stakeholder ดู
รับ Feedback
ปรับ Product Backlog
4️⃣ Sprint Retrospective
📅 หลัง Review
อะไรทำได้ดี
อะไรควรปรับปรุง
จะพัฒนา Sprint หน้ายังไง
6. การวางแผนการทํางานแบบ Agile

1.PO คุยกับลูกค้า/user ได้โจทย์
2.PO กลับมาคุยโจทย์กับ Team วางแผนว่าทำอะไรต่อ [ได้ Product backlog/Sprint backlog]
3.เขียน Agile project charter ประกอบด้วย Vision/Mission/Success (ตัววัด)
4.PO เขียน User story ตามมุมมองของ user
5.เมื่อ PO เขียน User story เสร็จ ทำการเขียน board เรียก kanban board [todo/doing/done]
6.ตอน Start sprint PO เป้นคนเลือก เอา user story ใน Product Backlog ไหนมาทำบ้างมาอยู่ในช่อง todo และเรียงลำดับความสำคัญก่อนหลัง
7.PO ประกาศ Sprint goal สิ้นสุด sprint มีอะไรให้ทดสอบบ้าง
8.Team เขียน task ย่อยแตกทางด้านขวาของ user story
9.ใน user story มีตัวเลขกำกับ เรียก story point เกิดจากการ Estimate ตามหลักการ Planning poker
10.ทำ Sprint burndown chart
แกน X จำนวน Task
แกน Y จำนวนวันทีต้องทำ
เส้นน้ำเงินเป็น Benchmark
จำนวนงานที่ทำปัจจุบันแทนด้วยเส้นสีแดง (actual)
ถ้าสีแดงอยู่สูงกว่าเส้นสีน้ำเงินมากๆ % งานไม่เสร็จมีสูง Team จะต้องปรับเปลี่ยนแผนเพื่อให้ได้งานหลังจบ sprint
11.ทำ Backlog Refinement เมื่อทำงานไปถึงครึ่ง sprint เพื่อดูว่าเป็นไปตามแผนหรือต้อง replan
12.ทำ Daily standup ทุกวันไม่เกิน 15 นาที
13.ทำ Sprint review (Product demo)
14.ทำ Retrospective (less of/more of/keep doing/start doing/stop doing)