#priwreadbooks Agile Coaching — Chapter 8 — Keeping It Visible (สรุป)

Photo by Sebastien Bonneval on Unsplash

Previous chapter:

• Chapter 1 — Starting the Journey
• Chapter 2 — Working with People
• Chapter 3 — Leading Change
• Chapter 4 — Building an Agile Team
• Chapter 5 — Daily Standup
• Chapter 6 — Understanding What to Build
• Chapter 7 — Planning Ahead

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

ทีมงานมีหลายสิ่งที่ต้องคำนึงถึง ได้แก่ แผนของรอบการทำงาน สิ่งที่ต้องทำจาก retrospective และสถานะของซอฟต์แวร์ ฝึกพวกเขาให้มองเห็นสิ่งที่พวกเขาต้องให้ความสนใจ

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

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

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

• Stories — เรื่องราวทั้งหมดถูกวางไว้ที่นี่ โดยเรียงลำดับความสำคัญจากบนลงล่าง
• Tasks — งานถูกวางไว้ในคอลัมน์ถัดจากเรื่องราวที่เกี่ยวข้อง (swim lanes)
• In progress — กำลังดำเนินการ เมื่องานเริ่มขึ้น งานจะถูกย้ายไปยังคอลัมน์นี้
• Awaiting QA — เมื่องานทั้งหมดเสร็จสิ้น การ์ดเรื่องราวจะถูกวางลงในคอลัมน์นี้ การเห็นการ์ดที่นี่ จะแจ้งให้ลูกค้าหรือผู้ทดสอบตรวจสอบงานและยืนยันว่าถูกต้องตรงกัน หากมีปัญหาต้องแก้ไข ให้ย้ายการ์ดเรื่องราวกลับไปที่คอลัมน์เรื่องราวและสร้างการ์ดงานใหม่สำหรับการแก้ไข
• Done — เสร็จแล้ว เป้าหมายคือ รับเรื่องราวทั้งหมดที่นี่ คอลัมน์นี้ควรเติมเต็มการทำซ้ำอย่างต่อเนื่อง

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

ทำให้บอร์ดของทีมอ่านง่าย

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

• Not Started ยังไม่ได้เริ่ม การ์ดทั้งหมดเริ่มต้นด้วยสติกเกอร์สีแดง
• In Progress กำลังดำเนินการ เมื่อเริ่มงานบนการ์ด ให้แปะด้วยสติกเกอร์สีเหลือง
• In Review อยู่ระหว่างการตรวจสอบ เมื่อมีการตรวจสอบงาน ให้แปะด้วยสติกเกอร์สีน้ำเงิน
• Done เมื่อทำงานเสร็จแล้ว ให้แปะด้วยสติกเกอร์สีเขียว
• หากพบข้อบกพร่องใดๆ แสดงว่าการ์ดกำลังดำเนินการอีกครั้ง แปะด้วยสติกเกอร์สีเหลือง
• ใช้สติกเกอร์ขนาดใหญ่ที่สว่างเพื่อให้มองเห็นสถานะได้ง่ายจากระยะไกล สร้างคำอธิบายว่าสติกเกอร์สีต่างๆ มีความหมายอย่างไร ตอนนี้ทุกคนสามารถตีความกระดานได้อย่างง่ายดาย

ใครทำงานอะไร

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

การเลือกใช้วัสดุ

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

บอร์ดอิเล็กทรอนิกส์

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

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

บอร์ดทั้งกระดานเป็นของคนทั้งทีม ในขณะที่ซอฟต์แวร์การวางแผนมักจะมีคนๆ เดียวเป็นเจ้าของ ปรับแต่ง ดูแล

ติดตามเรื่องราวที่เสร็จสมบูรณ์ ไม่ใช่งานที่ทำ

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

หากคุณมีทั้งบอร์ดอิเล็กทรอนิกส์และบอร์ดจริง มุมมองทั้งสองจะต้องซิงค์กัน ไม่จำเป็นต้องทำซ้ำในบอร์ดจริงและในซอฟต์แวร์ ข้อมูลงานระดับ Task มักจะไม่เกี่ยวข้องหลังจากสิ้นสุดรอบการทำงาน

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

ทำงานร่วมกับทีม

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

Burndown และ Burnup

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

เราพบว่าทีมส่วนใหญ่ชอบ Burndown การประมาณการในการ์ดงานโดยการขีดฆ่าของเก่าและใส่การประมาณการของใหม่ลงไป ใน Daily Standup

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

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

(จากภาพด้านบน) ทีมงานจะวางแผนจุดเรื่องราวทั้งหมด เทียบกับ จุดเรื่องราวทั้งหมดที่เหลือที่ต้องทำ

• เส้นบน แสดงการเพิ่มหรือนำเรื่องราวออกจากการ release
• เส้นล่าง แสดงให้เห็นว่าพวกเขาใกล้จะ “เสร็จสิ้น” มากน้อยเพียงใด

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

การดูแลบอร์ดของทีม

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

อุปสรรคที่อาจเจอ

ไม่มีที่สำหรับบอร์ด

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

ทีมไม่อัปเดตบอร์ดของพวกเขา

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

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

กังวลว่าการ์ดจะสูญหาย

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

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