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
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 responsableQue 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.
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
Código no es un snapshot, es algo en movimiento
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