ปีนี้เป็นปีแรกในรอบหลายปีเลยที่ไปงาน Agile Thailand แล้วไม่หนีกลับก่อน 😂 เลยอยากจะบันทึกไว้ว่าได้อะไรบ้าง แต่ที่ประทับใจสุดของวันเป็น Session ของพี่รูฟเลยที่มาเล่าเรื่อง Pair Programming 10 years later ซึ่งดีงามมากจนต้องจดบันทึก key takeaway เอาไว้หลายอย่างมาก ซึ่งถ้าใครอยากชมเต็มๆ สามารถไปดูได้ที่นี่เลยครับ ฟังพี่รูฟเล่าเองอินกว่าเยอะ ส่วนข้างล่างเป็นโน๊ตผมจดๆ ไว้ตอนอยู่ใน Session ครับ

• การทำ Pair programming ทำให้ทีมมี Level of collective ownership สูงกว่า
• ปัจจุบันมี paper แล้วเกี่ยวกับเรื่อง Pair programming - The collaborative software process - proof ได้เลยว่ามันดี มี calculation model, research, graph

Benefit

• Pair-Pressure - เราจะลากกันไป ทำให้ทีมส่งงานได้ และเรียนรู้ซึ่งกันและกัน
• Pair-Thinking - เราจะแชร์ ความรู้สึกและวิธีคิด จะได้ solution ที่ต่างกันจากต่างคน
• Pair-Relaying - ถ่ายเทความรับผิดชอบต่อกันได้ เช่น เวลา Pair กันแก้ปัญหายากๆ อีกคนหมดหลอด ให้อีกคนไปเขียน commit message สวยๆ ยังไหวอยู่
• Pair-Reviews - อีกคนจะคอยเช็คให้เราได้ทำตาม Practice ที่มันควรจะเป็นตาม convension มั้ย สามารถให้ฟีดแบคได้แล้ว learning ได้เร็วมาก
• Debugging by Explaining - มีตามากกว่าหนึ่งตาช่วยมองของได้ เห็นปัญหาได้เร็วขึ้น
• Pair-Learning - เราได้ความรู้ทุกๆ commit ที่เกิดขึ้น

Key success factor

จะ Pair ไม่ใช่โยนลงไป Pair เลยแล้วบอกว่าเราทำกันอยู่แล้ว แต่ต้องอธิบายจุดประสงค์ให้เข้าใจด้วยว่าทำไม

• Pair-Jelling - ทีมมี goal เดียวกัน และรู้ว่าทำงานเพื่ออะไร
  • ต้องอธิบายอย่างชัดเจน ว่า pair แล้วได้อะไร ทำไปเพื่ออะไร
  • ไม่มีใคร comfortable ที่จะ pair ตั้งแต่แรก
• Project ownership
• Mutual and self-respect - ต้องรู้ว่าตัวเองวิ่งได้เร็วเบอร์ไหนและไม่เบลมตัวเอง อย่าสร้างกำแพงมาล้อมตัวเราเอง
• Ego-Less Programming - คนที่มีประสบการณ์สูงต้องห้ามตัวเองไม่ให้ว่าคนอื่นว่ากาก แล้วไปว่าคนอื่นให้ทำงานช้าลง
  • เราต้องรับรู้ว่าทีมเรามีความสามารถแค่ไหน เราใส่พลังเข้าไปได้แค่ไหน
  • เราอย่าเป็นคนเก่งที่ทำให้คนอื่นบาดเจ็บจากความเก่งของเรา
• Workspace Layout - โต๊ะต้องใหญ่และคนนั่งด้วยกันได้เป็นคู่ จอใหญ่ 27++ ห้าม block google
  • ตรงนี้เกี่ยวกับ Feedback loop ทั้งหมดที่เกี่ยวกับการทำ Software ตรงๆ เลย

จำนวน test case cover มากกว่าทุก Artifact ถ้าเรา pair และ จำนวน defect ในระดับปี ลดลงอย่างมีนัยยะสำคัญ แล้วเราจะไปได้เร็วขึ้น

พอเราเป็น Introvert เราจะรู้สึกว่า Pair แล้วมันเหนื่อยมาก ซึ่งจริงๆ แล้วเราไม่จำเป็นต้อง Pair ตลอดก็ได้ พอเรา Pair เราใช้เวลาร่วมกับคนอื่นเพิ่มขึ้น 15-20% แค่ประมาณ 10ชม ต่อ sprint แค่นี้ก็ effective ก็มากขึ้นแล้ว ไม่จำเป็นต้องอยู่ครบ 8 ชม ทั้งวัน ก็ยังได้ประโยชน์จาก pair programming อยู่

และสิ่งที่เกิดขึ้นคือเกิน 90% ของคนที่ pair programming มั่นใจขึ้นและกล้าออกความคิดเห็น เพราะว่า software ที่ deliver ไป quality มันสูงขึ้นด้วย

Pair เถอะครับ เราทำงานช้าลงแต่มีคุณภาพมากขึ้น แล้วคนที่อยู่กับเราจะมีความภูมิใจกับงานที่ทำมากขึ้น

ถึงจุดนี้เลยเกิดคำถามคือ ทำยังไง Collective code ownership ถึงจะ scale ออกไปได้ในหลายทีมมากขึ้นและ maintain ได้ใน scale ที่ใหญ่ขึ้น

• การทำ software ไม่ได้ทำแค่ single component ทีมต้อง own architecture ต้องรู้ว่าโค้ดที่เราเขียนมัน reflect กับ Business ยังไง → DDD → เลยเกิด co-design, co-domain
• อย่าไปแบ่ง BU/IT อีกต่อไป เราเป็น software department เดียวมีหน้าที่ในการ delivery software
• ถ้าเราหมุนคนไปทำของที่จำเป็นได้ แล้ว component ข้างในมัน share ownership ได้จริงๆ organization เราจะไปได้เร็วมาก
• ถ้าการทำงานที่ share ownership มันมี benefit เราก็ไม่ควรสร้างกำแพงรอบสิ่งนี้ แต่มันควรจะ scale ไปในระดับ organization wide ด้วย
  • ทุกคนควรมี access ที่จะสามารถ contribute กลับไปหาต้นน้ำได้ตลอดเวลา
  • ต้นน้ำก็สามารถตรวจสอบ quality ได้ด้วย

เริ่มต้นที่ Pair Programming จบที่ Collective Ownership ไม่มีคำว่า Code

ปล.ผมชอบประโยคสุดท้ายมากครับ