Posponer decisiones
•Descargar como PPTX, PDF•
1 recomendación•702 vistas
Posponer hasta el último momento responsable nos permite conocer mejor el problema a resolver, crear soluciones más sencillas y mejor adaptadas al problema. Pero para poder posponer estas decisiones, se requiere que nuestro proceso y nuestro diseño de software, esté preparado para ello. Esto incluye hacer todas estas decisiones conscientes y explícitas. Asumir que lo que se decida es lo mejor que se pudo decidir en ese momento con lo que sabíamos y que si en el futuro se ha de cambiar, no hay problema. Ya se sabe; la única constante es el cambio. Así que mejor abrazar el cambio. Dicho así suena sencillo, pero la realidad es un poco más complicada. Posponer decisiones, desde el punto de vista técnico, significa que decisiones tan importantes como la persistencia de los datos, los tipos de comunicación entre los componentes, o en algunos casos, hasta el lenguaje usado para desarrollar algunas de las partes, se van a proponer a etapas muy avanzadas del desarrollo. Como además desarrollamos de forma ágil significa que muchas de estas decisiones llegarán cuando el sistema ya lleve tiempo en producción. Esto pone mucha presión en la calidad técnica del sistema, en tener una arquitectura fácil de evolucionar y un sistema fácil de modificar (confiable, con tests, feedback, etc). Esta charla explicará los motivos para posponer, las ventajas, las dificultades y explicará de forma práctica qué podemos hacer para posponer decisiones (arquitectura, simple design, parallel changes, etc). También se explicarán algunas estrategias para descomponer historias de usuario de forma que parte de ellas se puedan posponer (incluso indefinidamente si existen otras prioridades).
Recomendados
Más contenido relacionado
Similar a Posponer decisiones
Similar a Posponer decisiones (20)
Más de Eduardo Ferro Aldama
Más de Eduardo Ferro Aldama (14)
Último
Último (20)
Posponer decisiones
- 4. ¿De dónde sale esto? @eferro
- 5. ¿A qué nos referimos? Hacer una ÑAPA(™) rápida No decidir nada Dejar que otros decidan @eferro
- 6. ¿A qué nos referimos? Posponer todas las decisiones hasta el último momento responsable(™) Mantener opciones abiertas lo máximo posible @eferro
- 9. Naturaleza Humana Decisión correcta Decisión incorrecta (no óptima) Incertidumbre (posponer decisión) @eferro
- 10. Motivos Más conocimiento del problema Aportamos valor real (ahora) @eferro
- 11. Motivos Minimiza el trabajo a realizar Minimiza el código Menos coste @eferro
- 12. Menos Complejidad “Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.” Alan Perlis @eferro
- 13. No posponemos Cultura ágil Prácticas técnicas / Build Quality in @eferro
- 14. Software NO es valor Software es inventario Valor impacto positivo de negocio Cómo entiendo el software @eferro
- 15. Nos COMPROMETE POCO ¿Cómo lo hacemos? Una decisión es buena, si... Nos permite POSPONER otras Es fácilmente REVERSIBLE Ataca problema ACTUAL (no futuro) @eferro
- 16. ¿Cómo lo hacemos? Pensamos en... ¿Qué es lo peor que puede pasar? ¿Cuánto tardamos en rehacerlo? ¿Hasta cuándo posponemos…? @eferro
- 17. ¿Cómo lo hacemos? Pensamos en... Todo se puede cambiar…. Código / Proceso / Diseño / etc. @eferro
- 19. ¿Cómo lo hacemos? Generamos el hábito... Decisiones conscientes @eferro
- 20. NEGOCIO @eferro
- 21. ¿Cómo lo hacemos? No hacemos lo que nos dicen Somos parte del negocio Entendemos el problema @eferro
- 22. ¿Cómo lo hacemos? Validamos, NO suponemos ¿Cuánto es baja latencia? ¿Usuarios concurrentes? Siempre hablando de coste @eferro
- 23. @eferro
- 24. ¿Cómo lo hacemos? No hace falta automatizarlo todo Quizás el happy path cubre el 80% PARETO 80/20 @eferro
- 25. TÉCNICA @eferro
- 26. ¿Cómo lo hacemos? Uncle Bob “Buena Arquitectura es aquella que nos permite posponer decisiones…” @eferro
- 27. ¿Cómo lo hacemos? ● Infraestructura desacoplada ● Código USABLE (no reusable) ● Piezas pequeñas @eferro
- 28. ¿Cómo lo hacemos? ● Cuidado con la aplicación del DRY ● Abstracciones prematuras ● Optimizaciones prematuras @eferro
- 30. ¿Cómo lo hacemos? Arquitectura evolutiva Bajo coste de cambio (TDD, IC…) Entrega Continua Optimizamos para borrar código @eferro
- 31. Problemas y Sensaciones Incertidumbre Ansiedad Conflicto como ingenieros @eferro
- 33. Conclusiones ● Prácticas técnicas (fácil cambiar) ● Buena Arquitectura ● Piezas pequeñas Posponer decisiones técnicas @eferro
- 34. Conclusiones ● Participamos en negocio ● Validamos (no asumimos) ● Mindset experimentación Posponer decisiones negocio @eferro
- 36. Inspiración Dan North, Christ Matts, Kent Beck, Uncle Bob, Tom&Mary Poppendieck, W.E. Deming, Alan Cyment, Martin Fowler, Ariel Ber, Ron Jeffries, Gene Kim, Marty Cagan, Greg Young @eferro
- 38. Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) http://www.eferro.net @eferro
Notas del editor
- Unos 30 años apasionado por crear cosas usando software. Los últimos 20, con dinero de por medio. Los últimos 10 años muy interesado en cómo lo hacemos, mejorando la colaboración, trabajando en equipo. Supongo que ya superada la fase de ameba tecnológica. Sistemas industriales, de gestión, de telecomunicación, retail, grandes, pequeños, embebidos, en la nube, en diversos lenguajes, programando, automatizando, operando… de todo. Menos frontend / temas visuales. Soy un negado… (de momento)
- Todo lo que voy a contar proviene de la experiencia práctica durante mis últimos 4 o 5 años en Alea Soluciones y un poco más de un año en TheMotion. Ambas empresas tienen la características que hacen productos, la primera para operadores de telecomunicaciones y la segunda have vídeos a gran escala para publicidad. La características de tener tus propios productos para clientes externos son: Las decisiones que tomes, te las comes (al contrario que en proyectos, que normalmente se lo come otro) Los usuarios no tienen que tragar con lo que les des, pueden elegir (al contrario que con empresas de desarrollo interno)
- Roadmap / Mapa tiene opciones Según avanzamos surgen nuevas opciones y desaparecen otras Incluso podemos cambiar el destino durante el camino Tener opciones es la base de la agilidad Es lo que nos permite abrazar el cambio Justo lo contrario a lo que suelen llamar un roadmap en el desarrollo de productos de software, que muchas veces es lineal y no tiene opciones… vamos que no es un roadmap Un backlog si no sirve para tener opciones, es un gantt puesto en vertical. Y algunas veces además el backlog, sólo es un gasto, una forma fácil de quitarnos de en medio el pensar sobre el producto.
- Es importante conocer por qué nos cuesta tanto tomar posponer decisiones. Los humanos ODIAMOS la incertidumbre. Todos los experimentos indican que la gente prefiere tomar una decisión incorrecta o poco optima antes que tener que vivir con la incertidumbre que genera posponer una decision Una posibilidad para que no cueste tanto es posponerla, pero fijando que condiciones se tienen que dar para que la tengamos que tomar. Por ejemplo, no lo decidimos ahora, pero lo vamos a decidir cuando tengamos implementado las analiticas basicas y podamos medir X...
- Más conocimiento del problema: Este es el motivo más evidente. Nuestras soluciones siempre serán más adaptadas y concisas si tenemos toda la cantidad de conocimiento posible del problema a resolver. Esto implica que no tenemos que crear algo abstracto que sirva para todo. Esto está relacionado con la manía malsana de seleccionar un framework tecnico el dia 0. Aportamos valor real: Posponiendo decisiones nos podemos centrar en las decisiones que no se pueden posponer, que seguramente no se puedan posponer pq ahora es el momento adecuado. Es decir, pq aportan valor ahora
- Cuando decidimos muy pronto, nos obligamos a solucionar problemas que aun no tenemos (y que puede que no tengamos nunca), tenemos que hacer el megasistema configurable, eso deriva Menos es más: posponer la decisión suele equivaler a no introducir más complejidad, de código y/o en el negocio. Es una forma de ayudarnos a ser MINIMALISTAS durante la creación del producto. Con mochila pequeña, se viaja cualquier sitio y muy rápido.
- Normalmente cuando entre el impulso de decidir y la decisión existe un tiempo de decisión y nos tenemos que plantear cuánto nos costaría quitarlo si la liamos: Tendemos a generar MENOS COMPLEJIDAD ACCIDENTAL. Complejidad intrínseca. La que deriva del propio problema Complejidad accidental. La que generamos nosotros por no entender el problema y por no saber hacer nuestro trabajo. (lo primero se soluciona esperando un poco y pensando. Lo segundo aprendiendo a hacer software).
- Hacemos software, y por muchos métodos de gestión ágiles que usemos, si no sabemos hacer software no hay nada que se pueda hacer. Da igual lo que se escuche en ciertos foros. Que no nos engañen, hacer software es difícil y requiere ser muy disciplinado para hacerlo con calidad. Sin prácticas ágiles, no salen productos de software,da igual cuantos árboles abracemos… Que no se me entienda mal, la cultura ágil es fundamental, pero las prácticas técnicas también… XP practices, continuous delivery, etc Así que nadie crea que va a hacer un producto software exitoso con un equipo que no sabe programar.
- Kent Beck comenta en el prólogo del libro “Understanding the Four Rules of Simple Design” como fue experimentando a no anticipar cambios… Primero 6 meses, 3, 1, una semana, un par de días… hasta que probó a sólo hacer lo que le demandaban y comprobó que el diseño era más sencillo de cambiar.
- hasta cuando posponemos se responde con una fecha o cuando se den ciertas condiciones. (cuando tengamos 5 clientes de estas caracteristicas, cuando el coste de una nueva funcionalidad sea X, cuando tengamos las analiticas y podamos identificar el valor maximo de Y…
- Asumimos que todo se puede cambiar: Puesto que ahora sabemos más de negocio Sabemos más técnicamente o incluso hemos cambiado como equipo
- Lo más importante es que exista un entorno de SEGURIDAD psicológica. Una cultura que no señale con el dedo si te equivocas, que te permita aprender… que asuma que quizás lo que se decidió era lo correcto, pero ahora las circunstancias han cambiado… Una cultura de APRENDIZAJE y CAMBIO. Una cultura AGIL
- El objetivo es que generemos un hábito de tomar decisiones conscientes… que siempre se valoren las opciones, los tradeoffs
- Participamos en el negocio, aportamos soluciones, entendemos el problema, nos interesamos. (No hacemos lo que nos dicen, lo cuestionamos, hacemos las preguntas (para qué, qué esperamos obtener, como podemos dividirlo, qué es lo mínimos que te podemos poner en producción)) Ayudar a trocear, ordenar y priorizar… y iterar todo el rato (backlog es desperdicio). Siempre identificar el pequeño siguiente trozo. Incluso si parece que todo un bloque tiene sentido, siempre seleccionar e identificar la parte más pequeña de esa funcionalidad (Hábito)
- Intuitivamente tenemos una respuesta a todas las preguntas que deberíamos hacer al usuario o a negocio. Esas respuestas “inventadas” son gran parte del problema. Cuando hablamos del coste que tiene hacer las cosas, la latencia, la concurrencia, el volumen, la capacidad, pasan a ser un problema de negocio, puesto que tienen un coste de oportunidad (mientras hacemos eso no hacemos otra cosa). De hecho es muy útil dividir usando la capacidad (implementamos esa funcionalidad, pero solo para usuarios de tipo X, o solo almacenamos Y días…)
- Muchas veces nos empeñamos en que hay que automatizar todos los casos, pero en muchos casos es mucho más valioso automatizar los casos principales, ser capaz de identificar cuando no lo estamos y derivar ese trabajo a una persona. Esto nos puede permitir pasar a otra parte del sistema donde quizás podamos aportar más.
- Parece que es un ciclo virtuoso, una buena arquitectura nos permite posponer decisiones, que a su vez nos permiten evitar complejidad y mantener un arquitectura simple.
- Infraestructura desacoplada: Hexagonal arquitecture, Clean arquitecture, otras… o simplemente hacer un esfuerzo consciente de no mezclar. Es especialmente útil el uso del patrón repositorio para permitir posponer la ciertas decisiones de persistencia, o evolucionarla con el tiempo y que esa decisión se pueda hacer de forma local a cada repositorio. Interesante es el uso del event sourcing que permite simplificar esa persistencia y el CQRS que nos permite tomar decisiones locales para los comandos del sistema y las queries. Código usable: El código se debe diseñar pensando desde el punto de vista del cliente de ese software. Si no hay un cliente, ese código es prematuro. Piezas pequeñas: DDD Bounded contexts, microservicios, docker. Nos permite tomar decisiones locales y posponer ciertas decisiones para el resto de componentes. También es importante posponer esta decisión hasta tener un conocimiento de negocio suficiente
- Una cosa que podemos posponer es el crear una abstracción (a cualquier nivel). Podemos posponerlo al menos hasta tener suficiente conocimiento del problema o hasta que existan varios usos de un mismo concepto. Vamos, hasta que estemos seguros teniendo en cuenta la dependencia que va ha generar las ventajas, superan los inconvenientes. En cuanto a abstracciones prematuras y optimizaciones prematuras, tened en cuenta, que no existen sistemas complejos funcionando que partan de un sistema complejo que no funcionaba. Solo existen sistemas que funcionan y que partían de un sistema más simple que funcionaba. La simplicidad es la CLAVE.
- Todo se resume en seguir las prácticas que nos han contado una y otra vez para conseguir un código mantenible, un diseño flexible y fácil de modificar… Por cierto que algo simple y entendible es fácil de modificar. Algo complejo es SIEMPRE dificil de modificar (independientemente del número de XML de configuración que tenga).
- La incertidumbre es algo que llevamos mal como humanos, pero si además somos ingenieros, lo llevamos fatal :) Nos encanta resolver problemas, y si los problemas de negocio no nos parecen suficientemente interesante, NOS INVENTAMOS PROBLEMAS… o hacemos un FRAMEWORK Crear valor, ayudar al negocio (o ser parte) y hacerlo bien (mantenible, no hipotecando el futuro) ya es un PROBLEMA MUY INTERESANTE.