ความสัมพันธ์ระหว่างเรื่องราวของผู้ใช้คุณสมบัติและมหากาพย์?

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

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

ผู้จัดการโครงการของเรายืนยันว่ามีโครงสร้างแบบลำดับชั้น:

Epic -> Features -> เรื่องราวของผู้ใช้

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

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

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

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

Epic
- อนุญาตให้ลูกค้าจัดการบัญชีของตนเองผ่านทางเว็บ

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

คุณสมบัติมักจะอธิบายว่าซอฟต์แวร์ของคุณทำอะไร:

คุณสมบัติ
- แก้ไขข้อมูลลูกค้าผ่านทางเว็บพอร์ทัล

เรื่องราวของผู้ใช้มีแนวโน้มที่จะแสดงสิ่งที่ผู้ใช้ต้องการทำ:

เรื่องราวของผู้ใช้
ในฐานะเสมียนธนาคาร
ฉันต้องการที่จะสามารถแก้ไขข้อมูลลูกค้า
เพื่อให้ทันสมัยได้

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

เรื่องราวของผู้ใช้ : ในฐานะลูกค้าฉันต้องการชำระเงินด้วยบัตรเครดิตที่เป็นที่นิยมที่สุด
ฟีเจอร์สนับสนุน GOV-TAX-02 XML API ของรัฐบาล

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

สถานการณ์จำลอง : การถอนเงิน
เนื่องจากฉันมี 2,000 ดอลลาร์ในบัญชีธนาคารของฉัน
เมื่อฉันถอน 100 $
จากนั้นฉันจะได้รับเงินสด 100 ดอลลาร์
และยอดคงเหลือของฉันคือ 1900 $

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

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

Epic : เรื่องราวของผู้ใช้ที่มีขนาดใหญ่มากซึ่งในที่สุดก็ถูกแยกย่อยเป็นเรื่องราวเล็ก ๆ

เรื่องราวของผู้ใช้:คำจำกัดความระดับสูงมากของข้อกำหนดซึ่งมีข้อมูลเพียงพอเพื่อให้นักพัฒนาสามารถประเมินความพยายามในการใช้งาน

http://www.telerik.com/agile-project-management-tools/agile-resources/vocabulary.aspx

คุณสมบัติ : คุณสมบัติหรือความสามารถที่แตกต่างของแอพพลิเคชั่นซอฟต์แวร์หรือไลบรารี (เช่นประสิทธิภาพความสามารถในการพกพาหรือการทำงาน)

http://en.wikipedia.org/wiki/Software_feature

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

แท็กใช้งานได้กับ Stack Exchange และสามารถใช้ได้กับคุณเช่นกัน

วิธีที่เราทำงานกับ Epics, Stories and Features มีดังนี้

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

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

สิ่งนี้นำไปสู่ ​​Epics เช่น

• เรียกดูแคตตาล็อกสินค้า
• ดูห้องว่าง
• ดูราคา
• สถานที่การสั่งซื้อ
• ดูประวัติการสั่งซื้อ

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

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

เรื่องราวของผู้ใช้คือหน่วยของการจัดส่ง มันเป็นเรื่องราวของผู้ใช้ที่สมบูรณ์หรือไม่สมบูรณ์ไปเผยแพร่หรือไม่เผยแพร่

Epic อาจส่งผลให้เรื่องราวของผู้ใช้จำนวนมากไม่ใช่ทั้งหมดจะได้รับการพัฒนาหรือเผยแพร่ในเวลาเดียวกัน

ตัวอย่างเช่นมหากาพย์เรียกดูแคตตาล็อกผลิตภัณฑ์อาจแบ่งออกเป็น

• นำทางลำดับชั้นของหมวดหมู่
• ค้นหาด้วยคำสำคัญ
• กรองตามคุณสมบัติของผลิตภัณฑ์ (เช่นช่วงราคาแบรนด์สีขนาด ฯลฯ )

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

โดยทั่วไปสำหรับโครงการส่วนใหญ่ของเราเรามี Epics เป็นสิบและมีหลายร้อยเรื่อง

ตอนนี้เมื่อเราผ่านวงจรชีวิตของเรื่องราวเราติดแท็กเรื่องราวเหล่านี้ด้วยฟีเจอร์ s ตัวอย่างเช่นการค้นหาและการค้นหาและสต็อกและเรื่องราวการกำหนดราคาทั้งหมดจะถูกติดแท็กด้วย, พูดว่า 'แคตตาล็อกผลิตภัณฑ์' สั่งซื้อเรื่องราวเกี่ยวกับการชำระเงินด้วยบัตรเครดิตอาจติดแท็กด้วย 'บัตรเครดิต' และรายการที่เกี่ยวข้องกับการชำระเงินด้วย PayPal จะถูกติดแท็กด้วยป้าย 'paypal'

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

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

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

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

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

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

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

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

คำตอบที่ฉันชอบคือจากค่ายของ Mike Cohn และมันค่อนข้างง่าย

http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes

• มหากาพย์เป็นเพียงเรื่องใหญ่ (ลำดับชั้น)
• ชุดรูปแบบเป็นเพียงกลุ่มของ Stories (คล้ายกับแท็ก)

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

ดังนั้นในคำจำกัดความ PM ของคุณฟีเจอร์จึงอยู่ที่ไหนสักแห่งท่ามกลางลำดับชั้นของ Epic-Story

