sábado, julio 29, 2017

Noticia Falsa: En cascada no existía deuda técnica




Hola a todos, hace poco compartía con un compañero el cual trabajó durante mucho tiempo en cascada y ahora esta comenzando a trabajar con scrum y esta viéndose en unos retos bien importante, el cual me argumentaba que:

- en cascada los problemas no teníamos los problemas de deuda técnica que existen en ágil. En cascada siempre entregabamos...

no les niego que mi cara fue similar a esta.



Vamos primero a aclarar términos:

Ver más sobre deuda técnica en (1)
La verdad parece que se nos olvida que en proyectos construidos en cascada de más de 6 meses (2) pasan las siguientes disfuncionalidades respecto a la parte técnica:
  1. Nos comprometemos a una fecha y no la cumplimos
  2. Las pruebas las empezamos 2 o 3 meses después de la fecha de finalización del proyecto (si es que tenemos suerte)
  3. Nos quedamos en ciclos interminables de pruebas (4, 5 o  hasta más) para poder entregar el sistema.
  4. El cliente nos acepta el producto después de dós o más ciclos de pruebas
  5. Salimos a producción muertos de miedo y estabilizando el sistema por más de 6 meses (muchas de las condiciones de aceptación de un producto en cascada dice cuando por 2 meses no aparezcan problemas en producción).
Estas disfuncionalidades son mayormente creadas por la pobre calidad técnica y lo que estamos tratando de hacer es entregar el proyecto con fuerza bruta.



¿Y en Agile como es?

La verdad es que, si tenemos excelencia técnica (buenas prácticas ágiles, buena ingeniería, buena arquitectura),  esto no se presentará (o al menos se reducirá enormemente su impacto) y la imagen de arriba hará honor a lo que profesamos:
  • Entregamos software de valor frecuentemente
  • Y la medida de progreso es software funcionando
Pero la realidad no es así, los equipos en general caen en "Agilidad Cosmética" que tiene como síntomas:
  • Solo se centra en el proceso scrum (o como sea que lo llamen) y no en las personas.
  • Los equipos no mejoran sus prácticas técnicas.
  • Los scrum masters solo se enfocan en mejorar la comunicación del equipo cuando hay muchos aspectos a mejorar.
  • Las retrospectivas son las mismas hace 5 sprints.
  • Los equipos no son retados técnicamente por el scrum master (ver más acá Scrum Master: Cómo Continuar la Mejora Continua de tu Equipo).
  • No se gestiona la deuda técnica.
  • No hay una preocupación seria por parte del equipo de la excelencia técnica.
Y debido a la entrega frecuente hace que la pésima calidad del software evidencie más rápido nuestras falencias técnicas como equipo de desarrollo.

Algunos tweets

Para terminar quisiera compartirles algunos tweets relacionados con la deuda técnica y la excelencia técnica tanto en cascada como en ágil.

























Comentarios, Aclaraciones, Notas y Referencias

  1. Presentación sobre deuda técnica (clic aquí)
  2. En proyectos más pequeños de tamaño (5 meses o menos) las disfunciones técnicas que tiene cascada para desarrollo de software no se evidencian tan fácilmente como en proyectos grandes, pues en últimas el mal código siempre generará impacto tipo de impacto en el tiempo, costo y satisfacción del cliente independiente del tamaño del proyecto (Gracias Luis Mulato @LuisMulato por el feeback y correciones respecto a este último punto y al post)

miércoles, julio 26, 2017

Un tweet sobre #Agile

viernes, julio 21, 2017

Algunas ideas sobre Historias de Usuario




Hola a todos:
Les quisiera compartir un listado de ideas centrales sobre historias de usuario que por lo regular comparto en los entrenamientos en Scrum:

  1. Las historias de usuario no son especificaciones
  2. Una historia de usuario debe ser tan pequeña que obligue a una conversación cara a cara donde todos entiendan mejor el problema (Leonardo Agudelo)
  3. Es preferible una historia de usuario ambigua que una bien escrita (la razón: la ambigua invita a la conversación) (Jeff Patton)
  4. Paremos de especificar las historias de usuario comencemos a explicarlas (Jeff Patton)
  5. Es en serio, las historias de usuario tienen que ser pequeñas
    • Una buena historia de usuario debe tomar entre 3 y 5 dias persona de esfuerzo para lograr el DONE
    • Una buena historia de usuario tiene entre 4 a 8 criterios de aceptación
  6. Lo más importante de una Historia se usuario es que sea menos importante que la conversación (Juan Pablo Bernal)
  7. Un buen sprint backlog tiene entre 6 a 10 historias de usuario
  8. Las historias de usuario no son requisitos, son más bien una carta de intención de lo que queremos que haga el sistema, son recordatorios para conversaciones que tendremos más adelante (Lucho Salazar).
  9. Es un error decir la historia de usuario está mal especificada, pues la historia de usuario no es una especificación, es mejor que este "mal escrita" por que invita a una conversación y una aclaración sobre la misma.
  10. Se llaman historias de usuario no "especificaciones de usuario", por lo tanto el énfasis se debe hacer en la historia que cuenta el usuario y no en lo que esta escrito o tratado de especificar.
  11. Las historias de usuario deben ser porciones funcionales end-to-end, que cuando funcionen se implementen agreguen valor, o sea, pasen exitósamente el siguiente test:
    • ¿puedo ponerla en producción?
    • ¿un usuario final puede usarla sin necesidad de algun truco o script extraño?¿es decir, se puede acceder desde la interfaz de usuario y funciona completamente?

