Topic 49: Pragmatic Teams

Topic 49	ทีมแบบ Pragmatic

ที่ Group L, Stoffel ดูแลโปรแกรมเมอร์ฝีมือดีอยู่หกคน ซึ่งเป็นความท้าทายด้านการบริหารที่พอๆ กับการต้อนฝูงแมวเลยทีเดียว

The Washington Post Magazine , June 9, 1985

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

ในหนังสือเล่มนี้จนถึงตอนนี้ เราได้ดูเทคนิคแบบ Pragmatic ที่ช่วยให้แต่ละคนเป็นโปรแกรมเมอร์ที่ดีขึ้น แต่วิธีการเหล่านี้จะใช้ได้กับทีมด้วยหรือเปล่า แม้แต่ทีมที่ประกอบด้วยคนดื้อรั้นและเป็นอิสระ คำตอบคือ “ได้แน่นอน!” การเป็นคนที่ทำงานแบบ Pragmatic นั้นมีข้อดีอยู่แล้ว แต่ข้อดีเหล่านั้นจะทวีคูณขึ้นหลายเท่าถ้าคนคนนั้นทำงานอยู่ในทีมที่เป็น Pragmatic ด้วยครับ

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

ทีมแบบ Pragmatic คือทีมเล็กๆ มีสมาชิกไม่เกิน 10-12 คนโดยประมาณ สมาชิกเข้าออกไม่บ่อย ทุกคนรู้จักกันดี ไว้ใจกัน และพึ่งพากันครับ

Tip 84	รักษาทีมให้เล็กและมีเสถียรภาพ

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

มาลองนำหัวข้อก่อนหน้านี้บางส่วนมาปรับใช้ในบริบทของทีมกันครับ

No Broken Windows (อย่าปล่อยให้มีหน้าต่างแตก)

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

ทีมโดยรวมไม่ควรปล่อยให้มีหน้าต่างแตก นั่นคือข้อบกพร่องเล็กๆ น้อยๆ ที่ไม่มีใครแก้ไข ทีม ต้อง รับผิดชอบต่อคุณภาพของผลิตภัณฑ์ สนับสนุนนักพัฒนาที่เข้าใจปรัชญา ไม่มีหน้าต่างแตก ที่เราอธิบายไว้ใน Topic 3, ​ Software Entropy ​ และให้กำลังใจคนที่ยังไม่เข้าใจแนวคิดนี้ครับ

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

Boiled Frogs (กบต้มน้ำอุ่น)

จำเรื่องกบในหม้อน้ำ (ซึ่งอาจไม่มีมูลความจริง) ที่พูดถึงใน Topic 4, ​ Stone Soup and Boiled Frogs ​ ได้ไหมครับ มันไม่ทันสังเกตการเปลี่ยนแปลงทีละน้อยของสภาพแวดล้อม สุดท้ายก็ถูกต้มจนสุก เรื่องแบบเดียวกันนี้ก็เกิดขึ้นกับคนที่ไม่ระแวดระวังได้เช่นกัน มันอาจยากที่จะคอยจับตาดูสภาพแวดล้อมโดยรวมของคุณท่ามกลางความเร่งรีบของการพัฒนาโปรเจกต์

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

ต่อสู้กับสิ่งนี้ครับ กระตุ้นให้ทุกคนคอยจับตาดูการเปลี่ยนแปลงของสภาพแวดล้อมอย่างจริงจัง ตื่นตัวและรับรู้ถึงขอบเขตงานที่เพิ่มขึ้น เวลาที่ลดลง ฟีเจอร์เพิ่มเติม สภาพแวดล้อมใหม่ๆ หรืออะไรก็ตามที่ไม่ได้อยู่ในความเข้าใจเดิม เก็บ metric เรื่อง requirement ใหม่ๆ ไว้ด้วย [76] ทีมไม่จำเป็นต้องปฏิเสธการเปลี่ยนแปลงทันทีหรอกครับ แค่ต้องรู้ตัวว่ามันกำลังเกิดขึ้น ไม่อย่างนั้นแล้ว คนที่ต้องเดือดร้อนก็คือ คุณ เองนั่นแหละครับ

Schedule Your Knowledge Portfolio (จัดตารางให้ Knowledge Portfolio ของคุณ)

ใน Topic 6, ​ Your Knowledge Portfolio ​ เราได้ดูวิธีที่คุณควรลงทุนใน Knowledge Portfolio ส่วนตัวในเวลาว่างของคุณเองไปแล้ว ทีมที่อยากประสบความสำเร็จก็ต้องพิจารณาการลงทุนด้านความรู้และทักษะของทีมด้วยเช่นกันครับ

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

การดูแลระบบเก่า

