ว่าด้วยเรื่อง ความสิ้นเปลือง 7 อย่างในการพัฒนา software

จากหนังสือ Lean Software Development: An Agile Toolkit
ได้ทำการสรุปความสิ้นเปลือง 7 อย่างในการพัฒนา software  ( 7 Wastes in Software Development )
นำมาจากความสิ้นเปลือง 7 อย่างจาก Lean ในโรงานอุตสาหกรรม
ซึ่งมีความน่าสนใจอย่างมาก
มาดูกันว่ามีอะไรบ้าง ?
มาดูกันว่าเราจะลด ความสื้นเปลือง เหล่านี้ได้อย่างไร ?

จากหนังสือ Lean Software Development ในหัวข้อ Seeing Waste

เขียนไว้ว่า

อะไรก็ตามที่ทำไปแล้ว ซึ่งไม่ได้สร้างคุณค่าให้กับลูกค้าโดยตรง
ถือว่า เป็นความสิ้นเปลือง (Waste) ทั้งหมด

ในปี 1970 นั้นคุณ Winston W. Royce
เขียนไว้ในเอกสารวิชาการ เรื่อง Managing the Development of Large Software System ไว้ว่า

ขั้นตอนพื้นฐานในการพัฒนา software นั้น ประกอบไปด้วย Analysis และ Coding
ส่วนขั้นตอนอื่น ๆ นั้นเป็นเพียงส่วนที่เพิ่มเข้ามา
ถึงจะมีความจำเป็น แต่ไม่ได้ส่งผลโดยตรงต่อ Final product
เหมือนกับ Analysis และ Coding
แถมขั้นตอนอื่น ๆ เหล่านั้น ยิ่งทำให้ค่าใช้จ่ายในการพัฒนาสูงขึ้นด้วย

ดังนั้นผู้เขียนหนังสือจึงตีความใหม่ว่า

ทุก ๆ ขั้นตอนในการพัฒนา software ยกเว้น Analysis และ Coding ล้วนเป็นความสิ้นเปลืองทั้งนั้น !!

สิ่งที่ควรถามกับตัวเราเอง ทีม และ องค์กร คือ
ขั้นตอนต่าง ๆ ที่เราสร้างขึ้นมา สำหรับการพัฒนา software นั้น
มันช่วยเพิ่มคุณค่าต่อลูกค้าหรือไม่ ?
หรือมันช่วยทำให้คุณสบายขึ้นกันแน่ ?

ความสิ้นเปลือง 7 อย่างในการพัฒนา software ประกอบไปด้วย

1. Partially Done Work
2. Extra process
3. Extra feature
4. Task switching
5. Waiting
6. Motion
7. Defect

มาดูรายละเอียดของแต่ละข้อกันว่าเป็นอย่างไร ?

1. Partially Done Work

มาจากคำว่า Inventory ใน Toyota Production System (TPS)
คืองานที่อยู่ในกลุ่ม Work In Progress หรือ ยังไม่เสร็จนั่นเอง
คืองานที่ไม่ได้มีคุณค่าอะไรเลย จนกว่าจะทำการ เสร็จจริง ๆ
และ ทำการ deploy ไปยัง production server
เช่น

• ออกแบบเสร็จแล้ว แต่ยังไม่ coding
• coding เสร็จแล้วแต่ไม่ทำการทดสอบ
• ทดสอบเสร็จแล้วแต่ยังไม่ทำการ deploy

ยิ่งมีจำนวนงานเหล่านี้มากเท่าไร ยิ่งก่อให้เกิดปัญหาตามมามากเท่านั้น !!

มาดูความสิ้นเปลืองชนิดนี้ แบบละเอียดหน่อยสิ

• ใช้เวลานานมาก กว่าจะรวม code หรือ merge code  ซึ่งปัญหาที่ตามมากนั้นมากมายใช่ไหม ?
• มี code จำนวนมากที่ไม่ถูกทดสอบ หรือ ไม่ทำการเขียน unit test เลย นั่นคือ ก่อให้เกิด bug อยู่อย่างเสมอ
• code ที่มันแย่ ๆ และ code ที่ไม่สามารถอธิบายตัวมันเองได้
• code ที่ยังไม่ทำการ deploy สักที บางระบบอาจจะ deploy ปีละครั้ง !! มันมีความเสี่ยงสูงมาก ๆ เราชอบการ deploy แบบ Big Bang !! ผลที่ได้คือ ระบบตัวเองล่มยังไม่พอ ดันพาระบบอื่น ๆ ล่มไปอีกด้วย ผลเสียตกที่ใคร ?
• code และ feature ที่ไม่เคยให้ผู้ใช้งานเข้ามาใช้งานเลย นั่นคือ เรื่อง feedback ของงานที่สร้างขึ้นมา มันมีคุณค่า ประโยชน์ต่อลูกค้าหรือไม่ ?
• เอกสารที่ไม่เคยตรงกับ code เลย !!

