วิธีกำหนดกฎเกณฑ์ทางธุรกิจที่ซับซ้อนโดยใช้เรื่องราวของผู้ใช้

คำจำกัดความที่รวดเร็วและสกปรกของเรื่องราวของผู้ใช้ :

"As a <role>, I want <goal/desire> so that <benefit>"

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

ตัวอย่างเล็กน้อยเพื่ออธิบาย:

"As a <librarian>, I want to <register new books> so that
<students can find their availability online>"

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

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

เรื่องราวของผู้ใช้ - สัญญาว่าจะมีการสนทนาเป็นรายการบล็อกเกี่ยวกับเรื่องนี้

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

คำตอบก่อนหน้านี้ให้จุดที่ถูกต้องเป็นพิเศษเกี่ยวกับเรื่องที่ผู้ใช้เป็นเตือนให้มีการสนทนา สิ่งอื่น ๆ ที่ควรพิจารณา:

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

2. รายละเอียดที่บ่งบอกถึงกรณีทดสอบที่แยกออกมาจากเรื่องราวนั้นเอง [ Mike Cohn ]

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

แนวทางในการประเมินว่าเรื่องราวของผู้ใช้ของคุณดีหรือไม่คุณอาจทำตามคำแนะนำของ Bill Wake :

• ฉันเป็นอิสระ (จากเรื่องราวอื่น ๆ )
• N egotiable
• V aluable (สำหรับผู้ใช้หรือลูกค้า)
• E สามารถกระตุ้นได้ (เพื่อการประมาณที่ดี)
• S mall (เพียงพอที่จะประเมินได้)
• T น่านับถือ

คุณอาจต้องการอ่านบทที่ 2 "การเขียนเรื่องราว"ของหนังสือเรื่องราวผู้ใช้ที่นำมาใช้โดย Mike Cohn

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

การลงทะเบียนหนังสือเล่มใหม่นั้นกว้างขวางดังนั้นอาจมีเรื่องราวของผู้ใช้เด็กอีก 10 คนเกี่ยวกับวิธีการ<role>ลงทะเบียนหนังสือ

รายละเอียดที่มากของสิ่งเหล่านี้หรือรายละเอียดที่แปลกประหลาดฉันมักจะกำหนดในหนึ่งหรือมากกว่าหนึ่งงานภายใต้เรื่องราวของผู้ใช้นั้น งานช่วยกำหนดงานพัฒนาและออกแบบที่ควรจะทำ (ในระดับทั่วไป) เพื่อตอบสนองเรื่องราวของผู้ใช้ (เช่นเขียน validator เพื่อให้แน่ใจว่าอินพุตในฟิลด์คำอธิบายน้อยกว่า 50 ตัวอักษร ... ) แก้ไข: ฉันแค่อยากจะเพิ่ม น่าจะดีกว่าที่จะไม่ให้รายละเอียดมากเกินไปจากเรื่องราวของผู้ใช้เพราะอาจเป็นไปได้ว่าไม่ใช่สิ่งที่ผู้ใช้จะให้ความสำคัญมากนัก ผู้ใช้ต้องการอธิบายซอฟต์แวร์ในแง่ทั่วไปและขึ้นอยู่กับผู้พัฒนาซอฟต์แวร์เพื่อค้นหาและซ่อนรายละเอียดจากพวกเขา

นี่เป็นเพียงวิธีที่ฉันเข้าถึงปัญหา แต่ฉันแน่ใจว่ามีหลายวิธีที่แตกต่างกัน

คำตอบนั้นง่ายรวมกฎธุรกิจเข้ากับเกณฑ์การยอมรับ

ตัวอย่างเล็กน้อยเพื่ออธิบาย:

ในฐานะบรรณารักษ์ฉันต้องการลงทะเบียนหนังสือเล่มใหม่เพื่อให้นักเรียนสามารถหาหนังสือออนไลน์ได้

ฉันจะพอใจเมื่อ: * ฉันสามารถลงทะเบียนฟิลด์ต่อไปนี้: - ISDN - ผู้แต่ง - Dewey Decimal blah blah * ฉันเห็นการยืนยันว่าหนังสือได้รับการลงทะเบียนโดยระบบ * ฉันสามารถดูหนังสือในระบบได้

วิธีกำหนดกฎเกณฑ์ทางธุรกิจที่ซับซ้อนโดยใช้เรื่องราวของผู้ใช้

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

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

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

ในตัวอย่างที่ระบุมีรายละเอียดมากมายเกี่ยวกับการลงทะเบียนหนังสือที่นักพัฒนาซอฟต์แวร์โยกย้ายมารู้จักเล็กน้อยเช่น Dewey หรือระบบการจำแนกอื่น ๆ , ISBN, หมายเลขการได้มา, สำเนา / ชื่อ / ผู้แต่งที่ซ้ำกัน, ฉบับอื่น ๆ เป็นต้น สำหรับระบบใหม่รายละเอียดดังกล่าวจะต้องได้รับจากลูกค้า (และบรรณารักษ์ของทุกคนจะดูแลพวกเขาอย่างแน่นอน )

เพื่ออ้างถึง Steve O'Connell "มันน่ากลัวที่จะพิจารณาว่านโยบายทางธุรกิจสร้างขึ้นโดยนักพัฒนาที่ขาดรายละเอียดที่จำเป็นในข้อมูลจำเพาะดังนั้นเพียงสร้างมันขึ้นมาเอง"