Normalmente somos 1-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 todas son variaciones de esencialmente el mismo concepto, sí)Metodología del proyecto para equipos pequeños
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 toma fuera de la caja, que es algo que evolucionan con el tiempo ... pero en cualquier caso le recomiendo que conseguir una copia de este libro: Head First Software Development
a continuación, adaptar las ideas que usted tiene gusto en 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. Al principio, simple, adopte las ideas que tengan más sentido y dé el mayor provecho posible, y no intente resolver problemas que aún no existen. Será un muy buen comienzo.
Para la programación en parejas, al menos, lo mejor es tener un número par de programadores ...; P
Una de las cosas buenas de los equipos pequeños es que no lo hace necesidad mucho apoyo sistemas 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.
Voy a decir que elijas las ideas que te gusten de las diferentes metodologías, se pueden considerar sugerencias de todos modos.
En mi experiencia, los enfoques ágiles, si se implementan bien, * crean * miembros del equipo automotivados. –
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 simples 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.
Bueno, yo diría que exactamente * porque * los programadores no entienden muy bien el aspecto comercial, deberían trabajar en estrecha colaboración con quienes no lo hacen. Un proyecto bien gestionado necesita la parte comercial y la parte técnica para estar en línea. Los enfoques ágiles logran eso. –
¿Qué es ágil? Una varita mágica? =) Los desarrolladores no saben de qué se trata la empresa y los clientes no saben de qué se trata la programación. El contacto directo entre ellos solo trae malentendidos y malas prácticas – Din
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 equipo pequeño (tres desarrolladores a tiempo completo más algunos diseñadores de UI a tiempo parcial) durante los últimos siete meses. He encontrado que las prácticas/procedimientos siguientes funcionan bien para nosotros ...
Naturalmente, también he adaptado los procesos de CM y las prácticas de prueba para adaptarse al proyecto y las necesidades del equipo.
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".
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.
Actualización: Es el año 2012 y Scrum y Agile aún no están pasados de moda. –
Actualización: 2016 ahora, aún no pasó – Kevin