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

ฉันกำลังศึกษาวิธีการที่จะเข้าใจได้ดีขึ้นว่าเวิร์กโฟลว์การรวมต่อเนื่องนั้นเหมาะกับ บริษัท พัฒนาซอฟต์แวร์ด้วยวิธีการแย่งชิงกันอย่างไร ฉันกำลังคิดเช่นนี้: นั่นจะเป็นขั้นตอนการทำงานที่ดีหรือไม่?

16 testing  development-process  scrum  continuous-integration  workflows 

จากประสบการณ์ของคุณการประชุม Sprint Planning ควรจะนานเท่าไร 8 ชั่วโมง? หรือควรสั้นลง (กระชับ) และควรมีการวางแผนการสนทนาเพิ่มเติมในฐานะส่วนหนึ่งของการวิ่ง Sprints ของเรามีความยาว 10 วัน

16 agile  scrum  planning 

ฉันแน่ใจว่านี่ไม่ใช่เรื่องแปลก เรามีทีมการต่อสู้สองทีมที่ทำงานได้ดีในการประเมินเรื่องราวของผู้ใช้โดยใช้จุดเรื่องราว (กลุ่มดาวในทีมปัจจุบันมีอายุประมาณ 8 เดือนเท่านั้นแม้ว่าสมาชิกในทีมจะมีประสบการณ์การต่อสู้หลายปี) แต่มันยากสำหรับส่วนธุรกิจของ บริษัท ที่เกี่ยวข้องกับเรื่องราวของผู้ใช้ พวกเขาต้องการหน่วยเวลาจริง (หรือ "สูตรในการแปลงคะแนนเรื่องราวเป็นชั่วโมง") เพื่อให้พวกเขาสามารถวางแผนได้ว่าเมื่อใดที่สิ่งต่างๆจะพร้อม ( "เราจำเป็นต้องรู้เมื่อเราสามารถบอกลูกค้าได้ว่า Feature X จะอยู่ในการผลิต " ) ฉันและผู้นำการต่อสู้ของฉันได้อธิบายว่า "ไม่มีความสัมพันธ์ที่ชัดเจนระหว่างจุดเรื่องราวและเวลาที่เกิดขึ้นจริง" และ "จุดเรื่องราวใช้เพื่อกำหนดจำนวนทีมที่สามารถวิ่งได้" และฉัน คุณสามารถเดาได้ว่าพวกเขาพึงพอใจแค่ไหนกับคำตอบนั้น พวกเขายังต้องการทราบตามเวลาในปฏิทินเมื่อเราจะไปที่เรื่องราวผู้ใช้ครั้งที่ 27 ใน Backlog ไม่ว่าในกรณีใดฉันได้รวบรวมสถิติบางส่วนและการประเมิน SP ของเราแปลเป็นผลลัพธ์ที่ใช้เวลาจริงที่แตกต่างกันอย่างดุเดือด (วัดโดยซอฟต์แวร์ scrum board ของเราซึ่งติดตามจำนวนตั๋วที่ใช้ในคอลัมน์ "กำลังทำงาน" ) สำหรับเรื่องราวของผู้ใช้ 1-SP นั้นแน่นอนว่ามีอคติอย่างหนักในช่วงเวลาสั้น ๆ (โดยมีการระเบิดขึ้นเป็นครั้งคราว) แต่โดยเฉพาะอย่างยิ่งสำหรับเรื่องราว 2-SP พวกเขาอยู่ทั่วทุกที่: มีปัจจัย 20 ระหว่างความสำเร็จ "เร็วที่สุด" …

15 scrum  estimation 

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

15 agile  scrum  planning 

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

15 agile  scrum 

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

15 scrum  compiler  porting 

