Evento: Desarrollo de Software en la era Post-Agile

Desde la Universidad Nacional de Tres de Febrero estamos organizando este evento en la previa de Agiles 2019. El evento lo estamos organizando desde el grupo de investigación en Procesos y Prácticas Agiles de Desarrollo de Software. Más allá del título (que lo pusimos con alguna intención marketinera) la idea es compartir lo que estamos viendo en la industria y en la academia en nuestras investigaciones sobre Desarrollo Ágil. Adicionalmente vamos a compartir lo que estamos haciendo en nuestra carrera de grado en UNTreF y vamos a anunciar nuestro primer seminario de postgrado sobre Software Delivery. A modo de cierre tendremos la presentación de una caso de industria a cargo de Diego Marcet (ContolShift Labs)

El evento se llevará a cabo el martes 17 de Septiembre a las 19.00 hs. (puntual) en la sede Buenos Aires del rectorado de UNTreF (Juncal 1319, Ciudad de Buenos Aires)

El evento es de entrada gratuita pero require registración (aquí).

Este es el texto que estamos usando en los flyers de difusión:

Agile alcanzó el mainstream, se filtró más allá del desarrollo de software y habilitó múltiples oportunidades de negocio. Trajo consigo una nueva mirada del desarrollo de software y el mundo del trabajo. En este proceso de difusión surgieron también distorsiones y oportunistas. Actualmente Agile perdió parte de su significado, muchas personas y organizaciones se consideran Agile sin casi haber recorrido mucho camino ni implementar sus prácticas. Sin embargo Agile marcó un antes y un después en la forma en que desarrollamos software y aportamos valor al negocio. A partir de esta mirada desafiante proponemos este espacio para compartir avances en investigación y experiencias reales de implementación en la industria.

Estudio formal sobre la enseñanza de Agile en Argentina

El año pasado empecé a trabajar en un estudio formal sobre la enseñanza de Agile. Más precisamente sobre la enseñanza de Métodos y Prácticas Ágiles de Desarrollo de Software. Fue así que en el contexto del la conferencia CONAIISI 2018 realicé una encuesta entre los estudiantes allí presentes. A partir de los datos recolectados en esa encuesta escribimos un artículo que enviamos al Workshop Brasilero de Métodos Agiles. Para nuestra alegría el artículo fue aceptado, será publicado en los proceedings de la conferencia y yo lo estaré presentando este miércoles.

Agradezco a todos los que participaron de la encuesta y comparto aquí algunos de los hallazgos más relevantes.

  • Al artículo se llama Initial Assessment of Agile Development in the Undergraduate Curricula
  • Conseguimos 62 datapoints (cantidad de encuestas respondidas) correspondientes a representantes de 14 universidades distintas
  • El 76% de los estudiantes avanzados indicaron haber estudiando Agile
  • Entre las prácticas más estudiadas (por encima de 60%) encontramos: Continuous Integration, Pair-Programming, Test Automation y Desarrollo Iterativo
  • Encontramos dos curiosidades importantes que sugieren que Agile puede estar siendo estudiado de forma muy superficial:
    • El 65 % de quienes respondieron haber estudiado Scrum indicaron que no estudiaron Retrospectivas
    • El 58% de quienes respondieron haber estudiado Extreme Programming indicaron no haber estudiado Test-Driven Development

Estructura de equipo para desarrollo de producto

Desde hace un tiempo estoy trabajando un equipo de producto de más de 20 personas y estamos organizados en una estructura que es nueva para mi pero que al mismo tiempo me parece viene resultando efectiva. La siguiente figura resume esta estructura.

Si bien todo el equipo de producto son más de 20 personas, en el día a día estamos divididos en 4 equipos: 3 feature teams y 1 equipo de toolsmiths (este nombre lo tomé del enfoque FDD, pero no es el nombre real del equipo)

Los 3 feature teams trabajan en funcionalidades del producto y están en el día a día con gente de negocio.

El equipo de toolsmiths es donde yo trabajo. Actuamos como proveedores/facilitadores de los features teams y nos encargamos de mantener/optimizar la infraestructura de desarrollo: repositorios, build server, ambientes, etc. Incluso en ocasiones agregamos código al producto, pero obviamente relacionado a cuestiones de soporte/infra como feature flags, health endpoints, etc. Como parte de nuestro trabajo tenemos que interactuar con otros grupos de soporte organizacional que se encargan de infraestructura de base y regulaciones (seguridad, red, etc). En el equipo somos 3 personas con skills mixtos: podemos codear, agregar tests, configurar servers, scriptear infraestructura pero sobre todo podemos hablar con otros grupos y generar concenso. Alguien podría tentarse de decir que somos DevOps, pero no lo vemos así, porque de entrada no creemos que DevOps sea ni un rol ni un área, sino un mindset con un conjunto de prácticas.

No se si este es el mejor enfoque para la estructura de un equipo de producto, pero consideramos que nos viene resultando bien: el negocio está contento, los distintos equipos están contentos, el producto está estable y tenemos la capacidad de ir a producción bajo demanda y de forma altamente automatizada.