ดังนั้นมาลดจำนวนงานเหล่านี้ดีกว่านะครับ
จะช่วยลดความสิ้นเปลืองต่าง ๆ
รวมทั้งช่วยลดความเสี่ยงอีกด้วย

แปลกนะว่า หลาย ๆ ทีม หลาย ๆ องค์กร ชอบความเสี่ยงเยอะ
ทั้ง ๆ ที่ก็ทำ Risk management นะ !!

2. Extra process

มาจากคำว่า Extra processing ใน Toyota Production System (TPS)
หมายถึง process หรือ activity ที่ไม่ได้เพิ่มคุณค่าให้กับ software หรือ product ที่พัฒนาเลย

ดังนั้นลองตั้งคำถามไปยังทีมพัฒนา และ ตัวเราเอง ดูสิว่า
มี process หรือ activity อะไรบ้างที่มันจำเป็นต่อ product ?
มีเอกสารอะไรบ้างที่มันจำเป็นต่อ product ?
เอกสารที่ทำมีไว้เก็บแบบนี้หรือเปล่านะ ?

ลองคิดดูสิว่า
ถ้าเราเขียน customer test หรือ Acceptance test มาแทนที่ requirement
มันน่าจะดีกว่าไหมนะ ?
มันจะช่วยลดงานเอกสารลงไปไหมนะ ?
มันน่าจะช่วยเพิ่มคุณค่าให้กับ product หรือเปล่านะ ?

มีกฎง่าย ๆ หนึ่งข้อ คือ
Keep it short
Keep it high level
Keep it off line

3. Extra feature

มาจากคำว่า Over production ใน Toyota Production System (TPS)
หมายถึง feature ต่าง ๆ ที่ถูกเพิ่มเข้ามาในระบบ
ดูเหมือนว่า จะเป็นสิ่งที่ดี
เพราะว่า เราสามารถเพิ่ม feature ได้เท่าที่เราต้องการ
ซึ่งมันคือ การเพิ่ม code และเทคนิคใหม่ ๆ เข้ามายังระบบ

แต่ในความเป็นจริงแล้ว
สิ่งที่เราเพิ่มเข้าไปส่วนใหญ่มักจะเป็นความสิ้นเปลืองเสมอ
เนื่องจากเมื่อใดก็ตาม ที่เราแตะต้อง code
จะต้องทำการ compile
จะต้องทำการ integrate
จะต้องทำการ ทดสอบ
จะต้องทำการ deploy
จะต้องทำการ maintain
และทุกครั้งที่เราเพิ่ม code เข้าไป
เราได้เพิ่มความซับซ้อนของระบบขึ้นไปอีก
และนั่นคือ ต้นกำหนดของสิ่งเล็ก ๆ ที่เรียกว่า BUG
หรือก่อให้เกิดข้อผิดพลาดได้

ดังนั้น Developer ควรลดจำนวน code ที่ไม่จำเป็นออกไปบ้าง
ถ้าไม่ยังไม่จำเป็นตอนนี้ ก็ไม่ต้องเผื่อไว้หรอกนะ

4. Task switching

มาจากคำว่า Transportation ใน Toyota Production System (TPS)
ในการให้คนคนหนึ่งทำงานหลาย ๆ project
มันคือ บ่อเกิดความสิ้นเปลืองสุด ๆ ของการพัฒนา software
ใครทำอยู่บ้าง ยกมือขึ้น ?

การสลับไปทำงานแต่ละ project มันย่อมเสียเวลา
และเวลาการทำงานแต่ละ project มีขอบเขตอีกด้วย
ดังนั้น คุณค่าที่จะส่งมอบได้รวดเร็วไหม ?

มันขัดแย้งกับ Lean principle ที่บอกไว้ว่า
Deliver as fast as posible

ซึ่งเคยเขียนอธิบายไว้ใน blog เรื่อง Developer ทำงานช้า !

ตอนนี้คุณเป็น Multi-Tasker หรือเปล่านะ ?

5. Waiting / Delay

มาจากคำว่า Waiting ใน Toyota Production System (TPS)
หมายถึงการรอสิ่งต่าง ๆ ไม่ว่าจะเป็น

• รอเริ่ม project
• รอประชุม
• รอ requirement ที่ชัดเจน
• รอเอกสารที่ครบถ้วน
• รอทีมอื่น ๆ ที่เกี่ยวข้อง
• รอการพัฒนาให้เสร็จทุก ๆ feature
• รอการ review
• รอการ approve
• รอการทดสอบ
• รอการ deploy

