ทีมต่อสู้หลายคนย้ายไปที่ค้างค้างเดียว


9

ขณะนี้เรามีทีมการต่อสู้ 5 ทีมที่ทำงานในส่วนที่เหลือของผลิตภัณฑ์ในปีที่ผ่านมา แต่ละทีมทำงานบนระบบเฉพาะของตัวเอง แต่เทคโนโลยีพื้นฐานเหมือนกัน. Net

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

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

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


ฉันไม่แน่ใจว่าฉันเข้าใจว่าเหตุใดคุณจึงต้องการรวม backlogs ทำไมไม่มีสมาชิกในทีมย้ายระหว่างทีมตามที่ต้องการแทน?
MetaFight

คุณรวมสองทีมเหล่านั้นเข้ากับทีมที่ใหญ่กว่าเพื่อทำงานกับผลิตภัณฑ์ที่แตกต่างกันหรือไม่
Ioannis Tzikas

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

1
@IoannisTzikas - ไม่มีทั้งสองทีมจะยังคงเหมือนเดิม การรวมทีมจะทำให้พวกเขาใหญ่เกินไป ผู้บริหารระดับสูงต้องการรวม backlogs ให้เป็นหนึ่งเดียวและให้ทั้งสองทีมทำงานนอกงานเดียวกันในขณะที่ข้ามนักพัฒนา
Malcolm

2
ความท้าทายที่ยิ่งใหญ่ที่สุดที่ฉันเห็นไม่ได้เกิดขึ้นกับทีม แต่สำหรับเจ้าของผลิตภัณฑ์ของ Backlog รวม พวกเขาจะต้องเห็นด้วยกับการจัดลำดับความสำคัญของงานสำหรับผลิตภัณฑ์ต่าง ๆ
Bart van Ingen Schenau

คำตอบ:


8

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

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

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

การจัดระเบียบสิ่งต่าง ๆ อาจเป็นความเจ็บปวดอย่างแท้จริงดังนั้นนี่คือบางประเด็นที่คุณต้องการพิจารณา

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

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

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

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

    1. เราจะนำหน้าชื่อ PBI พร้อมชื่อผลิตภัณฑ์หรือรุ่นจดชวเลข
    2. เรามีฟิลด์แยกต่างหากที่บ่งบอกถึงผลิตภัณฑ์โดยรวมและจะต้องมีการกรอกเช่นกัน
  • เราต้องใช้ความพยายามอย่างมีสติในการฝึกอบรมข้ามสายและเพื่อให้แน่ใจว่าทุกคนได้รับความร่วมมือในด้านต่างๆ เรามีฐานรหัสขนาดใหญ่มากเกี่ยวกับทีมพัฒนาของเรา รหัสบางอย่างที่เราทำมีความพิเศษเช่นกัน หัวหน้าทีมของเรานั้นยอดเยี่ยมมากในเรื่องนั้นและเขาจะลดระดับความมุ่งมั่นของเราลงเพื่อให้เราสามารถจ่ายความไร้ประสิทธิภาพที่มาจากการฝึกอบรมข้ามสายงาน การมีผู้นำทีมที่แข็งแกร่งเป็นสิ่งสำคัญในเรื่องนี้

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

  • รหัสการเดินผ่านและการตรวจสอบกลายเป็นสิ่งที่สำคัญยิ่งกว่าเดิม ช่วยให้ทุกคนทราบถึงสิ่งที่เปลี่ยนแปลงในด้านต่าง ๆ

  • ในทำนองเดียวกันอันดับประจำวันที่เกี่ยวข้องกับ devs ทั้งหมดรวมถึงคน UI ของเรา เราอยู่ที่ขอบของการสื่อสารความร่วมมือที่เป็นประโยชน์และความไร้ประสิทธิภาพจากคนจำนวนมากเกินไป แต่เราจะรักษาระดับขั้นให้น้อยกว่า 15 นาทีและจะดำเนินการต่อจากการสนทนาด้าน โดยปกติเราใช้เวลาประมาณ 5 ถึง 10 นาที

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

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

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

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

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

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


I can't speak to the effects on metrics like velocity or overall commitment and burndown rates. Those aspects just haven't been important enough for us to follow closely.- แล้วคุณจะรู้ได้อย่างไรว่าจะพอดีกับการวิ่งมากแค่ไหน? ต้องมีบางอย่างเกิดขึ้นแม้ว่ามันจะหมดสติไป
Izkata

2

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

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

เจ้าของผลิตภัณฑ์

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

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

การพัฒนาผลิตภัณฑ์กับการบำรุงรักษา

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

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

การสลับบริบท

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

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

อันตราย

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

ตัวอย่าง

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

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

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

ความเป็นมืออาชีพ

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

ตรวจสอบและปรับตัว

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

บรรทัดล่าง

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

การต่อสัญญา

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

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


1

เมื่อไม่นานมานี้เราเพิ่งได้รับการสนับสนุนจากทีมอื่น ทีมมีสมาชิกเพียงคนเดียว (ฉันรู้ไม่มากนัก) แต่มีงานในมือที่ยังไม่เกิดขึ้นจริง เราไม่คุ้นเคยกับงานของพวกเขามากและพวกเขาไม่คุ้นเคยกับงานของเรามากนัก

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

ให้เริ่มจากการให้ทั้งสองทีมทำงานในสิ่งที่พวกเขาทำมาก่อน ความแตกต่างเพียงอย่างเดียวคือทุกอย่างอยู่ใน backlog เดียวกัน

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

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


1

ฉันสมมติว่าเหตุผลที่คุณ (หรือการจัดการ) ต้องการสร้าง Backlog ที่ผสานสำหรับสองทีมคือคุณต้องการให้สามารถเลือกเฉพาะรายการ Backlog สำหรับหนึ่งในระบบและให้ทั้งสองทีมทำงานกับพวกเขา

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

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


0

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

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

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.