เพิ่งคุยเรื่องของการพัฒนา software กันไปว่า
มันมี waste อะไรบ้างที่มักจะเกิดขึ้นมา
แถมส่งผลมากมายต่อการพัฒนา
หนึ่งในนั้นคือ speed หรือความเร็วของการพัฒนา
เลยหยิบรายละเอียดมาจาก Lean for Software Development
มาสรุปไว้กันลืมในบางข้อ
มาเริ่มกันเลย
โดยที่ waste ประกอบไปด้วย 7 อย่างคือ
- Partially done work
- Extra features
- Relearning
- Handoffs
- Delays
- Task switching
- Defects
มาดูเรื่องที่น่าสนใจในบางเรื่องกันนิดหน่อย
เรื่องที่ 1 Partially done work (In-process Inventory)
ในการพัฒนา software นั้น เราจะพบว่า
Code ที่พัฒนาขึ้นมานั้น
ที่ทีมบอกว่าเสร็จ มันเสร็จจริง ๆ ไหม ?
ทำการ checkin ไปยัง version control ไหม ?
ทำการทดสอบไหม ?
ถูก integrate เข้ากับระบบจริง ๆ ไหม ?
ทำการ deploy จริง ๆ ไหม ?
ทำการส่งมอบไปถึงมือลูกค้าหรือผู้ใช้งานจริง ๆ ไหม ?
หรือต้องรอส่งเป็นชุดใหญ่ไฟกะพริบ เช่น เดือน หรือ หลายเดือน หรือ ปีละครั้ง
ดังนั้นงานที่คุณทำเสร็จ มันเสร็จจริงไหม
นี่คือ waste ที่มักจะเกิดขึ้นตลอดเวลา
ไม่ว่าจะด้วยเหตุผล หรือ ข้อจำกัดใด ๆ ก็ตาม
เราจำเป็นต้องลงเวลาและจำนวนของงานแบบนี้ลงไปให้มาก ๆ
เพราะว่าสิ่งเหล่านี้ มันก็เหมือนของที่ไม่มีประโยชน์ แต่ต้องเก็บไว้
นับวันยิ่งมาก ปัญหาที่ตามมาก็เยอะ
ตัวอย่างของ Partially done work ที่พบเจอบ่อย ๆ คือ code เช่น
- Code ที่ copy and paste มาใช้
- Code ที่ถูก comment ซึ่งไม่ได้ใช้งาน มีไว้ทำไม ?
- Code กับ เอกสารต่าง ๆ ไม่ตรงกัน
- Code ของนักพัฒนาแต่ละคนไม่ตรงกัน หนักกว่านั้น code ที่ขึ้น production ก็ code ที่พัฒนาไม่ตรงกัน
- Code ที่ไม่ทำการทดสอบ หรือ ทำการทดสอบเพียงบางส่วน เรามักจะเจอคือ แก้ไข 1 bug ได้กลับมาอีก 5 bug เป็นต้น
- Code ที่ไม่สามารถอธิบายได้ หรือ ไม่มีเอกสารอธิบายการทำงาน ทำให้การดูแลรักษาลำบากอย่างมาก
- Code ที่ไม่ถูก deploy ไปยัง production ส่งผลให้เราต้องทำการ deploy แบบ big bang ซึ่งส่งผลให้เกิดปัญหามากมายตามมา
เรื่องที่ 2 Extra features (Overproduction)
สังเกตุได้ว่าในการพัฒนาระบบงานนั้น
สิ่งที่เราเจอบ่อยมาก ๆ นอกเหนือจากการพัฒนาระบบงาน
มักจะมีเรื่องต่าง ๆ ดังนี้เพิ่มเข้ามา
- Code ต้องถูก track ว่าถูกใช้หรือไม่ และมีการเปลี่ยนแปลงอย่างไร
- Code ต้องถูก compile
- Code จำเป็นต้องใช้งาน dependency/library ต่าง ๆ ดังนั้นต้องไป download มาอีก
- Code ต้องถูก integrate เข้ากับส่วนต่าง ๆ
- Code ต้องถูกทดสอบ
- Code ต้องดูแลรักษาได้ง่าย
- Code จะมีความซับซ้อนขึ้นเรื่อย ๆ
- Code ยิ่งเยอะก็ยิ่งเพิ่มโอกาสผิดพลาด
- Code อาจจะไม่ถูกใช้งานอีก
ประเด็นหลัก ๆ คือ เราจะแก้ไขปัญหาของงานต่าง ๆ เหล่านี้ไปได้อย่างไร ?
แนวทางที่น่าสนใจคือ short feedback loop
ทำการพัฒนาเฉพาะ feature ที่มีความสำคัญ
จากนั้นทำการ demo บ่อย ๆ
ยังไม่พอ ต้องทำการ deploy ไปยัง production บ่อย ๆ
เพื่อให้ถึงมือผู้ใช้งานบ่อยๆ
จะช่วยลดปัญหา เวลาและค่าใช้จ่าย ๆ จาก extra work หรืองานงอกต่าง ๆ
ที่สำคัญแต่ละ feature ที่พัฒนาขึ้นมานั้น
ต้องทำการติดตามดูด้วยว่า มีการใช้งานด้วยหรือไม่ ?
ถ้าไม่ถูกใช้งานก็ควรลบหรือเอาออกไปจากระบบงาน
เพื่อลดความซับซ้อน และ ง่ายต่อการดูแลรักษามากยิ่งขึ้น
นี่มันแนวคิดของ YAGNI (You Ain’t Gonna Need It) นี่ !!
นั่นคือการเพิ่ม feature/code ต่าง ๆ เข้าไป
เท่าที่ผู้ใช้งานต้องการหรือใช้งาน
เรื่องที่ 3 Hand offs (Transportation)
นั่นคือการส่งงานจาก role หนึ่งไปอีก role หนึ่ง
ในการพัฒนาระบบงานมักจะมีการส่งงานแบบนี้เยอะมาก เช่น
Business analyst -> Analyst -> Designer -> Programmer/Developer -> Tester/QA -> Operation
ในแต่ละ role ก็มีหน้าที่และบทบาทต่างกันไป
แต่ปัญหาที่ตามมาจากการทำงานในรูปแบบนี้คือ
ปัญหาในการส่งต่อความรู้ (Transfer knowledge)
พบว่าความรู้ความเข้าใจจะลดลงไปอย่างมาก เมื่อส่งต่อเยอะ ๆ ดังนี้
- ส่งไป 1 ต่อ ความรู้จะลดลงไปเหลือเพียง 50%
- ส่งไป 2 ต่อ ความรู้จะลดลงไปเหลือเพียง 25%
- ส่งไป 3 ต่อ ความรู้จะลดลงไปเหลือเพียง 12%
- ส่งไป 4 ต่อ ความรู้จะลดลงไปเหลือเพียง 6%
- ส่งไป 5 ต่อ ความรู้จะลดลงไปเหลือเพียง 3%
ดังนั้น เรายังทำงานในรูปแบบนี้อีกหรือ ?
ปัญหานี้ต้องรีบทำการแก้ไข
ยกตัวอย่างเช่น
- ลดจากการส่งงานเป็นทอด ๆ แบบนี้ลง กลับมาทำงานเป็นทีมดีกว่า (Cross-functional team)
- เปลี่ยนการติดต่อสื่อสารให้มีประสิทธิภาพมากยิ่งขึ้น เช่น face-to-face, vdo เป็นต้น ส่วนการติดต่อสื่อสารด้วยตัวอักษรก็ลดลงไป
- เอกสารก็ทำเท่าที่จำเป็นต่อการทำงานร่วมกัน ยกตัวอย่างเช่นการเขียนใน Wiki เป็นต้น
- ต้องทำให้เกิด fast feedback หรือ ให้มีขั้นตอนการทำงานที่สั้น ๆ ไม่เทอะทะ
เรื่องที่ 4 Task Switching (Motion)
ในการทำงานนั้น เราจะเข้าใจกันว่า
ถ้าคน ๆ หนึ่งทำงานจนเข้าสู่สถานนะไหลลื่นหรือ flow แล้ว
จะช่วยทำให้คนนั้นมี productivity ที่สูงมาก
แต่ในการทำงานจริง ๆ กลับพบว่า
มีงานแทรก
มีสิ่งที่ทำให้เสียสมาธิ เช่น ประชุม หรือ งานด่วนและด่วนมาก
มีงานทำมากกว่า 1 project ให้ทำและดูแล และอื่น ๆ
ผลที่ตามมาคือ งานก็ไม่ค่อยได้เรื่อง ความผิดพลาดก็เยอะ เหนื่อยกายและใจ
สุดท้ายก็ …
ปัญหานี้ควรได้รับการแก้ไขอย่างเร่งด่วน
แน่นอนว่า ทีมพัฒนาฝ่ายเดียวทำไม่ได้แน่ ๆ
ฝ่าย management ก็ต้องเข้าใจและจัดการด้วย อะไรที่สำคัญบ้าง ?
อะไรที่ไม่สำคัญก็ไม่ควรทำ หรือเข้าคิวไว้ท้าย ๆ จัดคิวให้ดี
ทำเพียงหนึ่งงานในช่วงหนึ่ง ๆ อย่าสลับไป ๆ มา ๆ มันไม่ดีเลย
ดังนั้น Limit Work in Progress จึงมีความสำคัญมาก ๆ
ถ้าทุกอย่างมันสำคัญหมด ก็คงไม่มีอะไรสำคัญเลย
