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

ในกระบวนการพัฒนาแบบ Agile โดยปกติจะเน้นที่เรื่องของผู้ใช้ แต่บางครั้งความต้องการเดียวอาจครอบคลุมเรื่องราวของผู้ใช้หลายคน ตัวอย่างเช่นลูกค้าอาจขอหน้าค้นหาสำหรับผู้ใช้ทั้งหมดในฟอรัมและมีการดำเนินการหลายอย่างที่อาจเกิดขึ้นกับผู้ใช้แต่ละรายเช่นผู้ใช้แบนผู้ใช้ลบผู้ใช้รีเซ็ตรหัสผ่าน ฯลฯ เราอาจแบ่งคุณลักษณะนี้ออกเป็นเรื่องราวของผู้ใช้อย่างน้อย 4 เรื่อง: ค้นหาผู้ใช้ แบนผู้ใช้ ลบผู้ใช้ รีเซ็ตรหัสผ่าน ผู้ออกแบบส่วนต่อประสานผู้ใช้จะใช้ส่วนต่อประสานกับผู้ใช้ได้อย่างไร? เขา / เธอควรทำงานกับเรื่องราวของผู้ใช้คนแรกแล้วเริ่มเพิ่มคุณสมบัติเพิ่มเติมให้กับ UI หรือไม่ อย่างไรก็ตามฉันคิดว่า UI ขั้นสุดท้ายจะเลอะ! หากเขาตัดสินใจที่จะทำงานกับคุณลักษณะทั้งหมด (การค้นหา + การกระทำ) จะเกิดอะไรขึ้นถ้าการกระทำที่มีลำดับความสำคัญต่ำและจะต้องดำเนินการซ้ำหลายครั้งหลังจากฟังก์ชั่นการค้นหาเสร็จสิ้นแล้ว

11 web-development  agile  user-interface  user-story  user-experience 

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

11 scrum  user-story  sprint 

คำจำกัดความที่รวดเร็วและสกปรกของเรื่องราวของผู้ใช้ : "As a <role>, I want <goal/desire> so that <benefit>" ในคำจำกัดความที่ยอมรับกันโดยทั่วไปนี้จะมีพื้นที่เพียงเล็กน้อยสำหรับการกำหนดกฎเกณฑ์ทางธุรกิจข้อ จำกัด หรืออินพุตของผู้ใช้ ตัวอย่างเล็กน้อยเพื่ออธิบาย: "As a <librarian>, I want to <register new books> so that <students can find their availability online>" ในตัวอย่างที่โง่นี้ใครจะกำหนดฟิลด์ที่จำเป็นเมื่อลงทะเบียนหนังสือ ควรเขียนที่ไหน? หรือควรส่งกฎธุรกิจที่จำเป็นตามคำบอกเล่าจากเจ้าของผลิตภัณฑ์?

11 business-rules  user-story 

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

10 user-story  extreme-programming  estimation 

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

10 agile  documentation  requirements  user-story 

เรื่องราวของผู้ใช้สามารถกำหนดได้ในประโยคเช่น: As a <type of user> I want <some goal> so that <some reason> เพียงแค่ Google สำหรับ 'สูตรเรื่องราวผู้ใช้' และลิงก์แรกเสนอสูตรนี้ทั้งหมด คำถามของฉันคือจุดประสงค์ของประโยคนั้นคืออะไร? มีผู้จัดการหรือไม่ มีเพื่อให้ผู้จัดการโครงการและผู้มีส่วนได้เสียสามารถเข้าใจลำดับความสำคัญของรายการได้ดีขึ้นหรือไม่ ทำไมถึงอยู่ที่นั่น? หมายเหตุ: ฉันทำงานกับas a <type of user> I want <some goal>สูตรแล้วและใช้ได้ดี ฉันไม่ได้สังเกตเห็นปัญหาใด ๆ ในการทำงานของฉันโดยใช้รูปแบบนี้ซึ่งสั้นกว่า

10 user-story 

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

10 agile  scrum  team  user-story 

