«Cierta cantidad de estos fenómenos han sido agrupados bajo el nombre de
“Ingeniería de Software”.
Así como la economía es conocida como “La Ciencia Miserable”, la ingeniería de software debería ser conocida como “La Disciplina Condenada”, condenada porque ni siquiera puede acercarse a su meta, dado que la misma es en sí misma contradictoria.
La ingeniería de software, por supuesto, se presenta a sí misma como otra causa valiosa, pero es un colirio: si lee cuidadosamente su literatura y analiza lo que realmente hacen quienes se avocan a ella, descubrirá que la ingeniería de software ha adoptado como su estatuto “Cómo programar si usted no puede”».
— Edsger Dijkstra
Está de moda criticar la agilidad y hay buenas razones para esto. Muchos no le encuentran sentido a tanta ceremonia. Otros alegan que no es ingeniería si no hay procesos ni documentación. Las críticas, por supuesto, van casi siempre a lo accidental, pero no a lo esencial.
¿Sirve la agilidad? ¿Cumple su promesa? Pues primero habría que preguntarse cuál es la promesa que no se cumple.
El problema, en mi opinión, parte por no entender el fin último de nuestra actividad.
La forma del equipo
La estructura del equipo sigue a la metodología de software. Cuando usábamos cascada teníamos una estructura más o menos como la de la figura 1.
El equipo estaba dividido en roles que se hacían cargo de la respectiva etapa del proceso. Este proceso de desarrollo de software parte de un fundamento esencial: la especificación de requerimientos es rigurosa, cubre todo lo que se necesita, y el arquitecto ha hecho un trabajo de diseño acucioso. En este modelo los programadores casi no tienen que pensar, son simples codificadores, el problema ya ha sido resuelto antes. Antes se llegaba a dibujar diagramas de flujo con la especificación de los algoritmos, que eran traducidos por los programadores en algún lenguaje específico. Esto pudo haber funcionado en algún momento, pero suele colapsar, por varias razones.
Una supuesta ventaja que tenía esta configuración es que los distintos roles quedaban desocupados al finalizar su etapa y podían ser reasignados a otros proyectos. Pero en la práctica no era tan simple. Las etapas se atrasan, se producen tiempos muertos, o a veces cuesta ubicar a alguien para resolver una duda porque está asignado a otro proyecto. Más que un equipo, tenemos silos funcionales que cumplen su parte en cada etapa y hay un cambio de manos en momentos específicos.
Luego viene la “transformación digital” y se le pide a este equipo que se vuelva ágil y aparece el concepto de “célula ágil”, que tiene una forma como la de la figura 2.
Esto obliga a reconvertir o mapear roles, una de las principales víctimas suelen ser los analistas, por el principio ágil que dice, “software funcionando sobre documentación extensiva”. En la figura 2 mantuve a los analistas (en amarillo) y los reasigné convirtiendo a uno en “Agile Coach” y a otro como QA. Noten que les cambié los nombres a los programadores, testers y sysadmin. QA significa Quality Assurance, pero así también les dicen a los testers, y DevOps es un movimiento, pero es la etiqueta que les ponen a los SysAdmin para volverlos ágiles 🤷🏻♂️. No estoy de acuerdo con esa nomenclatura, pero es lo que suele pasar.
Otra discusión que aparece es sobre quién se hace cargo de los roles de Scrum Master y Product Owner, pues se suele adoptar SCRUM como la metodología ágil para toda la organización. Esta discusión se visualiza en la figura 3.
Originalmente, el Scrum Master (SM) era un rol que lo ejercía uno de los desarrolladores. No era alguien que estuviera dedicado a eso. Yo sospecho que en lo que pensaban los creadores de SCRUM era en uno de los desarrolladores más “senior” que cumple con la función de dirigir las ceremonias, y preocuparse de destrabar bloqueos. Posteriormente, se convirtió en un rol que además se preocupa del liderazgo técnico y sobre todo un “guardián” de la metodología. Como el SM se convirtió en un trabajo de tiempo completo, el rol de promover los valores ágiles y cuidar que la metodología se mantuviera pura, se dejó en manos del “Agile Coach”, que a veces es un externo, la persona que vende la asesoría de transformación de la organización. Pero a veces es alguien interno, un entusiasta que ha estudiado las metodologías y se convierte en el “evangelizador” del método.
Agilidad es flexibilidad y rapidez
Ahora les propongo comparar el equipo de la figura 4 con la célula de la figura 3.
¿Cuál creen ustedes que es el equipo más ágil?
El equipo de la figura 4 tiene un líder, que es el que gestiona la labor del mismo. Define los proyectos que se abordan, es el nexo con el resto de la organización, negocia plazos, establece objetivos, gestiona los proyectos, etc. Hay uno o quizás dos o tres personas que se encargan de la definición de los requerimientos desde la perspectiva del negocio, acá los llamo product manager, pero pueden ser analistas de negocio o algo similar. Son las personas que decantan los requisitos del software que es construido por los ingenieros de software. Los ingenieros de software se encargan de analizar, diseñar, arquitectura, programar, probar y desplegar el software.
No hay testers, porque el testing es automatizado y es escrito por los mismos ingenieros. Hay pruebas funcionales que se conducen en conjunto con los usuarios finales, o a través de experimentos en vivo. Tampoco hay “sysadmins” o “devops”, pues se apoyan en con lo que se conoce como “Platform Engineering” algo de lo que hablaré en un próximo artículo.
La verdadera agilidad se da en este equipo por las siguientes razones:
Se reduce el “cambio de manos” entre etapas. Los múltiples roles dedicados en cada etapa del proceso, lo único que hacen es generar “pérdida de proceso”1
Hemos aumentado significativamente la cantidad de personas que saben programar.
El gran error de la metodología de cascada y de Scrum y otros métodos similares tiene su raíz en algo esencial. Hay demasiada gente en estos equipos (tradicionales o “ágiles”) que no saben programar. He visto equipos en que hay más testers que programadores. O en que los analistas han pasado meses escribiendo un mamotreto de cientos de páginas que nadie llegó a leer nunca.
No puedes ser ágil ni hábil en algo si no sabes hacerlo. Así que la clave es primero contratar a gente que sepa desarrollar software, y la única forma que funciona es programando. Una vez que tienes a ese grupo de personas, empodéralos y déjalos hacer lo que saben hacer, y vas a ver cómo funciona. Si hacen sprints o retrospectivas, es realmente secundario.
Pérdida del proceso en mi blog.
hola Eduardo gracias por el post! Nosotros llegamos a algo muy parecido a 4., excepto que todavía tenemos un sysadmin para mantener la infraestructura. Tienes alguna estimación del número óptimo de Ingenieros de Software que aguanta ese modelo ? Supongo que pasada una cantidad debería haber una "mitosis" ?
Gran post, Eduardo.
En todo caso, haciendo de abogado del diablo, la figura 4 muestra un equipo de un único rol (software engineer) haciendo muchas cosas y entre ellos se tendrán que auto-organizar de alguna forma. Un manager "tradicional" va a preferir algo más estructurado (como en las figuras 1 y 2), con roles, actividades y responsabilidades ya que tiene más control.
De hecho, igual queda la duda ¿como se organizarían internamente los ingenieros de la figura 4? ¿como la figura 2?