วิธีประสานงานผู้พัฒนาใช้เวลาระหว่างสองโครงการที่แตกต่างใน Scrum ได้อย่างไร

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

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

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

ปัญหานี้เก่าเท่าที่มีการต่อสู้ มีวิธีแก้ปัญหา แต่คุณจะไม่ชอบมัน

• เพิ่มงานใหม่ลงใน Backlog
• อย่าขัดจังหวะนักพัฒนาซอฟต์แวร์
• รอการวิ่งครั้งต่อไป

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

หากคุณลองใช้สิ่งเหล่านั้นโดยทั่วไปคุณจะกลับไปที่วิธีการพัฒนา 'วุ่นวาย' หรือ 'JFDI' พร้อมปัญหาทั้งหมดของผู้ดูแลเช่น

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

แน่นอนว่าการตอบสนองตามปกติสำหรับคำแนะนำนี้คือ "แต่ฉันทำไม่ได้! ธุรกิจต้องการให้แก้ไขข้อบกพร่องการผลิตเหล่านั้นโดยเร็ว!"

แต่นั่นไม่เป็นความจริง

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

มีโอกาสมากขึ้นที่จะเป็นหนึ่งในสิ่งต่อไปนี้:

• ข้อบกพร่องคือปัญหาการดำเนินงานพื้นที่ดิสก์ไม่ DR ไม่มีข้อมูลสำรองไม่มีข้อผิดพลาดเป็นต้นรับทีม OPS

• ข้อบกพร่องคือผู้ใช้ไม่เข้าใจว่าระบบควรทำงานอย่างไร "สิ่งนี้เกิดขึ้น! มันเป็นข้อผิดพลาดหรือไม่" รับฝ่ายช่วยเหลือและฝึกอบรมผู้ใช้เขียนเอกสาร

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

แค่พยายามคิดนอกกรอบที่นี่

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

ทำไมไม่ลองคาดการณ์สิ่งนี้และใช้มันเพื่อผลประโยชน์ของคุณ?

คุณจะต้องมีทีมงาน 5+ เพื่อให้เป็นจริง

แต่ทำไมไม่นำนักพัฒนาคนใดคนหนึ่งออกไปทุกคน (การหมุนระหว่างนักพัฒนาแต่ละคนจะได้ผลัดกัน)

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

• ใช้การทดสอบเพื่อระบุปัญหาคอขวดของประสิทธิภาพการทำงาน
• การบำรุงรักษาระบบการสร้าง
• การประชุมกับลูกค้า
• ค้นคว้ากรอบ / ห้องสมุดใหม่
• การสำรวจคุณสมบัติภาษาที่คุณต้องการใช้
• อ่านเกี่ยวกับปัญหาด้านความปลอดภัย
• การบำรุงรักษาฐานข้อมูล
• การบำรุงรักษาเซิร์ฟเวอร์

ความเร็วของทีมอาจสูงขึ้นความเครียดอาจลดลงความขัดแย้งกับผู้บริหารอาจลดลงคุณได้รับเวลาจริง ๆ ในการพัฒนาความรู้ของคุณ

ทางออกที่มีประสิทธิภาพสำหรับการจัดการความพยายามของนักพัฒนาสำหรับปัญหาการผลิตที่สำคัญอย่างแท้จริงที่ฉันเคยใช้คือ "แนวทางแบทแมน"

ความรับผิดชอบด้านการสนับสนุนการผลิตที่มีราคาแพงในขณะที่พัฒนาฟังก์ชันการทำงานใหม่คือการสลับบริบทดังนั้นคุณควรตั้งเป้าหมายที่จะ จำกัด

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

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