SCRUM จัดการสภาพแวดล้อมที่สมาชิกในทีมแบ่งปันกันอย่างไร


13

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

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

ใคร?


1
คุณหมายถึงอะไรโดยการแชร์? คุณหมายถึงว่าบางคนสามารถย้ายจากทีมหนึ่งไปอีกทีมหนึ่งหรือว่าบางคนอาจทำงานหลายทีมพร้อมกันหรือไม่ นี่จะส่งผลต่อคำตอบของฉัน
สาธารณรัฐประชาธิปไตยประชาชนลาว

คำตอบ:


6

ในวิธีการแย่งชิงมันเพียงส่งผลกระทบต่อการประเมิน

คุณจะกำหนดปัจจัยโฟกัสสำหรับบุคคลนั้นโดยพิจารณาจากการจัดสรรเวลาของแต่ละโครงการ

ดังนั้นหากฉันทำงานในโครงการ Aและโครงการ Bอย่างเท่าเทียมกันโครงการ A จะคำนวณทรัพยากรดังนี้:

โครงการ A - ปัจจัยการโฟกัสทีม 70%
Sam - 10 วัน, การจัดสรร 100% (7 หลังจากปัจจัยโฟกัส)
Joe - 10 วัน, การจัดสรร 100% (7 หลังจากปัจจัยการโฟกัส)
Me - 10 วัน, การจัดสรร 50% (3.5 หลังจากปัจจัยการโฟกัส) )
ทั้งหมด: 25 วัน * ปัจจัยการโฟกัส 70% = 17.5 ความเร็วที่คาดการณ์

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

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


2
ปัญหาของฉันเกี่ยวกับการทำเช่นนี้ก็คือมันไม่ได้เป็นเพราะการสลับงานได้ดีมาก ตัวอย่างเช่นลองวิ่ง 2 สัปดาห์ (10 วัน) การมีนักพัฒนาที่มีปัจจัยการโฟกัส 50% ซึ่งคุณได้รับตรง 5 วันนั้นแตกต่างจากการมีนักพัฒนาอย่างมากทุก ๆ ชั่วโมงเป็นเวลา 10 วัน อดีตมีประสิทธิภาพมากขึ้น ตัวอย่างสุดขั้ว แต่คุณได้คะแนนของฉัน
Brook

@Brook คุณกำลังพูดถึงปัจจัยการโฟกัส (1 การวัดต่อคน) ซึ่งแตกต่างจากการจัดสรรโครงการ (ในกรณีนี้แยก 50/50) ปัจจัยโฟกัส% ของวันที่เหมาะที่วันจริงของคุณคุ้มค่า โดยปกติแล้วจะอยู่ที่ประมาณ 70-80% แต่สำหรับบางคนที่แยกโครงการมันอาจจะน้อยกว่า (ซึ่งฉันตอบในคำตอบ) มันขึ้นอยู่กับความมั่นคงในบางช่วงเวลา หากคุณไม่สามารถมีความมั่นคงคุณไม่ควรที่จะทำเช่นนั้นในการต่อสู้
นิโคล

ส่วนความสอดคล้องเป็นจุดของฉันจริงๆ หากคุณมีทีมงานที่ผู้คนมักจะถูกดึงไปใน 10 ทิศทางที่แตกต่างกันและคุณไม่สามารถเปลี่ยนแปลงสิ่งนั้นได้สrumไม่ช่วยอะไรคุณ
Brook

@Brook - มันเป็นจุดที่ดีและคุณช่วยให้ฉันคิดเกี่ยวกับมันในแบบที่ฉันไม่ได้เดิม ดูเหมือนว่าเราจะเห็นด้วย
นิโคล

1
@NickC ดูเหมือนว่าจะเป็นไปได้ อย่างน้อยที่สุดฉันก็เห็นพ้องต้องกันว่าสมาชิกในทีมสามารถเปลี่ยนแปลงได้ทุกครั้งโชคดีที่มันไม่ได้เกิดขึ้นมากนัก สถานที่ทำงานยังคงเหมือนเดิมเสมอเวลาที่โครงการมอบให้บางครั้งครึ่งหนึ่งของความสามารถของสมาชิกในทีม (เพราะสมาชิกในทีมกำลังทำกิจกรรมต่าง ๆ จาก 2 โครงการ) แต่สิ่งนี้ดูเหมือนจะเหมาะสมสำหรับการคำนวณความเร็วสำหรับโครงการต่างๆอย่างน้อยที่สุด ขอบคุณสำหรับการอ้างอิง
Xanathos

10

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

โดยทั่วไปคุณควรพยายามทำให้ทีมนั้นเหมือนเดิม & ทุ่มเทอย่างน้อยที่สุดตลอดการวิ่งมากกว่านี้ถ้าคุณทำได้


2
ใช่แน่นอน! พยายามที่จะแบ่งปันสมาชิกระหว่างโครงการเพียงแค่ส่งผลให้โครงการที่เกี่ยวข้องทั้งหมดล่าช้า มันไม่สมเหตุสมผลเลยที่จะแยกคนแบบนั้นออกจากกันและคิดว่าสิ่งต่างๆจะเสร็จเร็วขึ้น
Martin Wickman

