คำถามติดแท็ก user-story

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

132 agile  scrum  estimation  user-story 

ฉันแค่สงสัยว่าเราควรกำหนดเรื่องให้กับงานซ่อมบั๊กหรือไม่ JIRA ซึ่งเป็นซอฟต์แวร์ติดตามปัญหาของเราไม่มีฟิลด์จุดเรื่องราวสำหรับปัญหาประเภทBug (เฉพาะสำหรับStory s และEpicเท่านั้น) เราควรเพิ่มประเภทของปัญหาBugไปยังประเภทของปัญหาที่เกี่ยวข้องในฟิลด์Story Pointsหรือไม่ ข้อดีและข้อเสียคืออะไร? มันจะเหมาะสำหรับการต่อสู้แย่งชิงกันหรือไม่

50 agile  scrum  bug  user-story 

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

33 requirements  user-story  requirements-management 

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

27 agile  requirements  user-story 

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

23 project-management  agile  scrum  user-story 

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

22 agile  scrum  user-story 

ตามที่เป็นอยู่ในปัจจุบันคำถามนี้ไม่เหมาะสำหรับรูปแบบคำถาม & คำตอบของเรา เราคาดหวังคำตอบที่จะได้รับการสนับสนุนจากข้อเท็จจริงการอ้างอิงหรือความเชี่ยวชาญ แต่คำถามนี้อาจเรียกร้องให้มีการถกเถียงอภิปรายโต้แย้งหรือการอภิปรายเพิ่มเติม หากคุณรู้สึกว่าคำถามนี้สามารถปรับปรุงและเปิดใหม่ได้โปรดไปที่ศูนย์ช่วยเหลือเพื่อขอคำแนะนำ ปิดให้บริการใน7 ปีที่ผ่านมา การพัฒนาซอฟต์แวร์ Agile นั้นอาศัยประเภทรายการงานที่เรียกว่าเรื่องราวของผู้ใช้เป็นอย่างมาก ตัวอย่างเช่นคุณมีงานในมือที่เต็มไปด้วยเรื่องราวของผู้ใช้และคุณสามารถเลือกให้พวกเขาสองสามคนทำงานในระหว่างการวิ่งครั้งต่อไป แต่ที่ไหนและอย่างไรคุณค้นหาเรื่องราวของผู้ใช้ที่จะใส่ลงในมือ? มีเทคนิคที่นิยมสำหรับการทำที่เรียกว่าการทำแผนที่เรื่องราว เจฟฟ์แพตตันคิดค้นมันและนี่เป็นคำแนะนำที่ชัดเจนเกี่ยวกับวิธีการที่จะทำมัน คำถามคือเครื่องมืออิเล็กทรอนิกส์อะไรบ้างที่สนับสนุนเทคนิคการทำแผนที่ของ Patton ผมเคยทำบิตของการวิจัยพบว่าสำคัญและชุมนุมปลั๊กอิน ( แต่ผมไม่ได้เป็นลูกค้าของทั้งสอง) และฉันกำลังทดลองกับSilverStories มีเครื่องมืออื่นอะไรอีกบ้าง? คุณใช้อะไร คุณแนะนำอะไร (ไม่) ทำไม? ปรับปรุง:บางคนที่เขียนความคิดเห็นดูเหมือนจะเอนเอียงไปกับคำตอบว่าการใช้เทคนิคนี้เป็นไปไม่ได้ด้วยเครื่องมืออิเล็กทรอนิกส์และเราก็ควรยอมรับมัน ไม่มีใครเขียนเป็นคำตอบใช่หรือไม่ ปรับปรุง (เพื่อชี้แจงคำถามในแง่ของความคิดเห็นของ Alex Feinman): คำถามเกี่ยวกับการระบุตัวเลือกสำหรับการทำแผนที่เรื่องราว เนื่องจากเทคนิคของเจฟแพตตันสามารถทำบนกระดานไวท์บอร์ดได้อย่างชัดเจนคำถามจึงเน้นไปที่ตัวเลือกเพิ่มเติมที่อาจมีให้ในเครื่องมืออิเล็กทรอนิกส์ (ก่อนกำหนด) ความมุ่งมั่นต่อเครื่องมือใด ๆ โดยเฉพาะหรือระดับของเครื่องมือไม่ใช่จุดของคำถามนี้

20 agile  user-story  product-backlog 

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

14 scrum  user-story  sprint  scrum-master 

