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

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

51 agile  scrum  sprint  meetings  process-improvement 

เราใช้ Scrum และบางครั้งพบว่าเราไม่สามารถทำเรื่องราวของผู้ใช้ให้จบได้ในการวิ่งที่วางแผนไว้ ในรูปแบบการต่อสู้ที่แท้จริงเราจัดส่งซอฟต์แวร์ต่อไปและพิจารณารวมเรื่องของผู้ใช้ในการวิ่งครั้งต่อไปในช่วงการวางแผน Sprint ถัดไป เนื่องจากเรื่องราวของผู้ใช้ที่เรากำลังดำเนินการอยู่นั้นเสร็จสมบูรณ์บางส่วนเราจะประเมินได้อย่างถูกต้องในเซสชันการวางแผน Sprint ครั้งถัดไปอย่างไร เราได้พิจารณาแล้ว: a) การปรับจำนวนคะแนนสตอรี่ลงเพื่อแสดงเฉพาะงานที่ยังคงทำให้เรื่องราวของผู้ใช้เสร็จสมบูรณ์ น่าเสียดายที่สิ่งนี้จะทำให้การรายงาน Backlog ผลิตภัณฑ์ล้มเหลว b) ปิดเรื่องราวของผู้ใช้ที่เสร็จสมบูรณ์บางส่วนและเพิ่มใหม่เพื่อใช้งานคุณสมบัติที่เหลือซึ่งจะมีคะแนนเรื่องราวน้อยลง สิ่งนี้จะส่งผลต่อความสามารถในการมองย้อนกลับไปในสิ่งที่เราไม่ได้ทำในการวิ่งครั้งนั้นและดูเหมือนจะใช้เวลานาน c) ไม่ต้องกังวลกับ a หรือ b และคาดเดาต่อไปในระหว่างการวางแผน Sprint ว่าสิ่งต่าง ๆ เช่น "เรื่องราวของผู้ใช้อาจเป็นจุดเรื่องราว X แต่ฉันรู้ว่ามันเสร็จ 95% ดังนั้นฉันแน่ใจว่าเราสามารถใส่ได้"

50 agile  scrum  estimation  planning 

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

50 agile  scrum  bug  user-story 

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

48 unit-testing  scrum  tdd 

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

43 agile  project-management  scrum  government 

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

42 agile  scrum  branching  stories 

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

42 design  architecture  agile  scrum  team-leader 

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

41 agile  terminology  scrum 

ฉันเป็นแฟนตัวยงของการพัฒนาที่คล่องตัวและใช้ XP ในโครงการที่ประสบความสำเร็จอย่างมากไม่กี่ปีที่ผ่านมา ฉันรักทุกอย่างเกี่ยวกับมันแนวทางการพัฒนาแบบวนซ้ำเขียนโค้ดเกี่ยวกับการทดสอบการเขียนโปรแกรมคู่การมีลูกค้าบนไซต์เพื่อดำเนินการต่างๆ มันเป็นสภาพแวดล้อมการทำงานที่มีประสิทธิผลสูงและฉันไม่เคยรู้สึกเหมือนถูกกดดัน อย่างไรก็ตามสถานที่ไม่กี่แห่งสุดท้ายที่ฉันใช้ Scrum ใช้แล้วใช้งานได้ ฉันรู้ว่ามันเป็นเด็กโปสเตอร์เพื่อการพัฒนาที่คล่องตัว แต่ฉันไม่เชื่อ 100% ว่าเป็นคนคล่องแคล่ว ด้านล่างนี้เป็นสาเหตุหลักสองข้อที่ทำให้ฉันไม่รู้สึกว่องไว ผู้จัดการโครงการรักมัน ผู้จัดการโครงการผู้ซึ่งหลงไหลตามกำหนดเวลาของพวกเขาดูเหมือนจะรักสกัล จากประสบการณ์ของฉันพวกเขาดูเหมือนจะใช้ Sprint Backlog เป็นเครื่องมือในการติดตามความต้องการของเวลาและเก็บบันทึกจำนวนเวลาที่ใช้ไปกับภารกิจที่กำหนด แทนที่จะใช้ไวท์บอร์ดพวกเขาทั้งหมดใช้แผ่น excel ซึ่งนักพัฒนาแต่ละคนจะต้องกรอกอย่างเคร่งครัด ในความคิดของฉันนี่เป็นวิธีการติดตามเอกสาร / เวลามากเกินไปสำหรับกระบวนการที่คล่องตัว เหตุใดฉันจึงต้องเสียเวลาในการประเมินว่างานจะใช้เวลานานแค่ไหนเมื่อฉันสามารถทำได้ด้วยตัวเอง หรือในทำนองเดียวกันว่าทำไมฉันถึงต้องเสียเวลาในการจัดทำเอกสารว่าต้องใช้เวลานานแค่ไหนเมื่อฉันสามารถย้ายไปยังงานต่อไปได้ การประชุมที่ยอดเยี่ยม การประชุมที่โดดเด่นในสถานที่ก่อนหน้านี้ที่ฉันทำงานนั้นเป็นฝันร้าย ทุกวันเราต้องอธิบายสิ่งที่เราทำเมื่อวานนี้และสิ่งที่เราจะทำในวันนั้น ถ้าเราไปในเวลา "ประเมิน" ของเราสำหรับงานผู้จัดการโครงการจะเตะเหม็นและอ้างอิง Sprint Backlog เป็นวิธีการแสดงความสามารถที่คุณไม่ได้ปฏิบัติตามระยะเวลา ตอนนี้ฉันเข้าใจความต้องการในการสื่อสาร แต่แน่นอนว่าการประชุมประจำวันควรมีความเบิกบานใจและมุ่งเน้นไปที่การแบ่งปันความรู้ ฉันไม่คิดว่ามันจะกลายเป็นสไตล์การทำการบ้านของคุณ แน่นอนว่าจุดของความคล่องตัวก็คือไทม์ไลน์เปลี่ยนไปพวกเขาไม่ควรถูกวางไว้ในหิน ข้อสรุป แนวคิดของความคล่องตัวคือการทำให้ซอฟต์แวร์ดีขึ้นโดยทำให้นักพัฒนาซอฟต์แวร์มีชีวิตที่ง่าย ดังนั้นในความคิดของฉันกระบวนการใด ๆ เปรียวที่ใช้โดยทีมงานควรเป็นผู้นำ ฉันไม่คิดว่าการมีผู้จัดการโครงการใช้กระบวนการที่พวกเขาระบุว่า "เปรียว" เพื่อติดตามโครงการมีส่วนเกี่ยวข้องกับการพัฒนาที่คล่องตัว คิดว่าทุกคน?

