“La
perfección no se logra cuando no hay nada más que añadir, sino cuando no hay
nada más que quitar” [Antoine de Saint
Exupéry]
En
el último conversatorio sobre Scrum que facilitamos en la Comunidad de Ágiles
Colombia en Medellín, hablamos de lo que significa ser ágil y llegamos
necesariamente a los valores y principios del Manifiesto ágil. Uno de los principios llamó especialmente la
atención: “La simplicidad, o el arte de
maximizar la cantidad de trabajo no realizado, es esencial.”
Luego
me encontré un artículo* de alguien que decía que había vivido gran parte de o
toda su vida sin usar el trinomio cuadrado perfecto y muchas otras cosas
complejas que le enseñaron en la escuela. A pesas de mi fascinación por el
Álgebra, tuve que ceder un espacio en mi mente para estar de acuerdo con este
pensamiento.
La
tarea que me quedó fue entonces definir qué significaba #simplicidad y qué era
eso de ‘maximizar’ el trabajo no realizado. Aquí algunas pistas:
Simplicidad es:
- Tener un equipo totalmente horizontal, sin títulos ni especialidades adheridas a la frente de cada miembro, sin protocolos que seguir para comunicarse unos con otros, incluyendo al usuario, donde cada uno sea responsable de sincronizarse con los demás y que nadie le rinda cuentas a nadie. Son equipos altamente productivos.
- Usar un framework que te permita adaptarte a los continuos cambios del entorno, que te permita inspeccionar tu situación y la de tu equipo y con el que puedas modificar tu comportamiento basado en la experiencia que vas adquiriendo. Un framework que no sea una fuente de artes adivinatorias, sino más bien que evolucione contigo.
- Priorizar las características del producto y construir solo aquellas que entreguen valor al usuario y al negocio. Según algunos estudios más del 65% del software que se construye se deja de usar muy pronto o nunca llega a instalarse, así que ¿por qué no construir solo lo que el usuario verdaderamente necesita y que genere un alto valor para la organización? Construye solo necesario para obtener rápida retroalimentación.
- No realizar estimaciones a mediano/largo plazo ni prometer una fecha fija de entrega. No componer planes súper elaborados sino planificar continuamente: planificar las entregas/salidas a producción, planificar las iteraciones o sprints, planificar cada día de trabajo. A la larga, los planes no son nada, pero la planificación lo es todo.
- Usar herramientas simples, como tableros de tareas simples que estén a la vista de todos, tarjetas simples con lo que quiere el usuario (las historias de usuario: como <<usuario>> quiero <<hacer algo>> para <<obtener algún valor>>): no hagas nada a menos que su valor esté plenamente establecido. Elaborar la documentación suficiente para cubrir las necesidades de la organización.
- No usar trinomios cuadrados perfectos todo el tiempo. Einstein lo dijo, las cosas deberían hacerse lo más simple posible… para construir algo, una funcionalidad por ejemplo, usa la técnica de reusar-comprar-hacer. Consulta primero si ya la tienes o la tiene alguien cercano a ti. ¿No? Búscala entonces en el mercado. ¿No la encontraste? Fabrícala, pero hazlo de manera simple, sin artificios exagerados, no vuelvas el software más complejo de lo que es por naturaleza.
 |
| "Pero no más simples" |
- Aprender continuamente. Si conoces muchas cosas, encontrarás respuestas cada vez más simples a problemas cada vez más complejos, como los que surgen en la construcción de productos de software. Así que nunca pares de aprender. Y conviértete en maestro, pero recuerda, no se trata solo de decir las cosas, porque tu aprendiz las olvida; tampoco se trata solo de enseñar, porque quizás solo logres que él/ella las recuerde; involúcralo y verás que también aprende.
¿Qué
más se les ocurre que es #simplicidad? Háganmelo saber por este medio o por
cualquiera de los medios habituales de comunicación.
*El artículo al que me refiero lo encuentran haciendo clic aquí.
