Scrum - เรื่องราวของผู้ใช้

ตามที่คุณเข้าใจแล้ว User Stories มักใช้เพื่ออธิบายคุณสมบัติของผลิตภัณฑ์และจะเป็นส่วนหนึ่งของ Scrum Artifacts - Product Backlog และ Sprint Backlog.

เรื่องราวของผู้ใช้

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

ในปี 2542 Kent Beck มีคำว่า User Stories สำหรับคุณลักษณะของผลิตภัณฑ์ เขาอธิบายว่าเรื่องราวของผู้ใช้ถูกบรรยายจากมุมมองของผู้ใช้เกี่ยวกับสิ่งที่เขาหรือเธอต้องการแทนที่จะเป็นสิ่งที่ระบบสามารถทำเพื่อเขาได้ ดังนั้นมุมมองจึงเปลี่ยนจากผลิตภัณฑ์เป็นผู้ใช้โดยสิ้นเชิงและเรื่องราวของผู้ใช้กลายเป็นมาตรฐานสำหรับข้อกำหนดในกรอบ Agile ทั้งหมดโดยพฤตินัย

ในโปรเจ็กต์ Scrum Product Backlog คือรายการเรื่องราวของผู้ใช้ เรื่องราวของผู้ใช้เหล่านี้ได้รับการจัดลำดับความสำคัญและนำไปไว้ใน Sprint Backlog ในการประชุมวางแผน Sprint

การประมาณยังขึ้นอยู่กับเรื่องราวของผู้ใช้และขนาดของผลิตภัณฑ์จะถูกประมาณใน User Story Points

โครงสร้างเรื่องราวของผู้ใช้

โครงสร้าง User Story มีดังนี้ -

ในฐานะที่เป็น<ประเภทของผู้ใช้> ,

ฉันต้องการ<การดำเนินการบางงาน> ,

เพื่อให้<I สามารถบรรลุเป้าหมายบาง / ประโยชน์ / ค่า>

ให้เรามาดูว่าเรื่องราวของผู้ใช้ถูกจัดทำขึ้นอย่างไรสำหรับสถานการณ์ที่ลูกค้าธนาคารถอนเงินสดจากตู้ ATM

เรื่องราวของผู้ใช้: การถอนเงินสดของลูกค้า

ในฐานะที่เป็น Customer,

ฉันต้องการ withdraw cash from an ATM,

ดังนั้น I don't have to wait in line at the Bank

เกณฑ์การยอมรับเรื่องราวของผู้ใช้

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

ต่อไปนี้เป็นเกณฑ์การยอมรับตัวอย่างสำหรับตัวอย่าง User Story การถอนเงินสดของลูกค้า

Acceptance Criterion 1:

Given ว่าบัญชีนั้นมีความน่าเชื่อถือ

• และบัตรถูกต้อง
• และตู้มีเงินสด

When ลูกค้าขอเงินสด

Then ตรวจสอบให้แน่ใจว่าบัญชีถูกหัก

• และตรวจสอบให้แน่ใจว่ามีการจ่ายเงินสด
• และตรวจสอบให้แน่ใจว่ามีการคืนบัตร

Acceptance Criterion 2:

Given บัญชีถูกถอนออกไป

• และบัตรถูกต้อง

When ลูกค้าขอเงินสด

Then ตรวจสอบให้แน่ใจว่าข้อความปฏิเสธปรากฏขึ้น

• และตรวจสอบให้แน่ใจว่าไม่มีการจ่ายเงินสด
• และตรวจสอบให้แน่ใจว่ามีการคืนบัตร

การเขียนเรื่องราวของผู้ใช้

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

ข้อกำหนดที่ไม่ใช้งานได้ในเรื่องราวของผู้ใช้

เป็นไปได้ที่จะรวมข้อกำหนดที่ใช้งานไม่ได้ไว้ในเรื่องราวของผู้ใช้ด้วย ในตัวอย่าง ATM ที่ระบุตู้ ATM ที่จะพร้อมใช้งานสำหรับผู้ใช้ 24X7, 365 วันเป็นข้อกำหนดที่ไม่สามารถใช้งานได้ซึ่งสามารถอธิบายได้ด้วยกรณีการใช้งาน

การจัดการเรื่องราวของผู้ใช้

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

ประโยชน์จากเรื่องราวของผู้ใช้

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

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

• เนื่องจากเกณฑ์การยอมรับเป็นส่วนหนึ่งของเรื่องราวของผู้ใช้เองจึงเป็นข้อได้เปรียบเพิ่มเติมให้กับทีม Scrum

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

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

สรุป

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