จัดการ Technical Debt อย่างไรดีนะ ?

ในปัจจุบันพบว่ามีการใช้คำว่า Technical Debt สูงขึ้นมาก
มีความหมายเพื่อบอกว่ามีพฤติกรรมแย่ๆ ขึ้นมามากมายเพียงใด
ดังนั้น เรามาจะดูแลและจัดการ Technical Debt กันดีกว่านะ

คำว่า Technical Debt ถูกอธิบายไว้อย่างดี ดังนี้

• เริ่มใช้มาตั้งแต่ปี 2009 โดยคุณ Ward Cunningham เพื่อใช้อธิบายผลที่ตามมาจากการออกแบบ และ พัฒนา software ให้คนฝั่ง business เข้าใจ
• ทำการอธิบายที่มาที่ไป และ ความหมายที่แท้จริงไว้ใน VDO
• คุณ Robert C. Martin  เขียน blog อธิบายไว้ในเรื่อง A Mess is not a Technical Debt
• คุณ Martin Fowler อธิบายต่อไว้ใน bliki เรื่อง Technical Debt Quadrant

โดยรวมแล้ว Technical Debt คือ

ทุกสิ่งทุกอย่างที่ทำให้ code มันยากต่อการแก้ไขหรือเปลี่ยนแปลง
ซึ่งทีมพัฒนามักจะมีหลากหลายเหตุผลเพื่อสร้างมันขึ้นมา เช่น

• ขาดทักษะ
• ได้รับความกดดันจาก deadline ที่ถูกกำหนดไว้
• ความขี้เกียจ
• ความไม่เป็นมืออาชีพในสิ่งที่ตนเองทำ

เมื่อเวลาผ่านไปนานๆ จะยิ่งมีจำนวนของ Technical Debt ยิ่งมากขึ้น
ผลก็คือ งานที่คุณทำ หรือ พัฒนาก็จะช้าลงไปเรื่อยๆ
รวมทั้งเวลาในการแก้ไขก็นานขึ้นเรื่อยๆ และ ยากขึ้น

ซึ่งปัญหาเหล่านี้มันจะเกี่ยวข้องกับ

• Sourcecode
• Development environment
• Library
• การออกแบบ
• Test coverage
• Test automation

ผลที่ตามมาก็คือ จำนวน defect ที่สูงขึ้น
จำนวนงานที่พัฒนาน้อยลงไป
การดูแลรักษายากขึ้นมาก

แสดงดังรูป

ดังนั้นเราจำเป็นต้องมีการจัดการ Technical Debt แล้วใช่ไหม ?

เพื่อไม่เกิดเหตุการณ์ตามที่อธิบายมา หรือ ให้เกิดน้อยที่สุดเท่าที่จะทำได้

หัวใจของการจัดการ Technical Debt นั้นประกอบไปด้วย

• ระมัดระวังอยู่เสมอ ไม่อยู่บนความประมาท
• หลีกเลี่ยงเส้นทางลัด หรือ นั่นคืออย่าขี้เกียจ
• ทำการออกแบบที่เรียบง่าย
• ทำการ refactor อยู่อย่างสม่ำเสมอ ไม่มีข้อยกเว้น

อย่าลืมว่าการไม่ตรวจสอบ หรือ จัดการ Technical Debt
มันจะทำให้การสร้างหรือพัฒนา software เป็นเรื่องที่ยากและใช้ค่าใช้จ่ายสูงมากๆ
สุดท้ายส่งผลให้เราต้องสร้างมันขึ้นมาใหม่นั่นเอง

หนึ่งในการจัดการ Technical Debt คือ การแบ่งกลุ่ม

โดยคุณ Martin Fowler ได้อธิบายไว้ดังรูป

สามารถนำแนวทางนี้ไปใช้สำหรับการตัดสินใจว่า
Technical Debt ที่เกิดขึ้นอยู่ในส่วนไหน และ จะทำการแก้ไขมันทันทีหรือไม่
และใช้สำหรับเป็นข้อมูลเพื่อหาวิธีแก้ไข
รวมทั้งการป้องกันไเพื่อไม่ให้เกิดขึ้นอีกต่อไป

ดังนั้นมาดูว่า Technical Debt แต่ละส่วนเป็นอย่างไร

1. Prudent and deliberate
เป็นส่วนหลักที่ขับเคลื่อน business กันเลยทีเดียว
เนื่องจาก software ที่ทำการสร้างสามารถปล่อยออกไปให้ผู้ใช้งาน
หรือ ลูกค้าได้ใช้งานทันที และ ตลอดเวลา

และมักจะต้องทำตามแก้ไขตามมาหลังจากนั้น
แต่สิ่งต่างๆ เหล่านั้นได้รับการยอมรับจากทุกๆ ฝ่าย
หรืออาจจะบอกว่า เราไม่มีปัญหาจากการกระทำเหล่านี้ !!