ปัจจุบันฉันทำงานร่วมกับอาจารย์ที่มหาวิทยาลัยของฉันเพื่อพัฒนาหลักสูตรใหม่สำหรับหลักสูตรวิศวกรรมซอฟต์แวร์และการออกแบบ Capstone ที่เปิดสอนในวิทยาลัยของฉัน จนกระทั่งเมื่อไม่นานมานี้ทั้งสองหลักสูตรใช้โมเดลน้ำตกโดยเฉพาะและทำให้นักเรียนใช้เวลาส่วนใหญ่ในการเขียนรายงานยาว ๆ หลังจากแรงกดดันจากฉันมากอาจารย์ของฉันตัดสินใจที่จะรวม Scrum ในหลักสูตรวิศวกรรมซอฟต์แวร์ภาคการศึกษาที่ผ่านมานี้ ครึ่งแรกของภาคการศึกษายังคงเป็นน้ำตกมีนักเรียนเขียนรายงานการออกแบบ 40 หน้าและเอกสารข้อกำหนดซอฟต์แวร์ กลางภาคเรียนทุกทีมจะต้องปล่อยตัวอย่างของแอปพลิเคชัน เมื่อถึงจุดนั้นเส้นทางก็เปลี่ยนไปเป็น Scrum พร้อมกับการวิ่ง 3 สัปดาห์สองครั้ง ตอนนี้เรากำลังพยายามหาวิธีกำจัดน้ำตกทั้งหมดและสร้างหลักสูตรที่ใช้การแย่งชิงกันโดยเฉพาะ น่าเสียดายที่เราพบความไม่ลงรอยกันระหว่าง Scrum และนักเรียน: การประชุมการต่อสู้รายวันแทบเป็นไปไม่ได้สำหรับนักเรียน แม้ในระหว่างชั้นเรียนมันไม่สะดวกสำหรับนักเรียนที่จะจัดการประชุม Scrum เนื่องจากอาจารย์มักจะบรรยาย การประมาณคะแนน / ชั่วโมงนั้นยากเนื่องจากนักเรียนไม่มีประสบการณ์ดังนั้นจึงไม่สามารถทำนายได้อย่างแม่นยำว่าจะต้องใช้เวลานานแค่ไหน การต่อสู้ทำงานได้ดีที่สุดกับนักพัฒนาแบบเต็มเวลาที่ทำงานร่วมกัน แต่นักเรียนไม่ใช่ ส่วนใหญ่นักเรียนใช้เวลา 15-20 ชั่วโมงต่อสัปดาห์ในการจัดหลักสูตรและการจัดงานประชุมอาจเป็นเรื่องยากมาก ทีมสามารถมีนักเรียนได้มากถึง 10 คน (และจะมีคนขี้เกียจหนึ่งหรือสองคน) อาจารย์ต้องการเอกสาร! ฉันไม่เคยได้ยินรายงานการแย่งชิงใด ๆ - เพียงแบ็คล็อกและชาร์ตการเผาไหม้ (ซึ่งฉันไม่แน่ใจว่าจะเพียงพอที่จะเอาใจนักวิชาการ) นักเรียนมักคิดว่าเปรียวหมายถึง "กระโดดเข้าและเริ่มเขียนโค้ดโดยไม่หันกลับมามอง" สิ่งนี้นำไปสู่โค้ดที่น่ากลัวที่สุดที่จินตนาการได้ ดังนั้นฉันกำลังมองหาวิธีในการบังคับใช้การออกแบบที่เหมาะสมโดยไม่ต้องใช้เอกสาร 50 หน้าหรือกองของไดอะแกรม UML …

15 agile  scrum  documentation 

