1

Desarrollo Lean: posponer decisiones

Workshop Software Crafters Barcelona 2022 (v1.2)

(@eferro & @islomar)

2

PREMIUM

3

Edu Ferro

(@eferro)

http://www.eferro.net

​

Isidro López

(@islomar)

https://islomar.es

​

4

https://creativecommons.org/licenses/by-sa/4.0/legalcode

Objetivo del taller

• Mostrar a través de un ejercicio práctico “basado en hechos reales” un ejemplo de puesta en práctica del principio Lean “defer commitment”.
• Evolucionar las soluciones técnicas a las necesidades de usuarios manteniendo opciones abiertas y minimizando el desperdicio (enfocándonos en el problema presente y evitando el diseño especulativo).
• Ver cómo posponer decisiones técnicas hasta el último momento responsable. Esto implica posponer decisiones “irreversibles” (o con alto coste de cambio) e intentar maximizar el número de decisiones reversibles.

5

¿Por qué queremos posponer (algunas) decisiones?

• Para trabajar menos 😬 (menor coste basal y menos tiempo implementando algo que tal vez no necesitemos)
• Para tener más información y poder entender mejor el negocio (problema/necesidad a resolver) y la solución más adecuada.
• Para evitar invertir tiempo y dinero en resolver el problema incorrecto (i.e. para no hacer algo que no aporte valor real en el presente)
• Para crear soluciones/sistemas más simples (evitar sobre-ingeniería), mínimos y fáciles de cambiar, con baja complejidad accidental y menos funcionalidades.

6

¿Por qué queremos posponer (algunas) decisiones?

• Para reducir el esfuerzo requerido en rehacer trabajo en caso de necesitarlo
• El objetivo es tener múltiples opciones reales: reaccionar bien y rápido a lo que venga, sin miedo.
• Cuanto más pospongamos, menos cargamos la “mochila” y menos cosas innecesarias añadimos (menos desperdicio).
• Todos sabemos que es más fácil moverse con menos carga en la mochila
• Una buena arquitectura nos permite posponer decisiones, pero esto no significa que estemos obligados a hacerlo. Sin embargo, ser capaz de posponerlas nos da mucha flexibilidad.

7

¿Qué NO posponemos?

• El lenguaje de programación (e.g. paradigma OO vs funcional) y el grueso de su ecosistema
• Trabajar con “excelencia técnica” (aka “agile”, continuous delivery, eXtreme Programming, etc.)

8

¿Cómo posponemos decisiones?

• De manera consciente y meditada
• Consideramos que una decisión es “buena” cuando:
• Nos compromete lo mínimo posible
• Nos permite posponer otras decisiones
• Es fácil de cambiar/revertir
• Resuelve un problema del presente (no del futuro)
• Es “suficientemente buena” (sin sobre-ingeniería)
• Priorizamos librerías sobre frameworks

9

¿Cómo posponemos decisiones?

• Trabajamos de manera muy iterativa
• Aceptamos que las decisiones tomadas fueron las correctas en el momento y contexto en que se tomaron: no pasa nada si hay que cambiarlas
• Nos esforzamos por hacer un buen slicing vertical de las funcionalidades (por ejemplo con el “método hamburguesa”), así como slicing técnico para avanzar en pequeños pasos seguros

10

¿Cómo posponemos decisiones?

• Buscamos la “excelencia técnica” (Clean Code, Simple Design, TDD, Evolutionary Design, etc).
• Seguimos arquitectura hexagonal y algunos de los principios, prácticas y patrones de DDD (nos desacoplamos de infraestructura/frameworks).

11

Caso real: ChatOps

Objetivo:

• Facilitar a los desarrolladores la ejecución automática de tareas tediosas, propensas a errores o con dependencias de otros equipos (e.g. de Platform)

​

Contexto:

• 200 usuarios en potencia (50-100 entre Ingeniería y Data Science)

12

Caso real: ChatOps

Restricciones:

• Uso de la aplicación de mensajería Slack
• ¿Por qué Slack?
• Ya se cuenta con ella en la empresa
• Todos los empleados tienen acceso
• En línea con concepto de Chatbot y ChatOps

13

Introducción al método de la hamburguesa

• Origen: Gojko Adzic, 2012
• Problema a resolver:
• la historia es demasiado grande para ser partida; el equipo sólo ve cómo simplificar a nivel técnico, no de negocio/usuario
• Objetivo:
• conseguir evolucionar la solución a un problema
• generar / visualizar opciones

14

Introducción al método de la hamburguesa

• Pasos
• Paso 1: identificar tareas (pasos requeridos para satisfacer una necesidad de usuario)
• Paso 2: identificar opciones para las tareas
• Paso 3: combinar resultados
• Paso 4: recortar las opciones
• Paso 5: tomar el primer bocado
• Paso 6: tomar el siguiente bocado… y continuar

15

16

¡Empecemos la práctica!

Caso de uso: creación de repositorio de contenedores

• La necesidad:
• Crear un repositorio de contenedores de forma self-service.
• Inicialmente se requería la intervención de dos equipos y el proceso duraba hasta 2 días (dependencias, bloqueos, errores).
• Propuesta de solución:
• Todos los usuarios pueden, mediante Slack, crear un repositorio de contenedores de manera autónoma e inmediata.
• Si el usuario se equivocara al crear el repositorio, no tendría efectos negativos (e.g. nada se rompe).

​

17

18

19

Autenticación Slack

Canales Slack

Token usuarios harcodeados

Hardcodeado en código

Fichero Hardcodeado

Slack Command

Conversación Slack

AWS API

20

RECORDATORIO sobre los criterios de selección

