Hace un par de semanas tuve la suerte de asistir a un curso sobre Metodologías Ágiles en desarrollo de Software impartido por Javier Garzás (@jgarzas) en la que nos dió unas pinceladas sobre distintas metodologías ágiles a implantar (Scrum, Kanban, …).
Fué un seminario muy interesante y me sorprendió el ver como en gran medida, muchas de las premisas comentadas ya estaban siendo utilizadas en Velneo:
- Equipo
- Iteraciones cortas
- Comunicación
- Interactuar con el usuario final
- …
Uno de los aspectos que me sorprendió gratamente fué la composición óptima del equipo: cuanto más pequeño mejor pero con una alta capacidad y brillantez. ¡Es lo que tenemos!
Muchos de nuestros clientes suelen hacerme la misma pregunta ¿cuántas personas componen el equipo de desarrollo de Velneo?.
La verdad es que suelen sorprenderse al responderles que nuestro equipo está formado por nuestro arquitecto (@varquitecto) y un reducido equipo de grandes desarrolladores. La siguiente pregunta no se hace esperar ¿porqué no ampliáis el equipo y avanzáis mucho más rápido?.
Mi respuesta siempre es la misma, lo mejor para proyectos de desarrollo de software empresarial es disponer de un equipo altamente cualificado y reducido en número, fácil de gestionar, bien comunicado entre sí e implicado en el proyecto.
Lo he vivido en mis empresas anteriores y es ciero, a mayor número de programadores no se corresponde un avance mayor del proyecto. Es más, en los últimos años, en mis tareas como consultor de Velneo he podido visitar «granjas» de desarrolladores en otras tecnologías que no hacían más que crecer en función de las demandas del cliente final, y que llegaban incluso a poner en peligro la viabilidad económica del proyecto.
Así que ya sabes, busca un equipo cualificado y lo suficientemente reducido, implícale en el proyecto (tienes que poner de tu parte para que se sientan así 😉 ), favorece la comunicación diaria entre ellos y conseguiras que tus proyectos mejoren en rentabilidad.
Un saludo.
Pues no estoy de acuerdo. A pesar de que las conclusiones parecen las naturales al acercarse a metodologías ágiles, creo que no es eso lo que dicen.
Por una parte, minimizar los recursos es un principio aplicable a todo tipo de proyectos, no exclusivo de las metodología ágiles, ni exclusivo de proyectos IT. Cuantos menos y más expertos, mejor. Cualquier jefe de obra apoya ese principio.
Un ejército de fuerzas especiales es carísimo. Y limita las operaciones que se pueden abordar.
Por otra parte, si aumentar los recursos no beneficia necesariamente los proyectos, reducirlos por debajo de cierto umbral también los perjudica:
– Un software para multinacional puede no ser adecuado si no refleja requisitos y peculiaridades locales tanto de usuarios como de negocio.
– Un software de alcance y ramificado puede requerir expertos en áreas específicas que engrosen inevitablemente el equipo.
Un ejemplo de esto puede ser el software para riesgo bancario en bancos multinacionales o el CRM de Zara o el punto de venta multinacional de Fiat. Cualquier producto Microsoft (dispone de su propia metodología ágil) o la mayoría del Open Source son ejemplos de equipos de desarrollo no necesariamente pequeños y próximos. Así es en Oracle, Apple, SAP… o Facebook.
Y es que el poder de las metodologías ágiles no está en la gestión de pequeños equipos y pequeños proyectos. Para ese viaje no hacen falta alforjas y son la forma natural y espontánea de trabajar. Esta idea de que «no sirve» si mi equipo y mi proyecto son grandes es el principal obstáculo para su extensión. Una suerte de leyenda negra que circula entre muchos clientes.
La potencia y efectividad de las metodologías ágiles se ponen de manifiesto en grandes proyectos. Con SCRUM bajo CMMI (no es una metodología) han salido adelante proyectos de enorme envergadura: hablo de miles de programadores y analistas repartidos en varios continentes.
Las software factory tienen el problema de la gestión y la metodología, más que del número y la tecnología. Si adoptan metodologías ruedan pero que muy bien. SCRUM sirve para Java, .Net o C++ ya que las metodologías son transparentes a la tecnología.
Por tanto una empresa de desarrollo puede crecer para alcanzar proyectos más grandes y variados de forma ilimitada, si la gestión y la metodología son adecuadas y se aplican bien. No se trata de que acudan a un sprint de 500 personas…
Así que opino que el tamaño no importa y está condicionado por el proyecto. Pero la metodología, sí importa. Y mucho. El mérito está en ser 500 y trabajar con la agilidad de 5.
Pues no estoy de acuerdo. A pesar de que las conclusiones parecen las naturales al acercarse a metodologías ágiles, creo que no es eso lo que dicen.
Por una parte, minimizar los recursos es un principio aplicable a todo tipo de proyectos, no exclusivo de las metodología ágiles, ni exclusivo de proyectos IT. Cuantos menos y más expertos, mejor. Cualquier jefe de obra apoya ese principio.
Un ejército de fuerzas especiales es carísimo. Y limita las operaciones que se pueden abordar.
Por otra parte, si aumentar los recursos no beneficia necesariamente los proyectos, reducirlos por debajo de cierto umbral también los perjudica:
– Un software para multinacional puede no ser adecuado si no refleja requisitos y peculiaridades locales tanto de usuarios como de negocio.
– Un software de alcance y ramificado puede requerir expertos en áreas específicas que engrosen inevitablemente el equipo.
Un ejemplo de esto puede ser el software para riesgo bancario en bancos multinacionales o el CRM de Zara o el punto de venta multinacional de Fiat. Cualquier producto Microsoft (dispone de su propia metodología ágil) o la mayoría del Open Source son ejemplos de equipos de desarrollo no necesariamente pequeños y próximos. Así es en Oracle, Apple, SAP… o Facebook.
Y es que el poder de las metodologías ágiles no está en la gestión de pequeños equipos y pequeños proyectos. Para ese viaje no hacen falta alforjas y son la forma natural y espontánea de trabajar. Esta idea de que «no sirve» si mi equipo y mi proyecto son grandes es el principal obstáculo para su extensión. Una suerte de leyenda negra que circula entre muchos clientes.
La potencia y efectividad de las metodologías ágiles se ponen de manifiesto en grandes proyectos. Con SCRUM bajo CMMI (no es una metodología) han salido adelante proyectos de enorme envergadura: hablo de miles de programadores y analistas repartidos en varios continentes.
Las software factory tienen el problema de la gestión y la metodología, más que del número y la tecnología. Si adoptan metodologías ruedan pero que muy bien. SCRUM sirve para Java, .Net o C++ ya que las metodologías son transparentes a la tecnología.
Por tanto una empresa de desarrollo puede crecer para alcanzar proyectos más grandes y variados de forma ilimitada, si la gestión y la metodología son adecuadas y se aplican bien. No se trata de que acudan a un sprint de 500 personas…
Así que opino que el tamaño no importa y está condicionado por el proyecto. Pero la metodología, sí importa. Y mucho. El mérito está en ser 500 y trabajar con la agilidad de 5.
Muchas gracias por tu comentario Paco.
Evidentemente no es una ciencia cierta, pero en empresas como la nuestra en la que desarrollamos una plataforma de desarrollo de aplicaciones empresariales, el hecho de disponer de un equipo reducido, eso sí, como bien dices sin llegar a superar el umbral mínimo, nos permite ser lo suficientemente ágiles como para incorporar las necesidades de los clientes, el porcentaje lógico de I+D, y las mejoras necesarias todo de una forma rápida y eficaz.
Un saludo.
Muchas gracias por tu comentario Paco.
Evidentemente no es una ciencia cierta, pero en empresas como la nuestra en la que desarrollamos una plataforma de desarrollo de aplicaciones empresariales, el hecho de disponer de un equipo reducido, eso sí, como bien dices sin llegar a superar el umbral mínimo, nos permite ser lo suficientemente ágiles como para incorporar las necesidades de los clientes, el porcentaje lógico de I+D, y las mejoras necesarias todo de una forma rápida y eficaz.
Un saludo.