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

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

132 agile  scrum  estimation  user-story 

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

124 scrum  planning 

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

109 agile  scrum  scrum-master 

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

108 project-management  scrum  development-process  process  product-owner 

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

103 agile  self-improvement  scrum 

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

89 agile  scrum 

หนังสือและบทความการต่อสู้จำนวนมากบอกว่าการวิ่งล้มเหลว (เมื่อทีมไม่สามารถทำคุณสมบัติบางอย่างจาก 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 

คำถามนี้ได้ทำในหัวของฉันในขณะที่ดังนั้นฉันต้องการถามผู้ที่ปฏิบัติตามเปรียว / ต่อสู้ในสภาพแวดล้อมการพัฒนาของพวกเขา ในที่สุด บริษัท ของฉันได้เริ่มต้นในการผสมผสานการปฏิบัติที่คล่องตัวและเริ่มต้นด้วยทีมนักพัฒนา 4 คนในกลุ่มเปรียวบนพื้นฐานการทดลอง เป็นเวลา 4 เดือนกับการทำซ้ำ 3 ครั้งและพวกเขายังคงทำต่อไปโดยไม่ต้องทำตัวให้คล่องสำหรับพวกเราที่เหลือ เนื่องจากความเชื่อมั่นของผู้บริหารที่จะตอบสนองความต้องการทางธุรกิจด้วยคำขอประเภทแอดฮอพเล็กน้อยจากด้านบน เมื่อเร็ว ๆ นี้ฉันได้พูดคุยกับนักพัฒนาที่เป็นส่วนหนึ่งของความคิดริเริ่มนี้ พวกเขาบอกฉันว่ามันไม่สนุก พวกเขาไม่ได้รับอนุญาตให้พูดคุยกับนักพัฒนาคนอื่นโดย Scrum master ของพวกเขาและไม่ได้รับอนุญาตให้รับสายโทรศัพท์ใด ๆ ในพื้นที่ทำงาน (ซึ่งอาจใช้ได้ในระดับหนึ่ง) ตัวอย่างเช่นถ้าฉันต้องการพูดคุยกับเพื่อนเพื่อเตะที่อยู่ในทีมเปรียวฉันไม่ได้รับอนุญาตหากไม่ได้รับการอนุมัติจากอาจารย์ Scrum; ใครกำลังนั่งถัดจากทีมเปรียว แนวคิดทั้งหมดนี้หรือความคล่องตัวคือการจัดหาสูญญากาศที่สมบูรณ์แบบสำหรับนักพัฒนาที่คล่องตัวจากการหยุดชะงักใด ๆ และเพื่อให้พวกเขาใช้เวลา 6 ชั่วโมงในการผลิตที่ดี เอ่อพวกฉันไม่ใช่กูรูที่คล่องแคล่ว แต่สิ่งที่ฉันได้อ่านเอกสารการเปิดตัวของ Yahoo เปรียวและคล้ายกับองค์กรอื่น ๆ มันทำให้ฉันรู้สึกว่าเปรียวนั้นไม่ถูก ต้องใช้ทรัพยากรและงบประมาณเพื่อปลูกฝังความคล่องตัวในทีมและแก้ไขปัญหาเมื่อพวกเขามาถึงเพื่อนำพวกเขากลับมาในการติดตาม สำหรับผู้เริ่มต้นนั้นจะต้องมีการฝึกอบรมสำหรับนักพัฒนาและผู้ฝึกสอนให้กับผู้จัดการและอื่น ๆ เป็นต้น ... Scrum master ปัจจุบันเป็นผู้จัดการที่ใช้เวลาสองวันในการฝึกอบรมที่ได้รับการจัดการโดยผู้บริหาร ฉันเคยได้ยินในการประชุมว่าแถลงการณ์เปรียวไม่ได้บอกว่าเปรียวไม่ได้ตั้งอยู่ในหินและมีการปรับแต่งแตกต่างกันไปในแต่ละ บริษัท ทุกอย่างฟังดูดีและมีเหตุผล …

80 agile  scrum  methodology 

ทุกสิ่งที่ฉันได้อ่านและค้นคว้ามาจนถึงจุดนี้อธิบายว่า Agile / Scrum ทำงานได้ดีกับทีมประมาณ 4 ถึง 6 คนอาจจะมากกว่านี้ ในร้านค้าปัจจุบันของฉันเรามีนักพัฒนาประมาณ 8 คนหรือมากกว่านั้น แต่ด้วยลักษณะของปริมาณโครงการและจำนวนแผนกที่เราให้การสนับสนุนเราไม่เคยมีคนมากกว่า 1 หรือ 2 คนที่มอบหมายให้กับโครงการที่กำหนด ฉันยังสามารถใช้ Agile / Scrum กับทีมนักพัฒนา 1 หรือ 2 คนได้หรือไม่? ฉันกำลังพยายามทำให้ผู้จัดการของฉันเริ่มทำงานกับวิธีการนี้ แต่ฉันต้องสามารถอธิบายวิธีลดขนาดสำหรับทีมนักพัฒนาขนาดเล็กหรือโน้มน้าวพวกเขาเพื่อให้แน่ใจว่าเราได้สมาชิกเพิ่มขึ้น โครงการ.

63 scrum  methodology  agile 

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

61 agile  project-management  scrum  requirements 

เราเป็นทีมการต่อสู้ของนักพัฒนา 3 คนนักออกแบบ 1 คนต้นแบบการต่อสู้และเจ้าของผลิตภัณฑ์ อย่างไรก็ตามเราไม่มีผู้ทดสอบอย่างเป็นทางการในทีมของเรา ปัญหาที่เกิดขึ้นกับเราเสมอคือการทดสอบแอปพลิเคชันและผ่านการทดสอบและการลบข้อบกพร่องนั้นได้ถูกกำหนดเป็นหนึ่งในเกณฑ์ในการพิจารณา PBI (Product Backlog Item) เช่นเดียวกับที่ทำ แต่ปัญหาคือว่าไม่ว่าเรา (นักพัฒนา 3 คนและนักออกแบบ 1 คน) จะพยายามทดสอบแอปพลิเคชันและใช้งานกรณียังคงมีข้อบกพร่องบางอย่างที่ไม่เห็นและทำลายการนำเสนอของเรา ( กฎหมายของเมอร์ฟี่ ) เพื่อเป็นการแก้ไขเราแนะนำให้ บริษัท ว่าจ้างผู้ทดสอบรายใหม่ ใครบางคนที่ทำหน้าที่ทดสอบและทดสอบเท่านั้น ผู้ทดสอบมืออาชีพอย่างเป็นทางการ อย่างไรก็ตามปัญหาคือว่าการต่อสู้หลักและผู้มีส่วนได้เสียเชื่อว่านักพัฒนา (หรือนักออกแบบ) ควรเป็นผู้ทดสอบ ถูกต้องหรือไม่ เราควรพัฒนา (หรือผู้ออกแบบ) ด้วยเช่นกัน?

60 testing  scrum 

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

56 agile  development-process  scrum 

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

55 agile  scrum  methodology  culture 

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

52 agile  scrum 

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

52 agile  project-management  scrum  development-process