• Nos compromete lo mínimo posible
• Nos permite posponer otras decisiones
• Es fácil de cambiar/revertir
• Resuelve un problema actual (NO futuro)
• Suficientemente “bueno” (sin sobre-ingeniería, simplicidad, testeado)
• Que sea pequeño

21

22

Durante los siguientes tres meses el sistema fue evolucionando con nuevos comandos y más usuarios. Ninguno de ellos necesitó cambios muy importantes en la arquitectura o la infraestructura de la aplicación.

23

🗓

24

Caso de uso: asignar rol a usuario de AWS

• La necesidad:
• Los miembros del equipo de IT quieren poder asignar fácilmente un rol a un usuario de AWS.
• Únicamente la gente de IT debe poder ejecutar este nuevo comando.

​

​

Este caso de uso evidenciaba la necesidad de sofisticar nuestro sistema de autorización

​

25

Atención

26

27

RECORDATORIO sobre los criterios de selección

• Nos compromete lo mínimo posible
• Nos permite posponer otras decisiones
• Es fácil de cambiar/revertir
• Resuelve un problema actual (NO futuro)
• Suficientemente “bueno” (sin sobre-ingeniería, simplicidad, testeado)
• Que sea pequeño

28

Caso de uso: crear y borrar usuarios de AWS

• La necesidad:
• Se requiere crear y borrar usuarios de AWS.
• Estas operaciones sólo las pueden ejecutar los equipos de SRE y IT.

Necesidad de aún mayor sofisticación para nuestro sistema de autorización

29

Atención

30

31

RECORDATORIO sobre los criterios de selección

• Nos compromete lo mínimo posible
• Nos permite posponer otras decisiones
• Es fácil de cambiar/revertir
• Resuelve un problema actual (NO futuro)
• Suficientemente “bueno” (sin sobre-ingeniería, simplicidad, testeado)
• Que sea pequeño

32

Caso de uso: resetear nuestras credenciales AWS

• La necesidad:
• Cada persona tiene que resetear sus credenciales al menos cada 60 días.
• Cada persona lo podía hacer en la consola de AWS, pero lo cierto es que generaba mucho soporte, mucha gente no lo sabía hacer.

​

• Propuesta de solución:
• Todos los usuarios pueden, mediante comando de Slack, resetear sus credenciales.
• Las credenciales se tienen que enviar de forma segura.

​

33

34

35

RECORDATORIO sobre los criterios de selección

• Nos compromete lo mínimo posible
• Nos permite posponer otras decisiones
• Es fácil de cambiar/revertir
• Resuelve un problema actual (NO futuro)
• Suficientemente “bueno” (sin sobre-ingeniería, simplicidad, testeado)
• Que sea pequeño

36

Caso de uso: release a Producción de aplicaciones

• La necesidad:
• La release a Producción de las aplicaciones (principalmente 3 monolitos que se despliegan a la vez por sus dependencias) es un proceso complejo, lento y propenso a errores: queremos automatizarlo y simplificarlo.
• Auditoría y búsqueda, persistente en el tiempo y con control de acceso (autorización)
• Contenido de la traza: comando ejecutado, quién y cuándo lo ejecutó.

​

Queremos una solución con auditoría, fácil de ejecutar, con feedback para el usuario y con algún tipo de mecanismo que impida que se ejecute por error

37

Atención

38

39

40

41

Recapitulación final

Finalmente, hace un par de semanas (año y medio después del arranque) hemos conectado el sistema de autorización con nuestro Inventario de Usuarios (por cierto implementado con No-Code).

42

🗓

43

Resumen final (I)

• El método Hamburguesa sólo es una herramienta (es el dedo, no la luna).
• Mantener opciones abiertas: forzarnos a pensar varias
• Priorizar decisiones que:
• Nos comprometan lo mínimo posible
• Nos permitan posponer otras decisiones
• Sean fáciles de cambiar/revertir
• Resuelvan un problema actual (NO futuro)
• Sean suficientemente “buenas” (sin sobre-ingeniería, simplicidad, testeado)

44

Resumen final (II)

• NO se sacrifica la “calidad interna” (testing, legibilidad, diseño simple y evolutivo, refactor “continuo”, etc.)
• Acompañarlo de arquitectura/diseño que permita posponer decisiones y revertirlas/cambiarlas fácilmente (e.g. arquitectura hexagonal)

45

RECORDATORIO sobre los criterios de selección

• Nos compromete lo mínimo posible
• Nos permite posponer otras decisiones
• Es fácil de cambiar/revertir
• Resuelve un problema actual (NO futuro)
• Suficientemente “bueno” (sin sobre-ingeniería, simplicidad, testeado)
• Que sea pequeño

46

Cuidado:

⚠️ Frameworks que cierran opciones

⚠️ Megaconstrucciones (para problemas futuros)

⚠️ Hype / CV Driven development

47

48

Referencias y recursos

49

50

Referencias (I)

• Lean Principle #4 – Defer Commitment
• The art of postponing decisions (Edu Ferro)
• Basal Cost of software (Edu Ferro)
• "Real Options" Underlie Agile Practices
• Podcast episode: “Operational simplicity is a gift to you”
• “YAGNI” (Martin Fowler)
• Software as liability

51

Referencias (II)

• Iterative and Incremental Development: we need both
• Visualizar, organizar, simplificar y dividir “user stories”
• Hamburger method
• User story mapping
• How to split a user story
• Slicing Functionality: Alternate Paths
• Libro “Fifty quick ideas to improve your user stories”
• Video: Big Transitions in Small Steps (Kent Beck)
• Arquitectura hexagonal (Alistair Cockburn)

52

¡GRACIAS!

@eferro - http://www.eferro.net

@islomar - https://islomar.es

¿Feedback?

https://t.ly/taller-lean-scbcn22

53

https://creativecommons.org/licenses/by-sa/4.0/legalcode