จากบทความเรื่อง Agile is not now, nor was it ever, Waterfall
มีสิ่งที่น่าสนใจคือ
การพัฒนา software ตามแนวคิด Agile (Agility) นั้น
ไม่ควรมี process หรือ ขั้นตอน ที่มากเกินไป
มีคำถามที่น่าสนใจ คือ
Developer ควรเรียนรู้ practice หรือ แนวปฏิบัติที่ดีในการพัฒนาหรือไม่ ?
ถ้านำมาใช้มาก ๆ มันจะทำให้ process การทำงานเยอะไปหรือเปล่านะ ?
ขอตอบได้เลยว่า ควรนะ แต่ไม่จำเป็นต้องทั้งหมด
ดังนั้น มาดูว่า Agile practice ซึ่งนำมาจาก Extreme programming มีอะไรบ้าง ?
เพื่อให้เข้าใจว่า
มันเกิดมาเพื่ออะไร อย่างไร
เพื่อให้สามารถนำมาใช้งานอย่างเหมาะสม
1. The planning game
มันคือการวางแผนการทำงาน หรือ การพัฒนา software
ประกอบไปด้วยคนที่เกี่ยวข้องกับการพัฒนา เช่น Business และ Development เป็นต้น
มีเป้าหมายเพื่อ เลือกงานที่มีคุณค่าต่อลูกค้ามาพัฒนานั่นเอง
และทำให้รู้ว่าทีมพัฒนากำลังทำอะไรกันอยู่
ไม่ใช่ทำไปวัน ๆ นะครับ
โดยในปัจจุบันมีวิธีการที่หลากหลายมาก
เพื่อให้เหมาะสมกับงาน และ ทีม เช่น
- บางทีมมีเพียง TODO list แบบง่าย ๆ
- บางทีมใช้ KANBAN board
- บางทีมต้องเขียน Story แบบเต็ม ๆ และ แตกงานออกมากแบบเต็ม ๆ ละเอียดยิบ
- บางทีมต้องใช้ story point, planning poker
ดังนั้น จะเลือกแบบไหน เอาให้เหมาะสมกับงาน และ ทีมก็แล้วกัน
2. Customer tests
ลูกค้าส่วนมากมัก ไม่ต้องการจะทดสอบระบบงานสักเท่าไร
ดังนั้น จึงมีวิธีการใหม่ คือ การ demo ให้ลูกค้าดูแทน
ตาม requirement ที่กำหนด
บางทีมที่ใกล้ชิดกับลูกค้ามาก ๆ
มักจะเขียน Automated Acceptance Test ขึ้นมาตาม requirement
แต่หลาย ๆ ทีมอาจจะไม่ได้ใกล้ชิดลูกค้ามากนัก
ทำให้แนวปฏิบัตินี้ไร้ค่าลงไปอย่างมาก
จากบทความได้แนะนำไว้ว่า
ถ้าลูกค้าของคุณไม่ต้องการที่จะอ่าน หรือ เขียน แล้ว
ให้ทีมเขียน high level unit test ก็เพียงพอแล้ว
3. Small releases
เป็นแนวปฏิบัติที่ดี และ มีคุณค่าต่อทีมและลูกค้าอย่างมาก
Keep the release small
ยิ่งส่งมอบให้ลูกค้าช้าเท่าไร
ก็ยิ่งเกิดความผิดพลาดมากขึ้นเท่านั้น
4. Whole team
เป็นแนวปฏิบัติที่ดี และ มีคุณค่าอย่างมาก
ถ้าคนฝั่ง business ทำงานใกล้ชิด หรือ ร่วมทำงานกับทีมพัฒนาเลย
แต่โชคไม่ดี ที่ทีมส่วนใหญ่ไม่ทำงานร่วมกัน !!
ต่างคนต่างทำตาม role ของตัวเองเท่านั้น
โดยไม่สนใจว่า software จะออกมาดี หรือ มีผู้ใช้งานหรือไม่
5. Collective ownership
ในทีมพัฒนาส่วนใหญ่นั้น
แต่ละคนมักจะถือครอง code แต่ละส่วนแยกกันไปเลย
ซึ่งก่อให้เกิดปัญหามากมายตามมา
เช่น เมื่อคนที่ถือครอง code นั้น ลาออกไป
สิ่งที่เกิดขึ้นตามมา คือ ทีมงานจะเข้าสู่นรก
หรือ เข้าสู่ความอ้างว้างอันไกลโพ้นอย่างมาก
ดังนั้นสิ่งที่เราต้องการ คือ Collective Ownership
ซึ่งสามารถทำได้ง่ายมาก ๆ คือ
code แต่ละส่วนนั้น จะต้องมีคนถือครอง และ รู้ อย่างน้อยสองคนเสมอ
ห้ามรู้อยู่คนเดียวโดยเด็ดขาด
ดังนั้น ยิ่งมีคนรู้เยอะ ยิ่งดีนะ
6. Coding Standard
เรื่องของ coding standard มันมาควบคู่กับ Collective Ownership เสมอ
รูปแบบของ code ต้องมีรูปแบบเดียวกันทั้งทีม
ไม่ใช่เป็นรูปแบบตามความพอใจของแต่ละคน
ดังนั้น ทุก ๆ คนในทีมต้องตกลงร่วมกันก่อนเริ่มทำงานเสมอนะครับ
7. Sustainable pace
เป็น practice ที่เรียบง่าย และ เป็นจริงอย่างมาก
เนื่องจาก การพัฒนา software นั้น ต้องใช้เวลานาน
เหมือนกับการวิ่งมาราธอน
ดังนั้น จำเป็นต้องมีสถาพแวดล้อมต่าง ๆ ที่ยั่งยืน
ไม่เช่นนั้น คุณจะกล้าลงมือทำมันหรือ ?
แต่แปลกนะที่ทุก ๆ ทีมมักจะฝ่าฝืน practice นี้เสมอ
ผลที่ได้ คือ ความล้มเหลวไงล่ะ !!
แต่ก็ยังฝืนทำกันต่อไป
8. Continuous Integration
เป็นสิ่งที่ทุกๆ ทีมควรมีระบบนี้ไว้เสมอ ไม่มีข้อยกเว้น
ถึงแม้จะบอกว่า ทีมมีขนาดเล็กเพียงใด
9. Pair programming
บางทีมนำ practice นี้ไปใช้แล้วได้ประโยชน์อย่างมาก
บางทีมนำ practice นี้ไปใช้แล้วไม่ได้ประโยชน์อะไรเลย
แต่มันอาจจะมาอยู่ในรูปแบบอื่น เช่น การทำ code review ก็ได้
ซึ่งมันกลับได้ประโยชน์กว่ามาก
ลองคิดดูสิว่า
จะดีเพียงใด
ถ้าทุก ๆ บรรทัดของ code นั้น
มีคนเห็น มีคนช่วยกันดู ช้วยกันคิด มากกว่า 1 คนเสมอ
10. Simple design
การออกแบบระบบที่มากจนเกินไป หรือ over มากๆ นั้น
มันไม่เคยส่งผลดีกับใครเลย
ซ้ำร้ายมันยังกลับมาทำร้ายทีมพัฒนาอีก
การออกแบบมันมีหลายระดับ
แต่สิ่งที่สำคัญสุด ๆ คือ ความเรียบง่าย นะครับ
11. Refactoring
ทุก ๆ คนต้องการให้ code มันดีใช่ไหม ?
ทุก ๆ คนทำการปรับปรุง code ให้ดีขึ้นใช่ไหม ?
แต่ละทีมล้วนมีวิธีการ Refactor code ที่แตกต่างกันไป
ไม่ว่าจะมาก หรือ น้อย
แต่ทีมจำเป็นจะต้องทำเสมอนะ
ไม่ใช่ไม่ทำอะไรเลย !!
12. Test-Driven Development
เป็น practice ที่มีการโต้แย้ง โต้เถียงกันมากที่สุดแล้ว
แต่ไม่ได้โต้เถียงว่า การเขียน unit test นั้นไม่ดี
แต่เถียงกันถึงลำดับของการเขียน test มากกว่า !!
ดังนั้น แต่ละทีมก็มีวิธีการที่แตกต่างกันไป
ตามความสามารถ และ ความเหมาะสม
ทีมยังต้องทำการทดสอบนะครับ
ยิ่งทดสอบได้เร็ว ก็ยิ่งสำเร็จเร็วขึ้นนะ
โดยสรุปแล้ว
ไม่ว่าการพัฒนา software จะอยู่ในรูปแบบไหนก็ตาม
ต้องนำ practice เหล่านี้ไปใช้เสมอ
แต่ไม่จำเป็นต้องนำทุก ๆ practice ไปใช้
แนะนำให้เลือกใช้ตามปัญหาที่ทีมพบเจอ น่าจะดีที่สุด
แต่ถ้าไม่นำไปใช้เลย ไม่น่าจะถูกต้องนะครับ !!
