#priwreadbooks Agile Coaching — Chapter 9— Getting to “Done” (สรุป)

Photo by Jason Goodman 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

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

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

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

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

ใครเป็นผู้ทดสอบ? การทดสอบไม่ใช่งานของคนคนเดียว เป็นความรับผิดชอบของทั้งทีม

• นักพัฒนา จำเป็นต้องตรวจสอบให้แน่ใจว่า โค้ดของพวกเขาผ่านการทดสอบก่อนที่จะปล่อยไปยังการทดสอบต่อไป สิ่งนี้จะช่วยหลีกเลี่ยงการเสียเวลาของลูกค้าและผู้ทดสอบที่รับโค้ดไปเพื่อทำการทดสอบ ให้นักพัฒนาใช้จุดแข็งในการเขียนโปรแกรมเพื่อทำให้การทดสอบเป็นแบบอัตโนมัติมากที่สุดเท่าที่จะทำได้ แม้ว่าพวกเขาจะไม่พบปัญหากับซอฟต์แวร์ที่เพิ่งเขียนขึ้นก็ตาม
• ลูกค้า รู้มากที่สุดเกี่ยวกับสภาพแวดล้อมที่ซอฟต์แวร์จะถูกใช้ โดยทั่วไปแล้วพวกเขาจะมุ่งเน้นไปที่ ผู้ใช้สามารถบรรลุเป้าหมายได้หรือไม่ ลูกค้าอาจพลาด edge cases ซึ่งระบบจำเป็นต้องจัดการกับข้อผิดพลาดหรือข้อมูลประหลาดได้ ให้ทีมจัดทำเวอร์ชันการทำงานล่าสุดของผลิตภัณฑ์ เพื่อให้ลูกค้าทดลองใช้งานได้อย่างง่ายดายทุกเมื่อ
• ผู้ทำการทดสอบ เก่งในการทดสอบแบบทำลายล้าง โดยคำนึงถึงกรณีต่างๆ ที่ระบบอาจถูกละเมิด ช่วยทีมสรุป ตรวจสอบว่าการทดสอบผ่าน ผู้ทดสอบมักต้องการการสนับสนุนจากนักพัฒนาเพื่อทำการทดสอบแบบอัตโนมัติ หาโอกาสให้พวกเขาจะจับคู่กันเพื่อทำเรื่องนี้
• ทีมงานภายนอก อาจทำการทดสอบเฉพาะทางก่อนที่จะเผยแพร่ซอฟต์แวร์ เช่น การทดสอบความปลอดภัย (security) การทดสอบการใช้งาน (usability) หรือการทดสอบแพลตฟอร์ม แนะนำให้ทีมรวมเวลาในการตอบสนองต่อปัญหาที่พบโดยการทดสอบพิเศษนี้ในแผนงานด้วย

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

กำหนดว่า “เสร็จสิ้น” หมายถึงอะไร ทำให้เห็นคำจำกัดความของ “เสร็จสิ้น”

นำทั้งทีมมารวมกันเพื่อตกลงคำนิยามของคำว่า “เสร็จสิ้น” ควรเป็นอย่างไร เริ่มต้นการสนทนาด้วยคำจำกัดความพื้นฐานนี้

“เสร็จ” หมายความว่า ลูกค้าพอใจกับสิ่งที่ได้รับการพัฒนาและผ่านการทดสอบเรื่องราวทั้งหมด

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

ตัวอย่างรายการที่ต้องได้รับการตรวจสอบ

1. โค้ดได้รับการตรวจสอบ (Review) โดยนักพัฒนาคนอื่นในทีม
2. โค้ดมี Unit Test
3. มีการสร้างการทดสอบอัตโนมัติสำหรับการทดสอบเรื่องราว
4. ผ่านการทดสอบเชิงสำรวจ (Exploratory testing) ดำเนินการโดยผู้ทำการทดสอบในทีม
5. เอกสารผู้ใช้ได้รับการอัปเดตเพื่ออธิบายฟังก์ชันใหม่
6. ดำเนินการทดสอบประสิทธิภาพ (Performance testing)

เขียนคำจำกัดความที่กำหนดเองของคำว่า “เสร็จสิ้น” บนไวท์บอร์ดที่ทุกคนสามารถเห็นได้ ทบทวนสิ่งนี้กับทีมอยู่เสมอก่อนทำการส่งมอบงาน

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

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

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

การสละเวลาฟังทุกคนในทีมและแสดงความสนใจในงานของพวกเขา แสดงว่าคุณให้ความสำคัญกับพวกเขาและการมีส่วนร่วมของพวกเขาในโครงการ

เมื่อคุณแสดงความเคารพ คุณก็มีแนวโน้มที่จะได้รับความเคารพเป็นการตอบแทน

เชิญผู้ทำการทดสอบแบ่งปันข้อกังวล

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

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

การจัดการข้อบกพร่อง (บั๊ก)

เพื่อให้ทีมดำเนินการเรื่องราวทั้งหมดให้ “เสร็จสิ้น” เมื่อสิ้นสุดการทำซ้ำ พวกเขาต้องมีความชัดเจนเกี่ยวกับวิธีจัดการกับข้อบกพร่องที่เกิดขึ้น

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

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

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

อย่ามี Backlog แยกระหว่าง Story และ Bug

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

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

จำไว้ว่ามีวิธีการแก้ปัญหามากกว่าหนึ่งวิธีเสมอ

ค้นหาสาเหตุที่แท้จริง

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

ให้นักพัฒนาขอความคิดเห็น รับข้อเสนอแนะตั้งแต่เนิ่นๆ

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

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

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

หากลูกค้าไม่ได้นั่งกับทีม ขอให้พวกเขาหาเวลาหนึ่งชั่วโมงทุกวันเพื่อช่วยเหลือทีม

การฟื้นคืน(ชีพ)จากการทำไม่เสร็จ

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

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

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

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

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

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

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

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

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

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

มันไม่ใช่ปัญหาของฉัน

บางครั้งเราพบบุคคลที่มีมุมมองที่ชัดเจนเกี่ยวกับงานที่เหมาะสมสำหรับพวกเขา

• คุณอาจมีนักพัฒนาซอฟต์แวร์หรือลูกค้าในทีมที่ยืนยันว่า “การทดสอบมีไว้สำหรับผู้ทำการทดสอบ”
• หรือคุณอาจมีผู้ทำการทดสอบที่บอกว่าการทดสอบอัตโนมัติต้องเขียนโดยนักพัฒนา

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

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

การทำงานกับผู้ทำการทดสอบที่อยู่ที่อื่น

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

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

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

องค์กรกำหนดให้ใช้ Bug Tracker

Mary Poppendieck กล่าวไว้ใน Implementing Lean Software Development ว่า งานของผู้ทำการทดสอบคือ “ป้องกันข้อบกพร่อง” แทนที่จะรวบรวมการเกิดข้อบกพร่อง

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