ยกระดับ ‘Software Delivery Performance’ ด้วยตัวชี้วัดมาตรฐานสำคัญ ที่นักพัฒนาซอฟต์แวร์ทั้ง มือใหม่-มือเก๋า ไม่ควรพลาด

หัวใจสำคัญในการพัฒนาซอฟต์แวร์ให้สำเร็จนั้น คือ การส่งมอบซอฟต์แวร์ (Software) ที่รวดเร็วและตรงตามความต้องการของลูกค้า ซึ่งซอฟต์แวร์นอกจากต้องส่งมอบเร็วแล้ว ยังต้องมีคุณภาพสูงด้วย ดังนั้นกระบวนการวัดคุณภาพและความเร็วจึงเป็นส่วนสำคัญ เพราะทำให้นักวิศวกรรมซอฟต์แวร์สามารถนำผลลัพธ์ที่ได้ไปปรับปรุงกระบวนการพัฒนาซอฟต์แวร์ให้มีเสถียรภาพและได้ประสิทธิผลดีขึ้น 

ด้วยเหตุนี้ บลูบิค จึงได้ทำการกลั่นกรองเนื้อหาที่มีประโยชน์สำหรับนักพัฒนาซอฟต์แวร์ทั้งมือใหม่และมือโปร จากหนังสือชื่อดังในแวดวงเทคฯ ‘Accelerate: Building Scaling High Performing Technology Organization’ โดย Nichole Forsgren PhD.  Jex Humble และ Gene Kim โดยทำการรวบรวมดัชนีชี้วัดสำคัญที่ใช้ตรวจสอบสมรรถนะของการส่งมอบซอฟต์แวร์ (Software Delivery Performance) ได้อย่างชัดเจน ประกอบด้วย 4 ตัวชี้วัดดังนี้ 

ตัวชี้วัดที่ 1 Delivery Lead Time (ระยะเวลาส่งมอบงาน): การวัด Lead Time หรือ ระยะเวลาการส่งมอบงานนั้น ให้วัดจากจุด Commit code จนถึงจุดที่ซอฟต์แวร์ทำงานใน Production ได้ถูกต้อง ซึ่งค่าของ Lead Time ที่ดีควรต่ำกว่า 1 ชั่วโมง Lead Time ที่ต่ำแสดงให้เห็นว่ากระบวนการพัฒนาซอฟต์แวร์มี Automation มากพอ 

ตัวชี้วัดที่ 2 Deployment Frequency (ความถี่ในการส่งมอบงาน): การ Deploy ลง Production ควรเป็นกิจกรรมที่ทำได้บ่อยเท่าที่ต้องการ โดยไม่จำเป็นต้องได้รับอนุมัติจากผู้บริหาร ซึ่งการจะทำแบบนี้ได้ ทีมต้องมี Deployment Automation และนักพัฒนาซอฟต์แวร์จำเป็นต้องแบ่งงานเป็นชิ้นเล็กๆ (Working in small batches) แล้ว Deploy งานทุกวันหรือหลายครั้งต่อวันแทนการทำฟีเจอร์ใหญ่ๆ แล้ว Deploy สัปดาห์ละหนึ่งครั้งหรือนานกว่านั้น 

ตัวชี้วัดที่ 3 Time to Restore Services ( ระยะเวลาเฉลี่ยในการกู้ระบบเมื่อ Deploy ล้มเหลว): ตัวชี้วัดหนึ่งและสองมุ่งเน้นที่ความเร็วเป็นหลัก ส่วนตัวชี้วัดที่สามและสี่จะมุ่งเน้นที่คุณภาพ หากมองย้อนกลับไปในอดีตการวัดคุณภาพซอฟต์แวร์ ด้วยความล้มเหลว (Failure) นั้นวัดได้ 2 แบบ คือ 

1) ระยะเวลาเฉลี่ยในการกู้ระบบคืนเมื่อ Deploy ล้มเหลว (Mean Time to restore: MTTR) 