+1 สำหรับสามัญสำนึกคุณไม่สามารถกำหนดผู้หญิงสามคนให้ตั้งครรภ์ได้สำเร็จภายในสามเดือน มันสมเหตุสมผลกว่าที่จะอุทิศผู้คนให้ทำงานที่เฉพาะเจาะจง
maple_shaft

ฉันเชื่อว่านี่เป็น "เสาหลัก" ของ Scrum ที่จริงแล้ว โปสเตอร์ดูเหมือนจะผสมบริบทเมื่อถามว่า "อะไร Agile พูดในสถานการณ์นี้" (vs Scrum) มีคำตอบ Agile (ไม่ใช่ Scrum) ...
Al Biglan

1

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

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

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

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

เนื่องจากข้อสรุปที่คล่องตัวก็คือการลดของเสีย (ใช่มันมาจากวิธี Lean) และการแบ่งปันสมาชิกในทีมเป็นหนึ่งในความล้มเหลวที่เลวร้ายที่สุดในแง่ของการแนะนำของเสียและการลดผลผลิต ฉันเดาว่าการส่งมอบมูลค่าทางธุรกิจสำหรับการจัดสรร 33% ไปยังโครงการเดียวจะเท่ากับมูลค่าทางธุรกิจที่ส่งมอบจาก 10-16% ของการจัดสรรแบบเต็มเวลา ซึ่งหมายความว่านักพัฒนาซอฟต์แวร์จะไม่เพียงแค่มีส่วนร่วมในโครงการ 1/3 เท่า แต่ในช่วงเวลานั้นผลผลิตของเขาจะอยู่ระหว่าง 1/3 ถึง 1/2


1

SCRUM ขึ้นอยู่กับการมีทีมที่มุ่งมั่นโดยไม่มีสมาชิกที่ใช้ร่วมกันดังนั้นคุณอาจต้องถามด้วยเช่นกัน:

เนื่องจากเราได้รับแจ้งว่าเราต้องทำให้เป็นจริง == false เราจะทำอย่างไร x

หากไม่ใช่ SCRUM อย่าเรียกว่า SCRUM!


0

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

บ่อยครั้งที่บุคลากรที่ทำหน้าที่พาร์ทไทม์ในโครงการมีส่วนร่วมในขอบเขตที่ จำกัด เท่านั้น ตัวอย่างเช่นคุณอาจมีบุคคลที่ทำการปรับฐานข้อมูลเท่านั้น

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


0

ฉันเชื่อว่าหนึ่งในประเด็นหลักของการต่อสู้คือการทำให้ทีมมุ่งเน้นไปที่สิ่งใดสิ่งหนึ่งในเวลาหนึ่งโครงการหนึ่งเรื่องหนึ่งงาน ...

คุณถามว่า "Agile เสนออะไร" ในสถานการณ์ที่คุณไม่สามารถจัดสรรทรัพยากรให้กับโครงการหนึ่ง ... คุณอาจลองทำหนึ่งใน:

  • เก็บบอร์ด Kanban ขนาดใหญ่ที่ครอบคลุมหลายโครงการ เมื่อโครงการมีความต้องการจะได้รับการเพิ่มเข้ามาในบอร์ดเนื่องจากผู้คนมีความสามารถพวกเขาจึงดึงเรื่องราวสำคัญ ปัญหาคือทุกโครงการได้รับการจัดการร่วมกันซึ่งจะช่วยลดความสามารถในการคาดการณ์โดยรวมของโครงการใดโครงการหนึ่ง ที่กล่าวว่าองค์ประกอบแต่ละเรื่อง / องค์ประกอบ Kanban จะถูกดึงและพัฒนาโดยบุคคลหรือทีมที่มุ่งเน้น (คุณอาจลองสร้างทีมเล็กกว่า 4-5 คนเพื่อดึงจากกระดาน Kanban
  • มอบหมายทรัพยากรที่กำหนดเท่านั้น เก็บพูลของทรัพยากรเฉพาะสำหรับโครงการ สิ่งเหล่านี้ได้รับการปกป้องเป็นทีมและการขัดจังหวะจะถูกเก็บไว้ใกล้ศูนย์ "ทีมตอบสนองอย่างรวดเร็ว" ที่ไม่มี Backlog และไม่มีโครงการ / ผลิตภัณฑ์ที่มุ่งเน้น เมื่อการขัดจังหวะเกิดขึ้นทีมตอบสนองที่รวดเร็วจะจัดการกับการขัดจังหวะ เมื่อพวกเขาไม่มีการขัดจังหวะพวกเขาสามารถมุ่งเน้นไปที่การปรับปรุงระบบการสร้างการเพิ่มกรอบการทดสอบระบบอัตโนมัติและอื่น ๆ นอกจากนี้พวกเขายังสามารถช่วยในการตรวจสอบโค้ด / บทวิจารณ์การออกแบบและการแก้ไขปัญหาข้อผิดพลาด จัดการการพัฒนาราวกับว่าทีมนี้ไม่มีอยู่จริง สิ่งที่พวกเขาทำได้คือดึงในการส่งมอบ หมุนคนผ่านทีมนี้เพื่อ "รักษาความสด" (คนดูเหมือนจะชอบ / เกลียดการอยู่ในทีมตอบสนองที่รวดเร็ว ... )

หวังว่านี่จะช่วยได้!

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