ฉันอยู่ในขั้นตอนการกำหนดขอบเขตและประเมินโครงการพัฒนาซอฟต์แวร์ใหม่ที่ค่อนข้างเล็ก ฉันเคยผ่านเรื่องราวของผู้ใช้ที่ลูกค้าแนะนำและวางภาระงานให้กับแต่ละคนโดยมีการประเมินและบันทึกย่อสั้น ๆ เกี่ยวกับวิธีการทำงานให้สำเร็จ มีเกณฑ์การยอมรับ ทุกคนควรจะดีกับโลก เมื่อดูงานที่ฉันวางแผนไว้ฉันก็รู้ว่ามีบางอย่างขาดหายไป จะมีค่าใช้จ่ายเริ่มต้นเพียงแค่ตั้งค่าสิ่งต่าง ๆ ที่เราสามารถใช้งานได้ สิ่งที่เป็นของเรื่องราวของผู้ใช้ทั้งหมดไม่ใช่เรื่องราวของผู้ใช้หนึ่งราย ตัวอย่างเช่นส่วนหนึ่งของแอปพลิเคชันนี้เป็นบริการที่แยกวิเคราะห์ XML จากมุมมองของผู้ใช้จะมีเรื่องราวเฉพาะที่ต้องทำสิ่งต่าง ๆ โดยขึ้นอยู่กับเนื้อหาของ XML การเขียนโปรแกรมวิเคราะห์คำ XML จริง ๆ - บิตที่มองหาไฟล์อ่านและดึงข้อมูลที่เกี่ยวข้องออกมาก่อนตัดสินใจว่าจะทำอย่างไรกับเนื้อหา - เป็นส่วนหนึ่งของเรื่องราวเหล่านั้นทั้งหมด เช่นเดียวกับการห่อไว้ในบริการ windows พร้อมกับตัวติดตั้ง ฯลฯ มันเป็นงานที่นักพัฒนาเป็นศูนย์กลางโดยไม่เกี่ยวข้องโดยตรงกับผู้ใช้ อีกตัวอย่างที่เกี่ยวข้องจากแอปพลิเคชันนี้คือการรับและการเขียนบล็อกของรหัสดั้งเดิมที่ไม่ดีซึ่งมีประโยชน์ต่อการทำงานของแอพนี้ อีกครั้งสิ่งนี้ไม่มีผลลัพธ์ทันทีสำหรับผู้ใช้ แต่เป็นงานที่จำเป็น การวางแผนและการดำเนินการของงานนี้ "สด" ในแผนโครงการเน้นเรื่องราวของผู้ใช้ที่ไหน ฉันเคยเห็นผู้คนแก้ปัญหานี้ด้วยการเขียนเรื่องราวของผู้ใช้ "ในฐานะนักพัฒนาฉันต้องการ ... " แต่ดังที่ได้มีการพูดคุยกันที่นี่ไม่ใช่เรื่องของผู้ใช้ มันเป็นหนึ่งในนักพัฒนา ฉันกำลังหาคำตอบที่เป็นรูปธรรมสำหรับสิ่งนี้เพื่อช่วยฉัน (และคนอื่น ๆ ) ในการวางแผนโครงการโดยใช้กรอบการจัดการที่เข้มงวดเช่น TFS ออนไลน์ สิ่งเหล่านี้ไม่มีแนวโน้มที่จะมีหน้าที่จัดทำ …

9 agile  team-foundation-server  planning  user-story 

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

9 agile  project-management  user-story  requirements-management  jira 

วิธีเปรียวคือการจัดโครงสร้างการทำงานลงไปในเรื่องที่ผู้ใช้แนวตั้งและส่งมอบที่มุ่งเน้น แต่การทำงานอย่างเต็มที่ชิ้นส่วนของแอพลิเคชันจากแบบ end-to-end เพราะนี่เป็นวิธีการใหม่ในการสร้างซอฟต์แวร์ฉันอ่านวรรณกรรมมากมายเกี่ยวกับสาเหตุที่ดีกว่าเรื่องแนวนอน แต่ฉันไม่พบข้อเสียของวิธีนี้มากนัก ฉันได้ดื่มเครื่องช่วยเย็นที่คล่องแคล่วและฉันก็ยอมรับด้วยว่าการหั่นเค้กในแนวดิ่งนั้นมีข้อดีมากกว่าการหั่นตามแนวนอน นี่คือรายการข้อเสียสั้น ๆ ที่ฉันจะได้รับ: นักพัฒนาอาจเริ่มช้าลงในการใช้งานคุณสมบัติเนื่องจากเขา / เธอต้องเข้าใจเทคโนโลยีทั้งหมดที่จำเป็นในการพัฒนาเรื่องราว (UI + บริการเลเยอร์ + การเข้าถึงข้อมูล + เครือข่าย ฯลฯ ... ) การออกแบบสถาปัตยกรรมโดยรวม (การสร้างกระดูกสันหลังของแอปพลิเคชัน) ไม่เหมาะกับมนต์นี้ (แต่บางคนอาจแย้งว่ามันเป็นส่วนหนึ่งของเรื่องราวของผู้ใช้ในการพัฒนา / เปลี่ยนสถาปัตยกรรมโดยรวม) อะไรคือข้อเสียเพิ่มเติมของการแบ่งเรื่องราวของผู้ใช้ในแนวตั้ง? หมายเหตุ: เหตุผลที่ฉันถามคำถามนี้ในตอนนี้ก็เพราะฉันจะพยายามโน้มน้าวให้ทีมงานเริ่มเขียนเรื่อง 'แนวตั้ง' และฉันต้องการที่จะนำการแลกเปลี่ยนที่เป็นไปได้ล่วงหน้าเพื่อให้พวกเขาชนะ พิจารณาถึงความล้มเหลวเมื่อต้องเผชิญกับข้อบกพร่อง

