Scrum, Kanban u Otros para el equipo de desarrollo de 4 personas

Question

Tenemos un equipo de desarrollo de cuatro personas que necesita un sistema formal de administración de proyectos. Tengo una comprensión general de Scrum y Kanban, pero es difícil de entender realmente hasta que se ha intentado. No podemos darnos el lujo de probar uno durante unas semanas y luego cambiar a otro, así que esperaba que alguien que estaba en una situación similar pudiera tener ideas sobre qué funcionó mejor para ellos y por qué. Además, cualquier otro sistema para administrar el desarrollo que funcionó sería genial de escuchar.

Otra nota: existe la posibilidad de que el equipo crezca, por supuesto, por lo que necesitaríamos un sistema que escalara bien.

Sin embargo, otra nota: Trabajamos en tres aplicaciones de software independientes de Windows todos los cuales se basan en una biblioteca central que también escribimos (así que supongo que se podría decir cuatro proyectos)

Answer 1

Tanto Scrum como Kanban son realmente "esqueletos" de proceso. Ninguno de los dos es específico para el desarrollo de software. Scrum fue popularizado por las organizaciones de desarrollo de software, pero se posiciona como técnica de gestión general en lugar de una técnica de gestión de proyectos de software. Kanban surgió de la fabricación y se ha adaptado al desarrollo de software, inicialmente por equipos de mantenimiento. Tanto Scrum como Kanban apuntan a administrar el flujo de unidades de trabajo a través del equipo que está haciendo ese trabajo, medir qué tan rápido fluye el trabajo para que las estimaciones se puedan hacer cada vez más precisas y hacer que los cuellos de botella sean altamente visibles para que puedan abordarse.

Dado que ninguno de los dos es específico del desarrollo de software, los equipos que utilizan Scrum y Kanban añaden prácticas de desarrollo de software al proceso para ayudarlos a liberar y mejorar el software incremental e iterativamente. La mayoría de los equipos, ya sea que trabajen en un proceso de Scrum o Kanban, adoptan las prácticas técnicas de XP y las prácticas reflexivas de Crystal.

XP es básicamente Scrum aplicado a un solo equipo más directrices sobre qué hace que el código sea de "alta calidad" y cómo los programadores pueden lograrlo. Crystal Clear también se aplica a los equipos pequeños que comparten el edificio, pero es más flexible en cuanto a las prácticas de programación, aunque también recomienda las prácticas de XP (el libro que describe el proceso es excelente y está lleno de consejos invaluables, independientemente del proceso que decida). Los equipos de Scrum también suelen adoptar las prácticas reflexivas de Crystal: retrospectivas regulares de "latidos del corazón" y retrospectivas más grandes después de cada hito importante. Kanban requiere una continua reflexión y mejora, pero algunos equipos también usan retrospectivas.

Si desea comenzar a aplicar un proceso incremental/iterativo en un pequeño equipo de programación, entonces creo que XP es un buen proceso para comenzar porque establece la barra bastante alta para la capacidad técnica y está muy bien documentada. Cómo se aplica el flujo continuo y Kanban a las diferentes áreas de la industria de desarrollo de software aún se está debatiendo en la lista de correo kanban-dev y en otros lugares.

Recomendaría también la realización de retrospectivas regulares para mejorar el proceso y adaptarlo a su situación específica.

Answer 2

La parte más importante es tener un mecanismo de reflexión/retrospectiva que facilite la mejora continua. Comience con algún modelo de proceso y evolucione con el tiempo para sus necesidades de. Deja de hacer cosas que no valen la pena hacer. Sigue haciendo cosas que aportan un alto valor. Pruebe cosas nuevas que crea que podrían ser valiosas o aborde problemas específicos.

Answer 3

¿De qué se trata? ¿Cuál metodología sería la más adecuada?

Answer 4

No obtendrá muchos beneficios de todos los gastos generales que un sistema formalizado impondrá a ese tamaño de equipo. En su lugar, intente con a good management technique para asegurarse de que todos se escuchen entre sí y se eliminen los bloques.

Answer 5

Creo que Scrum trabaja para equipos pequeños y medianos. Comparado con XP, deja fuera algunos detalles, por lo que puedes tomar prestado de XP o hacer algo que tenga sentido. Cualquiera de las metodologías que elijas, debes considerar el rol de los pollos (clientes/gerentes/interesados ​​/ expertos de dominio). A veces tienes que interpretar los roles tú mismo, pero muchas metodologías ágiles funcionan porque hay un coche de ritmo externo con un conocimiento sólido del dominio.

Otros aspectos clave son el nivel de comunicación entre su equipo y alguna forma de mecanismo de garantía de calidad. Es difícil hacer la programación de pares si no se encuentra en el mismo edificio. Scrum intenta hacer que una característica sea aceptada dentro de un ciclo de sprint, y XP intenta integrar la función dentro del día mediante pruebas unitarias, revisión de código e integración continua.

*) Sprint puede variar de 15-30 días.

Answer 6

He trabajado con un equipo de ese tipo y aún más grande en dos equipos que compartieron algunas bibliotecas comunes. Scrum funcionó bien para nosotros. Ahora trabajo con un equipo con 6 miembros y usamos XP y creo que también funciona. El primer equipo desarrolló un producto y las influencias del "espacio exterior" no fueron tan grandes. De modo que las iteraciones más largas funcionaron bien. No, desarrollamos un proyecto de cliente y, por lo tanto, los ciclos de lanzamiento más cortos son mejores para nosotros.

Pero SCRUM y XP son más que eso. Ahora usamos TDD y Pair-Programming (ambos más del mundo XP). También tenemos reuniones standup diarias que son más similares a SCRUM. Adoptamos XP y SCRUM para trabajar en nuestro proyecto y nuestra situación.

Comenzaría con ciclos cortos (1 semana) y reseñas de este ciclo. Llevará algún tiempo adoptar una nueva metodología en su equipo, pero si los miembros están dispuestos a aprender y cambiar, funcionará.