TechX Sharing : Pair Programming 10 Years Later
SCB TechX มีการจัด TechX Sharing กันทุกวันศุกร์เป็นประจำอยู่แล้ว สำหรับ Session แรกของปี 2022 เมื่อวันที่ 14/01/2022 ที่ผ่านมานั้น พี่รูฟ Twin Panitsombat ซึ่งเป็น Software Stylist จาก ODDS มาแชร์ประสบการณ์ให้เราฟังกันในหัวข้อ Pair Programming 10 Years Later
Blog นี้ จึงทำการสรุปมาให้ทุกคนได้อ่านกันว่า Pair Programming 10 Years Later เนี่ย มันเกิดอะไรขึ้นบ้าง อะไรดีไม่ดี อะไรควรทำไม่ควรทำ ควรทำยังไง แล้วเราจะขายงานที่จะต้องใช้ 2 คนทำ 1 งาน ยังไงให้ลูกค้าเข้าใจ ว่าสิ่งที่เค้าได้มันคุ้มค่า Blog นี้เรามีสรุปไว้ให้หมดเรียบร้อยแล้ว 😜
⚫ Agile Principles
วกกลับมาถึง Agile principles ที่คนส่วนมากน่าจะรู้และเข้าใจกันมาระดับนึงแล้วในยุคนี้ ซึ่งก็มี Agile principles ข้อนึงที่ดูคล้ายคลึงกับเรื่องนี้ก็คือ
11. The best architecture, requirements, and designs emerge from self-organizing teams.
Design emerge
หรือ Emergent design ที่หลายๆคนคุ้นหู 1 ใน Core software principle design ในรูปแบบของการทำ Agile ที่เชื่อว่า Software ไม่มี Solid architecture หรือว่า Solid design ที่บอกได้ตั้งแต่ Day 1 ของ Project ว่าเนี่ยคือ Best ที่สุดสำหรับ Product ตัวนี้ เพราะว่า Business requirements เปลี่ยนแปลงตลอดเวลา การแข่งขันเกิดขึ้นอยู่ตลอดเวลา
⚫ Pair Programming
การที่จะเอาคน 2 คน ไปทำงาน 1 งาน แล้ว Pratice เหล่านี้ก็ยากที่จะ Adopt ใน Organization ที่มันใหญ่ ณ ช่วง 10 ปี ที่แล้วนั้นมันดูเหมาะกับ Organization ที่ยังไม่ใหญ่มากและมี Product ไม่มาก และเกิดคำถามมากมายที่ไม่มีหลักฐานในเชิง Research paper หรือ Case study รองรับ ว่าสิ่งๆนี้มันดียังไง นอกจากคำพูดว่ามันดี
Design emerge
สิ่งนี้จะเกิดขึ้นได้ Team ควรจะมี Practice ที่ชื่อว่า Pair programming เพราะว่า สิ่งหนึ่งของการที่เราไม่สามารถ Emerge software ได้ก็คือ ปัญหาของการทำ Software แบบ Personal ownership อธิบายๆง่ายก็คือ Module หรือ components นั้น Belong to individual หรือก็คือ ถูกผูกอยู่กับคนเพียงคนเดียวมากเกินไป
ใน Legacy system ที่ถูกส่งต่อกันมาอย่างยาวนาน ก็อาจจะมีบาง Components ที่ Document ไม่ Update มาหลาย Version คนทำไม่อยู่แล้ว เหลือแต่เพียงพระเจ้าเท่านั้นที่รู้ว่าตอนนี้ Components นี้ทำงานยังไง สาเหตุสำคัญคือ Process การทำงานสมัยก่อนมักจะสร้าง Expert ทางด้าน Components นั้นๆขึ้นมา โดยไม่ได้คิดถึงว่าคนนั้นจะไม่ได้อยู่กับเราตลอดไป เป็น Fact อย่างนึงว่าไม่มีใครอยู่กับบริษัทไปตลอดกาล คำถามคือ เราจะ Maintance knowledge ยังไงให้ยังอยู่ภายใน Team ของเรา ?
○ Collective Code Ownership
เป็น Key concepts ของ Extreme programming ถ้าเราอยากจะให้ทั้ง Team มีความเป็นเจ้าของใน Software ที่เค้าดูแลอยู่เนี่ย ต้องทำยังไงบ้าง ?
อย่าให้คนเพียงคนเดียวทำสิ่งนั้น
ต้องพยายามให้มีอย่างน้อย 2 คน ทำสิ่งนั้น หรือว่า Pair กัน ค่อยๆ Deliver ของสิ่งนั้นไปด้วยกัน คุยกันแชร์ความคิดกัน ช่วยกันทักท้วงว่ามีอะไรผิดไปจาก Design ที่คุยกันจริงๆศาสตร์นี้ยังมีอีกเยอะมากแต่เราพูดถึงกันเพียงเท่านี้ก่อน
○ การเริ่มทำ Pair Programming
การทำ Pair programming นั้นมีหลายส่วนประกอบ ไปเริ่มกันที่
Workspace
ใช้ จอ Monitor , Keyboard , Mouse 1 อัน และ โต๊ะ 1 ตัว เก้าอี้ 2 ตัว สำหรับการทำงาน 1 Pair หรือ 2 คน จริงๆแล้วเรา
Pair
จับคู่สมาชิกในทีม โดยมีคนนึงถือ Keyboard คนนี้เรียกว่า Driver จะเป็นคนที่มีประสบการณ์น้อยใน Area ของ Software หรือสิ่งที่เรากำลังจะทำ
ส่วนอีกคนที่ถือ Mouse คนนี้เรียกว่า Navigator คือคนที่มีประสบการณ์เยอะกว่าใน Area ของ Software หรือสิ่งที่เรากำลังจะทำ
โดยเริ่มจาก Driver หยิบ Card สิ่งที่เค้าจะทำแล้ว Think out lound step สิ่งที่ต้องการจะทำ Design ออกมายังไง แล้วต้องการเขียนออกมายังไง ส่วน Navigator ก็จะ Review process นี้ก่อนว่าถูกต้องตามที่ควรจะเป็น ตาม Standard ของ Components นี้รึป่าว ถ้าถูกต้องก็ให้ Navigator เรา Navigate ไปที่ File ที่เราต้องการจะทำแล้วก็ลงมือทำ แล้ว Driver ก็ค่อยๆพูดไปว่าต่อไปจะทำตรงนี้ ต่อไปจะทำตรงนั้น มาถึงตรงนี้เราก็จะพบว่าคนที่เป็น Navigator ซึ่งเป็นคนที่มีประสบการณ์ตรง Components นี้มากกว่าเนี่ยได้ Review สิ่งที่เราทำอยู่ตลอดเวลา ดังนี้โอกาศที่เราจะผิดพลาดในการ Deliver software components นั้นๆเนี่ยก็จะน้อยลงมาก
โดยส่วนใหญ่ ครึ่งวัน หรือ 1 วัน หรือจบ Card จะทำการสลับ Pair ให้มีโอกาศได้สลับกับไปดูทุก Components ทำให้ใน 1 Sprint เนี่ยเราได้ไปแตะหลายส่วนของ Software ที่เราทำไม่ยึดอยู่กับ Secure card ที่เราเป็น Owner components นั้นเพียงอย่างเดียว ทำให้ทุกๆคนมีความรู้ในแต่ละส่วนเท่าๆกัน ทำให้ความเร็วโดยเฉลี่ยในการ Deliver ของในแต่ละ Sprint ไม่ตกลงไปเมื่อมีคนลา หรือหายไป
○ ข้อควรระวังในการทำ Pair Programming
Navigator ต้องอย่าสั่งให้ Driver ทำ เด็ดขาด ! พิมพ์ตรงนี้สิ ทำแบบนี้สิ ! ต้องอย่าลืมว่า Driver คือคนที่มีประสบการณ์น้อยกว่าใน Components นั้น แบบนี้ไม่โอเคและไม่ถูกต้อง เพราะจะทำให้มีศพอยู่ตรงนั้น เรียกว่า ตายคาที่ กันเลยทีเดียว ให้ Driver เค้าคิดออกมาแล้วก็พูดตลอด อย่างที่บอกไปข้างต้น แล้ว Navigator ก็ Review
○ ความเข้าใจผิดในการทำ Pair Programming
คนส่วนมากเข้าใจว่าการ Pair จะต้องเกิดขึ้นตลอดวัน หรือตลอด Sprint โดยไม่สามารถปลีกตัวไปทำงานคนเดียวได้เลย แต่อย่าลืมว่าโลกมีคนอยู่หลายประเภท เช่น
Introvert : คนที่ชอบอยู่คนเดียว ไม่สุงสิงกับใคร ชอบคิดคนเดียว
Extrovert : คนที่ชอบพูดคุยกับคนอื่น เดินไปเดินมา
ซึ่งคนที่เป็น Extrovert มักจะชอบการทำงานเป็นกลุ่มมากกว่า เช่น เป็น Pair หรือ เป็น Mob แต่ Introvert เนี่ยไม่ได้ชอบที่จะทำงาร่วมกับคนอื่นมากนัก เราควรทำยังไง ?
เราสามารถแบ่งเวลาได้ เช่น 1 Sprint เราอาจจะแบ่งเวลาสัก 70% ในการทำ Pair อีก 30% ให้แยกไปทำของตัวเองแล้วกลับมา Sync กัน การแบ่งเวลาแบบนี้ยังคงให้ผลได้ใกล้เคียงกับการทำ Pair 100% ทั้งนี้ทั้งนั้นขึ้นอยู่กับ Team ด้วยว่าอยากจะเลือก Ratio ในการ Pair เป็นเท่าไหร่ที่เหมาะสมกับ Team ของตัวเอง
⚫ Academic Research
Classic question ของ Business team หรือ Investor team ก็คือ แล้วทำไมเราจึงต้องนำคน 2 คน ไปทำงาน 1 ชิ้น กันนะ ? ในมุมของ Business ก็อาจจะมองว่า Team เสีย Productivity มั้ย ก็ดูเป็นคำถามที่กระอักกระอวมที่จะตอบ เพราะไม่มีหลักฐานทางตัวเลขหรือทางสติถิ หรือ Use case ว่าสิ่งนี้มันดีจริงๆ แบบเป็นรูปธรรม
แต่ในปัจจุบันได้มี Research ที่ตอบเรื่องพวกนี้ได้หมดแล้ว เช่นตัวอย่าง Research นี้
○ Why Collaborative Programming is Beneficial
ทำไมการเขียน Program ร่วมกัน Collaborative Programming หรือ Pair Programming ถึงมีประโยชน์ Research นี้บอกไว้ด้วยกันทั้งหมด 6 ข้อ ดังนี้
Pair-Pressure
เป็นการสร้าง “ความกดดัน” เชิงบวกด้วยกันทั้งคู่ หรือก็คือการไม่อยากทำให้ Pair ของตัวเองผิดหวังทำให้ตั้งใจทำงานมากขึ้น Focus กับงานมากขึ้น และมีแรงจูงใจที่จะทำงานให้เสร็จมากขึ้น และจะไม่ถูกรบกวนจาก Check email หรือการรับโทรศัพท์ หรือรวมไปถึงการเล่น Socail media ด้วย เพราะจะทำให้เราเกรงใจ ไม่นำเรื่องส่วนตัวของเราไปยุ่งเกี่ยวกับเวลาของ Pair
Pair-Think
โดยปกติ Developer คนนึงเหมือนได้โจทย์ A ก็จะมี Solution ของโจทย์ A อยู่สำหรับ Developer คนนั้น แต่ถ้าหากมี Developer ที่มาทำโจทย์ A เพิ่มขึ้นมาอีกคนนึง ก็จะมีโอกาศเกิด Design หรือ Solution สำหรับโจทย์ A ที่อาจจะดีกว่าขึ้นมา 2 เท่า 3 เท่า หรือมากกว่าขึ้นอยู่กับประสบการณ์ของ Pair หรืออาจจะ มี 1 Solution เหมือนเดิม แต่เป็น Solution ที่มีการ Review เกิดขึ้นมาเพิ่มแทน
ใน Research พบว่า Pair ส่วนมาก จะมี Solution ที่ต่างกันเสมอ สำหรับโจทย์เดียวกัน และจะเกิด New solution ที่ดีกส่าเมื่อนำทั้ง 2 Solution มา Merge กันอยู่เสมอ ซึ่งเกิดจากการ Discussion จนทำให้เกิด New alternatives ตลอดเวลา
Pair-Relaying
มักจะเจอเวลาที่ Developer ได้ทำโจทย์ที่ยากมากๆ เมื่อ Solve โจทย์นั้นได้แล้วก็เกิดอาการแบบว่า MP หมดหลอด พลังหมด หมดแรง ล้า สมองเบลอ นั่งอ้าปากค้าง เหนื่อยแล้วไม่ไหวแล้ววววววว แต่ยังต้อง Push code ต้องเขียน Commit message ต้องรอ Build ผ่าน แล้วก็ต้องเปิด Merge request เราก็จะยังมี Pair เราที่มาคอยช่วยทำตรงส่วนนี้ให้ตอนที่เรา MP หมดหลอด
Pair-Reviews
ก่อนที่ Driver จะทำอะไรลงไปใน Code เนี่ยเค้าจะต้องพูดจะต้องบอก Navigator เสมอทำให้เกิดการ Reviews ทันที ทำให้โอกาศที่จะเกิด Defects จะลดลง หรือ Wrong design จะลดลง ทำให้ Cost ของการ Fix ลดลงเพราะเราเจอความผิดพลาดตั้งแต่เริ่มต้น
Debugging by Explaining
ถ้า Pair บ่อยๆจะเป็นการฝึกการ Debugging by Explaining หรือคือการค่อยๆอธิบายให้ Pair เราฟังว่าเราจะทำอะไรเป็น Step by step ไปเรื่อยๆ แก้ปัญหาการสื่อสารไม่เข้าใจ หรือเขียน Code ไม่เข้าใจ เพราะว่าถ้า Pair ของเราที่มีประสบการณ์ตรงนี้มากกว่ายังไม่เข้าใจ คนอื่นที่มาดูต่อก็คงไม่เข้าใจ
Pair-Learning
เกิดการเรียนรู้กันกับ Pair เป็น Learning process ระหว่างคนที่มีประสบการณ์น้อยกับคนที่มีประสบการณ์มากใน Software ส่วนนั้น Research พบว่าถ้าทำไป 4–6 เดือน Team จะมี Knowledge เท่าๆกันใน Software ตัวที่ทำ Pair คนไม่เก่งก็จะตามทัน คนที่เก่งก็จะได้รู้ว่าจะต้องลด Speed ยังไงให้ความเก่งของเค้าไม่ไปทำร้ายใคร วิ่งด้วยจังหวะไหนจะทำให้ Team เดินไปด้วยกันด้วยความเร็วเฉลี่ยสูงที่สุด
ซึ่งถ้าหากเราทำ Pair programming ไปได้สักระยะเวลานึงแล้วเนี่ย Software ชิ้นนี้จะมีลายมือเหมือนกันโดยที่เราแยกไม่ได้เลยว่าใครเป็นคนทำ
○ Quantitative Results
มาดูตัวเลขทางสถิติของ Research นี้กันบ้าง
Pair-Quality
แผนภูมิแท่งในด้านล่างบอกถึง % ของการทดสอบว่า Run test cases ผ่านเป็นกี่ % จากทั้ง 2 กลุ่ม พบว่า กลุ่มที่ทำ Pair สามารถ Run test cases ผ่านมากกว่าการทำงานคนเดียว 15% โดย Significant ที่ p < 0.05 ในทุกกรณี
ทางด้านของ Collaborative นั้นมีค่า Median สูงกว่า Individual (ดูจากเส้นสีดำที่ขีดอยู่ในกล่องแดง) และมีการกระจายตัวน้อยกว่า Individual ดังรูปด้านล่าง
Pair-Time
การทำงานเป็น Individual ทำงานเสร็จเร็วกว่าประมาณ 15–20% ซึ่งตรงนี้จะเป็น Trade-off ที่ Team จะต้องใช้เป็นตัวเลือกว่าการทำงานคนเดียวแต่เร็วกว่า กับการทำงานช้ากว่าแต่มีคุณภาพมากกว่า Team ต้องการที่จะเลือกแบบไหน
ทางด้านของ Collaborative นั้นมีค่า Median ใกล้เคียงกันกับ Individual (ดูจากเส้นสีดำที่ขีดอยู่ในกล่องแดง) ในหน่วยของนาที(minutes) +- ต่างกันที่ประมาณ 100 และมีการกระจายตัวมากกว่า Individual ดังรูปด้านล่าง
สิ่งที่เราควรจะต้องระวังคือ หากเราเลือกที่จะทำการในช่วงแรกเล็ก แล้วไป Solve defect ในช่วงท้ายแทน Cost จะสูงกว่ากว่า Solve defect ในช่วงต้นมาก
Pair-Satisfaction
Members มีความพึงพอใจที่จะทำงานกับ Team ที่ทำงานเป็น Pair มากกว่า เพราะเมื่อไหร่ที่เค้าต้องการความช่วยเหลือจะมีคนที่คอยมาช่วยเค้าเสมอ และ Code base ของ Team มีมาตราฐานเดียวกันทั้งทีม ไม่ต้องมาคอยปวดหัวว่า Code ส่วนนี้ของใคร ไม่อยากไปแตะ
Pair-Confidence
ความมั่นใจในการทำงาน Research บอกว่า Members ที่ทำงานเป็น Pair จะมีความมั่นใจ ในการตัดสินใจ ในการเสนอ Solution ในการเขียน Code สูงกว่า Team ที่ทำงานแบบ Individual
Design Quality
สิ่งสำคัญอีกอย่างนึงถ้าเราให้โจทย์เดียวกันกับคน 2 กลุ่มคือ กลุ่มคนที่ทำงานแบบ Individuals และ กลุ่มคนที่ทำงานแบบ Pair เนี่ย ใน Research พบว่า จำนวน Lines of Code ที่เกิดขึ้นของกลุ่มที่ทำงานเป็น Pair จะน้อยกว่า Individuals 20%
คำถามคือ จำนวน Lines of Code สามารถบอกอะไรกับเราได้ ?
ก็อาจจะตอบได้และตอบไม่ได้ แต่ก็มีโอกาศที่จะตอบได้ว่ายิ่ง Lines of Code มากเนี่ย ยิ่งมีโอกาศเกิด Duplicate Code หรือ Smell Code ต่างๆ
สุดท้ายแล้ว Pair Programming เป็นเพียงอีกทางเลือกในการพัฒนา Software เพื่อปรับความรู้ของคนใน Team ให้เท่าๆกัน อยู่ที่ว่า Team จะเลือกใช้แบบไหน มีความถี่ในการทำแค่ไหน หรือจะไม่ใช้เลยก็ไม่ได้ผิดอะไร
ที่ SCB TechX เองเปิดรับและพัฒนา Engineering Practice ให้เหมาะกับงานที่ทำอยู่เสมอ ถ้าใครสนใจอยากเรียนรู้ อยากร่วมงานกับ SCB TechX ไปตามกันได้ที่นี่เลยยย
Reference :
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97.2425&rep=rep1&type=pdf