9 agile  user-story 

ฉันกำลังจะเริ่มโครงการที่จะเกี่ยวข้องกับการพัฒนาต้นแบบแอปมือถือดั้งเดิม (iOS และ Android ในตอนแรก) รวมถึงส่วนติดต่อผู้ดูแลระบบบนเว็บและ API สำหรับแอปเหล่านี้เพื่อสื่อสารกับ เรามีรายการเรื่องราวที่ร่างขึ้นแล้ว แต่มีหลายเรื่องที่อยู่ในรูปแบบ: As a mobile user I want to be able to view a login screen so that I can sign into the app หากนี่เป็นเป้าหมายสำหรับแพลตฟอร์มเดียวฉันจะไม่เห็นปัญหา อย่างไรก็ตามเนื่องจากเรากำหนดเป้าหมายหลายแพลตฟอร์มฉันไม่แน่ใจว่าสิ่งเหล่านี้ควรทำซ้ำเช่น "ในฐานะผู้ใช้ Android" หรือคล้ายกัน ดูเหมือนว่าจะซ้ำกัน แต่มันเป็นงานที่จะต้องทำให้เสร็จสิ้นแยกต่างหากสำหรับแต่ละแพลตฟอร์ม นี่เป็นโครงการมือถือครั้งแรกที่เราให้กำเนิดก่อนหน้านี้คือ Phonegap และเรารวบรวมเรื่องราวทั้งหมดใน "เป็นผู้ใช้มือถือ" เนื่องจากโดยพื้นฐานแล้วนี่เป็นแอปบนเว็บที่มีโค้ดเนมซึ่งไม่ได้มีปัญหามากนัก แต่ฉันก็ทราบว่าแอพที่เป็นภาษาพื้นเมืองทั้งหมดเป็น ballgame ที่แตกต่างกัน!

9 agile  mobile  user-story 

เราวางแผนที่จะนำเรื่องราวของผู้ใช้ไปใช้เพื่อจับภาพ 'เจตนา' ของผู้มีส่วนได้ส่วนเสียในรูปแบบที่มีน้ำหนักเบามากกว่า SRS ที่หนักหน่วง (ข้อกำหนดคุณสมบัติซอฟต์แวร์) อย่างไรก็ตามดูเหมือนว่าแม้ว่าพวกเขาจะเข้าใจคุณค่าของเรื่องราว แต่ก็ยังมีความปรารถนาที่จะ 'เปลี่ยน' เรื่องราวให้เป็นภาษาที่เหมือน SRS ด้วยคุณลักษณะทั้งหมดลำดับความสำคัญอินพุตอินพุตเอาต์พุตแหล่งปลายทาง ฯลฯ เรื่องราวของผู้ใช้ 'กำจัด' ความต้องการ SRS ที่เป็นทางการอย่างเช่นสิ่งประดิษฐ์ที่จะเริ่มต้นด้วยดังนั้นอะไรคือจุดที่มี SRS ฉันจะโน้มน้าวทีมของฉันได้อย่างไร (ซึ่งเป็นกลุ่ม CS ที่มีคุณสมบัติตามที่ต้องการ - ทั้งจากการศึกษาและการปฏิบัติ) ที่ SRS จะ 'ถูกกำจัด' ถ้าเรานำเรื่องเล่าของผู้ใช้มาใช้เพื่อจับความต้องการการทำงานของระบบ (สามารถบันทึก NFRs และอื่น ๆ ได้เช่นกัน แต่นั่นไม่ใช่จุดประสงค์ของคำถาม) ดังนั้นนี่คืออาร์กิวเมนต์ 'ขั้นตอนการทำงาน' ของฉัน: จับภาพความต้องการเริ่มต้นเป็นเรื่องราวของผู้ใช้และอธิบายรายละเอียดภายหลังเพื่อใช้กรณี (ซึ่งจะต้องมีการบันทึกไว้ในระดับต่ำเช่นอธิบายการโต้ตอบกับต้นแบบ UI / mockups และโพสต์ที่ส่งมอบได้ การใช้งาน) ดังนั้นจะเปลี่ยนจากเรื่องราวของผู้ใช้เป็นกรณีใช้มากกว่าเรื่องราวของผู้ใช้ไปยัง SRS ไปยังกรณีใช้งาน ตอนนี้คุณเป็นอย่างไรบ้างที่จะรวบรวมเรื่องราวของผู้ใช้ในที่ทำงานของคุณ …

9 agile  requirements  user-story  requirements-management 

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

9 scrum  user-story 

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

9 agile  scrum  productivity  user-story