El arte del patadon pa'lante / Postponer decisiones técnicas

24/6/2013 Actualización de formato y añadidas referencias

Este post contiene la esencia de lo que estamos haciendo en Alea Soluciones para postponer en todo lo posible las decisiones técnicas. Vamos a usar este post como base para compartir nuestras experiencias al respecto en el AOS2013

Comenzamos:

Nuestro contexto

• Hacemos productos en entorno de telecomunicaciones
• Equipo Extreme Programming
• Deploy continuo / Entrega continua

A qué nos referimos

Postponer todas las decisiones técnicas hasta el último momento responsable

Que no postponemos

• La forma en qué hemos decidido trabajar (de forma ágil, deploy continuo, extreme programming)
• El lenguaje base de desarrollo  de cada componente... python...
• Buenas prácticas de OO

Por qué queremos postponer / Beneficios conseguidos

• Cuanto más tarde tomemos una decisión más conocimiento tendremos del negocio y del entorno técnico
• Soluciones más simples/sencillas
• Soluciones más pequeñas
• Trabajar menos :-)
• Más probabilidades de no hacer nada que no aporte valor real ahora
• Más probabilidades de no hacer sobre ingeniería
• Menos esfuerzo en rehacer trabajo si es necesario
• Nuestro objetivo es tener mucho juego de cintura... reaccionar bien y rápido a cualquier cosa... y sin echarnos las manos a la cabeza
• Cuanto más postponemos, menos llenamos la mochila.... es más dificil coger lastre y tendemos a viajar ligeros.... añadimos menos cosas innecesarias.
• Todos sabemos que una mudanza se hace fácil si tenemos pocas cosas
• Una buena arquitectura nos permite postergar decisiones importantes, esto no significa que estemos obligados a hacerlo. Sin embargo, al poder postergarlas tenemos muchísima flexibilidad.

Esta forma de actuar está alineada con los principios lean de eliminar el desperdicio y los principios ágiles de post poner hasta el último momento responsable y es una  de las forma de actuar que mas puede ayudar  a la creación de un arquitectura limpia. A su vez una arquitectura limpia hace que sea mas fácil post poner otras decisiones.

Cómo lo hacemos

• Postergamos las decisiones de forma consciente y meditada
• Consideramos una decisión como buena cuando:
• nos compromete lo mínimo posible
• nos permite postponer otras decisiones
• Es fácilmente cambiable
• Ataca un problema actual (no futuro)
• Suficientemente bueno (sin sobreingenieria, ni nuestra ni de otra gente)
• Prohibido Megaconstrucciones
• Reusamos librerías pero no Frameworks (vamos no dejamos que nos usen a nosotros)
• Consideramos qué todo se puede cambiar (código / diseño / proceso)
• Cuanto vamos a afrontar un sprint o un grupo de funcionalidades nos centramos en identificar qué tenemos que cambiar en nuestra arquitectura y nuestro entendimiento del dominio / lenguaje ubicuo.
• y lo que se decidió era lo correcto en ese momento y en ese contexto y si hay que cambiarlo, no pasa nada, manos a la obra...
• Método Hamburguesa descomposición de PBIs grandes.
• Clean Code
• DDD (u otra variante que permita que la arquitectura no se centre en las herramientas BD, GUI, etc)

Qué necesitamos para hacer fácil postponer.

• seguridad/confidence
• Feedback temprano
• TDD
• Refactor continuo
• Todo se pueda cambiar

Dividimos cambios medios/grandes en cambios pequeños, incluso duplicando código y duplicando datos... todo con el objetivo de poder postponer decisiones, no impedir deploy y hacer cambios incrementales, pequeños y seguros.

Código no es un snapshot, es algo en movimiento

Siempre puedes iterar... iterar/refactorizar es fácil sin miedo y con red... TDD, BDD...

Problemas/Sensaciones que genera postponer decisiones...

• Incertidumbre
• Ansiedad
• Conflicto (como ingenieros)

Postponer... hasta el infinito y más allá...

Hasta el último momento responsable!!!!

Referencias:

• Método Hamburguesa para descomposición de historias de usuario http://gojko.net/2012/01/23/splitting-user-stories-the-hamburger-method/
• Articulo relacionado recomendado Real options enhance agility http://www.infoq.com/articles/real-options-enhance-agility  Gracias Marcin
• Domain Driven Design http://www.domaindrivendesign.org/
• Clean Architecture http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html 
• Hexagonal Architecture http://alistair.cockburn.us/Hexagonal+architecture