ใน Scrum วิธีจัดการกับความขัดแย้ง / ภาระงานเมื่อสิ้นสุดการวิ่ง

8

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

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

เราพบปัญหา 2 ข้อเมื่อสิ้นสุดการวิ่ง:

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

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

agile scrum

— Vincent Hubert
แหล่งที่มา

7

วลี"การผสานรวมอย่างต่อเนื่อง"เป็นสิ่งสำคัญ

— Robert Harvey

1

การบูรณาการอย่างต่อเนื่องคือสิ่งที่ระบบการรวมระบบทำได้ด้วยตัวเองเมื่อผู้รวมระบบผสานรวมแต่ละอุปกรณ์เข้าด้วยกัน น่าเสียดายที่การตั้งค่าของเราไม่ง่ายเหมือนการตรวจสอบรหัสเราจำเป็นต้องตั้งค่าการเชื่อมต่อทางกายภาพด้วยมอเตอร์และการ์ด I / O และสิ่งที่ไม่ ตรวจสอบให้แน่ใจว่าอุปกรณ์ใหม่ของคุณทำงานในสภาพแวดล้อม CI เป็นงานของตัวเองและนั่นคืองานที่ก่อให้เกิดความขัดแย้ง สิ่งที่น่าสนใจคือการรับสิ่งที่อยู่ในระบบ CI และนำไปใช้กับเครื่องจักรจริงเป็นกระบวนการที่ไม่สำคัญ - พิสูจน์ว่า CI นั้นมีค่า

— Vincent Hubert

2

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

— Thomas Owens

6

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

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

— บ๊อบภารโรง
แหล่งที่มา

2

การแก้ไขข้อบกพร่องเป็นอีกภารกิจหนึ่งที่ทำให้เรายุ่งในตอนท้ายของการวิ่ง

— Sjoerd

5

คุณควรแก้ไขระบบการรวมของคุณเพื่อให้ทีมของคุณสามารถรวมงานของพวกเขาได้ทันทีที่แต่ละงานเสร็จสมบูรณ์แทนที่จะรอการระเบิดครั้งใหญ่ในตอนท้ายของการวิ่ง

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

— Martin Wickman
แหล่งที่มา

2

ที่จริงแล้วการรวมสามารถทำได้บนระบบได้ตลอดเวลา ปัญหาคือไม่มีอะไรที่จะรวมก่อนที่งานจะอยู่ในขั้นตอนการรวมตัวและส่วนใหญ่มาถึงขั้นตอนนั้นใกล้ถึงจุดสิ้นสุดของการวิ่ง

— Vincent Hubert

1

ดูเหมือนว่าคำแนะนำของฉันเกี่ยวกับการทำให้งานของคุณสั้นลงจะช่วยได้ที่นี่ไม่?

— Martin Wickman

4

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

นอกจากนี้คุณอาจต้องการดูทฤษฎีของข้อ จำกัด ( เป้าหมายของ Goldratt ) และดูว่าคุณสามารถวิเคราะห์สาเหตุและสถานที่ที่คุณมีคอขวดรวมเหล่านี้ได้อย่างไร

— Matthew Flynn
แหล่งที่มา

3

เราได้จัดการเรื่องนี้โดยใช้วิธีการ Kanban

เรามีคิวในซอฟต์แวร์การติดตามของเรา (จิรา) ที่มีค่าต่ำสุดและสูงสุด

เราเตรียม 'ตามต้องการ' อาจเป็นสัปดาห์ละครั้งอาจมี 3 ครั้งขึ้นอยู่กับข้อ จำกัด และงานที่ทำ

สิ่งนี้จะช่วยคุณในการทำให้เจ้าของผลิตภัณฑ์มุ่งเน้นไปที่การรักษาคิวของคุณด้วยสิ่งที่ต้องทำมากมายและสามารถลดการจัดการไมโครตั๋วแต่ละใบได้ เพียงจำไว้เสมอว่าการเปลี่ยนแปลงจะต้องใช้เวลา

เรายังคงสาธิตทุก ๆ สองสัปดาห์และเราปล่อยรายสัปดาห์

— Michael Durrant
แหล่งที่มา

2

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

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

— Jiggy
แหล่งที่มา

"ได้ยินการทบทวนย้อนหลังและการวางแผนครั้งใหญ่" - ถ้าคุณรู้สึกว่าการย้อนหลังนั้นเป็นภาระมากคุณไม่จำเป็นต้องทำทุกการวิ่ง การวางแผนควรขึ้นอยู่กับสิ่งที่คุณวางแผนเท่านั้นดังนั้นไม่ควรน้อยกว่าด้วยการวิ่งระยะยาว

— sleske

0

ปัญหาที่สองอาจเป็นผลมาจากการพยายามแก้ไขไม่ใช่ # 1 คุณควรหาคนที่ไม่ว่างมาช่วยเพื่อน แทนการทำงานที่ไม่ใช่การวิ่งซึ่งทำให้เกิดการโต้แย้งในการรวมที่ จำกัด

นอกจากนี้คุณไม่ควรรวมในตอนท้ายของการวิ่ง แต่ต่อเนื่อง

— บรูโน่การ์เดีย
แหล่งที่มา

0

คุณเพิ่งเริ่มต้น ให้โอกาสทีมแก้ไขปัญหานี้ด้วยตนเองผ่านกระบวนการย้อนหลัง

ประการที่สองเจ้าของผลิตภัณฑ์ของคุณควรไว้วางใจทีมให้รู้วิธีการจัดระเบียบและปรับให้เหมาะสมที่สุด ในทางกลับกันทีมไว้วางใจ PO เพื่อให้รู้ว่าลูกค้าต้องการอะไรดีที่สุด

สิ่งเหล่านี้เป็นความท้าทายที่พบบ่อยมากกับทีมงานใหม่ที่คล่องตัว ยอดเยี่ยมในการดูว่าทีมใดจะเริ่มทำลายไซโลของตนเองและเติบโต

— Kris Van Bael
แหล่งที่มา