Mes: agosto 2018

El riesgo de los Frontend Developers

En una época los developers se identificaban con lenguajes: java developer, c-sharp developer, python developer, etc y algunos aún se identifican así.

Pero da la impresión que las nuevas generaciones ya no se identifican con lenguajes (¡bien!) sino con las capas de la aplicación (¡oops!): frontend developer, backend developer, etc.

Este último enfoque me resulta riesgoso, porque desde el punto de vista del usuario las aplicaciones tienen funcionalidades que requieren tanto de front como de back. Me parece bien que un developer se especialice en una capa siempre y cuando tenga también la capacidad de trabajar también en otras. En una palabra yo esperaría que un developer pueda hacer una funcionalidad de punta a punta y esto es justamente lo que no estoy viendo en muchos casos. Me ha tocado trabajar en equipos donde los developers solo tenían instalados en sus máquinas el runtime/ambiente para correr su capa. Este tipo de escenarios suele generar las siguientes situaciones:

  • Un developer no puede estimar el esfuerzo de construir una funcionalidad completa porque solo conoce de una capa. Esto trae complicaciones de gestión y visibilidad hacía el usuario.
  • Desbalance y tiempos muertos: el equipo se compromete a desarrollar un conjunto de funcionalidades que requieren distinto esfuerzo en cada capa haciendo que en un determinado momento los devs de una capa esten muy ajustados mientras que los de la otra estén sin trabajo y terminen trabajando en cosas de menor prioridad.

Estas situaciones no tienen que ver particularmente con los frontend-devs sino con esta separación en capas, pero que a mi parecer  se manifiesta más fuertemente en los frontend-devs.

Mi recomendación es armar los equipos con fullstack-devs y en términos más generales con gente de perfil-T, o sea, especialistas en una cuestión (palito vertical de la T) pero con conocimiento general en el resto de las cuestiones (palito horizontal de T).

Pero en un postura de abogado del diablo alguien podría decir  que el problema no es del chancho sino de quien le da de comer. O sea, la culpa no es de los «capa-developers» sino de las organizaciones que los buscan y arman equipos con ellos.

Continuará…

(nobleza obliga: algunas de estas ideas las terminé de redondear con mi colega Matias Gorostegui, gracias Goros)

Cuestión: Duración de la iteración

Una de las decisiones que debe tomar un equipo que decide trabajar en forma iterativa es la duración de sus iteraciones. Según nuestro estudio de prácticas ágiles en la comunidad latinoamericana, el 74% de los encuestados reportó trabajar con iteraciones de 2 semanas.

Yo personalmente me siento más cómodo trabajando con iteraciones de 1 semana, pues eso lleva a una agenda más uniforme cosa que me sienta más cómodo:  se que el mismo día todas las semanas tengo reuniones de planificación, revisión y retrospectiva.

Sin embargo, en varios de los últimos proyectos que he trabajado hemos utilizado iteraciones de 2 semanas pues tanto el cliente como la mayoría de los miembros del equipo así lo preferían. En estos casos logramos cierta uniformidad semanal estableciendo un día recurrente para las reuniones: en la semana 1 hacíamos review/retro/planning y la semana 2 usábamos ese mismo espacio horario para hacer refinamiento y mid-sprint-demo.

Workshop de Escalabilidad en Auth0

El sábado pasado estuve facilitando un taller de escalabilidad organizado conjuntamente por la gente de FreeCodeCampBA y Auth0. El taller se realizó en la oficinas de Auth0 y duró poco más de 3 horas. Vimos un poco de teoría y mucha práctica usando AWS y Nginx. La evaluación general de los participantes fue de 9.2/10 lo que me deja muy contento 🙂

Los slides están disponibles aquí.

Materiales de Extreme Programming Moderno

El lunes pasado estuve en Santiago de Chile y participé en un meetup organizado conjuntamente por la gente de Chile Ágil y Software Crafters Chile. En ese contexto estuve hablando de Extreme Programming Moderno. Comparto aquí algunos recursos que mencioné:

