Technical Debt กับ Scrum Teams
What is Technical Debt?
Technical Debt (ต่อไปนี้ผมจะขอเรียกสั้นๆ ว่า หนี้) เป็นการพูดเปรียบเทียบในวงการ software คือการอธิบายให้เราเข้าใจว่า short-term decisions นั่นส่งผลให้เกิดหนี้และเพิ่มต้นทุนในระยะยาวให้กับระบบของเรา เช่น เราตัดสินใจไม่เขียน test ในตอนนี้เพราะ… ดังนั้นในอนาคตเวลาที่มีการแก้ไข code จะทำให้เกิด bug ที่เราไม่รู้ตัวได้
ตัวอย่างของ Technical Debt ที่พบเจอบ่อย ๆ
- ไม่มี automation build, test และ deploy
- เกิด duplication code
- ไม่ update library
- ไม่มี document
มุมมองของ Scrum Teams
การสร้างการ์ดเพื่อแก้ technical debt ใน product backlog มักจะเป็นประเภท technical work เรามาลองสวมหมวกของทั้ง 3 หน้าที่ เมื่อมีการ์ดประเภทนี้เกิดขึ้นกัน
Product Owner จะให้ความสำคัญกับ business values, feature, จัดลำดับความสำคัญของงานและสังเกตว่าอะไรที่น่าจะตอบโจทย์กลุ่มลูกค้าได้มากที่สุด เรื่องหนี้จากกรอบแว่นของ PO จะมองในเชิงของ values ที่ได้รับหลังจ่ายหนี้สำเร็จ มองว่า effort ที่เสียไปถ้าทำการ์ดอื่นจะคุ้มค่ากว่าไหมหรือมองว่าถ้าแก้แล้วในระยะยาวจะช่วยเรื่องอะไร สิ่งที่คาดหวังเมื่อมีการ์ดที่เป็น technical work ทีมต้องบอกได้ว่า a กับ b หรือ c มี trade-off อะไร ถ้าไม่แก้ตอนนี้จะกระทบต่อการทำงานส่วนไหนบ้าง หรือถ้าตัดสินใจแก้มีอะไรรับประกันได้ไหมว่าจะไม่กระทบการทำงานของระบบ เช่น unit test, E2E อย่าลืมว่า effort ในการ re-test หรือ release ไม่ทัน ก็เจ็บปวดไม่แพ้กัน
สิ่งที่สำคัญมากๆ คือ หนี้ที่มีผลต่อ cost ทีมควรรีบแจ้งให้ PO รับทราบเพื่อที่เขาจะได้ตัดสินใจหรือรับรู้ความเสี่ยงที่เขาอาจจะต้องเจอในอนาคต
Scrum Master คนที่สวมเสื้อในหน้าที่นี้(ที่ผมรู้จัก)จะใช้ไม้บรรทัดของทีมในการตัดสินใจว่าสิ่งนี้คือ technical debt ไหม? ถึงแม้เขาจะเห็นว่า solution ที่ทีมคุยกันทำให้เกิดหนี้ เขาจะถามทีมก่อนเสมอว่า “ทางที่จะเดินทำให้เกิด technical debt ไหม?” ถ้าทีมตอบ ”ไม่” ก็จะปล่อยให้ทีมคุยกันต่อไป แต่ถ้าทีมตอบ “ใช่” อาจจะหาทางออกร่วมกันหรือถ้าพวกเขาสามารถจัดการปัญหานี้ได้ก็จะปล่อยให้ทีมคุยกันต่อ อย่าลืมว่าสุดท้ายคนที่ต้องแก้ปัญหาตอนเกิด incident คือทีมและทีมก็มี ownership ใน code มากกว่า scrum master (เขาจะเล่าความกังวลให้ทีมฟัง ถ้ารู้สึกว่าเป็นหนี้ก้อนโตแต่สุดท้ายคนที่ตัดสินใจคือ “ทีม”)
Team members ผู้รู้ ผู้ตื่น ผู้เบิกบาน ทีมคือคนที่รู้มากที่สุดว่าตรงไหนมีหนี้ ตื่นเต้นทุกครั้งเมื่อหนี้ทำให้เกิดปัญหาและเบิกบานใจเมื่อเราจ่ายหนี้สำเร็จ ผมเชื่อหมดใจว่าไม่มีทีมไหนอยากสร้างหนี้ เหตุการณ์ที่มักทำให้เกิดหนี้ ตัวอย่างเช่น ทีมไม่ได้นอนต้องทำงานแข่งกับ deadline มือพิมพ์คีย์บอร์ด เท้าที่ขยับตามเสียงดนตรีในขณะที่รอบข้างมีแรงกดดันจากหลายๆ ทางพร้อมกัน โดยที่ไม่รู้ด้วยซ้ำว่าจะต้องดูแลงานนี้ต่อหรือไม่ ผมนึกภาพไม่ออกว่าพวกเขาจะมีช่องว่างให้คิดถึงเรื่องเหล่านี้ได้อย่างไร อีกตัวอย่างที่มักเกิดขึ้นคือ PO เป็นคนตัดสินใจว่าจะกู้หนี้เพื่อให้ได้ quick solutions เพราะอยากให้ product ออกสู่ตลาดให้เร็วที่สุดจะได้เก็บ feedback หรือดูทิศทางของธุรกิจต่อไป
ก่อนที่ทีมจะสร้างการ์ดเพื่อแก้ technical debt ควรอธิบายให้ได้ก่อนว่าหนี้ก้อนนี้ส่งผลกระทบต่อระบบอย่างไร ไม่ใช่บอกแค่ว่า maintenance ยากหรือแก้โค้ดลำบาก อาจจะหาตัววัดให้ได้ว่ายากแค่ไหน ลำบากอย่างไร เช่น ถ้าไม่ชำระหนี้ การ์ดที่รับเข้ามาใหม่จะใช้เวลา 2 วันในการเพิ่ม feature หรือ debug ปัญหา แต่ถ้าจ่ายหนี้เสร็จ จะใช้เวลาแค่ 2 ชม. ต้องรู้ว่าหนี้ก้อนนี้รีบจ่ายไหม? ถ้าจ่ายแล้วมีความเสี่ยงที่จะกระทบกับส่วนไหนบ้าง? ถ้าไม่จ่ายจะเกิดอะไรขึ้น? หรือตกลงกันก่อนว่า หนี้ก้อนนี้จำเป็นต้องจ่ายจริงๆ ใช่ไหม?
Conclusion
technical debt เป็นเรื่องที่ซับซ้อน ไม่มีทางออกที่ชัดเจน เป็นเหมือน trade-off ลองนึกภาพว่าถ้าระบบที่เราพัฒนาไม่มีหนี้เลย แต่ระบบไม่มี customer ใช้งาน เราจะทำไปเพื่ออะไร หรือระบบเรามี customer ใช้งานเยอะมาก แต่ maintenance ยาก การที่จะเพิ่ม feature ใหม่ๆ ก็ใช้เวลานาน ทำให้แข่งขันไม่ทันในโลกของธุรกิจอยู่ดี
ส่วนตัวผมชอบ quote จากบทความ Technical Debt Is Like Tetris เขาบอกว่า You can’t win. You can only control how quickly you lose. อย่าลืมว่า technical debt ไม่แย่เสมอไป บางครั้งก็มีประโยชน์ อย่างน้อยคุณก็ได้เรียนรู้จากมัน