2) ระยะห่างเฉลี่ยของการ Deploy ล้มเหลวสองครั้งที่ติดกัน (Mean Time to between failures: MTBF) 

การวัดคุณภาพโดยใช้ MTBF นั้นจะทำให้นักพัฒนาซอฟต์แวร์กลัวการ Deploy เพราะการ Deploy บ่อยทำให้ความล้มเหลวมีโอกาสเกิดขึ้นใกล้ๆ กัน แต่ในความเป็นจริงแล้วสิ่งที่นักพัฒนาซอฟต์แวร์ควรสนใจ คือ ความเร็วในการกู้คืนระบบ (MTTR) ความพร้อมในการ Rollback และ Deployment Automation จะทำให้ทีมงานกู้ระบบคืนในกรณีที่ล้มเหลวได้ ในเวลาไม่เกิน 1 ชั่วโมง 

ตัวชี้วัดที่ 4 Change Fail Rate: หมายถึง อัตราความล้มเหลวในการ Deploy ลง Production ซึ่งความล้มเหลวหมายถึงการ Deploy ที่ต้องมี Hotfix หรือ Rollback ตามมา การกู้คืนระบบได้เร็วตามตัวชี้วัดที่สาม และอัตราความล้มเหลวที่ต่ำตามตัวชี้วัดนี้ แสดงให้เห็นถึงการส่งมอบซอฟต์แวร์ที่มีคุณภาพ  ซึ่งอัตราความล้มเหลวในการ Deploy ที่ดีนั้นควรอยู่ต่ำกว่า 15%

Technical Practices: The Goal is to Achieve Continuous Delivery (CD)

การที่นักพัฒนาซอฟต์แวร์จะส่งมอบงานให้ประสบความสำเร็จตามตัวแปรที่กล่าวไว้ข้างต้น ไม่ว่าจะเป็น การ Deploy ได้บ่อยและเร็ว การมี Automation ที่ครอบคลุม หรือความพร้อมในการ Rollback นักพัฒนาซอฟต์แวร์จำเป็นต้องมี Practice เพื่อสนับสนุนประสิทธิภาพตามตัวชี้วัด  แนวทางเหล่านี้ที่สามารถนำทีมไปสู่ Continuous Delivery (CD) ได้ ซึ่งเป็นคุณสมบัติสำคัญของการส่งมอบซอฟต์แวร์อย่างมีประสิทธิภาพ

