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

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

เกณฑ์การยอมรับ: 1. แปลงการทดสอบด้วยตนเอง 50 รายการเป็นการทดสอบอัตโนมัติทั้งหมด 2. การทดสอบจะต้องดำเนินการในเวลาน้อยกว่า 1 ชั่วโมง "

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

อัปเดตเมื่อวันที่ 6/7/2554 - คำถามที่นำมาใช้ใหม่เพื่อเน้นคำว่า "เรื่องราวของผู้ใช้"

ใช่

ผู้มีส่วนได้เสียใด ๆ คุณสมบัติใด ๆ ที่ช่วยปรับปรุงระบบ

[ปล่อยให้คนพิถีพิถันลงคะแนนเริ่มต้น!]

"ผู้บริหารของฉันต้องการใช้ Agile สำหรับทุกสิ่งรวมถึงงานที่เกี่ยวข้องกับการพัฒนาที่ไม่ใช่ซอฟต์แวร์"

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

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

เรื่องราวของผู้ใช้! = ความคล่องตัว

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

Agile เป็นวิธีการจัดการโครงการ คุณสามารถใช้เรื่องราวของผู้ใช้หรือไม่ในโครงการ Agile

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

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

หาก QA ไม่ได้รับเรื่องราวของพวกเขาจะมีการสูญเสียธุรกิจจริงเพียงใด?

หากผู้มีส่วนได้เสียที่แท้จริงไม่ได้รับเรื่องราวของพวกเขาธุรกิจจะประสบอย่างแท้จริง

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

ในบันทึกย่อนั้นซอฟต์แวร์คือ:

1. กำหนดชี้แจงได้
2. ทดสอบ

การปรับปรุงกระบวนการเปิดให้บริการแล้วและโดยทั่วไปมักเป็นเรื่องส่วนตัว

เกณฑ์การยอมรับ: 1. การปรับปรุงการทดสอบ 1 (โดย x / y)

คุณวัดการปรับปรุงเพื่อการทดสอบอย่างไร ไม่มีสัญญาที่แน่นอนสำหรับการที่

และในบันทึกที่ไม่เกี่ยวข้องฉันหวังว่าตัวอย่างของคุณที่ระบุไว้ข้างต้น

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

... เป็นเพียงตัวอย่างเพราะมีข้อผิดพลาดมากมายที่ฉันไม่สามารถอธิบายได้

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

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

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

คุณมีปัญหาที่ลึกซึ้งเมื่อคุณใส่ "เรื่องราวของผู้ใช้" ภายในไว้ในการมิกซ์กับเรื่องราวของผู้ใช้จริง

โปรดอ่านคำจำกัดความของ "ผู้มีส่วนได้เสีย" ให้มากที่สุดเท่าที่จะทำได้

http://en.wikipedia.org/wiki/Scrum_(development )

http://wiki.openbravo.com/wiki/Scrum/Pigs_and_Chicken

http://www.testertroubles.com/2009/04/scrum-pigs-and-chickens.html

อ่านอย่างระมัดระวังเพื่อให้คุณเห็นความแตกต่างระหว่างไก่และหมู

"เรื่องราวของผู้ใช้" ภายในเขียนโดยไก่

เรื่องราวของผู้ใช้จริงเขียนโดยหมู

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

ที่ขอบพร่ามัวของการโต้แย้งเป็นปัญหา QA QA มีความสำคัญและไม่มีมันไม่มีอะไรทำงาน

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

หาก QA ไม่แสดงการทดสอบการปรับปรุงในการทดสอบจะไม่มีใครตกหล่นในธุรกิจ เงินจะไม่สูญหาย

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

อย่ารวมผู้มีส่วนได้ส่วนเสียภายใน ("ไก่") และผู้มีส่วนได้เสียที่แท้จริง ("หมู")

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

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

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