Golden nanotube
จากงาน OOP 2015 conference มีหัวข้อเรื่อง Technical Excellence ของคุณ James Grenning
ซึ่งได้อธิบายว่ามันคืออะไร
มีความสำคัญอย่างไร ต่อการพัฒนา software
แต่ทำไมนะ นักพัฒนา software ถึงไม่ค่อยนำไปใช้และปฏิบัติ
ดังนั้น มาดูว่าเขาทำการอธิบาย และ แนะนำอย่างไรบ้าง ?

ว่าด้วยเรื่องของ Technical Excellence ?

มันคือสิ่งที่นักพัฒนาทุกคนพึงมี พึงกระทำ
มันคือสิ่งจะช่วยแก้ไขปัญหาต่างๆ ได้

แต่บ่อยครั้งเราพบว่า ในการพัฒนา software นั้น

ผู้คนจำนวนมากมายมักจะยอมรับ
ให้มี code ที่มี bug ได้
ให้มี code ที่ยุ่งเหยิงสุดๆ ได้

นักพัฒนาก็ได้แต่นั่งรอ นั่งสร้าง ระบบที่มันซับซ้อนขึ้นไปทุกๆ วัน
ทั้งระบบที่มัน dependency ที่สูงขึ้น
เราก็ยอมรับ และ ยอมให้มันเกิดขึ้นมา
มันส่งผลให้เราเป็นผู้ประสบภัยในการพัฒนา software
ทั้งๆ ที่เราควรเป็น master หรือ ผู้เชี่ยวชาญมากกว่าหรือเปล่านะ ?

ดังนั้น เราควรที่จะเริ่มขยับตัวกันได้แล้วนะ
หนึ่งในนั้นคือ เรื่องของ Technical Excellence ซึ่ง

  • มันเกี่ยวกับความเป็น professional ในการพัฒนา software
  • มันเกี่ยวกับการเรียนรู้อย่างต่อเนื่อง (Continuous Learning)
  • มันเกี่ยวกับการปรับปรุงอย่างต่อเนื่อง (Continuous Improvement)

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

คำถามที่น่าสนใจ คือ ทำไมนักพัฒนา software ถึงไม่ค่อยสนใจ technical practice ?

ตัวอย่างเช่น Test-Driven Development (TDD) และ Refactoring
คำตอบที่น่าสนใจ คือ

  • นักพัฒนา software ส่วนใหญ่ไม่รู้ว่ามันคืออะไร ?
  • ไม่รู้ว่ามันช่วยแก้ไขปัญหาอะไร ?
  • ไม่รู้ว่าจะนำมันมาใช้อย่างไร ?

เรามักพบว่า นักพัฒนา software ไม่ค่อยมีเวลาในการเรียนรู้ และ ศึกษาสิ่งใหม่ๆ
จะมีเวลาเพียงการสร้าง และ พัฒนา software เท่านั้น !!

ยังไม่พอ ยังพบอีกว่าวิธีการที่นักพัฒนา software ใช้งานนั้น
มันเป็นสิ่งที่เก่าแก่มากๆ เกิดขึ้นมาตั้งแต่ยุค 70, 80 และ 90 กันเลย
เช่น การ print statement, การกำหนด break point และ การ debugging เป็นต้น
นั่นมันบ่งบอกว่า เราไม่ได้พัฒนา ไม่ได้เรียนรู้ ไม่ได้ปรับปรุงกันเลยใช่ไหม ?

ปีนี้มันปี 2015 แล้วนะ !!
คุณเคยเรียนรู้ TDD บ้างไหม ?
เพื่อช่วยป้องกันความผิดพลาดต่างๆ ซึ่งมันเกิดมาในปี 1999

หลายๆ คนก็บอกว่า เคยศึกษานะ
แต่ว่าเอาเข้าจริงๆ ก็บอกว่า ไม่มีเวลามาเขียนหรอกนะ ไอ้ test ต่างๆ เนี่ย
แค่จะเขียน code ให้มันเสร็จก็จะไม่ทันแล้วนะ
นั่นหมายความว่า
เราไม่มีเวลาแม้กระทั่งการป้องการปัญหาต่างๆ (Proactive)
แต่เรามีเวลาในการตามแก้ไขปัญหา (Reactive)
ซึ่งมันไม่น่าจะใช่สิ่งที่ถูกต้องหรือเปล่านะ ?
ลองคิดดูหน่อยสิ !!!