ฉันเป็นผู้นำทีมพัฒนาโครงการใหม่ที่ บริษัท ของฉัน นี่เป็นโครงการแรกที่ บริษัท จะใช้การต่อสู้ เรามี SDLC น้ำตก / ซ้ำ BAs เขียนเอกสารความต้องการมอบให้ dev และทดสอบ dev เริ่มพัฒนาและจะปล่อยให้ทดสอบในการทำซ้ำ ผู้ทดสอบใช้เวลานานในการทดสอบรุ่นที่ devs ดำเนินการพัฒนาต่อไป แต่ยังแก้ไขข้อผิดพลาดสำหรับรุ่นปัจจุบัน ฉันมีคำถามสองสามข้อ ในการวิ่งกับพูด 5 เรื่องเมื่อคุณปล่อยให้ทดสอบ? มันเป็นทันทีที่เรื่องราวเสร็จสมบูรณ์โดย dev หรือหลังจากเสร็จสิ้นเรื่องราวทั้งหมด แต่ก่อนสิ้นสุดการวิ่งให้ทดสอบเวลาที่ต้องการในการทดสอบ ถ้า BA เขียนเรื่องราวของผู้ใช้สิ่งที่ควรเป็นรายละเอียด ตามเนื้อผ้าใช้เวลานานในการเขียนข้อมูลจำเพาะด้วยเค้าโครง UI พฤติกรรมข้อความ ฯลฯ ทั้งหมดเพื่อให้ได้ข้อสรุป ฉันเดาคำถามของฉันคือวิธีการเขียนเรื่องราวที่สามารถนำไปปฏิบัติและทดสอบได้ ทีมทดสอบของเราไม่มีเทคนิค การทดสอบ UI อัตโนมัติสำหรับ Scrum มีความสำคัญแค่ไหน UI นั้นใช้ WPF ฉันมีประสบการณ์การพัฒนาที่มั่นคงโดยใช้วิธีการแบบว่องไว (TDD, การตรวจสอบโค้ด, …

15 scrum 

ฉันมีสองประเด็นเกี่ยวกับการต่อสู้ในระบบฝังตัว ขั้นแรกมีงานให้ทำมากมายโดยเฉพาะในช่วงแรกซึ่งไม่สามารถพิสูจน์ได้ เราเริ่มต้นด้วยบอร์ดการพัฒนาไม่มีระบบปฏิบัติการไม่มีจอแสดงผลไม่มีการสื่อสารแบบอนุกรม ฯลฯ เราไม่มีจอแสดงผลของเราสำหรับการวิ่งหกครั้ง การวิ่งสี่ครั้งแรกคือ: ทำให้RTOSทำงานได้ สร้างงานเขียนเครือข่ายและไดรเวอร์แบบอนุกรม การเขียนรูทีนอินเตอร์รัปต์สำหรับปุ่มการสื่อสาร ฯลฯ การเขียนคลาสฐานข้อมูลหลักและวิธีการ การเขียนเมนูดีบักแบบอนุกรม งานเหล่านี้ส่วนใหญ่ไม่เหมาะกับเรื่องราวของผู้ใช้ ในความเป็นจริงอินเทอร์เฟซเดียวในระบบทั้งหมดคือเมนูดีบักอนุกรมซึ่งสร้างขึ้นใน sprint 3 ดังนั้นจึงไม่มีสิ่งใดแสดงให้เห็นในตอนท้ายของการวิ่ง แม้แต่เมนูซีเรียลก็มีไว้สำหรับใช้ภายในและไม่ใช่ผู้ใช้ อย่างไรก็ตามฉันยังต้องการติดตามและจัดการกิจกรรมการพัฒนาเหล่านี้ผ่านทาง Scrum เราลงเอยด้วยการเขียนวลี "เรื่องราวของผู้ใช้" เช่น "ในฐานะนักพัฒนา ... " ซึ่งฉันไม่พอใจกับมัน แต่ในการใช้ Target Process (www.targetprocess.com) ไม่มีแนวคิดของรายการค้างซึ่งเป็น งานหรืองานบ้าน ประการที่สองคุณจัดการกับรุ่นและการทดสอบอย่างไร มันเป็นความเจ็บปวดที่แท้จริงสำหรับเราเพราะผู้ทดสอบไม่มีตัวแก้ไขปัญหาฮาร์ดแวร์ดังนั้นเราจึงต้องสร้างโค้ดเวอร์ชันแฟลชและเขียนลงในบอร์ดการพัฒนาเพื่อทดสอบ ผู้ทดสอบนั้นไม่ได้มีความคมชัดเหมือนนักพัฒนาซอฟต์แวร์และมักต้องการการสนับสนุนมากมายในการทำให้สิ่งต่าง ๆ ทำงานได้ในระยะแรก (รีเซ็ตบอร์ดเชื่อมต่อการสื่อสารแบบอนุกรม ฯลฯ ) หรือแม้กระทั่งในการทำความเข้าใจผลลัพธ์ ในที่สุดเกี่ยวกับคำจำกัดความของการวิ่งไม่สามารถทำให้เสร็จได้จนกว่าเรื่องราวทั้งหมดจะเสร็จสมบูรณ์ เรื่องราวทั้งหมดยังไม่สมบูรณ์จนกว่าจะได้รับการยืนยันจากผู้ทดสอบ ไม่มีทางที่จะหลีกเลี่ยงเวลาของนักพัฒนา "ปล้น" เพื่อมอบให้แก่ผู้ทดสอบ กล่าวอีกนัยหนึ่งถ้าเรื่องราวของผู้ใช้สามคนสุดท้ายในการวิ่งจะใช้เวลาห้าวันในการทดสอบพวกเขาจะต้องถูกเข้ารหัสและหน่วยทดสอบห้าวันก่อนสิ้นสุดการวิ่ง นักพัฒนาควรทำอะไร หยุดทำงาน? …

15 agile  scrum  embedded-systems 

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

15 agile  code-reviews  scrum 

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

15 development-process  agile  scrum 

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

15 agile  scrum  users  iterative-development 

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

14 agile  scrum  planning  sprint 

หากฉันเข้าใจการต่อสู้อย่างถูกต้องนี่คือวิธีที่ฉันพิจารณาว่าทีมของฉันสามารถทำอะไรได้บ้างในการวิ่งครั้งต่อไป: ฉันเฉลี่ยจำนวนคะแนนที่เสร็จสมบูรณ์สำหรับการวิ่งหลายครั้งที่ผ่านมา ปริมาณนี้คือความเร็วเฉลี่ยของเรา การเร่งความเร็วครั้งต่อไปเราจะทำเรื่องหลาย ๆ นี่เป็นค่าเฉลี่ยดังนั้นหากประวัติศาสตร์ซ้ำรอยเดิมการวิ่งนี้มีโอกาส 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