Saturday, June 22, 2013

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:

2 comments:

Unknown said...

Interesante articulo y buena argumentación. Siempre mola conocer experiencias reales. Estais de algún modo midiendo de algún modo si las decisiones de posponer o no posponer son correctas?

eferro said...

La verdad es que no estamos midiendo... (esa es otra de las cosas que postponemos...)
Lo que si que es verdad es que desde que estamos en este proceso, el sistema se ha convertido de un sistema centralizado a varios sistemas, uno de ellos centralizado y otro distribuido, se ha cambiado de persistencia para los agregados y de sistema de indexación y hemos realizado algunas refactorizaciones importantes, tanto de negocio como de infraestructura. Todos estos cambios se han realizado sin miedo, sin ansiedad y sin sentir que estabamos tirando la mitad de la aplicación...

En lo que si que tenemos mucho margen de mejora es en postponer decisiones de negocio e historias de usuario y hacer un desarrollo más Lean.