ทำให้เกิด Technical Debt ที่ต้องตามมาจัดการ
บางครั้งปัญหาอาจจะใหญ่ และ ส่งผลกระทบต่อลูกค้าและบริษัท ด้วย

ตัวอย่างงานที่อยู่ในส่วนนี้ เช่น

• สร้างตลาดใหม่
• งานตามเทศกาล

2. Reckless and deliberate
ในส่วนนี้จะสะท้อนถึงการจัดการที่แย่ๆ
เนื่องจากยึดการส่งงานตามที่ deadline
มากกว่าจะทำการ clear เรื่อง business requirement
และการทำความเข้าใจระหว่างทีมพัฒนา และ business
แน่นอนว่ามันคือ ต้นเหตุของ Technical Debt ต่างๆ มากมาย เช่น

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

ผลที่ตามมาคือระบบที่สร้างนั้น มันยากต่อการแก้ไขมากมาย
หรือไม่สามารถแก้ไขได้เลย
ดังนั้น หยุดพฤติกรรมแบบนี้ดีกว่าไหม เพื่อผลในระยะยาว

3. Reckless and inadvertent
ในส่วนนี้มักจะเกิดขึ้นจาก developer ที่ขาดความรู้ หรือ ไม่ระมัดระวัง เลินเล่อ
ในการเพิ่ม และ การแก้ไข code
หรืออาาจะมาจากคุณไม่รู้ว่า คุณไม่รู้อะไร !!
ซึ่งก่อนให้เกิด Technical Debt จำนวนมหาศาล

โดยการจัดการ technical Debt ในส่วนนี้จำเป็นต้องใช้ความรอบคอบและระมัดระวังอย่างมาก
เช่นการพัฒนาคน การกำหนดขั้นตอนการทำงาน และ นำเครื่องมือมาช่วย เช่น

• Pair programming
• Code review
• Continuous integration
• Automated testing
• สร้าง community of practice ขึ้นมาในองค์กร
• การ training คนทั้ง technical skill และ soft skill
• กำหนด role ให้ชัดเจน

และอย่าลืมว่าต้องทำการดูด้วยว่าสิ่งที่กำลังทำนั้น มันส่งผลดีหรือไม่ อยู่อย่างเสมอ
เพื่อหาทางปรับปรุงให้ดีขึ้น ซึ่งคุณต้องหาทางที่เหมาะสมให้เจอ

4. Prudent and inadvertent
ในส่วนนี้มันจะเกิดขึ้นโดยธรรมชาติของทีม
ขึ้นอยู่กับประสบการณ์และความรู้ของทีมว่ามีมากน้องเพียงใด
ดังนั้น ทีมต้องทำการปรับปรุงอยู่อย่างเสมอ
จากสิ่งที่ไม่รู้ไม่เข้าใจ ก็ต้องทำการศึกษาให้มากยิ่งขึ้นไป
จากสิ่งที่ทำไว้แล้ว ให้กลับมาดู และ แก้ไขปรับปรุงให้มันดีขึ้นกว่าเดิม

ยิ่งอยู่กับระบบนานมากขึ้น ความรู้ที่ได้จะมาขึ้น
ส่งผลให้งานที่พัฒนาดีขึ้นตามาเช่นกัน

โดยในส่วนนี้ควรที่จะยึดถือแนวปฏิบัติของ Agile principle  ดังนี้

• ต้องทำกาสร้าง และ ส่งของที่ลูกค้าต้องการสุดๆหรือมีคุณค่า และทำการส่งมอบบ่อยๆ อย่างสม่ำเสมอ
• ทำการส่งมอบสิ่งที่เรียกว่า working software อยู่อย่างบ่อยๆ เช่น ทุกสัปดาห์ ทุกสองสัปดาห์ เป็นต้น
• ตัวชี้วัดความคืบหน้าของงาน คือ working software เท่านั้น
• เน้นที่ technical excellence และ การออกแบบที่พร้อมรับต่อการเปลี่ยนแปลง
• สถาปัตยกรรมที่ดีที่สุดของระบบ การออกแบที่ดีที่สุด ต้องออกมาจากทีม ไม่ใช่ใครคนใดคนหนึ่ง
• ทีมจะต้องกลับมา reflect สิ่งที่ทำมา กระบวนการทำงานที่ผ่านมา อยู่อย่างเสมอ เพื่อทำการแก้ไขปรับปรุง

โดยสรุป

ในทุกๆ องค์กร จำเป็นต้องมีความรู้ความเข้าใจเกี่ยวกับ Technical Debt
เพื่อหาเส้นทาง วิธีการในการจัดการที่มีประสิทธิภาพ
เพื่อป้องกันไม่ให้เกิดปัญหากับระบบที่คุณพัฒนากันนะครับ