PBI เทียบกับเรื่องราวของผู้ใช้

เมื่อเร็ว ๆ นี้มีการเพิ่มรายการไปยัง Product Backlog โดยเจ้าของผลิตภัณฑ์ซึ่งระบุว่า "เมื่อฉันไปที่หน้าเข้าสู่ระบบจากหน้า x ฉันเห็นข้อผิดพลาดฉันต้องการข้อผิดพลาดนั้นจะถูกลบ"

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

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

รายการที่ค้างของผลิตภัณฑ์แมปกับเรื่องราวของผู้ใช้หรือไม่ พวกเขาเหมือนกันหรือไม่

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

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

ดังนั้นคำถามของฉันคืออะไรประเภทของสิ่งที่ได้รับใน Backlog สินค้าเป็นรายการ?

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

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

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

เราไม่เคยใช้คำว่า PBI (แม้ว่าเครื่องมือค้างของเราเรียกพวกเขาว่า) ก็มักจะเรื่องที่ผู้ใช้เรื่องข้อผิดพลาดหรือเพียงแค่เรื่องราว

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

ทุกคำตอบดังกล่าวไม่สามารถอ้างอิงแหล่งที่มาเอกสารสิทธิ์สำหรับกรอบการต่อสู้: ต่อสู้คู่มือ

สินค้าคงค้าง

มีส่วนที่อธิบายถึง Backlog ของผลิตภัณฑ์และรายการที่มักเรียกว่า PBI ซึ่งอยู่ในนั้น

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

แต่ไม่ได้รับการแก้ไขเหมือนแผนของโครงการ

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

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

เรื่องราวของผู้ใช้คำไม่เคยปรากฏใน The Scrum Guide เพราะ

มันเป็นกรอบที่คุณสามารถใช้กระบวนการและเทคนิคต่างๆ

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

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

@ Falcon ได้อธิบายไว้อย่างดี หนึ่งหน้าที่มีคำจำกัดความอย่างเป็นทางการคือ: http://en.wikipedia.org/wiki/Scrum_(development)#Product_backlog สิ่งที่คุณได้อธิบายไว้จะต้องไม่ถูกวางในผลิตภัณฑ์ค้าง (Backlog) อย่างน้อยที่สุด

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

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

• ข้อกำหนดเฉพาะที่แตกต่างกันของการเปลี่ยนแปลงและเพิ่มเติมของผลิตภัณฑ์เรียกว่า Product Backlog Items (PBIs) ที่รวมกันเป็น Product Backlog
• PBI แต่ละตัวอธิบายสิ่งที่ผู้พัฒนาสามารถพัฒนาและส่งมอบเพื่อเพิ่มมูลค่าให้กับผู้มีส่วนได้ส่วนเสียที่เกี่ยวข้องเมื่อดำเนินการเสร็จสิ้น (ดูคำจำกัดความของเสร็จสิ้น)
• ผู้มีส่วนได้เสียที่พบบ่อยที่สุดคือตลาดหรือตัวแทน - เจ้าของผลิตภัณฑ์
• อย่างไรก็ตาม PBI อาจอธิบายงานที่ลดต้นทุนให้กับองค์กรหรือลดความพยายามในการพัฒนาทีมหรือเครื่องมือที่ช่วยให้เจ้าของผลิตภัณฑ์ทำงานได้ดีขึ้น
• PBI สามารถอธิบายทุกสิ่งที่มีคุณค่าต่อผู้มีส่วนได้เสีย

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

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

• ในฐานะผู้ใช้
• ฉันต้องการที่จะเข้าสู่ระบบจากหน้า X (และไม่ได้รับข้อผิดพลาดแทน)
• ดังนั้นฉันจะไม่เสียเวลารำคาญและเสียศรัทธาในผลิตภัณฑ์

ฟังดูเหมือนมันคุ้มค่ากับความพยายาม