#priwreadbooks Agile Coaching — Chapter 12 — Demonstrating Results (สรุป)

Photo by Matthew Osborn 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
• Chapter 8 — Keeping It Visible
• Chapter 9 — Getting to “Done”
• Chapter 10 — Driving Development with Tests
• Chapter 11 — Clean Code

น่าแปลกที่ทีม Agile จำนวนมากมองว่าการ Demo เป็นทางเลือก สาเหตุบางประการที่เราพบ เช่น

• ไม่มีอะไรจะแสดง เพราะไม่ได้วางแผนรอบการทำงานที่ได้ซอฟต์แวร์ที่สามารถสาธิตได้
• Go Live ไปแล้ว
• ลูกค้าอยู่ในทีมในระหว่างรอบการทำงาน

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

เตรียมการสาธิต (Demo)

อย่าลืมเริ่มจาก วางแผนที่จะสร้างเรื่องราวที่สามารถ Demo ได้ ให้ทีมคิดหาวิธีแสดงเรื่องราวของผู้ใช้ ต่อผู้มีส่วนได้ส่วนเสีย

ใครเข้าร่วมบ้าง

ทุกคนในทีมจะต้องเข้าร่วม ปกป้องสิทธิ์ของทีมในการแสดงผลงานของตนเอง การ Demo เป็นโอกาสที่จะแสดงสิ่งที่พวกเขาสร้างขึ้น

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

ลำดับการ Demo

ในวันสุดท้ายของรอบการทำงาน ทีมจำเป็นต้องซ้อมเพื่อเตรียมพร้อมสำหรับการ Demo

สิ่งที่พวกเขาสามารถทำได้เพื่อเตรียมการ:

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

บางทีมยังวางตารางเวลาที่มองเห็นได้ในพื้นที่ทำงานของพวกเขา เพื่อเตือนถึงสิ่งที่ต้องทำเพื่อเตรียมตัว

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

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

ความหายนะของการ Demo

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

ก่อนเริ่มการประชุม ให้ทำดังนี้

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

ทุกคนมีส่วนร่วม

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

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

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

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

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

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

ก่อนปิดการประชุม ใช้โอกาสสุดท้ายเพื่อบันทึก Velocity ของทีม หากพบข้อบกพร่องร้ายแรงในระหว่างการสาธิต ทีมงานอาจตัดสินใจไม่นับ points สำหรับเรื่องราวนั้น หากทีมทำผลงานได้น้อยเกินไป พวกเขาอาจต้องหารือเกี่ยวกับการเปลี่ยนแปลงแผนการเปิดตัว (release plan) ก่อนที่จะแยกย้ายกันไป

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

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

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

สุดท้าย หากสิ่งต่างๆ ไม่เป็นไปด้วยดีในการสาธิต ให้หารือเกี่ยวกับสิ่งที่ผิดพลาดใน retrospective

การเปิดตัวซอฟต์แวร์

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

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

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

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

ซอฟต์แวร์ไม่ทำงานในการสาธิต (Demo)

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

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

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

การรับฟังผู้มีส่วนได้ส่วนเสียที่ผิดหวัง อาจกระตุ้นให้ทีมทำงานได้ดีขึ้นในครั้งต่อไป

พวกเขายังคงสามารถรับข้อเสนอแนะที่เป็นประโยชน์เกี่ยวกับซอฟต์แวร์ได้ แม้ว่าจะยังสร้างไม่เสร็จก็ตาม

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

การไม่มีอะไรเสร็จทำให้ทีมมีปัญหา: ความเร็วเป็นศูนย์ หากทีมสาธิตซอฟต์แวร์ที่ไม่ตรงตามคำจำกัดความของคำว่า “เสร็จสิ้น” พวกเขาอาจจะรู้สึกว่าเสร็จสิ้นแล้ว และทีมก็พร้อมที่จะดำเนินการกับเรื่องราวใหม่ๆ ตรวจสอบให้แน่ใจว่าลูกค้าเข้าใจว่ายังมีงานต้องทำก่อนที่ทีมจะดำเนินการเพิ่มเติม

เมื่อทีมทำงานไม่ทัน แนะนำให้พวกเขาแก้ไขแผนการเผยแพร่เพื่อให้เห็นผลกระทบ หากทีมเลื่อนการทดสอบออกไปจนกว่าจะถึงรอบถัดไป อาจมีอันตรายที่ทีมจะพลาดตกลงไปใน mini-waterfall และผู้ทดสอบจะทำงานตามไม่ทัน

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

Demo อาศัยซอฟต์แวร์จากทีมอื่น

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

ซอฟต์แวร์ของเราไม่มี User Interface (หน้าจอ)

เป็นการยากที่จะทำให้ลูกค้าสนใจการสาธิตซอฟต์แวร์หากพวกเขาไม่สามารถติดตามการสาธิตได้เนื่องจากไม่มีหน้าจอ ให้ทีมสร้างภาพการประมวลผลข้อมูลเพื่อให้สามารถสาธิตได้ ท้ายที่สุด นี่เป็นข้อบ่งชี้ว่า ทีมอาจต้องกำหนดขอบเขตงานให้แตกต่างออกไป พวกเขาอาจพิจารณาย้ายไปพัฒนาฟีเจอร์จากส่วนหน้าไปยังส่วนหลัง (front end to the back end) มากกว่าการพัฒนาตามส่วนประกอบ (component-based)