Equipos de scrum contra equipos tradicionalmente organizados [cerrado]

Question

Para aquellos de ustedes que comenzaron a usar scrum en sus equipos de desarrollo: ¿Mantuvieron los equipos tradicionales o formaron equipos nuevos? En nuestra organización, estamos divididos en bases de datos, desarrollo de productos y desarrolladores de aplicaciones frontales (¡simplificado!).

Me interesa saber si otros reorganizaron realmente toda la estructura de su equipo debido al scrum o si formaron equipos dedicados a proyectos (?) combinando, por ejemplo. una persona de cada " antiguo " equipo.

Answer 1

En realidad, ni siquiera puedo imaginar cómo podría funcionar scrum si mantienes tus silos de rol. En scrum, creamos cortes verticales a través del producto para que cada característica entregada durante un sprint requiera todas las habilidades que mencionó (además del control de calidad que usted no). ¿Cómo crearía una colaboración continua y haría que la gente se comprometiera con el sprint si no estuvieran todos en el mismo equipo? Parece la forma más probable de terminar en " Scrumfall " a mi. No soy un experto de ninguna manera, pero me parece que la forma segura de fallar en scrum es pensar en ello como una solución de gestión de proyectos en lugar de un cambio organizativo completo. Es cultural en el núcleo.

Para responder a tu pregunta sobre " generalistas " ;. La respuesta fácil es que al tener ciertas personas que solo pueden trabajar en ciertas cosas, se crean grandes cuellos de botella para llegar a Hecho. Con las especialidades, siempre está limitado en cada paso por tener recursos limitados para trabajar en algo. En el sprint 1, es posible que tenga que hacer mucho trabajo de db donde hay más de lo que puede hacer un dba. Pero luego, en Sprint 5, donde no hay ningún cambio en el modelo de datos, su dba estará sentado y aburrido. Es casi imposible en la planificación del sprint comprometerse en un tiempo razonable si tiene que dividirse y asignarse en el nivel de la tarea por rol, en lugar de simplemente agarrar el siguiente conjunto de características de prioridad que se ajusta a la velocidad de su equipo. El modelo generalista inevitablemente traerá valor comercial a largo plazo. Es posible que no lo vea de inmediato hasta que logre la polinización cruzada.

Le advierto que si ya está en grupos de silo-ed por rol, debe ser muy cuidadoso en una reorganización ágil. Muchas personas no están listas y no quieren estar listas para perder sus títulos especiales y simplemente convertirse en miembros del equipo. Creo que casi siempre deberías esperar una cierta cantidad de facturación.

Answer 2

Es preferible que, en el desarrollo de scrum / ágil, la mayoría de las personas del equipo sean "generalistas", lo que significa que cualquiera puede asumir cualquier función de manera razonable para que cualquiera pueda sacar elementos del backlog cuando llegue el momento y nadie esté esperando. otros.

ahora puede que este no sea el caso en su situación actual, pero hacer cosas como la programación entre pares y las reuniones de apoyo para ver dónde las personas tienen impedimentos y para mejorar la polinización cruzada del conocimiento ayudará a lograr este objetivo.

Answer 3

En mi empresa, creamos un equipo de funciones cruzadas temporales para cada proyecto. Nuestros equipos existentes todavía están allí, pero es realmente importante que tengamos equipos multifuncionales para scrum.

Answer 4

En general, tratamos de mezclarnos un poco para obtener conocimientos de varios equipos, pero en su mayor parte trabajamos en nuestras especialidades. Pero a medida que avanza el proyecto, podemos ayudar más fácilmente en diferentes equipos

Answer 5

Cuando trabajé para mi empleador anterior, la empresa reorganizó toda la organización de desarrollo y la gestión de productos. Pusieron ingenieros, qa, y analistas en cada equipo. La división fue mayormente vertical / funcional con algunas excepciones. Esas excepciones fueron un error: la arquitectura vertical no encajaba, porque era realmente horizontal. Pensé que los equipos multifuncionales funcionaban bien. En su caso, los departamentos de db y front-end deben fusionarse con el resto si es posible, y se pueden crear nuevos verticales específicos para su producto

Answer 6

Dividimos a nuestro equipo en Desarrollo de nuevos productos y Mantenimiento del producto existente, con la capacidad de que cualquier desarrollador salte de uno a otro entre los sprints.

Answer 7

Creo que hemos mantenido el equipo tradicional, al menos por ahora. Hay un par de otros equipos dentro de la rama de aplicaciones del departamento de Sistemas de información donde trabajo, aunque estos se instalaron justo antes de que entráramos en Scrum.

Hay un gran proyecto en el que estamos trabajando con Scrum y el equipo parece estar evolucionando muy bien. Tenemos algunas herramientas y procesos nuevos que nos han ayudado mucho y nos han dado un sentido de "maravilla". eso esperamos que pasemos a los otros equipos.

Para los cambios en una base de datos, cualquiera de nosotros, los desarrolladores, puede hacer el cambio en el entorno de desarrollo y luego pasar el script a un DBA para que esté listo para la producción. Para los cambios en la red, hay personas en la infraestructura que manejan eso e inicialmente configuran un servidor en términos de O / S, red, memoria, discos duros, etc.