Scrum Guide | 19. เรื่องราวของผู้ใช้ – มันคืออะไร?
เผยแพร่แล้ว: 2022-05-20เรื่องราวของผู้ใช้คือคำอธิบายสั้นๆ เกี่ยวกับฟังก์ชันการทำงานของผลิตภัณฑ์ใหม่หรือการเพิ่มประสิทธิภาพ ไม่มีวิธีแก้ปัญหาทางเทคนิคแต่ตอบคำถามเกี่ยวกับฟังก์ชันการทำงาน: ใครคือผู้ใช้? ผลิตภัณฑ์ทำอะไร? และจุดประสงค์ของมันคืออะไร? User Story อธิบายผลิตภัณฑ์ด้วยภาษาในชีวิตประจำวันหรือภาษาธุรกิจ แม้ว่าจะชี้ไปที่งานของทีม Scrum ที่มีจุดประสงค์เพื่อปรับปรุงประสิทธิภาพของทีม
เรื่องราวของผู้ใช้คืออะไร? – สารบัญ:
- บทนำ
- เรื่องราวของผู้ใช้ เรื่องราวของใคร?
- วิธีการใช้เรื่องราวของผู้ใช้?
- เกณฑ์การยอมรับ
- สรุป
บทนำ
User Story เป็น วิธีการทั่วไปในการกำหนดงานที่ ดำเนินการโดย Scrum Team เรื่องราวของผู้ใช้รายเดียวกำหนดฟังก์ชันการทำงานเล็กๆ ของผลิตภัณฑ์ อธิบายเป้าหมายผลิตภัณฑ์บางส่วนที่มีความหมายที่เล็กที่สุด ด้วยเหตุนี้ เรื่องราวของผู้ใช้จึงสั้นมาก
เรื่องราวของผู้ใช้ถูกสร้างขึ้นตลอดระยะเวลาการทำงานกับผลิตภัณฑ์ สิ่งเหล่านี้ถูกสร้างขึ้นอย่างต่อเนื่องตั้งแต่ช่วงเวลาที่ตัดสินใจเริ่มงาน ไปจนถึงการบรรลุเป้าหมายผลิตภัณฑ์
การสร้างเรื่องราวของผู้ใช้เป็น งานของเจ้าของผลิตภัณฑ์ จากการสนทนากับลูกค้า กำหนดคำตอบสำหรับคำถามที่อนุญาตให้สร้าง User Story และ ป้อนลงใน Product Backlog อย่างไรก็ตาม User Stories ไม่เพียงสะท้อนความต้องการของลูกค้าเท่านั้น
เรื่องราวของผู้ใช้ เรื่องราวของใคร?
ทีม Scrum สร้าง User Story เพื่อกำหนด ความต้องการของผู้ใช้ และนั่นเป็นเหตุผลว่าทำไมจึงใช้ภาษาธุรกิจ กล่าวอีกนัยหนึ่ง มันบ่งบอกถึงประโยชน์ที่การใช้งานจะนำมาสู่ผู้ใช้ผลิตภัณฑ์ อย่างไรก็ตาม ใน Product Backlog อาจมี User Stories ที่อธิบาย ความต้องการของทีมพัฒนา เช่น การปรับปรุงเวิร์กโฟลว์ระหว่างนักพัฒนา หรือการอธิบาย ความต้องการของเจ้าของผลิตภัณฑ์ เช่น การจัดระเบียบ Product Backlog ในกรณีดังกล่าว ผู้ใช้ใน User Story คือผู้พัฒนาและเจ้าของผลิตภัณฑ์
คุณสามารถอธิบาย User Story ได้โดยตอบ คำถาม 3W :
- ใคร?
- กำลังทำ อะไร?
- ทำไม
เรื่องราวของผู้ใช้จะมีอยู่ในสูตร:
ในฐานะที่เป็น [ประเภทผู้ใช้] ฉันต้องการ [ทำอะไร] เพราะ [ทำไม? ทำไม?].
ตัวอย่างของ User Stories เกี่ยวกับการทำงานของร้านค้าออนไลน์ที่เขียนในแบบฟอร์มนี้แสดงไว้ในตารางด้านล่าง:
สูตรนี้ไม่เพียงแต่ช่วยให้สามารถกำหนด User Story ได้เท่านั้น แต่ยังช่วยแปลภาษาทางเทคนิคเป็นธุรกิจได้อย่างง่ายดาย และ ในทางกลับกัน ด้วย เป็นผลให้ทั้งนักพัฒนาและผู้มีส่วนได้ส่วนเสียมองเห็นเป้าหมายและขั้นตอนของความคืบหน้าได้อย่างชัดเจน เราจะกล่าวถึงการสร้าง User Stories ที่ดีโดยใช้วิธี INVEST ในบทความแยกต่างหากในชุด Scrum Guide
วิธีการใช้เรื่องราวของผู้ใช้?
การสร้างแผนผัง User Story เป็นเพียงจุดเริ่มต้นเท่านั้น เป็นสัญญาณและ จุดเริ่มต้นสำหรับการอภิปรายปัญหาและแนวทางแก้ไข การสนทนาเกี่ยวกับเรื่องราวของผู้ใช้เกิดขึ้นระหว่างการวางแผน Sprint เพื่อแยกแยะว่าปัญหาทางเทคนิคใดที่ทีมพัฒนาจะเพิ่มใน Sprint Backlog
โดยทั่วไป ในพื้นที่ทางกายภาพ เรื่องราวของผู้ใช้จะ เขียนบนการ์ดสีเล็กๆ ที่ ปักหมุดไว้ในสถานที่ทำงาน อย่างไรก็ตาม ในพื้นที่ดิจิทัล กระดานไวท์บอร์ดดิจิทัลที่แชร์โดย Scrum Team ทำงานได้ดีที่สุด
การบันทึกเรื่องราวของผู้ใช้ด้วยวิธีนี้มีข้อดีหลายประการ เนื่องจาก:
- เน้นย้ำถึงความเป็นเอกเทศของ User Story แต่ละเรื่อง – แต่ละส่วนมีกรอบการทำงานที่แยกจากกันและสามารถดำเนินการได้โดยอิสระจากผู้อื่น
- เน้นย้ำถึงไดนามิกของ User Stories – ลำดับของการรับรู้จะถูกเจรจาใหม่โดยทีม Scrum และลำดับการรับรู้ปัจจุบันจะปรากฏบนกระดานด้วยการจัดเรียงการ์ดที่มี User Stories
- ทำหน้าที่เป็นเครื่องเตือนใจ – ด้วยการแสดงภาพของ User Stories ทำให้ทีม Scrum มีป้ายบอกทางที่มองเห็นได้เพื่อเตือนพวกเขาถึงเป้าหมายเมื่อสร้างโซลูชันโดยละเอียด
ทีมพัฒนาประเมินความพยายามที่จำเป็นในการทำให้ User Story สมบูรณ์ด้วยจำนวนวัน ชั่วโมงการทำงาน หรือ Story Points
เกณฑ์การยอมรับ
เรื่องราวของผู้ใช้ต้องมี เกณฑ์การยอมรับในขณะนี้ซึ่งเป็นที่ยอมรับสำหรับการพัฒนา โดยทีมพัฒนา เกณฑ์การยอมรับจะกำหนดว่างานใดใน User Story ที่ถือว่าเสร็จสิ้น
วิธีนี้ทำให้ทั้งลูกค้าและนักพัฒนารู้ว่างานของพวกเขาจะแปลงเป็นมูลค่าทางธุรกิจได้อย่างไร โดยทั่วไป เรื่องราวของผู้ใช้จะถือว่า เสร็จสมบูรณ์เมื่อผู้ใช้ที่ระบุในนั้นสามารถดำเนินการตามที่อธิบายไว้ได้ จากตัวอย่างข้างต้น ให้ดูที่ User Story นี้พร้อมเนื้อหา:
ลูกค้าสามารถซื้อไม้กายสิทธิ์ได้ด้วยคลิกเดียว
จะเสร็จสมบูรณ์เมื่อ ปุ่ม "ซื้อเลย" ที่ใช้งานได้ปรากฏ บนหน้าร้านค้าออนไลน์ ซึ่งใช้ข้อมูลการชำระเงินและการจัดส่งเริ่มต้นสำหรับผู้ใช้ที่เข้าสู่ระบบ
สรุป
เรื่องราวของผู้ใช้คือคำอธิบายสั้นๆ เกี่ยวกับฟังก์ชันหรือการปรับปรุงผลิตภัณฑ์ใหม่ มันทำหน้าที่เป็น เป้าหมายที่เล็กที่สุดที่แสดงในภาษาธุรกิจ นั่นคือ จากมุมมองของมูลค่าธุรกิจและผู้ใช้ ช่วยในการกำหนดงานที่จะต้องดำเนินการอย่างชัดเจนรวมถึงเกณฑ์สำหรับความสมบูรณ์ของงาน
หากคุณชอบเนื้อหาของเรา เข้าร่วมชุมชนผึ้งที่วุ่นวายบน Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest
ผู้เขียน: แคโรไลน์ เบ็คเกอร์
ในฐานะผู้จัดการโครงการ Caroline เป็นผู้เชี่ยวชาญในการค้นหาวิธีการใหม่ๆ เพื่อออกแบบเวิร์กโฟลว์ที่ดีที่สุดและเพิ่มประสิทธิภาพกระบวนการ ทักษะในการจัดองค์กรและความสามารถในการทำงานภายใต้แรงกดดันของเวลาทำให้เธอเป็นคนที่ดีที่สุดในการเปลี่ยนโครงการที่ซับซ้อนให้กลายเป็นจริง
คู่มือการต่อสู้:
- อภิธานศัพท์ของคำศัพท์พื้นฐาน บทบาท และแนวคิด
- Scrum คืออะไร?
- ค่าการต่อสู้
- วิธีใช้งาน Scrum ในบริษัทของคุณ
- Scrum Team - มันคืออะไรและทำงานอย่างไร?
- เจ้าของผลิตภัณฑ์คือใคร?
- ข้อผิดพลาดที่พบบ่อยที่สุดของ Product Owner
- Scrum Master คือใคร?
- ลักษณะของ Scrum Master ที่ดี
- ข้อผิดพลาดที่พบบ่อยที่สุดของ Scrum Master
- สถิติและตัวชี้วัดใดที่ Scrum Master ควรติดตาม
- ความร่วมมือระหว่าง Product Owner และ Scrum Master
- ทีมพัฒนาใน Scrum
- ข้อผิดพลาดที่พบบ่อยที่สุดของ Developers
- สิ่งประดิษฐ์การต่อสู้
- สเกลการต่อสู้
- Sprint Backlog
- Backlog สินค้าคืออะไร?
- เรื่องราวของผู้ใช้คืออะไร?
- สร้าง User Story ที่ดีที่สุดกับ INVEST
- ข้อผิดพลาด User Story ที่พบบ่อยที่สุด
- เกณฑ์การยอมรับเรื่องราวของผู้ใช้
- การประมาณค่าและจุดเรื่องราวใน Scrum
- การวางแผนโป๊กเกอร์
- เกมประเมินทีม
- กำหนดส่วนเพิ่ม
- เหตุการณ์การต่อสู้
- Sprint ใน Scrum คืออะไร?
- ความมุ่งมั่นของทีม Scrum - เป้าหมายผลิตภัณฑ์ เป้าหมาย Sprint และคำจำกัดความของความสำเร็จ
- แผนภูมิ Burndown คืออะไร?
- จะสร้างและตีความแผนภูมิเบิร์นดาวน์ได้อย่างไร?
- ข้อดีและข้อเสียของแผนภูมิการเบิร์นดาวน์
- กระดาน Kanban ใน Scrum และ Scruban
- Velocity in Scrum - ความเร็วของทีมพัฒนา
- การต่อสู้รายวัน
- การวางแผนการวิ่ง
- Sprint Review
- Sprint Retrospective คืออะไร?
- ข้อผิดพลาดทั่วไประหว่าง Sprint Retrospective
- บำรุง Backlog สินค้า