ฉันจะร่างเรื่องราวของผู้ใช้ในฐานะนักพัฒนาได้อย่างไร


10

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

{1} ฉันกำลังประเมินบริการการจัดการโครงการเปรียวTargetProcessและเรื่องราวของผู้ใช้แต่ละคนต้องเชื่อมโยงกับคุณลักษณะหลัก ระบบดูเหมือนว่าเหมาะสมดีดังนั้นข้อ จำกัด เล็ก ๆ นี้เป็นสิ่งที่ฉันอยากทำงานมากกว่าที่จะหลีกเลี่ยง

คำตอบ:


14

เทมเพลตเรื่องราวทั่วไปนั้นมองเห็นได้ง่ายมาก:

As a [ROLE] I need to [WHAT] so that/because [WHY].

สิ่งที่น่าสนใจคือความสำคัญของส่วนประกอบต่าง ๆ

ทำไมมีความสำคัญมากกว่าสิ่งที่และที่สำคัญกว่าบทบาท

ตัวอย่างการใช้คำถามนี้

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

สิ่งที่มากกว่านั้นทำให้ความตั้งใจและการใช้เรื่องราวของผู้ใช้ซับซ้อนขึ้น

เครื่องมือเพิ่มเติม (บูรณาการที่ดีที่สุด)

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


5

มุ่งเน้นไปที่สิ่งที่และเหตุผลและหลีกเลี่ยงวิธีเมื่อเขียนเรื่องราวของผู้ใช้

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

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

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

อัปเดต:
IMO ไม่เป็นไรที่จะใส่รายละเอียดลงในกรณีใช้งานซึ่งระบุระดับรายละเอียดที่จำเป็นสำหรับข้อมูล ตัวอย่างเช่นระบบการลงทะเบียนเป็นเกมที่ยุติธรรมที่จะระบุ
- นามสกุล; ฟิลด์ที่จำเป็น
- ชื่อ; ฟิลด์ที่ต้องระบุ
- ID บัญชี; ระบบไม่จำเป็นต้องสร้างอินพุต
- สัญญาณโหราศาสตร์; ฟิลด์ตัวเลือก - (ข้อเสนอแนะ) ให้การค้นหาจากการป้อนวันเกิด?
- ฯลฯ ....

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

หากคุณพูดได้หลายภาษาให้ใช้สองภาษาที่แตกต่างกันเป็นการทดสอบสารสีน้ำเงินของคุณ ตัวอย่างเช่นสตริงใน C โดยทั่วไปจะเป็นอาร์เรย์ char (นักแสดง) ในขณะที่ C ++, Java และ C # (โอเคและเกือบทุกคนอื่น ๆ ... ) มีสตริงเหมือนวัตถุจริง หากคุณพบว่าข้อกำหนดของคุณไม่ถูกต้องโดยใช้หนึ่งในภาษาเหล่านั้นคุณจะรู้ว่าคุณระบุไว้มากเกินไป

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

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


3
แม้แต่การพูดว่า "รายการแบบหล่นลง" อาจเป็นการระบุที่มากเกินไป
Donal Fellows

@ DonalFellows - นั่นเป็นประเด็นที่ดีและฉันก็ไตร่ตรองสิ่งนั้นสักนิด ฉันไปกับมันเนื่องจากการเลื่อนลงเป็นองค์ประกอบ UI ทั่วไปที่ค่อนข้างธรรมดาที่คุณจะเห็นด้วย wireframes Listbox และ Combobox เป็นโครงสร้างภาษาเฉพาะสำหรับรายการแบบหล่นลง +1 ในความคิดเห็น

@ GlenH7 ฉันเข้าใจสิ่งนี้ แต่ปัญหาของฉันคือฉันไม่รู้ว่าจะเก็บข้อมูลทางเทคนิคได้ที่ไหน หากต้องการบางฟิลด์สำหรับพนักงานใหม่เช่นฉันไม่ต้องการใช้เรื่องราวสำหรับแต่ละฟิลด์ แต่แทนที่จะเป็น "ในฐานะผู้ใช้ที่ฉันต้องการรวบรวมฟิลด์ x และ y" และ "อาจเลือกที่จะเก็บฟิลด์ q และ z "พิมพ์สิ่ง หากตัวอย่างรวดเร็วของฉันที่นี่เป็นทิศทางที่ถูกต้องฉันจะลองออกกำลังกายมากขึ้น
ProfK

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

2
@ProfK - อัปเดตคำตอบเพื่อตอบคำถามของคุณ IMO ฉันคิดว่าคุณกำลังถูกทาง ฉันได้ใช้วิธีการต่าง ๆ มากมายและสิ่งสำคัญที่ต้องจำก็คือการทำให้มันเหมาะกับสถานการณ์ของคุณ ดูเหมือนว่าคุณต้องการมากกว่าเรื่องที่เป็นทางการของผู้ใช้ ดังนั้นปรับวิธีการที่คุณสร้างเรื่องราวผู้ใช้ของคุณและก้าวไปข้างหน้า บางคนอาจจะจุดไฟให้ฉันเพื่อแสดงความคิดเห็น แต่โดยสุจริตจุดทั้งหมดคือการเขียนโค้ดและทำให้โครงการเดินหน้าต่อไป
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.