agile - proyectos - scrum master
Metodología del proyecto para pequeños equipos (6)
Están muy cerca de los negocios, lo cual es malo porque los programadores a menudo no comprenden bien las implicaciones de la contabilidad, el tiempo o la gestión de riesgos, etc. Incluso si creen que sí. Ven el negocio como otra oportunidad atractiva para mejorar sus sofisticadas habilidades técnicas. Como la compañía es pequeña, puede ser excesivo implementar metodologías complejas dentro del equipo de desarrollo. Ellos mismos pueden manejar las preguntas técnicas con facilidad. Lo que no pueden manejar es entender que si están cerca del entorno empresarial no significa que ya no sean programadores.
Sugiero implementar algunas políticas sencillas que aseguren la disciplina y el enfoque en el aspecto técnico en lugar de hablar con los clientes sobre temas técnicos, que es lo que a algunos programadores les gusta tanto.
Por lo general, somos 1 a 4 desarrolladores / directores de arte / redactores en cada proyecto de mi empresa, ¿qué metodología recomendaría utilizar? ¿Ágil? XP? ¿Melé? ¿Algo más? (Sé que son todas variaciones de esencialmente el mismo concepto, sí)
La respuesta es, proverbialmente, depende ...
Cada equipo es una mezcla de personalidades y habilidades, y cada miembro del equipo es diferente. En lugar de enfocarse en encontrar una "metodología" per se, le recomendaría que se concentre en lo que necesita cada miembro del equipo para tener éxito y lo combine con lo que el proyecto necesita para tener éxito. Encontrarás la metodología correcta y la combinación de procesos entre esas dos consideraciones.
Como ejemplo, he dirigido un pequeño equipo (tres desarrolladores a tiempo completo más algunos diseñadores de UI a tiempo parcial) durante los últimos siete meses. Descubrí que las siguientes prácticas / procedimientos funcionan bien para nosotros ...
- Adoptando espirales cortas (60-90 días) bien definidas, que mantienen al equipo enfocado y orientado a la entrega y nos ayuda a minimizar los riesgos.
- Adoptamos un ciclo de vida iterativo, en el cual realizamos algunas entregas incrementales al cliente durante el curso de una espiral y discutimos lo que hemos hecho. Hacerlo nos permite a nosotros y al cliente asegurarnos de que estamos atendiendo sus necesidades.
- Tareas y dirección de personalización para cada miembro del equipo. Por ejemplo, un miembro del equipo es un desarrollador más joven, mientras que el otro miembro del equipo es un desarrollador muy bueno, pero no maneja bien las tareas abiertas. Requieren diferentes enfoques.
Naturalmente, también he adaptado procesos de CM y prácticas de prueba para adaptarse al proyecto y las necesidades del equipo.
No creo que haya una respuesta general, la pregunta es demasiado amplia, y no se puede simplemente "adoptar una metodología" como si se tratara de un producto que se saca de la caja, es algo que se desarrolla con el tiempo ... pero en cualquier caso, le recomiendo que obtenga una copia de este libro: Head First Software Development
Luego, adaptas las ideas que te gustan a tu proyecto. No se preocupe por los nombres y las palabras de moda, de todos modos serán todos "aprobados" el próximo año. Manténgalo simple al principio, adopte las ideas que tengan más sentido y aproveche al máximo, y no intente resolver problemas que aún no existen. Será un muy buen comienzo.
Para equipos tan pequeños, definitivamente consideraría un enfoque ágil para el desarrollo de software. Personalmente, probablemente usaría una mezcla de XP, Scrum y Lean, porque los conozco mejor. Especialmente si es nuevo en Agile, XP proporciona un buen punto de partida desde el que puede encontrar la adaptación específica de su proyecto. Recomiendo mucho el libro "El arte del desarrollo ágil".
Para la programación de pares, al menos, es mejor tener un número par de programadores ...; P
Una de las cosas buenas de los equipos pequeños es que no se necesitan muchos sistemas de soporte para comunicarse internamente (un rastreador de errores se convierte más o menos en una lista de tareas para usted, pero de todos modos es bueno tenerlo). Si tener una reunión con todo el equipo solo implica girar el charir y decir "¡Oye, Bob y Carl, échale un vistazo a esto!", En realidad no necesitas todas las reglas formales de una metodología. Pero los métodos ágiles en general son bastante adecuados para los equipos pequeños y medianos, pero requieren miembros de equipo motivados por sí mismos.
Diré que elijas las ideas que te gusten de las diferentes metodologías, de todos modos pueden considerarse sugerencias.
Mi equipo de 3 desarrolladores simplemente usa despliegues continuos Kanban + y nos mantiene en movimiento rápidamente. Miré a Scrum y a otros y hay demasiados gastos generales para nuestro pequeño equipo.