#priwreadbooks Agile Coaching — Chapter 6— Understanding What to Build (สรุป)

Photo by Sebastian Bill 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

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

เรื่องราวของผู้ใช้เป็นรากฐานของงานทั้งหมดที่ทีม Agile ทำ ซึ่งเป็นพื้นฐานของแผน การพัฒนา และการทดสอบ

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

วงจรชีวิตของเรื่องราวผู้ใช้ โดยเปรียบเทียบกับวงจรชีวิตของผีเสื้อ

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

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

Ron Jeffries สรุปแง่มุมที่สำคัญสามประการของเรื่องราวของผู้ใช้เป็น 3Cs

1. Card: การเขียนเรื่องลงในบัตร (หรือ Post-it) เพื่ออำนวยความสะดวกในการสนทนากลุ่ม
2. Conversation: ถามคำถามและแนะนำวิธีแยกเรื่องราว
3. Confirmation: ตกลงว่าจะใช้การทดสอบอะไร เพื่อประเมินว่าเรื่องราวเสร็จสมบูรณ์หรือไม่

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

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

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

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

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

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

ใช้รูปแบบเลย์เอ้าท์ที่เหมือนกันสำหรับการ์ดที่บอกเล่าเรื่องราว (Story Card)

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

Story Templates

“As a…user, I want…capability so that…benefit.”

ยกตัวอย่างเช่น

“As a book buyer, I want to see customer book reviews for a book so that I can decide whether to buy it.” เทมเพลตนี้ช่วยให้ทีมจำได้ว่า ผู้ใช้คือใคร และประโยชน์ของการพัฒนาเรื่องราวคืออะไร

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

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

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

การยืนยันรายละเอียด

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

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

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

• What data does the user enter? ผู้ใช้ป้อนข้อมูลอะไร
• What does the user expect to see? ผู้ใช้คาดหวังที่จะเห็นอะไร
• Are there business rules that we need to be aware of? มีกฎทางธุรกิจที่เราจำเป็นต้องทราบหรือไม่?

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

ต่อไปนี้คือการทดสอบเรื่องราวบางส่วนสำหรับเรื่องราวของผู้ใช้: ในฐานะนักช้อป ฉันต้องการค้นหาหนังสือตามชื่อเรื่องเพื่อที่ฉันจะได้ซื้อมัน สิ่งนี้ใช้เทมเพลตการทดสอบเรื่องราวอย่างง่ายเรียกว่า Given-When-Then

• กำหนดให้ผู้ใช้ดูหน้าค้นหาและป้อน “Agile Coaching” (ซึ่งมีเพียงข้อเดียว) เมื่อผู้ใช้คลิกปุ่มค้นหา จากนั้นรายละเอียดหนังสือทั้งหมด (ชื่อเรื่อง ผู้แต่ง รูปภาพปกหนังสือ เรื่องย่อ ราคา บทวิจารณ์ ) และปุ่มเพิ่มไปยังรถเข็นจะปรากฏขึ้น
• กำหนดให้ผู้ใช้ดูหน้าค้นหาและป้อน “Test-Driven Development” (ซึ่งมีหลายรายการที่ตรงกัน) เมื่อผู้ใช้คลิกปุ่มค้นหา รายการสรุปหนังสือ (ชื่อเรื่อง ผู้แต่ง และราคา) จะแสดงราคา สั่งซื้อด้วยปุ่มแสดงเพิ่มเติมถัดจากข้อมูลสรุปแต่ละรายการ
• กำหนดให้ผู้ใช้ดูหน้าค้นหาและป้อน “Waterfall Coaching” (ซึ่งไม่มีข้อมูลที่ตรงกัน) เมื่อผู้ใช้คลิกปุ่มค้นหา แล้วข้อความ “ขออภัย เราไม่พบหนังสือเล่มนั้น” จะปรากฏขึ้น

ทำการทดสอบเรื่องราว

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

“ทำไมผู้ใช้จึงต้องค้นหา ISBN” Damian ถาม “พวกเขาสามารถค้นหาจากผู้แต่งหรือคำสำคัญได้แล้ว”

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

Damian ขมวดคิ้ว “เราควรออกแบบวิธีการทำงานของการค้นหาใหม่ใช่ไหม ฉันคิดว่านี่เป็นการแก้ไขอย่างรวดเร็ว ระหว่างที่เราหาวิธีดำเนินการดังกล่าว” Amanda พยักหน้าและเขียนการ์ดเรื่องราวนี้

Damian ถามว่า “จะเกิดอะไรขึ้นหากผู้ใช้กดค้นหาโดยไม่ได้ป้อน ISBN แบบเต็ม คุณต้องการการจับคู่ ISBN บางส่วนหรือไม่”

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

Larry ผู้ทดสอบอ่านมัน “เราต้องจัดการ ISBN สิบสามหลักด้วยเหรอ” Amanda พยักหน้า และเขาเพิ่มโน้ตที่ด้านล่างของการ์ดเรื่องแรก

“เราจะส่งคืนผลลัพธ์ก็ต่อเมื่อพวกเขาป้อนตัวเลขเท่านั้นใช่หรือไม่ แล้วช่องว่างและยัติภังค์ล่ะ”

“แน่นอน” Damian เสริมว่า “การลบช่องว่างและยัติภังค์ออกไปไม่ใช่เรื่องยาก ดังนั้นเราอาจใส่เข้าไปด้วย”

Amanda เห็นด้วย “เป็นความคิดที่ดี”

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

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

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

ไม่มีฟังก์ชันที่ผู้ใช้เห็นหน้าจอ

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

ข้อกำหนดจะต้องมีการจัดทำเป็นเอกสาร

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

อีกวิธีหนึ่งในการสร้างเอกสารที่ไม่สามารถข้ามได้คือ ในโค้ดต้องมีการเขียนการทดสอบข้อกำหนดที่สามารถดำเนินการได้จริง

ทีมไม่สามารถพบกันตัวเป็นๆ ได้

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