Agradezco a Loreto Arriagada y David Lay por haberse encargado de la organización.

My summary of Agile 2018

In my  opinion the best part of  the conference was what happen outside the sessions: informal talks with old and new colleagues.  Beyond that, I really enjoy some of the sessions.

  • I liked the keynote session by Troy Magennis about Agile Data (video here)
  • The session «Database DevOps: Strategies to Address DevOpsLast Mile» by Scott Ambler was really interesting (slides here)
  • One of the most interesting sessions for me was  «Building evolutionary cloud infrastructure«, it presented a really useful model (slides here). Beyond the slides some of the content of the session is available in the website infrastructure-as-code.com
  • The Impact Mapping workshop delivered by John Hughes and Rachet Whitt allowed me to practice this technique for the first time and I think I will include it in software engineering course.
  • The session «Stepping Stones in Refactoring to Microservices» delivered by Amr Noaman (slides here) provided a interesting but controversial method to move to microservices

There were some other sessions that I couldn’t attend and that received very good feedback from my collegues:

  • Agile Quantified (Measuring the impact of Agility) by Larry Maccherone (no slides available)
  • The 12-factor pipeline by Juni Mukherjee (slides here)

Finally, I am very happy with the session I delivered: «Principles of Self-Service Infrastructure«, it was recorded so I will shared the video as soon as the organization publishes it.

 

 

Preparando la tercera edición de MeMo2 (95.21 / 75.10)

Se acerca un nuevo cuatrimestre y como de costumbre estamos haciendo ajustes en la planificación de la materia. Comparto aquí algunos datos importantes para aquellos alumnos que estén evaluando anotarse en nuestro curso este segundo cuatrimestre de 2018.

  • La materia se dictará lunes y jueves de 19 a 22.
  • El equipo docente estará conformado por Emilio Gutter y por quien escribe.
  • Estimamos que los alumnos deberán dedicar aproximadamente unas 7 horas de trabajo semanal extra-clase.
  • Mantendremos la misma propuesta pedagógica, la cual implica: clase invertida y trabajo continuo todas las semanas.
  • Continuaremos trabajando con el mismo stack de herramientas/tecnologías (Ruby, Padrino, GitLab, Heroku) e intentaremos agregar algo de Infraestructura como Código y Monitoreo.
  • Tendremos dos trabajos prácticos grupales.

Más allá de todo esto, estamos realizando varios ajustes a las clases.

Agile Disciplinado, ¿curioso u obvio?

Agile Disciplinado (Disciplined Agile) es el nombre del enfoque/marco ágil propuesto por Scott Ambler. La primera vez que escuche este nombre me hizo reflexionar:

  • Por un lado me gustó, porque me gusta el trabajo disciplinado y al mismo tiempo porque creo que si bien en general los métodos ágiles tienen pocas reglas, seguirlas suele requerir de bastante disciplina*.
  • Por otro lado me pareció muy apropiado, ya que en ciertos ambientes hay una percepción de que los métodos ágiles son «medio hippies» o «poco serios» (para algunos armar un plan de proyecto pegando post-it en una pared resulta nada serio).  Dado este contexto, decir «Agile Disciplinado» suena a decir «esto es agile, pero de verdad, no somos hippies».

Esta sensación inicial me llevó a indagar un poco más sobre este enfoque y para ello decidí leer el libro de referencia. El enfoque está planteado en forma integral desde una perspectiva general de la organización (en este sentido el enfoque de Agile Disciplinado se presenta como una alternativa más en el contexto de los métodos de transformación agile).  El enfoque hace mención explícita a temas organizacionales y técnicos incluyendo: diseño de arquitectura, control de configuración y calidad entre otros, todo con una visión Lean/DevOps.

*comparados con métodos orientados al plan como UP, la cantidad de reglas propuestas por los métodos ágiles es muy menor