วิธีจัดการกับเรื่องราวที่แบ่งปันการใช้งาน

ฉันมีสองเรื่อง (ฉันรู้ว่าพวกเขาหายไปส่วนผลประโยชน์)

1. ในฐานะผู้ใช้การจัดการเครดิตฉันสามารถดูความแตกต่างของเงินเดือนปัจจุบันและก่อนหน้าสำหรับสำนักงาน
2. ในฐานะผู้ใช้การจัดการเครดิตฉันสามารถรับอีเมลที่มี PDF ของความแตกต่างของเงินเดือนปัจจุบันและก่อนหน้าสำหรับสำนักงาน

ทั้งสองเกี่ยวข้องกันซึ่งจะมีเกณฑ์การสืบค้น / ตัวกรองเหมือนกัน ข้อแตกต่างเพียงอย่างเดียวคือในเรื่อง "มุมมอง" ผลลัพธ์จะปรากฏต่อผู้ใช้และในเรื่อง "อีเมล" ผลลัพธ์จะถูกเขียนลงใน PDF ที่ส่งถึงผู้ใช้ทางอีเมล

ฉันกำลังดิ้นรนกับการแยกแง่มุมทั่วไปของสองเรื่องนี้หรือถ้าฉันควรทำเช่นนั้น

ตัวอย่างเช่นพวกเขาทั้งสองจะมีข้อความค้นหาเดียวกันสิ่งที่พวกเขาทำกับผลลัพธ์ต่างกัน

ฉันควรแยกคำถามออกเป็นเรื่องอื่นที่เป็นเรื่องทางเทคนิคหรือไม่?

การสร้าง PDF และการส่งอีเมลควรทำแบบออฟไลน์นั่นควรเป็นเรื่องทางเทคนิคหรือไม่

ฉันเห็นการแบ่งเรื่องราวสองเรื่องเหล่านี้ออกเป็น 2 เรื่องและเรื่องราวทางเทคนิค 2 เรื่อง

1. ในฐานะระบบฉันสามารถคำนวณความแตกต่างในบัญชีเงินเดือนปัจจุบันและก่อนหน้าสำหรับสำนักงาน

2. ในฐานะผู้ใช้การจัดการเครดิตฉันสามารถดูความแตกต่างในการจ่ายเงินเดือนปัจจุบันและก่อนหน้าสำหรับสำนักงาน

3. ในฐานะที่เป็นระบบฉันสามารถสร้างเอกสาร PDF ของความแตกต่างในบัญชีเงินเดือนปัจจุบันและก่อนหน้าสำหรับสำนักงาน

4. ในฐานะผู้ใช้ด้านการจัดการเครดิตฉันสามารถขอรับอีเมลที่มี PDF ของความแตกต่างในการจ่ายเงินเดือนปัจจุบันและก่อนหน้าสำหรับออฟฟิศ

ปัญหาที่ฉันกลับมาเรื่อย ๆ ก็คือเรื่องทั้งสี่นั้นไม่ได้เป็นอิสระและไม่ "ฝานเค้ก"

ดังนั้นฉันไม่แน่ใจว่าจะจัดการกับสองสิ่งนี้อย่างไร

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

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

ไม่: ลองแบ่งเรื่องราวให้ทำเรื่องหนึ่งแล้วเล่าเรื่องอื่น

ทำ: ตรวจสอบให้แน่ใจว่าทีมผู้พัฒนาตระหนักถึงเรื่องที่สอง

ปัญหาของการพยายามวางแผนงานที่มีรายละเอียดและสร้างโมเดลทั่วไปที่สามารถจัดการกับทั้งสองอย่างอย่างสง่างามคือมันยาก

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

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

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

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

สิ่งสำคัญที่จะเพิ่มในเรื่องราวของผู้ใช้คือ:

• เกณฑ์การยอมรับ
• สมมติฐาน

การพูดอย่างเคร่งครัดเรื่องราวของผู้ใช้คือสัญญาของการสนทนาเพื่อทำความเข้าใจผลลัพธ์ที่ต้องการ

ตัวอย่างเช่นนำเรื่องราวของผู้ใช้ที่สองของคุณ

ในฐานะผู้ใช้การจัดการเครดิตฉันสามารถรับอีเมลที่มี PDF ของความแตกต่างของเงินเดือนปัจจุบันและก่อนหน้าสำหรับสำนักงาน

คิดเกี่ยวกับสิ่งต่อไปนี้:

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

เมื่อเข้าใกล้การแยกเรื่องให้จดจำเกณฑ์การลงทุนของคุณหากเป็นไปได้

1. ฉัน ndependent
2. N egotiable
3. มีค่า
4. อีกระตุ้น
5. Sห้างสรรพสินค้า
6. T น่านับถือ

มันก็โอเคที่จะมีเรื่องราวที่มีลำดับตามธรรมชาติ คำนึงถึงเรื่องนั้น - เรื่องแรกมักจะมีขนาดใหญ่ขึ้นตามที่นำมาในฟังก์ชั่นที่จำเป็นและเรื่องที่สองสร้างขึ้นมา

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

TL; DR

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

เรื่องควรจะถูกย่อยสลายไปยังงานซ้ำ

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

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

Tasks Implement Stories

นี่คือวิธีคิดเกี่ยวกับการวางแผนการพึ่งพาสำหรับเรื่องราวของผู้ใช้ โดยทั่วไป:

1. มหากาพย์ / ชุดรูปแบบใช้สำหรับการวางแผนระยะยาวหรือการจัดกลุ่มในงานในมือ
2. เรื่องราวของผู้ใช้ใช้สำหรับการสื่อสารวัตถุประสงค์บริบทและขอบเขต
3. การวางแผนแบบทันเวลาถูกใช้เพื่อพัฒนาการใช้งานที่เหมาะสมภายในการทำซ้ำเพียงครั้งเดียว
4. Tasks ใช้แผนทันเวลาที่ตรงตามคำนิยามของ Done สำหรับเรื่องราวของผู้ใช้หนึ่งเรื่องหรือมากกว่า

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