คำถามติดแท็ก sprint

หนังสือและบทความการต่อสู้จำนวนมากบอกว่าการวิ่งล้มเหลว (เมื่อทีมไม่สามารถทำคุณสมบัติบางอย่างจาก Sprint Backlog) ไม่ใช่สิ่งที่เลวร้ายมันเกิดขึ้นเป็นครั้งคราวและมันจะมีประโยชน์จริง ๆ ถ้าทีมเรียนรู้จากความผิดพลาดของพวกเขา และปรับปรุงบางสิ่งบางอย่างในการวิ่งดังต่อไปนี้ และทีมงานไม่ควรถูกลงโทษเนื่องจากไม่ได้ทำงานให้สำเร็จ สิ่งนี้ดูดีมากจากมุมมองของนักพัฒนา แต่สมมุติว่าเรามี บริษัท ซอฟต์แวร์ " Scrum-Addicts LLC " กำลังพัฒนาบางสิ่งสำหรับลูกค้าที่จริงจัง (" Money-Bags Corporation "): ผู้จัดการของ Scrum-Addicts แนะนำให้สร้างชิ้นส่วนของซอฟต์แวร์สำหรับ Money-Bags พวกเขาตกลงในรายการคุณสมบัติและ Money-Bags ขอให้ระบุวันที่จัดส่ง ผู้จัดการ Scrum-Addicts ปรึกษาทีมการต่อสู้ของพวกเขาและทีมบอกว่าจะใช้เวลา 3 สัปดาห์ในการเร่งความเร็วเพื่อให้คุณสมบัติทั้งหมดเสร็จสมบูรณ์ ผู้จัดการ Scrum-Addicts เพิ่ม 1 สัปดาห์เพื่อความปลอดภัยสัญญาส่งซอฟต์แวร์ใน 1 เดือนและเซ็นสัญญากับ Money-Bags หลังจาก 4 sprints (กำหนดส่งพัสดุ) ทีมการต่อสู้สามารถส่งมอบคุณลักษณะ 80% เท่านั้น (เนื่องจากไม่มีประสบการณ์กับระบบใหม่จำเป็นต้องแก้ไขข้อบกพร่องที่สำคัญในคุณลักษณะก่อนหน้านี้ในสภาพแวดล้อมการผลิต …

80 agile  scrum  sprint 

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

51 agile  scrum  sprint  meetings  process-improvement 

ฉันทำงานกับรหัสฐานที่มีโค้ดมากกว่า 500K บรรทัด มันเป็นความต้องการที่จริงจังในการ refactoring มีการพยายามปรับโครงสร้างใหม่ที่ระบุว่าจะใช้เวลานานกว่าการวิ่งสองสัปดาห์ปกติ สิ่งเหล่านี้ไม่สามารถแยกย่อยเป็นงานเล็ก ๆ อย่างที่ฉันเห็นในคำตอบอื่น ๆ ในเว็บไซต์นี้ ผลิตภัณฑ์จำเป็นต้องทำงานในตอนท้ายของการทำซ้ำและการรีแฟคเตอร์บางส่วนจะทำให้ระบบอยู่ในสถานะใช้งานไม่ได้เนื่องจากการพึ่งพาระหว่างไอเท็มนั้นแย่มาก ดังนั้นวิธีที่ดีที่สุดในการเข้าถึงอุปสรรค์นี้คืออะไร? อีกครั้งฉันพูดถึงการแบ่งมันเป็นชิ้นเล็ก ๆ ไม่ใช่ตัวเลือกที่ได้ทำไปแล้ว อัปเดต: ผู้คนดูเหมือนจะต้องการคำอธิบายว่าทำไมสิ่งนี้ถึงไม่เหมาะกับการวิ่ง 2 สัปดาห์ มีส่วนร่วมในการวิ่งมากกว่าแค่การเขียนโค้ด เรามีนโยบายที่ไม่มีรหัสหากไม่มีการทดสอบ นโยบายนั้นไม่ได้มีอยู่เสมอและส่วนใหญ่ของ codebase ไม่มีอยู่ นอกจากนี้การทดสอบการรวมบางส่วนของเรายังเป็นการทดสอบด้วยตนเอง ปัญหาไม่ได้อยู่ที่การปรับโครงสร้างใหม่นั้นใหญ่มาก มันเป็นความจริงที่ว่าการเปลี่ยนแปลงเล็กน้อยมีผลกระทบกับหลาย ๆ ส่วนของระบบและเราต้องมั่นใจว่าชิ้นส่วนเหล่านั้นยังคงทำงานได้อย่างถูกต้อง เราไม่สามารถชะลอหรือขยาย sprint ได้เนื่องจากเรามีโปรแกรมแก้ไขด่วนรายเดือน ดังนั้นการเปลี่ยนแปลงนี้ขยายผ่าน sprint ไม่สามารถหยุดงานอื่น ๆ ที่ถูกเพิ่มลงในโปรแกรมแก้ไขด่วน Refactoring vs Redesign: เพียงเพราะกระบวนการพัฒนาของเราไม่ได้มีประสิทธิภาพเพียงพอที่จะจัดการ refactoring นี้ในรอบสองสัปดาห์ไม่รับประกันว่าจะเปลี่ยนชื่อเป็นการออกแบบใหม่ ฉันอยากจะเชื่อว่าในอนาคตเราสามารถทำงานเดียวกันให้สำเร็จภายในสองสัปดาห์เมื่อกระบวนการของเราดีขึ้น รหัสที่เป็นปัญหาที่นี่ไม่ต้องเปลี่ยนในเวลานานมากและค่อนข้างมีเสถียรภาพ ตอนนี้เมื่อทิศทางของ บริษัท ปรับเปลี่ยนได้มากขึ้นเราต้องการให้ส่วนฐานของโค้ดนี้สามารถปรับเปลี่ยนได้เหมือนกับส่วนที่เหลือ ซึ่งต้องมีการปรับสภาพใหม่ …

49 refactoring  sprint 

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

33 agile  scrum  sprint 

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

18 scrum  sprint 

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

14 agile  scrum  planning  sprint 

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

14 scrum  user-story  sprint  scrum-master 

เมื่อเร็ว ๆ นี้ฉันได้อ่านเกี่ยวกับการต่อสู้หลายครั้งและฉันพบว่าสิ่งที่ฉันดูเหมือนจะเป็นข้อมูลที่ขัดแย้งกันไม่ว่าจะเป็นการดีหรือไม่ที่จะเปลี่ยนงานค้างในระหว่างการวิ่ง บทความวิกิพีเดียในการต่อสู้บอกว่ามันไม่ได้ตกลงต่างๆและบทความอื่น ๆ ที่พูดแบบนี้เช่นกัน อาจารย์สอนการพัฒนาซอฟต์แวร์ของฉันก็สอนเรื่องเดียวกันในภาพรวมของการต่อสู้ อย่างไรก็ตามฉันอ่านScrum และ XP จาก Trenchesและอธิบายส่วนของรายการที่ไม่ได้วางแผนไว้บน taskboard ดังนั้นฉันจึงค้นหาScrum Guideและมันบอกว่าในระหว่างการวิ่ง "ไม่มีการเปลี่ยนแปลงใด ๆ ที่จะส่งผลกระทบต่อเป้าหมาย Sprint" และในการอภิปรายของเป้าหมาย Sprint "หากงานนั้นแตกต่างจากที่คาดการณ์ไว้ทีมพัฒนา จากนั้นพวกเขาก็ร่วมมือกับเจ้าของผลิตภัณฑ์เพื่อเจรจาขอบเขตของ Sprint Backlog ภายใน Sprint " มันจะพูดในการสนทนาของ Sprint Backlog: Sprint Backlog เป็นแผนที่มีรายละเอียดเพียงพอที่สามารถเข้าใจการเปลี่ยนแปลงในความคืบหน้าใน Daily Scrum ทีมพัฒนาปรับเปลี่ยน Sprint Backlog ตลอด Sprint และ Sprint Backlog ปรากฏในระหว่าง Sprint การเกิดขึ้นนี้เกิดขึ้นเมื่อทีมพัฒนาทำงานผ่านแผนและเรียนรู้เพิ่มเติมเกี่ยวกับงานที่จำเป็นเพื่อให้บรรลุเป้าหมาย Sprint เมื่อจำเป็นต้องมีงานใหม่ทีมพัฒนาจะเพิ่มเข้าไปใน Sprint …

14 scrum  sprint  product-backlog 

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน6 ปีที่ผ่านมา เครื่องมือการจัดการซอฟต์แวร์ Scrum บางตัวให้ตัวเลือกนี้แก่คุณเพื่อระบุชื่อ sprints ของคุณอย่างชัดเจน คุณมีวิธีที่ดีที่สุดในการตั้งชื่อ sprints ของคุณหรือคุณแค่ใช้รูปแบบง่ายๆเช่น 1, 2, 3, ... ?

13 scrum  sprint 

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

12 agile  sprint 

ฉันอยู่ในทีมโปรเจคที่มี 4 devs ฉันรวมอยู่ด้วย เราได้มีการพูดคุยกันอย่างยาวนานเกี่ยวกับวิธีจัดการกับงานพิเศษที่เกิดขึ้นในรายการงานชิ้นเดียว งานพิเศษนี้มักจะเป็นสิ่งที่เกี่ยวข้องกับงานเล็กน้อย แต่ไม่จำเป็นเสมอไปที่จะบรรลุเป้าหมายของรายการ (อาจเป็นความเห็น) ตัวอย่างรวมถึง แต่ไม่ จำกัด เฉพาะ: refactoring ของรหัสการเปลี่ยนแปลงโดยรายการงาน refactoring code ที่อยู่ใกล้เคียงรหัสที่ถูกเปลี่ยนแปลงโดยรายการ ออกแบบพื้นที่โค้ดขนาดใหญ่รอบตั๋วอีกครั้ง ตัวอย่างเช่นหากรายการที่คุณเปลี่ยนฟังก์ชั่นเดียวคุณรู้ว่าตอนนี้ทั้งคลาสสามารถทำซ้ำได้เพื่อให้รองรับการเปลี่ยนแปลงนี้ได้ดียิ่งขึ้น ปรับปรุง UI บนแบบฟอร์มที่คุณเพิ่งแก้ไข เมื่องานพิเศษนี้เล็กเราไม่รังเกียจ ปัญหาคือเมื่องานพิเศษนี้ทำให้ส่วนขยายของรายการเกินกว่าการประมาณจุดคุณลักษณะดั้งเดิม บางครั้งรายการ 5 คะแนนจะใช้เวลา 13 คะแนน ในกรณีหนึ่งเรามีรายการ 13 จุดที่ในการหวนกลับอาจมี 80 คะแนนหรือมากกว่า ในการสนทนาของเรามีสองทางเลือกสำหรับวิธีจัดการกับปัญหานี้ เราสามารถรับงานพิเศษในรายการงานเดียวกันและเขียนออกเป็นการประเมินที่ผิดพลาด อาร์กิวเมนต์สำหรับสิ่งนี้ได้รวม: เราวางแผนสำหรับ "การเติมเต็ม" ในตอนท้ายของการวิ่งเพื่ออธิบายสิ่งนี้ ปล่อยให้รหัสอยู่ในรูปที่ดีกว่าที่คุณพบเสมอ อย่าเช็คอินงานครึ่งทาง หากเราออกจากการปรับโครงสร้างใหม่ในภายหลังมันยากที่จะกำหนดเวลาและอาจไม่เสร็จสิ้น คุณอยู่ใน "บริบท" ทางจิตใจที่ดีที่สุดในการจัดการงานนี้ในขณะนี้เนื่องจากคุณอยู่ลึกเข้าไปในรหัสแล้ว ดีกว่าที่จะนำมันออกไปให้พ้นทางและมีประสิทธิภาพมากกว่าที่จะเสียบริบทนั้นไปเมื่อคุณกลับมาในภายหลัง เราวาดเส้นสำหรับไอเท็มงานปัจจุบันและบอกว่างานพิเศษเข้าสู่ตั๋วแยกต่างหาก ข้อโต้แย้งรวมถึง: การมีตั๋วแยกต่างหากช่วยให้การประเมินใหม่ดังนั้นเราจึงไม่โกหกตัวเองเกี่ยวกับจำนวนของสิ่งที่เป็นจริงหรือต้องยอมรับว่าการประเมินทั้งหมดของเรานั้นแย่มาก …

12 agile  refactoring  estimation  sprint 

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

11 scrum  sprint 

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

11 scrum  user-story  sprint 

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

11 agile  scrum  sprint 

เรากำลังพัฒนาซอฟต์แวร์ที่คล่องตัวโดยทั่วไปติดตาม Scrum เราพยายามที่จะแสดงความคิดเห็นโดยวิ่ง แต่พบว่ามันยาก ซอฟต์แวร์ของเราทำการประมวลผลข้อมูลจำนวนมากและเรื่องราวมักเกี่ยวกับการเปลี่ยนแปลงกฎระเบียบต่างๆ มีตัวเลือกอะไรบ้างสำหรับการสาธิตการเปลี่ยนแปลงที่เกิดขึ้นใน sprint เมื่อไม่มี UI หรือการเปลี่ยนแปลงเวิร์กโฟลว์ที่มองเห็นได้ แต่การเปลี่ยนแปลงนั้นเป็นกฎทางธุรกิจที่ละเอียดอ่อนในงานประมวลผลที่ใช้เวลา 10 วินาทีหรือแม้กระทั่งสองสามชั่วโมง ?

10 agile  scrum  sprint