41 agile  scrum 

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

40 agile  scrum  scrum-master 

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

40 project-management  scrum  meetings 

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

40 agile  scrum  meetings  development-methodologies 

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

33 agile  scrum  sprint 

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

33 scrum  planning 

เรามีทีม SCRUM "ทั่วไป" และเรามุ่งมั่นที่จะทำงานเพื่อการวิ่งและยังคงมีงานในมือ เมื่อเร็ว ๆ นี้เราประสบปัญหาในการพยายามรวม / จัดการกับงานของนักพัฒนาที่ประสบผลสำเร็จมากเกินไปในการทำงานนอกกลุ่ม (เลือกที่จะทำงานนอกเวลาทำงานปกติ / การวิ่ง) เพื่อยกตัวอย่างถ้าทีมงานใช้ 50 คะแนนในการทำงานสมมติว่าพวกเขาจะทำงานทั้งหมดให้เสร็จภายในกรอบ SCRUM ในตอนท้ายของการวิ่งและพวกเขาและ บริษัท มีความสุข หนึ่งในสมาชิกในทีมตัดสินใจที่จะทำงานด้วยตัวเองในรายการที่ค้างในเวลาว่างของตัวเอง พวกเขาไม่ได้ตรวจสอบในงานนี้ แต่แทนที่จะบันทึกไว้ (เราใช้ TFS และอยู่ในชั้นวาง) วิธีจัดการกับสิ่งนี้? ปัญหาเล็กน้อย .. ในระหว่างการวิ่งครั้งต่อไปสมาชิกในทีมบอกว่างานเขียนโปรแกรมเสร็จแล้ว 99% และเพียงแค่ต้องการตรวจสอบรหัสและทดสอบ คุณจัดการกับสิ่งนี้ใน SCRUM และวิธีการแบบเปรียวได้อย่างไร ผู้พัฒนารายอื่นบ่นว่าไม่เกี่ยวข้องกับการตัดสินใจออกแบบที่เกี่ยวข้องกับเรื่องราวเหล่านี้เนื่องจากงานเสร็จจากวง เจ้าของผลิตภัณฑ์ของเราถูกล่อลวงให้ดึงงาน "ฟรี" นี้และสมาชิกที่ประสบความสำเร็จมีแนวโน้มที่จะทำสิ่งนี้โดยมีจุดประสงค์เพื่อให้ได้คุณสมบัติเพิ่มเติมลงในผลิตภัณฑ์ที่ทีมไม่สามารถทำได้ในการวิ่ง มีมุมมองว่าสิ่งนี้กำลังทำลาย "กระบวนการ" เห็นได้ชัดว่า QA, UI และงานเอกสารยังคงต้องทำในงานนี้ ฉันเห็นการสนทนาจำนวนมากเกี่ยวกับการไม่บังคับให้ทีม SCRUM ทำงานล่วงเวลา แต่สมาชิกในทีมทำงานด้านบนและเกินความคาดหวังที่เกิดขึ้นระหว่างการวางแผนและการดำเนินการวิ่งหรือไม่ ฉันลังเลที่จะปกครองบุคคลนี้และบอกว่าคุณไม่สามารถทำงานพิเศษได้ (เตือนให้หมดกำลังใจ) …

32 agile  scrum  team