ที่ บริษัท ที่ฉันทำงานอยู่ตอนนี้เราก็เริ่มทำโครงการสrum ไม่ยากนักที่จะโน้มน้าวให้ผู้จัดการย้ายจากน้ำตกไปยังสrum เรากำลังทำโครงการที่เราสร้างแพลตฟอร์มขึ้นใหม่จากศูนย์ ดังนั้นฟังก์ชั่น (ส่วนใหญ่) จึงเป็นที่รู้จักและการปรับปรุงส่วนใหญ่ค่อนข้างใช้เทคนิค ในเรื่องนี้มันอาจเป็นเหตุผลที่จะมีงานด้านเทคนิคมากกว่าเรื่องราวของผู้ใช้ งานในมือของเรามีงานด้านเทคนิคทุกประเภทเช่น: เขียนคลาส DB ใหม่จาก MySQL เป็น PostgreSQL ใช้การบันทึกระบบ เขียนแคชวัตถุใหม่ สิ่งต่าง ๆ ที่เกิดขึ้นระหว่างการยืนรวมถึงความต้องการ "งานวิจัย" ที่ยาวนาน แต่พวกเขาไม่เคยทำ นอกจากนี้สมาชิกในทีมเรียกร้องในช่วงกลางของการวิ่งที่ต้องเพิ่มงานที่ไม่ได้วางแผนไว้ Scrum Master ควรจัดการกับสิ่งนี้อย่างไร เป็นไปได้ไหมว่าสำหรับโครงการประเภทนี้การแย่งชิงกันไม่ใช่ทางที่จะไป?

14 project-management  scrum  user-story  product-backlog 

ดังนั้นฉันมีโมดูลการตรวจสอบสิทธิ์ที่ฉันเขียนเมื่อไม่นานมานี้ ตอนนี้ฉันเห็นข้อผิดพลาดในทางของฉันและเขียนการทดสอบหน่วยสำหรับมัน ในขณะที่เขียนการทดสอบหน่วยฉันมีช่วงเวลาที่ยากลำบากในการหาชื่อที่ดีและพื้นที่ที่ดีสำหรับการทดสอบ ตัวอย่างเช่นฉันมีสิ่งที่ชอบ RequiresLogin_should_redirect_when_not_logged_in RequiresLogin_should_pass_through_when_logged_in Login_should_work_when_given_proper_credentials โดยส่วนตัวฉันคิดว่ามันน่าเกลียดนิดหน่อยถึงแม้ว่ามันจะดูเหมือน "เหมาะสม" ก็ตาม ฉันยังมีปัญหาในการแยกความแตกต่างระหว่างการทดสอบโดยการสแกนพวกเขา (ฉันต้องอ่านชื่อวิธีการอย่างน้อยสองครั้งเพื่อทราบว่าล้มเหลวเพียงใด) ดังนั้นฉันคิดว่าอาจจะแทนที่จะเขียนแบบทดสอบที่ทดสอบการทำงานล้วนๆอาจจะเขียนชุดการทดสอบที่ครอบคลุมสถานการณ์ ตัวอย่างเช่นนี่คือส่วนทดสอบที่ฉันสร้างขึ้นด้วย: public class Authentication_Bill { public void Bill_has_no_account() { //assert username "bill" not in UserStore } public void Bill_attempts_to_post_comment_but_is_redirected_to_login() { //Calls RequiredLogin and should redirect to login page } public void Bill_creates_account() { //pretend the login page …

13 design-patterns  .net  testing  unit-testing  user-story 

ติดตามสไตล์ของผู้ใช้อย่างเป็นทางการ: ในฐานะที่<user>ผมต้องการเพื่อให้<goal><benefit> จะเขียนเรื่องราวได้อย่างไรเมื่อไม่มีการโต้ตอบกับผู้ใช้อย่างชัดเจนเช่นในกรณีของกระบวนการอัตโนมัติเช่นการแจ้งหนี้ทุกคืน

13 user-story 

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

13 scrum  user-story 

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

12 agile  project-management  user-story  task 

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

12 agile  database  scrum  database-design  user-story 

เรื่องราวของผู้ใช้ด้านเทคนิคได้รับอนุญาตในการต่อสู้หรือไม่? ถ้าใช่เทมเพลตมาตรฐานสำหรับการเขียนเรื่องราวผู้ใช้ด้านเทคนิคใน 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>เช่นของมัน แล้วอันไหนที่เป็นมาตรฐาน? ตัวอย่างเช่นมีเรื่องราวของผู้ใช้ที่ชอบ: ในฐานะนักวิจารณ์ฉันต้องการอัปโหลดรูปภาพของโรงแรม / อาหารเพื่อให้ผู้ใช้รายอื่นสามารถเห็นและชอบได้ ในฐานะผู้ใช้ฉันต้องการเพิ่มความคิดเห็นเกี่ยวกับรูปภาพเพื่อให้ฉันสามารถอธิบายมุมมองของฉันได้ดียิ่งขึ้น ตอนนี้สำหรับเรื่องราวของผู้ใช้ทั้งสองนี้มีรายการทางเทคนิคที่สำคัญคือการบันทึกและดึงภาพ ดังนั้นฉันสามารถเพิ่มเรื่องทางเทคนิคที่ชื่อว่า "การจัดเก็บและเรียกค้นภาพกลไก" พร้อมคำอธิบายต่อไปนี้ได้หรือไม่ ในฐานะนักพัฒนาฉันต้องการพัฒนากลไกในการจัดเก็บและดึงภาพเพื่อให้ผู้ใช้สามารถเพิ่ม / …

11 project-management  agile  scrum  project  user-story