การรอ และ delay สิ่งต่าง ๆ เหล่านี้มันคือ ความสิ้นเปลืองทั้งนั้น
และดูเหมือนจะเป็นความสิ้นเปลืองที่เยอะมาก ๆ สำหรับการพัฒนา software
เนื่องมาจากขั้นตอนการพัฒนาที่เทอะทะ เยอะเกินไป !!

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

ทางที่ดีที่สุด ในการจัดการสิ่งที่ไม่แน่นอน ก็คือ การส่งมอบบ่อย ๆ นั่นเอง

6. Motion / Flow

มาจากคำว่า Motion ใน Toyota Production System (TPS)

คำถาม

• เมื่อทีมพัฒนามีคำถามเกี่ยวกับ requirement ต้องใช้เวลานานเท่าไร กว่าจะได้คำตอบ ?
• ถ้าเกิดมีปัญหาเชิงเทคนิค มีใครตอบได้บ้าง ?
• มีลูกค้า หรือ ตัวแทนของลูกค้าคอยตอบปัญหา และ คำถามต่าง ๆ  ใกล้ ๆ หรือไม่ ?
• จะรู้ผลการทดสอบได้อย่างไร ต้องเดินไปถามหรือไม่ ?
• ทีมพัฒนาแยกกันทำงานคนละที่ คนละตึก คนละแผนก หรือไม่ ?

ถ้าใช้เวลานานในการตอบคำถาม
ถ้าไม่มีใครคอยตอบคำถาม หรือ ปัญหา
ถ้าต้องเดินไปมา เพื่อสอบถาม
ถ้าแยกกันทำงาน
ทั้งหมดนี่คือ ความสิ้นเปลือง ของการพัฒนา software

ดังนั้น คำว่า การทำงานเป็น TEAM WORK สำคัญมาก ๆ
ลดระยะทางของการติดต่อสื่อสารลงซะ
ทั้งระหว่าง developer กับ developer
ทั้งระหว่าง developer กับ tester
ทั้งระหว่าง ทีม กับ ลูกค้า

ไม่ใช่เพียงแค่คนเท่านั้น ที่ต้องเคลื่อนย้าย
เอกสารต่าง ๆ ก็ต้องตามไปด้วย
ซึ่งเราจะพบว่า เมื่อใดก็ตามที่เอกสารมันเคลื่อนย้าย
คนจะต้องตามไปด้วย เนื่องจากเอกสารมันไม่เคยอธิบายได้เลย

แปลกนะ แล้วเราจะทำเอกสารไปทำไม ?
ถ้ามันไม่สามารถอธิบายสิ่งที่มันต้องการสื่อสารได้
ซึ่งนี่ก็คือ ความสิ้นเปลือง ที่พบมาก ๆ ในการพัฒนา software

7. Defects

มาจากคำว่า Defects ใน Toyota Production System (TPS)
มันหมายถึง Bug, Error, Incident หรือความผิดพลาดต่าง ๆ ที่เกิดขึ้นมา
โดยผลการทำงานไม่เป็นไปตามที่คาดหวังนั่นเอง

ความสิ้นเปลือง ที่เกิดจาก defect มันมาจาก

• ผลกระทบที่เกิดขึ้นจาก defect นั้น ๆ
• เวลาในการหาต้นเหตุของ defect นั้น ๆ
• เวลาในการแก้ไข defect นั้น ๆ

ถ้าใช้เวลาในการหา และ แก้ไข น้อย ๆ ก็ สิ้นเปลืองน้อย
แต่ถ้าใช้เวลามาก ก็สิ้นเปลืองมาก
ดังนั้น แทนที่จะเสียเวลาไปกับการหา defect
เรามาแก้ไขที่ต้นเหตุของ defect ดีกว่าไหม ?
เรามาแก้ไขเพิ่มหา defect ได้อย่างรวดเร็ว ดีกว่าไหม ?

นั่นคือ
เราควรมีการทดสอบอยู่บ่อย ๆ
ทั้ง unit test
ทั้ง integration test
ทั้ง system test
ทั้ง acceptance test
ทั้ง user interface test
ทำการ deploy และ release ให้เร็ว ให้บ่อยที่สุดเท่าที่จะทำได้
เพื่อลด ความสิ้นเปลือง เหล่านี้ลงไป

สุดท้ายแล้ว

ลองกลับมาดูตัวเราเอง
ลองกลับมาดูทีม
ลองกลับมาดูองค์กร
ว่าในการพัฒนา software ของเรา ได้สร้าง ความสิ้นเปลือง เยอะหรือไม่ ?
และเราจะแก้ไข และ ปรับปรุง มันอย่างไรดี ?