Espero les sean útiles estas cortas ideas.

Saludos Ágiles
Jorge Abad

De Colección: Laloux Culture Model and Agile en español

Laloux Culture Model and Agile en español from Agile For All on Vimeo.

domingo, julio 09, 2017

La Diferencia entre el Cumplimiento y Entender el Propósito





Hola a todos

Hace poco salí con mi familia y unos amigos de paseo y nos encontramos en una situación vergonzosa: íbamos todos en el mismo carro de regreso al hotel en carretera destapada (no pavimentada) y de repente a unos 10 metros de nosotros un motociclista tiene un accidente, se cae de la moto con su novia o esposa, e inmediatamente los dos automóviles que estábamos cerca nos detuvimos a auxiliar a la pareja, no fue grave el incidente, algunas raspaduras y heridas leves. todos sacamos nuestro botiquín y nos encontramos conque ambos contábamos con lo mínimo que nos exige la ley (confieso que ese el mismo que yo tenía en mi carro):



  • Un pedazo de gaza 
  • Algodón
  • Guantes
  • Un desinfectante (alcohol antiséptico)
  • Un aplicador
  • Cinta microporo
Con esto tan insignificante no logramos atender las heridas del motociclista y su novia, el recuadro de gasa era insuficiente necesitábamos más para cubrir la herida en la mano y que el pudiera conducir su moto, el alcohol lo acabamos rápido, realmente estábamos limitados; de suerte que a los pocos minutros pasó otro automóvil con un botiquín serio (no el que teníamos los dos carros - que era el para cumplir la regulación-) y pudimos auxiliar y prestar los primeros auxilios a la pareja, vendarlos etc.



De este pequeño incidente me quedaron varias enseñanzas.
  • Teníamos un botiquín solo para cumplir con la regulación colombiana, pero no nos sirvió para un leve accidente 
  • No entendíamos el propósito del botiquín en nuestros carros, si fuéramos conscientes que con este atenderemos un herido ya sea nuestro o externo no seríamos tan irresponsables de andar con un botiquín de juguete.
  • Cuando nos centramos en el cumplimiento y no entendemos el propósito nuestras soluciones no son las correctas.
  • El botiquín no esta en mi carro para evitar sancionado por la ley, sino para ayudar a salvar mi vida, la de mi familia, o de alguien que requiera mi ayuda.
  • Cambiar inmediatamente el botiquín de primeros auxilios de mi auto.
Y extrapolando esto a la agilidad
  • No podemos usar frameworks y metodologías como SCRUM, Kanban, XP, SAFe, LESS sin saber que son y cual es su propósito y el problema que pretenden resolver
  • Sin propósito cualquier implementación de Agile se hará por cumplir o por moda y con seguridad carecerá de los elementos necesarios para ser exitosos en su contexto.
  • Tener personas ejecutando roles (PO, SM, Team Members, etc) en los cuales ellos no tengan claro el propósito y la razón de ser del mismo llevará a implementaciones erróneas e ineficientes (ya lo he vivido, de seguro ustedes también)
  • Igualmente no tener claro el por qué de los artefactos y de las ceremonias, hará que estos sean implementados de forma incorrecta y no proporcionarán los resultados y beneficios esperados. (ya lo he vivido, de seguro ustedes también)(1)
Unas cuantas preguntas para cerrar:
  • ¿sabes cual es propósito de tu rol?
  • ¿por que usas scrum, y no xp, u otro framework?
  • tu transformación hacia ágil tiene propósito o es solo ponerse a la moda
  • ¿sabes por que las historias de usuario deben ser pequeñas? (Es en serio, las historias usuario tienen que ser pequeñas (clic aquí) )
  •  ¿Tienes claro que el MVP - Mínimo Producto Viable - debe ser lo mas pequeño posible? ¿o tu MVP es de todo el producto?
Consejo:
  • Busca siempre entender cual es el propósito de lo que haces y esto como suma al propósito general.


Bueno hasta acá este compartir

Saludos ágiles

Jorge Abad



Notas, aclaraciones, comentarios y referencias

  1. Todo esto me hace recordar mi anterior reencarnación en la que fui ingeniero civil (ejercí esta hermosa profesión 3 años antes de adentrarme de lleno al apasionante mundo de la ingeniería de software) y resulta que existe un método bien claro para diseñar la estructura de un edificio para lo cual se requiere un ingeniero civil calculista que determine de que tamaño son las estructuras y materiales que deben tener (concreto, acero, etc), pero en Colombia los maestros de obra en los barrios populares construyen (fuera de la ley) estructuras de 1, 2, 3, hasta 4 pisos (si no es más - ojala no-) replicando lo que esquemas que han visto en las construcciones en las que han trabajado con ingenieros civiles pero estas soluciones no son ni las mejores costo-eficientes, y ni se sabe si resistirán las calidades sísmicas de la zona en la que se encuentran.