1. Vision Control: คือการใช้ Git เพื่อเก็บ Version ของ Software แต่การใช้ Git ให้เกิดประโยชน์สูงสุดนั้นไม่ใช่การเก็บแค่ Application Code แต่จะต้องเก็บ Configuration และ Scripts ทั้งหมดที่ใช้รัน (Run) Automated Test, Automated Build และ Automated Deployment  เพื่อเป็นพื้นฐานการทำ Automation ในส่วนต่างๆ 
2. Deployment Automation: การ Deploy ซอฟต์แวร์ จำเป็นต้องมี Automation ที่ครอบคลุม เพื่อให้สามารถทำได้ด้วยคนเดียว เป็นกิจกรรมปกติ ทำได้ในเวลางาน และมีโอกาสผิดพลาดต่ำ
3. Continuous Integration: การทำ Continuous Integration นั้นประกอบไปด้วย การเช็คอินโค้ดทุกวัน การทำ Automated Test ในทุกเช็คอิน และการแก้ไขทันทีเมื่อเช็คอินไม่ผ่าน Test การทำTest บ่อยๆในทุกการเปลี่ยนแปลงของซอฟต์แวร์ จะช่วยลดข้อผิดพลาด (Error) และการเช็คอินโค้ดทุกวันช่วยลด Merge Conflict รวมถึงลดโอกาสการเกิด Bug ใหม่ๆ ทั้งหมดนี้เพื่อรักษาคุณภาพของ Master Branch เพื่อให้มั่นใจได้ว่าทีมสามารถนำซอฟต์แวร์ไปลง Production ได้เสมอ
4. Trunk-Based Development: เป็นการแบ่งงานเป็นชิ้นเล็กและ Merge เข้า Master Branch ให้ถี่ อย่างน้อยวันละหนึ่งครั้ง หากทำ Feature Branch นานโดยไม่มีการ Merge มีโอกาสทำให้เกิด Merge Conflict สูง ด้วยเหตุนี้การ Merge บ่อยด้วยการเปลี่ยนแปลงทีละน้อยๆ บวกรวมกับ Automated Test จะทำให้แน่ใจได้ว่า Master Branch มีคุณภาพสูง 
5. Test Automation: Test ที่ดีนอกจากจะต้องครอบคลุมแล้วยังต้องเชื่อถือได้และรวดเร็วด้วย ทีมควรมี Automated Test ในทุกเช็คอิน และเมื่อ Test ไม่ผ่านให้แก้ไขทันที ดังนั้น Test ต้องเชื่อถือได้เพื่อให้นักพัฒนาซอฟต์แวร์ใช้เป็น Feedback เบื้องต้นของงานตัวเอง Test ที่น่าเชื่อถือ มีการทำงานที่ขึ้นกับระบบอื่นน้อยที่สุดเท่าที่เป็นไปได้ เพื่อให้ความผิดพลาดของระบบอื่นไม่กระทบ Test ของทีม หาก Test ตัวใดถูกพบว่าเชื่อไม่ได้ ให้นำออกจากระบบ Test จนกว่าจะมีการแก้ไข อีกประการหนึ่งที่สำคัญคือ Test ส่วนใหญ่ควรทำงานได้เร็ว เพื่อให้ Test ถูกรันบ่อย และได้ Feedback เร็ว ซึ่งทำได้ด้วยการออกแบบให้มี Unit Test เป็นสัดส่วนเยอะ เพราะส่วนนี้ใช้ทรัพยากรน้อยและทำงานได้เร็ว 
6. Test Data Management: ต้องมีการบริหารจัดการ Test Data เพื่อให้ Test Data มีลักษณะสอดคล้องกับข้อมูลจริงใน Production ตลอดเวลา และทีมสามารถนำข้อมูลส่วนนี้ออกมาใช้ได้ง่าย เพื่อไม่ให้เรื่องนี้เป็นอุปสรรคในการทำ Test
7. Shift Left on Security: ในอดีตนักพัฒนาซอฟต์แวร์อาจพิจารณาเรื่อง Security ช่วงท้ายของโครงการก่อนส่งมอบงาน (Delivery) ส่งผลให้ปัญหา Security บางอย่างแก้ไขได้ยาก เพราะต้องแก้ตั้งแต่ระดับงานออกแบบ (Design) ดังนั้น เรื่อง Security ควรคิดไว้เลยตั้งแต่แรกเริ่ม (Day One) และฝังอยู่ในโครงการ นั่นหมายความว่าเรื่อง Security จะต้องอยู่ใน Test ด้วย โดยเป็นส่วนหนึ่งของ Nonfunctional Acceptance Test 

ไม่ว่าจะเป็นโลกธุรกิจ หรือการพัฒนาซอฟต์แวร์ การตรวจสอบและวัดผลคุณภาพของสิ่งที่ส่งมอบให้ลูกค้า เป็นการแสดงให้เห็นถึงความเป็นมืออาชีพของตัวคุณเองและองค์กร ด้วยเหตุนี้ การเลือกใช้แนวคิดทฤษฎี หรือมาตรฐานชี้วัดที่เหมาะสมกับงานจึงเป็นสิ่งที่ต้องให้ความสำคัญ เพราะนั่นอาจเป็นดัชนีชี้วัดที่คนภายนอกมีให้กับตัวคุณเองและองค์กรในอนาคต