Topic 47: Working Together

ผมไม่เคยเจอมนุษย์คนไหนที่อยากอ่านเอกสาร 17,000 หน้าเลย แล้วถ้ามีคนแบบนั้นอยู่จริง ผมคงต้องฆ่าเขาทิ้งเพื่อไม่ให้ยีนแบบนั้นแพร่พันธุ์ต่อไป

Joseph Costello , President of Cadence

นี่คือหนึ่งในโปรเจกต์แบบ “เป็นไปไม่ได้” ประเภทที่คุณเคยได้ยินเล่าขานกัน ซึ่งฟังดูทั้งน่าตื่นเต้นและน่ากลัวไปพร้อมๆ กัน ระบบเก่าแก่ตัวหนึ่งกำลังจะหมดอายุการใช้งาน ฮาร์ดแวร์กำลังจะหายไปจริงๆ และต้องสร้างระบบใหม่เอี่ยมขึ้นมาให้ตรงกับพฤติกรรมเดิม (ที่มักไม่มีเอกสารบันทึกไว้) เป๊ะๆ เงินของคนอื่นหลายร้อยล้านดอลลาร์จะไหลผ่านระบบนี้ และเส้นตายตั้งแต่เริ่มโปรเจกต์จนถึงวันขึ้นระบบจริงก็อยู่ในระดับไม่กี่เดือนเท่านั้น

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

ตลอดทั้งเล่มนี้เราแนะนำให้ทำงานใกล้ชิดกับ user เพราะพวกเขาก็เป็นส่วนหนึ่งของทีมคุณด้วย ในโปรเจกต์แรกที่เราทำร่วมกันนั้น เราปฏิบัติในสิ่งที่ปัจจุบันอาจเรียกกันว่า pair programming หรือ mob programming นั่นคือมีคนหนึ่งพิมพ์โค้ด ในขณะที่อีกคนหรือหลายคนในทีมช่วยกันคอมเมนต์ ครุ่นคิด และแก้ปัญหาไปด้วยกัน มันเป็นวิธีทำงานร่วมกันที่ทรงพลัง เหนือกว่าการประชุมไม่รู้จบ บันทึกช่วยจำ และเอกสารทางกฎหมายหนาเตอะที่เน้นน้ำหนักมากกว่าประโยชน์ใช้สอย

และนั่นแหละคือสิ่งที่เราหมายถึงจริงๆ เมื่อพูดว่า “working with”: ไม่ใช่แค่การถามคำถาม พูดคุยกัน และจดบันทึก แต่คือการถามคำถามและพูดคุยกัน ในขณะที่คุณกำลังเขียนโค้ดอยู่จริงๆ

Conway's Law (กฎของคอนเวย์)