ถึงแม้เราจะชอบทำงานกับระบบใหม่เอี่ยมที่แวววาว แต่ก็มักจะมีงานดูแลรักษาระบบเก่าที่ต้องทำอยู่เสมอ เราเคยเจอทีมที่พยายามผลักงานนี้ไปไว้มุมห้องเฉยๆ ถ้าทีมได้รับมอบหมายให้ทำงานเหล่านี้ ก็ต้องทำมันจริงๆ ครับ

การทบทวนและปรับปรุงกระบวนการทำงาน

การปรับปรุงอย่างต่อเนื่องจะเกิดขึ้นได้ก็ต่อเมื่อคุณใช้เวลามองดูรอบตัว หาว่าอะไรทำงานได้ดีและอะไรไม่ดี แล้วค่อยเปลี่ยนแปลง (ดู Topic 48, ​ The Essence of Agility ​ ) หลายทีมยุ่งอยู่กับการวิดน้ำออกจนไม่มีเวลาไปอุดรอยรั่วเสียที จัดตารางให้มัน แล้วแก้ไขมันซะครับ

การทดลองเทคโนโลยีใหม่

อย่านำเทคโนโลยี เฟรมเวิร์ก หรือไลบรารีใหม่มาใช้แค่เพราะ “ทุกคนก็ใช้กัน” หรือเพราะเห็นในงานสัมมนาหรืออ่านเจอในอินเทอร์เน็ต ให้ตรวจสอบเทคโนโลยีที่เป็นตัวเลือกอย่างจงใจด้วยการทำ prototype ใส่งานลงในตารางเพื่อลองสิ่งใหม่ๆ แล้ววิเคราะห์ผลลัพธ์ครับ

การเรียนรู้และพัฒนาทักษะ

การเรียนรู้และพัฒนาตัวเองเป็นจุดเริ่มต้นที่ดี แต่หลายทักษะจะมีประสิทธิภาพมากขึ้นเมื่อกระจายไปทั่วทั้งทีม วางแผนที่จะทำมัน ไม่ว่าจะเป็นมื้อเที่ยงแบบ brown-bag ที่ไม่เป็นทางการ หรือเซสชันฝึกอบรมที่เป็นทางการมากขึ้นก็ตามครับ

Tip 85	จัดตารางให้มันเพื่อทำให้มันเกิดขึ้นจริง

Communicate Team Presence (สื่อสารการมีอยู่ของทีม)

เป็นเรื่องชัดเจนว่านักพัฒนาในทีมต้องพูดคุยกัน เราให้คำแนะนำบางอย่างเพื่อช่วยเรื่องนี้ไว้ใน Topic 7, ​ Communicate! ​ แล้ว แต่มันง่ายที่จะลืมไปว่าตัวทีมเองก็มีการมีอยู่ (presence) ภายในองค์กรด้วยเช่นกัน ทีมในฐานะหน่วยหนึ่งจำเป็นต้องสื่อสารกับโลกภายนอกอย่างชัดเจนครับ

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

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

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

Don't Repeat Yourselves (อย่าทำซ้ำในสิ่งเดียวกัน)

ใน Topic 9, ​ DRY—The Evils of Duplication ​ เราพูดถึงความยากลำบากในการกำจัดงานที่ซ้ำซ้อนกันระหว่างสมาชิกในทีม ความซ้ำซ้อนนี้นำไปสู่ความพยายามที่สูญเปล่า และอาจกลายเป็นฝันร้ายในการดูแลรักษาได้ ระบบแบบ “stovepipe” หรือ “siloed” พบได้บ่อยในทีมแบบนี้ มีการแบ่งปันกันน้อยและมีฟังก์ชันการทำงานที่ซ้ำซ้อนกันเยอะครับ

การสื่อสารที่ดีคือกุญแจสำคัญในการหลีกเลี่ยงปัญหาเหล่านี้ และคำว่า “ดี” ที่เราหมายถึงคือ ทันที และ ไร้แรงเสียดทาน

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

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

รักษาความตื่นตัวเอาไว้เพื่อให้ DRY อยู่เสมอครับ

Team Tracer Bullets (Tracer Bullet ของทีม)

ทีมโปรเจกต์ต้องทำงานหลายอย่างที่แตกต่างกันในหลายพื้นที่ของโปรเจกต์ แตะต้องเทคโนโลยีที่หลากหลาย การทำความเข้าใจ requirement การออกแบบสถาปัตยกรรม การเขียนโค้ดฝั่ง frontend และ server การทดสอบ ทั้งหมดนี้ต้องเกิดขึ้น แต่มีความเข้าใจผิดที่พบบ่อยว่ากิจกรรมและงานเหล่านี้สามารถเกิดขึ้นแยกกันเป็นเอกเทศได้ ซึ่งมันทำไม่ได้ครับ

