แนวคิดหนึ่งที่ปัจจุบันมักจะได้ยินบ่อยๆ ขึ้นมา มี 3 เรื่อง คือ

  1. You Aren’t Gonna Need it (YAGNI)
  2. การทำในสิ่งที่เรียบง่ายที่สุด เท่าที่จะทำให้งานมันทำงานได้ตามที่ต้องการ
  3. Pain Driven Development

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

ถ้าแปล Pain Driven Development ตรงตัวแล้วนั้น
มันคือการพัฒนาที่ขับเคลื่อนด้วยความเจ็บปวด

แต่สิ่งที่มักพบเจอก็คือ ทีมจะเลือกวิธีการแก้ไขปัญหา
ที่จะเพิ่มความซับซ้อนให้กับระบบที่พัฒนาอยู่เสมอและรวดเร็ว (มันแปลกดีนะ !!)
ซึ่งมันมันยิ่งสร้างความเจ็บปวดให้เรา และ ทีม ใช่ไหม ?

ส่วนทีมที่ดีมักจะเพิ่มความซับซ้อนในอัตราที่ช้า
และมีการพิจารณาในการเลือกใช้วิธีการแก้ไขปัญหาที่ดี

คำถาม
แล้วมีวิธีอย่างไรล่ะ
คำตอบ

  1. ให้ทีมยึดแนวคิด You Aren’t Gonna Need it (YAGNI) คือ จะไม่ทำอะไรที่ยังไม่ต้องการ เช่น ถ้าคุณและทีมไม่มีปัญหา ดังนั้นก็ไม่จำเป็นต้องหาวิธีมาแก้ไขนะ ไม่มีการเผื่อเพื่ออนาคตนะครับ มีแต่ปัจจุบัน
  2. ให้รอจนกว่า คุณ และ ทีม จะรู็สึกเจ็บปวด นั่นมันบ่งบอกว่า เจอกับปัญหาที่แท้จริงแล้ว
  3. ให้หาวิธีแก้ไขปัญหาที่เรียบง่ายที่สุดเท่าที่จะเป็นไปได้
  4. ให้รอไปจนกว่าจะรู้สึกเจ็บปวดกว่าเดิม ถึงจะเริ่มหาวิธีแก้ไขปัญหาต่อไป

ซึ่งขั้นตอนนี้มันคือ แนวคิดของ Pain Driven Development

Pain Driven Development

เป็นวิธีการพัฒนาแบบ iterative นะ

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

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

แล้วทำซ้ำในรูปแบบนี้ไปเรื่อยๆ ดังรูป

Screen Shot 2557-11-09 at 12.53.08 PM

ขออธิบาย YAGNI สักหน่อยสิ

หนึ่งใน principle ของ Agile คือ

Simplicity–the art of maximizing the amount
of work not done–is essential.

ส่วนคำว่า YAGNI มันมาจาก Extreme Programming
เพื่อเน้นย้ำในเรื่องของคำว่า Simplicity
สำหรับจัดการกับสิ่งที่ยังทำไม่เสร็จ
ว่างานส่วนใดที่มันไม่จำเป็น หรือ ส่วนไหนจำเป็น
หัวใจคือ ทำให้น้อยที่สุด แต่ได้คุณค่ามากที่สุด
มันจะช่วยทำให้งานที่คุณทำนั้นประสบความสำเร็จ

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

ทีมจะรู้สึกเจ็บปวดได้อย่างไร

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

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

Screen Shot 2557-11-09 at 1.14.00 PM

คำอธิบาย
เป็นการทำ retrospective สำหรับเรื่อง Technical Debt ประกอบไปด้วยสองแกนคือ

  • แนวนอน คือ pain หรือ ความรู้สึกเจ็บปวดน้อย ไป มาก
  • แนวตั้ง คือ Effort หรือ สิ่งที่คุณต้องใช้ไปในการแก้ไข

โดยที่ความเจ็บปวด มันกระทบโดยตรงกับ productivity ของทีม เพราะว่าทีมต้องชดใช้หนี้ที่ก่อขึ้นมาด้วย
เช่นการ refactoring code เป็นต้น

คำถาม
แล้วเราจะชดใช้หนี้อะไรก่อนดีล่ะ ?
คำตอบ
ลองแบบออกเป็น 4 ช่องดังรูป แล้วคุณจะเห็นว่าต้องเลือกใช้หนี้อะไร
ซึ่งน่าจะอยู่ในส่วนของ High Return ใช่ไหมครับ

Screen Shot 2557-11-09 at 1.19.42 PM

ดังนั้นขอแนะนำให้ The Simplest Thing that Could Possibly Work ครับ
ทั้งการออกแบบระบบ การวาง architecture ของระบบ
ตลอดจนการแก้ไขปัญหาต่างๆ แล้วชีวิตจะดีขึ้นมา

Reference Website
http://itsadeliverything.com/pain-driven-development
http://www.markhneedham.com/blog/2011/08/21/pain-driven-development/