หลายๆ คนก็บอกว่า เคยศึกษานะ
แต่ว่าเอาเข้าจริงๆ แล้วทางหัวหน้าไม่ได้บอกให้ทำ !!!!

ปัญหาเรื่อง feedback loop ที่นานมากๆ
ซึ่งเชื่อว่านักพัฒนา software ทุกคนอยู่ในวังวนนี้เสมอ
นั่นคือ เราจะทำการประเมินเวลาการทำงานหนึ่งในหัวหน้า
อาจจะเป็นหลายสัปดาห์ หรือ หลายเดือน

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

ลองเปลี่ยนใหม่ หรือ หาวิธีการใหม่ๆ บ้างไหม ?

ลองทำงานเป็นรอบสั้นๆ
แบ่งการทำงานเป็น feature ย่อยๆ
ส่งมอบงาน หรือ feature อยู่บ่อยๆ
มันน่าจะทำให้ทีมพัฒนาได้รับความเชื่อมั่น และ ไว้เนื้อเชื่อใจมากขึ้นนะ
ยิ่งถ้ามี test คลุมการทำงาน
ถ้ามีการเปลี่ยนแปลงพฤติกรรมการทำงาน เราก็สามารถรู้ได้เลย
ไม่ต้องมานั่ง debug code แบบที่เป็นกันอยู่ มันก็น่าจะดีกว่าเดิมนะ

แล้วการฝึก และ นำ Technical Practice มาใช้ มันช่วยเพิ่ม Technical Excellence หรือ ?

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

ถึงแม้จะทำการ review code แต่ทำหลังจากที่พัฒนา หรือ สร้างไปแล้ว
มันก็ยากต่อการแก้ไข และ ปรับปรุงให้ดีขึ้น

ดังนั้น แนวทางที่ดีกว่า คือ
ให้คนทำงานมาทำงานด้วยกัน ใกล้ชิดกันสิ
มันจะช่วยทำให้ความรู้ต่างๆ กระจายไปหากันได้ง่าย
เนื่องจากเป็นการพูดคุยแบบ 2 ทาง
ซึ่งมันจะช่วยให้เกิด Technical Excellence ภายในองค์กรได้อย่างกว้างขวาง

สิ่งที่ยากมากๆ คือ คุณจะพูดโน้วน้าวให้ manager สนับสนุนได้อย่างไร ?

มันเป็นคำถาม how-to ? ที่ถามกันเยอะมากๆ ..
แปลกดีนะเออ … !!!

ก่อนอื่นที่จะไปบอกให้ใครทำอะไร อย่างไร
ช่วยกลับมาดูตัวเองก่อนว่า
คุณลงมือทำมันหรือยัง ?
คุณเข้าใจมันหรือยัง ?
คุณมีความเชื่อกับมันแล้วหรือยัง ว่ามันดีนะ ?
หรือเพียงไปฟังคนอื่นมาว่ามันดีอย่างนั้น อย่างนี้ !!

ถ้ายังก็เชิญลงมือปฏิบัติก่อนได้เลย
เพราะว่า มันต้องเริ่มจากหน่วยเล็กๆ ก่อนคือ คุณนั่นเอง

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

  • เมื่อเกิดปัญหาขึ้น ให้ระบุก่อนว่าปัญหาเกิดจากอะไรบ้าง
  • ให้เสนอทางเลือกในการแก้ไขปัญหา โดยจุดนี้เราสามารถเสนอแนวทางของเราไปได้
  • จากนั้นจึงเริ่มลงมือแก้ไขปัญหา

ถ้าแนวทางของเราได้รับการเลือก และผลที่ออกมามันดี
ต่อไปทีม และ องค์กร รวมไปถึง manager ก็จะเลือกใช้โดยอัตโนมัติ
แล้วคุณล่ะ คิดว่า มีแนวทางไหนอีก ?

Slide ของ session นี้

เมื่อปี 2014 ก็เคยเขียนสรุป session นี้จาก Agile Singapore 2014 ไว้เช่นกัน