Screen Shot 2558-01-08 at 9.29.23 AM
เรื่องที่ 23 ที่นักพัฒนาควรรู้ และ เข้าใจก็คือ Pair Program and Feel the Flow

ลองจินตนาการดูหน่อยสิว่า
ถ้านักพัฒนาทุกๆ คน

  • ได้ focus ในงานที่ทำ
  • ได้ทำงานเฉพาะอย่างในเวลาหนึ่ง
  • ได้เข้าไปมีส่วนร่วมกับงาน

แล้วคุณจะลืมเรื่องของเวลาไปเลย
แล้วคุณจะรู้สึกดีกับมันมากๆ

ซึ่งนั่นคือ คุณตกอยู่ในสภาวะลื่นไหล ภวังค์ หรือ Flow นั่นเอง
แต่มันยากนะ !!

แต่ในความเป็นจริงมันยากมากๆ

ที่จะรักษาสมดุลระหว่าง งานที่ต้องทำให้เสร็จ กับ สภาวะลื่นไหล
ของทีมพัฒนา เนื่องจากมันมีหลากหลายเหลือเกินทั้ง

  • งานแทรก งานงอกต่างๆ นานา
  • สิ่งรบกวนต่างๆ มากมาย เช่น การ Chat, โทรศัพท์, Social network และอื่นๆ อีกมากมาย

สิ่งต่างๆ เหล่านี้มันทำให้สภาวะ และ ความสมดุล ไม่มีเลย
แล้วจะแก้ไขอย่างไรดีล่ะ ?

สิ่งที่ขอแนะนำคือ Pair Programming

ถ้าคุณยังไม่เคยลองในทีมพัฒนาแล้ว
แนะนำให้ลองนำไปใช้งานดู แล้วคุณจะได้สถาวะลื่นไหลกลับคือมา

วิธีการนั่นง่ายมากๆ คือ ทำงานเป็นคู่นั่นเอง

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

Pair programming จะสำเร็จได้นั้น
ทุกๆ คนในทีมจะต้องใช้ความพยายาม และ ลงแรงพอสมควร
เนื่องจากแต่ละคนในทีมล้วนแตกต่างกัน
ทั้งความสามารถ วุฒิภาวะ ต่างๆ
แต่ว่าในแต่ละคุณล้วนมีสิ่งที่มีค่าทั้งนั้น
ไม่ว่าด้านใดก็ด้านหนึ่ง

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

ไม่เท่านั้น ยังส่งผลดีต่อทีม
และแน่นอนว่า มันส่งผลดีต่อระบบที่พัฒนาด้วยอย่างแน่นอน

ต่อจากนั้นในระดับของทีม
จะต้องใช้การ pair programming เพื่อกระจายความรู้ต่างๆ ออกไปให้แต่ละคนในทีมด้วยการ

  • ทำงานเป็นคู่
  • แก้ไขปัญหาเป็นคู่
  • ให้ทำการสลับสับเปลี่ยนคู่อยู่อย่างสม่ำเสมอ เช่น ทุกๆ สัปดาห์ เป็นต้น
  • ให้ทำการสลับงานกันทำ

โดยทุกคนในทีมจะต้องเห็นด้วยกับการสลับแบบนี้ด้วยนะ

การสลับไม่จำเป็นต้องสลับหลังจากที่งานเสร็จ

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

จากการทำ Pair programming พบว่า

มันช่วยรักษาสภาวะลื่นไหลของการทำงานได้ ดังนี้

ลดปัญหา Truck factor
ในทีมพัฒนาใครคือ Hero หรือ มีปัญหาคอขวดไหม ?
ความรู้ต่างๆ ในการพัฒนาระบบอยู่ที่คนใดคนหนึ่ง หรือ อยู่กับทีม ?
ถ้ามีใครคนใดคนหนึ่งออกจากทีมไป ทีมสามารถทำงานได้ไหม ?
ถ้าสลับงานไปให้คู่ pair อื่นทำ จะยังสามารถพัฒนาให้งานนั้นเสร็จด้วยความรู้ที่มีได้ไหม ?

ถ้าสามารถทำงานได้ โดยไม่ส่งผลต่อสภาวะลื่นไหลของทีม
แสดงว่า Truck factor ไม่มีผลอะไรกับทีมของคุณเลย

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

ปกติที่ทำกันอยู่ ถ้าคิดแก้ไขปัญหาอยู่คนเดียว
คุณมักจะตกอยู่ในปัญหาคนเดียว
ปวดหัวคนเดียว ซึ่งมันไม่สนุกเลยใช่ไหม

การเขียน code และการ integrate code ในระบบดีขึ้น
เนื่องจากในการ pair programming นั้น
เหลือมีคนช่วย review code ที่เขียนว่ามันดี หรือไม่ดี
เนื่องจากมีตาช่วยกันดูถึง 2 คู่
และคุณจะได้คุยกันถึงสิ่งที่กำลังพัฒนา
เพื่อปรับปรุงให้ดีขึ้น เช่น การปรับปรุงการตั้งชื่อ เอกสาร และ การทดสอบเป็นต้น

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

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

ลองกลับไปดูวิธีการสอนแบบเดิมของคุณสิว่า มัน work ไหม ?
ถ้ามันไม่ work ลองมาทำแบบ pair programming ดูนะ

รวมทั้งสามารถนำมาใช้ในการสัมภาษณ์คน
เพื่อเข้ามาทำงานร่วมกับทีมด้วยนะครับ

สุดท้ายแล้ว

ถ้าคุณสามารถรักษาสภาวะลื่นไหลในการทำงานของทีมพัฒนาไว้ได้
คุณจะพบว่า productivity มันจะสูงขึ้นมาแบบอัตโนมัติ
แต่มันก็มีความเสี่ยงเช่นกัน

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

Do what you can to get it, and hold on to it when you’ve got it!