"เรื่องราวของผู้ใช้ด้านเทคนิค" ได้รับอนุญาตในการต่อสู้หรือไม่

เรื่องราวของผู้ใช้ด้านเทคนิคได้รับอนุญาตในการต่อสู้หรือไม่? ถ้าใช่เทมเพลตมาตรฐานสำหรับการเขียนเรื่องราวผู้ใช้ด้านเทคนิคใน Scrum คืออะไร มันเหมือนกันหรือAs a <user> I want to do <task> so that I can <goal>ไม่?

ฉันได้อ่านในบางบล็อกที่เป็นผู้พัฒนาไม่เป็นเรื่องผู้ใช้แต่ฉันได้อ่านด้วยว่า Scrum ไม่ได้บังคับใช้สิ่งเหล่านี้ มีไม่กี่บล็อกที่พวกเขาได้ร่วมกันเป็นเรื่องที่ผู้ใช้กับระบบเป็นผู้ใช้as a <user who is not end user> i want to <system functionality> so that <some techinical thing>เช่นของมัน แล้วอันไหนที่เป็นมาตรฐาน?

ตัวอย่างเช่นมีเรื่องราวของผู้ใช้ที่ชอบ:

ในฐานะนักวิจารณ์ฉันต้องการอัปโหลดรูปภาพของโรงแรม / อาหารเพื่อให้ผู้ใช้รายอื่นสามารถเห็นและชอบได้

ในฐานะผู้ใช้ฉันต้องการเพิ่มความคิดเห็นเกี่ยวกับรูปภาพเพื่อให้ฉันสามารถอธิบายมุมมองของฉันได้ดียิ่งขึ้น

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

ดังนั้นฉันสามารถเพิ่มเรื่องทางเทคนิคที่ชื่อว่า "การจัดเก็บและเรียกค้นภาพกลไก" พร้อมคำอธิบายต่อไปนี้ได้หรือไม่

ในฐานะนักพัฒนาฉันต้องการพัฒนากลไกในการจัดเก็บและดึงภาพเพื่อให้ผู้ใช้สามารถเพิ่ม / ดูภาพได้ทุกที่ที่ต้องการ

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

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

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

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

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

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

เรื่องราวทางเทคนิคมีมากขึ้น "ในฐานะนักพัฒนาฉันต้องการลดความซ้ำซ้อนในโมดูลการเก็บข้อมูลเพื่อที่ฉันจะได้ไม่ต้องเปลี่ยนแปลงทุกอย่างใน 6 ที่"

คำถามที่ว่าสิ่งเหล่านี้ควรรวมอยู่ในการวิ่งนั้นเป็นเรื่องยากหรือไม่ มันคือผู้ใช้ปลายทางหรือธุรกิจที่จ้างคุณหรือธุรกิจที่จ้างธุรกิจที่จ้างคุณ

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

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

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

ในที่สุดฉันขอแนะนำให้คุณลอง และถ้ามันไม่ได้มีคุณค่าให้หยุดทำ

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

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

ตัวอย่างเช่นการตัดการเชื่อมต่อในแอปพลิเคชันใหม่ถ้าเราไม่ได้รับอนุญาตให้เพิ่มเรื่องราวทางเทคนิคคือฉันจะฮัมเพลงมาหนึ่งสัปดาห์หลังจากการเริ่มต้นการสร้างโมเดลฐานข้อมูลและรอให้ผู้สร้างข้อมูลของฉันอนุมัติ พวกมันย้ำ w / the modeler และเมื่อเสร็จแล้วก็ส่งสคริปต์ไปยัง dba และรอให้พวกเขาสร้างวัตถุ db ในระหว่างนี้ฉันจะสร้างโครงการรหัสใหม่ฟังก์ชั่น ORM พื้นฐานบางส่วนและเค้าโครงการควบคุมแหล่งที่มาของฉันและเมื่อทุกคนพูดและทำเสร็จฉันจะมีเวลาในการสร้างหน้า Landing Page ว่างและปรับใช้

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

หากมีวิธีปฏิบัติที่ดีที่สุดในการทำเช่นนี้ฉันก็เป็นได้

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

ฉันจะลงจากกล่องสบู่ของฉันตอนนี้ แต่ถ้าคุณถามว่าด้านล่างนี้เป็น 'การต่อสู้' จริงโปรดอ่านอีกครั้งด้านบน

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

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

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

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

ควรมุ่งเน้นไปที่การสร้างมูลค่า บางครั้งค่านั้นมาจากงานด้านเทคนิคเช่นการอัพเกรดโครงสร้างพื้นฐาน อย่ายกเว้นรายการเหล่านั้น!

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

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

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

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