บางระเบียบวิธีสนับสนุนให้มีบทบาทและตำแหน่งต่างๆ มากมายภายในทีม หรือสร้างทีมเฉพาะทางแยกออกไปต่างหากเลย แต่ปัญหาของแนวทางนั้นคือมันสร้าง ประตูกั้น และ การส่งต่องาน ขึ้นมา แทนที่จะเป็นการไหลลื่นจากทีมไปสู่การดีพลอย ตอนนี้คุณกลับมีประตูกั้นที่ทำให้งานหยุดชะงักแทน มีการส่งต่องานที่ต้องรอการยอมรับ มีการอนุมัติ มีเอกสารต่างๆ กลุ่มคน Lean เรียกสิ่งนี้ว่า ความสูญเปล่า (waste) และพยายามกำจัดมันออกไปอย่างจริงจังครับ

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

ใน Topic 12, ​ Tracer Bullets ​ เราแนะนำให้พัฒนาฟีเจอร์แต่ละตัวแยกกัน ไม่ว่าจะเล็กและจำกัดแค่ไหนในตอนแรก แต่ต้องวิ่งจากต้นจนจบผ่านทั้งระบบ นั่นหมายความว่าคุณต้องมีทักษะทั้งหมดที่จำเป็นอยู่ในทีม ทั้ง frontend, UI/UX, server, DBA, QA และอื่นๆ ที่คุ้นเคยและทำงานร่วมกันได้อย่างสบายใจ ด้วยแนวทาง tracer bullet คุณสามารถ implement ฟังก์ชันการทำงานชิ้นเล็กๆ ได้อย่างรวดเร็วมาก และได้ feedback ทันทีว่าทีมของคุณสื่อสารและส่งมอบงานได้ดีแค่ไหน สิ่งนี้สร้างสภาพแวดล้อมที่คุณสามารถเปลี่ยนแปลงและปรับจูนทีมและกระบวนการทำงานได้อย่างรวดเร็วและง่ายดายครับ

Tip 86	จัดทีมให้ทำงานได้ครบวงจรในตัวเอง

สร้างทีมให้คุณสามารถสร้างโค้ดได้ตั้งแต่ต้นจนจบ แบบค่อยเป็นค่อยไปและวนซ้ำเป็นรอบๆ ครับ

Automation (การทำงานอัตโนมัติ)

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

การทำงานอัตโนมัติเป็นองค์ประกอบสำคัญของทุกทีมโปรเจกต์ ต้องแน่ใจว่าทีมมีทักษะด้าน การสร้างเครื่องมือ (tool building) เพื่อสร้างและดีพลอยเครื่องมือที่ทำให้การพัฒนาโปรเจกต์และการดีพลอยขึ้น production เป็นอัตโนมัติครับ

Know When to Stop Adding Paint (รู้ว่าเมื่อไหร่ควรหยุดแต้มสี)

จำไว้ว่าทีมประกอบขึ้นจากปัจเจกบุคคล ให้สมาชิกแต่ละคนมีโอกาสได้เปล่งประกายในแบบของตัวเอง ให้โครงสร้างแค่พอดีที่จะสนับสนุนพวกเขาและทำให้แน่ใจว่าโปรเจกต์ส่งมอบคุณค่าได้ แล้วก็เหมือนกับช่างทาสีใน Topic 5, ​ Good-Enough Software ​ ต้านทานสิ่งล่อใจที่จะแต้มสีเพิ่มเข้าไปอีกครับ

Related Sections Include (หัวข้อที่เกี่ยวข้อง)

• Topic 2, ​ The Cat Ate My Source Code ​
• Topic 7, ​ Communicate! ​
• Topic 12, ​ Tracer Bullets ​
• Topic 19, ​ Version Control ​
• Topic 50, ​ Coconuts Don't Cut It ​
• Topic 51, ​ Pragmatic Starter Kit ​

Challenges (แบบฝึกหัดท้าทายความคิด)

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

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

• คุณอาจเคยเจอโจทย์แบบ “ถ้าคนงาน 4 คนขุดคูน้ำเสร็จใน 6 ชั่วโมง คนงาน 8 คนจะใช้เวลาเท่าไหร่” แต่ในชีวิตจริง ถ้าคนงานเหล่านั้นเขียนโค้ดแทน มีปัจจัยอะไรบ้างที่ส่งผลต่อคำตอบ มีกี่สถานการณ์ที่เวลาจะลดลงได้จริงๆ

• อ่าน The Mythical Man Month  [Bro96] โดย Frederick Brooks เพื่อคะแนนพิเศษ ให้ซื้อสองเล่มจะได้อ่านเร็วขึ้นเป็นสองเท่าครับ