[บันทึก key takeaway #ATH21] Pair Programming 10 years later - @roofimon

[บันทึก key takeaway #ATH21] Pair Programming 10 years later - @roofimon

Subscribe to my newsletter and never miss my upcoming articles

ปีนี้เป็นปีแรกในรอบหลายปีเลยที่ไปงาน 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 ตรงๆ เลย

Screen Shot 2564-10-16 at 17.26.10.png

จำนวน 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 เถอะครับ เราทำงานช้าลงแต่มีคุณภาพมากขึ้น แล้วคนที่อยู่กับเราจะมีความภูมิใจกับงานที่ทำมากขึ้น

Screen Shot 2564-10-16 at 17.26.53.png

ถึงจุดนี้เลยเกิดคำถามคือ ทำยังไง 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

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

 
Share this