ถนนสาย Technical สู่ Agility
จากประสบการณ์ผมที่ดูแลเรื่อง engineering practice ในฐานะสกรัมมาสเตอร์มา ผมเห็น pattern ของลำดับของ practice ที่ผมมักจะสอนให้กับทีม บ่อยครั้งผมจะเริ่มที่ Test Driven Development เพื่อจะได้มั่นใจว่าซอฟต์แวร์จะออกมาอย่างมีคุณภาพ แต่บ่อยครั้งผมพบว่าการเริ่มที่นี่ต้องอาศัยวินัยจากสมาชิกในทีมสูงมาก
หลังจากอ่านหนังสือ The DevOps Handbook ลำดับของ practice ผมก็เปลี่ยนไปตามด้านล่าง
- Trunk-based development
- Continuous Integration
- Feature toggle
- [Automate migration or NoSQL]
- Continuous deployment
- [Post mortem]
- [Observability]
- [Acceptance Test Driven Development]
- [Test Driven Development]
- Canary release
- Continuous delivery
- Chaos Monkey
- Accident near-misses
Flow
จาก Trunk-based development จนถึง Continuous deployment เป็นการสร้าง flow ซึ่งเป็น the first way (ทางเส้นแรก) ของทางทั้ง 3 ในหนังสือ The DevOps Handbook ซึ่งจะตอบ 3 ใน 12 Agile principles ดังนี้
- ความสำคัญสูงสุดของพวกเราคือความพึงพอใจของลูกค้า
ที่มีต่อการส่งมอบซอฟท์แวร์ที่มีคุณค่าต่อลูกค้า ตั้งแต่ต้นอย่างต่อเนื่อง - ส่งมอบซอฟท์แวร์ที่ใช้งานได้จริงอย่างสม่ำเสมอ
อาจเป็นทุกสองถึงสามสัปดาห์หรือทุกสองถึงสามเดือน
โดยควรทำให้ระยะเวลาระหว่างการส่งมอบนั้นสั้นที่สุดเท่าที่เป็นไปได้ - ซอฟท์แวร์ที่ใช้งานได้จริงเป็นตัวหลักในการวัดความก้าวหน้าของโครงการ
จาก Flow ใน the first way ด้านบนน่าจะส่งมอบซอฟต์แวร์จนถึง production อย่างสม่ำเสมอแล้ว แต่จะมี quality แค่ไหนก็จะขึ้นกับพลังวัตรพื้นฐานที่ทีมมีมาแต่เดิมล้วน ๆ
สถานการณ์แบบนี้เปิดโอกาสให้ product owner เลือกที่จะ release กับกลุ่มผู้ใช้งานบางกลุ่มได้ถ้าต้องการ
ถ้าทีมพลังวัตรไม่ถึง ขั้นตอนนี้จะเป็นการส่งขยะขึ้นสายพานสู่ production อย่างรวดเร็ว ซึ่งอาจจะสร้างความวุ่นวายและความเสียหายได้ แต่ทั้งหมดนี้ก็เป็นความจริง บ่อยครั้งผมพบว่าการเสียเวลาเก็บของให้เนี๊ยบ พอถึงตอน release จริงก็วุ่นวายอยู่ดี
Feedback
จาก Post mortem (Release Retrospective) ถึง Continuous delivery น่าจะเป็นการเติม feedback เข้าไปใน flow และเน้นให้ feedback ชัดขึ้น เพื่อให้ทุกคนเรียนรู้ไปด้วยกัน
ใน the second way นี้ มีหลายขั้นตอนที่สามารถข้ามได้ (ที่อยู่ในวงเล็บ) เช่น การเติม Observability จะจำเป็นก็ต่อเมื่อเราเจอปัญหาบน production เราอยากเพิ่ม Observability ที่ขาดหายเข้าไปเพื่อให้ครั้งหน้าเราเห็นปัญหาได้เร็วขึ้น
ถ้าถึง Continuous delivery แล้ว software ก็จะถูก release อย่าสม่ำเสมอ feedback ที่ทีมได้รับก็จะเข้มข้นขึ้นจากแค่ เสร็จ/ไม่เสร็จ เป็น business impact ที่เกิดขึ้น ซึ่งตอบอีก 4 ใน 12 Agile principles ดังนี้
- ส่งมอบซอฟท์แวร์ที่ใช้งานได้จริงอย่างสม่ำเสมอ
อาจเป็นทุกสองถึงสามสัปดาห์หรือทุกสองถึงสามเดือน
โดยควรทำให้ระยะเวลาระหว่างการส่งมอบนั้นสั้นที่สุดเท่าที่เป็นไปได้ - ตัวแทนจากฝ่ายธุรกิจและนักพัฒนา
จะต้องทำงานร่วมกันเป็นประจำทุกวันตลอดโครงการ - ทำให้แน่ใจว่าสมาชิกโครงการเข้าใจและมีจุดมุ่งหมายของโครงการร่วมกัน
สร้างสภาวะแวดล้อมและให้การสนับสนุนในสิ่งที่พวกเขาต้องการ
และให้ความไว้วางใจแก่พวกเขาในการที่จะทำงานให้บรรลุเป้าหมายนั้น - วิธีที่มีประสิทธิภาพและประสิทธิผลสูงสุดในการถ่ายทอดข้อมูลต่างๆ
ไปสู่ทีมพัฒนาและภายในทีมพัฒนาเองคือการพูดคุยแบบซึ่งหน้า
สังเกตว่าผมจะแยกคำว่า deploy กับ deliver ออกจากกัน โดย deploy คือการเอาซอฟต์แวร์ล่าสุดขึ้นไปบน production แต่อาจจะปิด toggle อยู่สำหรับ feature ที่เรายังไม่ release ขณะที่คำว่า deliver หมายถึงผู้ใช้งานได้รับคุณค่าที่ทีมสร้างขึ้นมาแล้ว นี่คือเหตุผลที่ผมย้ำ principle เรื่องการส่งมอบซอฟต์แวร์อีกครั้งตอนเราเพิ่มจาก Continuous deployment เป็น Continuous delivery
Continuous Improvement towards perfection
จาก flow และ feedback จะทำให้ทีมได้เรียนรู้และเติบโตอย่างยิ่งยวด หลังจากที่ทีมคุ้นชินกับงานเหล่านี้ตามปรกติแล้ว เราจะเพิ่มการเรียนรู้ด้วย Chaos monkey และ retrospective บน Accident near-misses ซึ่งตอบอีก 2 ใน 12 Agile principles ดังนี้
- การใส่ใจในความเป็นเลิศทางเทคนิค
และงานออกแบบที่ดีอย่างต่อเนื่องจะช่วยเพิ่มความเป็นอไจล์ - ทุกช่วงเวลาหนึ่งเป็นประจำ ทีมจะต้องย้อนกลับไปตรองดูสิ่งที่ผ่านมา
เพื่อหาทางที่จะพัฒนาความมีประสิทธิผลของทีม
แล้วนำสิ่งเหล่านั้นมาปรับปรุงและเปลี่ยนแปลงพฤติกรรมของทีม
ในบริบทของการผลิตซอฟต์แวร์ที่ทั้งธุรกิจและเทคโนโลยีเปลี่ยนแปลงอย่างรวดเร็วเช่นทุกวันนี้ การจะรักษาประสบการณ์การใช้งานที่ราบรื่นให้กับผู้ใช้งาน อาจจะต้องใช้มากกว่าการที่ทุกคนทำตามขั้นตอนที่เราออกแบบไว้อย่างรอบคอบ ถ้าจะต้องฝากความหวัง ผมจะฝากไว้กับการเรียนรู้และฝึกฝนที่จะแก้ปัญหาบน production อย่างสม่ำเสมอ