นี่คือกราฟิกข้อมูลของฉันของคำจำกัดความนี้จากบทความ InfoQ ของฉันhttp://www.infoq.com/articles/visualize-big-picture-agile ;-)

ฟีเจอร์และ Epics ไม่เหมือนกัน

• ฟีเจอร์ไม่ใช่เรื่องราวของผู้ใช้
• An Epic เป็นเรื่องราวของผู้ใช้
• เรื่องราวของผู้ใช้อาจเป็นเรื่องยิ่งใหญ่
• เรื่องราวของผู้ใช้สามารถมีคุณสมบัติมากมาย
• ฟีเจอร์สามารถเติมเต็มเรื่องราวของผู้ใช้ได้ 1 ถึงหลายเรื่อง

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

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

มันเป็นเพียงปัญหาการสลายตัว มันเป็นเพียงเรื่องราวยกเว้นขนาดที่แตกต่างกัน

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

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

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

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

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

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

เราต้องมีหลายระดับระหว่าง Feature และ Business Epic แต่เรายังไม่ได้แก้ไขสิ่งนี้นอกจากจะเรียกพวกเขาว่า "Themes" - ซึ่งเรารู้ว่าไม่ใช่คำที่ถูกต้องเพราะสับสนกับ SAFe Investment Themes สำหรับโครงการขนาดใหญ่ (เผยแพร่) เรามีระดับลำดับชั้นที่แตกต่างกัน 5-8 ระดับแต่ละโครงการแบ่งงานออกเป็นชิ้นเล็ก ๆ และเล็กลง คุณสามารถนึกถึงชุดรูปแบบเหล่านี้ว่าเป็น "กลุ่มคุณสมบัติ" แต่นั่นไม่จำเป็นต้องเป็นคำที่ถูกต้องเช่นกัน

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

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

บรรทัดล่างคือว่านี่ยังคงเป็นความคืบหน้าการทำงานสำหรับเราและเรายังคงดิ้นรนกับมัน แต่การยึดมั่นกับคำจำกัดความของ SAFe เกี่ยวกับ Theme, Epic, Feature และ Story ทำให้เราก้าวไปในทิศทางที่ถูกต้อง!

Product Backlog Hierarchy นั้นขึ้นอยู่กับขนาดของผลิตภัณฑ์และ modularity ของมัน (จำนวนของพื้นที่ผลิตภัณฑ์ที่กำหนดไว้)

สำหรับโครงการขนาดเล็ก: มหากาพย์> เรื่องราวนั้นมากเกินพอ และคุณเรียกว่า "คุณสมบัติ"
โครงการขนาดใหญ่อาจเหมือนกันกับ: นวนิยาย> ธีม> มหากาพย์> คุณสมบัติ> เรื่องราว

ตัวอย่างที่ดีที่สุดอาจเป็นดังต่อไปนี้:
นวนิยาย =
ชุดรูปแบบ MS Office = MS Word / MS Excel ...
มหากาพย์ = ไดเรกทอรีตาราง / ฟอนต์ ...
คุณลักษณะ = พื้นฐานตาราง / ตารางสีโครงการ / การดำเนินการกับเซลล์ ...
เรื่อง (สำหรับ ' คุณสมบัติตารางพื้นฐาน 'ภายใน' ตาราง 'มหากาพย์) = เพิ่มตาราง / วาดตาราง / แทรกคอลัมน์ดิบ / แทรก ...

สิ่งที่ฉันเชื่อว่าเป็นประโยชน์ต่อการจำเมื่อกำหนดขนาดของคุณเองสำหรับงานในมือคือ:
1. เรื่อง:ก) เป็นไปได้เสมอภายในวิ่งหนึ่ง; b) ไม่สามารถทดสอบได้สำหรับผู้ใช้เสมอไป
2. มหากาพย์ / คุณสมบัติ: a) ไม่พอดีกับระยะเวลาการวิ่งหนึ่งครั้งและจำเป็นต้องสลายตัว b) ควรทดสอบได้สำหรับผู้ใช้ปลายทางเสมอ; c) shippable เสมอสามารถสร้างรายได้ - รับผลตอบแทนการลงทุนสำหรับการคำนวณ
3.เมื่อพิจารณาเพิ่มหรือไม่ Epic> ส่วนคุณสมบัติหรือติดกับ Epic> เรื่อง: ฉันแนะนำให้แทรก Feature ในระหว่าง Epic และ Story เฉพาะเมื่อ: Epic doesn ' เสื้อสวมใส่ได้ 1 วางจำหน่ายดังนั้นคุณจึงจำเป็นต้องกำหนดองค์ประกอบ shippable ที่จะพอดีกับระยะเวลา

หวังว่านี่จะเป็นประโยชน์

ในองค์กรของเราเรามีดังต่อไปนี้:

ธีม = ใช้เพื่อจัดกลุ่มคอลเลกชันเรื่องราว

Epic = อธิบายเรื่องราวของผู้ใช้จำนวนมาก (ตามความต้องการจริง ๆ ) ที่จะต้องแยกย่อยเป็นเรื่องราวของผู้ใช้

คุณสมบัติ = ทำตามที่ระบุไว้บนกระป๋องหรือไม่อธิบายถึงคุณสมบัติของผลิตภัณฑ์ที่ต้องการ

เรื่องราวของผู้ใช้ = นี่คือรายละเอียดระดับต่ำสุดที่ได้รับมาจากงาน