ในปี 1967 Melvin Conway ได้นำเสนอแนวคิดหนึ่งไว้ใน How do Committees Invent?  [Con68] ซึ่งต่อมากลายเป็นที่รู้จักในชื่อกฎของคอนเวย์ (Conway's Law):

องค์กรที่ออกแบบระบบต่างๆ จะถูกจำกัดให้ผลิตดีไซน์ที่เป็นสำเนาของโครงสร้างการสื่อสารภายในองค์กรนั้นเองเสมอ

กล่าวคือ โครงสร้างทางสังคมและช่องทางการสื่อสารของทีมและองค์กร จะสะท้อนออกมาในแอปพลิเคชัน เว็บไซต์ หรือผลิตภัณฑ์ที่กำลังพัฒนาอยู่เสมอ มีงานวิจัยหลายชิ้นที่สนับสนุนแนวคิดนี้อย่างหนักแน่น เราเองก็เคยเห็นกับตามานับไม่ถ้วนแล้ว เช่น ในทีมที่ไม่มีใครคุยกับใครเลย ผลลัพธ์ก็คือระบบที่แยกส่วนกันแบบ "stove-pipe" หรือทีมที่ถูกแบ่งออกเป็นสองส่วน ก็มักจบลงที่การแบ่งเป็น client/server หรือ frontend/backend

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

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

Pair Programming (การเขียนโค้ดเป็นคู่)

Pair programming เป็นหนึ่งใน practice ของ eXtreme Programming ที่ได้รับความนิยมแพร่หลายออกไปนอกวงการ XP เอง ใน pair programming นักพัฒนาคนหนึ่งจะเป็นคนคุมคีย์บอร์ด ส่วนอีกคนไม่ทำ ทั้งคู่ทำงานแก้ปัญหาไปด้วยกัน และสลับหน้าที่พิมพ์กันได้ตามต้องการ

pair programming มีประโยชน์มากมาย คนแต่ละคนมีพื้นฐานและประสบการณ์ต่างกัน มีเทคนิคและวิธีแก้ปัญหาต่างกัน และมีระดับความโฟกัสกับความใส่ใจต่อปัญหาหนึ่งๆ ต่างกันไปด้วย นักพัฒนาที่ทำหน้าที่พิมพ์ต้องโฟกัสกับรายละเอียดปลีกย่อยของ syntax และ coding style ในขณะที่นักพัฒนาอีกคนมีอิสระที่จะคิดถึงประเด็นและขอบเขตในระดับที่สูงกว่า แม้ฟังดูเหมือนเป็นความต่างเล็กๆ แต่อย่าลืมว่าสมองมนุษย์เรามีแบนด์วิดท์จำกัด การวุ่นวายอยู่กับการพิมพ์คำและสัญลักษณ์แปลกๆ ที่ compiler จะยอมรับแบบขัดใจ ก็กินพลังการประมวลผลของเราไปไม่น้อยแล้ว การมีสมองเต็มๆ ของนักพัฒนาอีกคนพร้อมใช้งานระหว่างทำงาน จึงเพิ่มพลังทางความคิดเข้ามาอีกมาก

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

Mob Programming (การเขียนโค้ดแบบกลุ่ม)

และถ้าสองหัวดีกว่าหัวเดียว แล้วถ้าให้คนหลากหลายสักสิบกว่าคนมาช่วยกันแก้ปัญหาเดียวกันพร้อมๆ กัน โดยมีคนพิมพ์แค่คนเดียวล่ะ จะเป็นยังไง?

Mob programming แม้จะชื่อแบบนี้ แต่ไม่ได้เกี่ยวอะไรกับคบเพลิงหรือคราดเลยนะครับ มันเป็นส่วนต่อขยายของ pair programming ที่มีนักพัฒนามากกว่าสองคน คนที่เคยลองใช้รายงานผลลัพธ์ที่ดีมากจากการใช้ mob แก้ปัญหายากๆ mob สามารถรวมคนที่ปกติไม่ถูกนับว่าเป็นส่วนหนึ่งของทีมพัฒนาเข้ามาได้ง่ายๆ ไม่ว่าจะเป็น user, project sponsor และ tester อันที่จริงในโปรเจกต์ “เป็นไปไม่ได้” โปรเจกต์แรกที่เราทำร่วมกัน มันเป็นภาพที่เห็นได้บ่อยๆ ที่คนหนึ่งในเราพิมพ์โค้ด ในขณะที่อีกคนคุยประเด็นนั้นกับผู้เชี่ยวชาญทางธุรกิจของเรา นั่นคือ mob เล็กๆ ที่มีแค่สามคนเท่านั้นเอง

คุณอาจมองว่า mob programming คือ การร่วมมือกันอย่างใกล้ชิดพร้อมกับการเขียนโค้ดสดๆ

What Should I Do? (ผมควรทำยังไงดี)

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

ถ้าคุณทำ pairing หรือ mobbing อยู่แล้ว มีใครรวมอยู่ในนั้นบ้าง? มีแค่นักพัฒนา หรือคุณเปิดให้สมาชิกในทีมที่ขยายออกไปเข้าร่วมด้วย เช่น user, tester, sponsor…?

และเช่นเดียวกับการร่วมมือกันทุกรูปแบบ คุณต้องบริหารจัดการมิติของมนุษย์ควบคู่ไปกับมิติทางเทคนิคด้วย นี่คือ tip เล็กๆ น้อยๆ ที่จะช่วยให้คุณเริ่มต้นได้:

• สร้างโค้ด ไม่ใช่สร้างอีโก้ของตัวเอง มันไม่ใช่เรื่องว่าใครฉลาดที่สุด เราทุกคนต่างก็มีช่วงเวลาที่ดีและแย่กันทั้งนั้น
• เริ่มจากเล็กๆ ก่อน mob กับคนแค่ 4-5 คน หรือเริ่มจากแค่ไม่กี่คู่ ในเซสชันสั้นๆ
• วิจารณ์ที่โค้ด ไม่ใช่ที่ตัวคน “มาดูบล็อกนี้กันหน่อย” ฟังดูดีกว่า “คุณทำผิด” เยอะเลย
• รับฟังและพยายามเข้าใจมุมมองของคนอื่น ความแตกต่างไม่ได้แปลว่าผิด
• จัด retrospective บ่อยๆ เพื่อพยายามปรับปรุงให้ดีขึ้นในครั้งถัดไป

ไม่ว่าจะเขียนโค้ดในออฟฟิศเดียวกันหรือแบบ remote คนเดียว เป็นคู่ หรือเป็น mob ล้วนเป็นวิธีที่มีประสิทธิภาพในการทำงานร่วมกันเพื่อแก้ปัญหาทั้งนั้น ถ้าคุณกับทีมเคยทำแบบเดียวมาตลอด ลองทดลองสไตล์ใหม่ๆ ดูก็ได้ แต่อย่าเพิ่งกระโดดเข้าไปแบบไม่มีความรู้ เพราะแต่ละสไตล์การพัฒนาก็มีกฎ ข้อแนะนำ และแนวทางของมันเอง เช่น ใน mob programming คุณควรสลับคนพิมพ์ทุกๆ 5-10 นาที

ลองอ่านและค้นคว้าเพิ่มเติม ทั้งจากตำราและจากรายงานประสบการณ์จริง เพื่อให้เข้าใจข้อดีและข้อผิดพลาดที่อาจเจอ คุณอาจเริ่มจากการเขียนโค้ดแบบฝึกหัดง่ายๆ ก่อน แทนที่จะกระโดดเข้าไปที่โค้ด production ที่ยากที่สุดของคุณเลย

แต่ไม่ว่าคุณจะทำแบบไหน ขอให้เราแนะนำคำแนะนำสุดท้ายอีกข้อหนึ่ง: