martes, mayo 18, 2021

100% de CPU es lento en nuestras máquinas, ahora llévalo a un 100% de ocupación tuyo de forma constante

Todos reconocemos y experimentamos que el 100% de CPU constate en nuestra máquina la relentiza y la hace ineficiente; me impacta es que no podamos reconocerlo en nosotros mismos y en nuestros colaboradores, y los/nos terminemos quemando.

Te invito a leer este artículo, donde está el sustento científico de esta "ineficiencia" en los humanos y una sugerencia para solucionarlo: "Exigir el 100% de ocupación de las personas esta destruyendo la eficiencia de tu equipo y organización" 



domingo, mayo 09, 2021

Mi viaje como Agile Coach




Hola a todos,

Hace poco cuando compartía con un equipo de Scrum Masters, hablando sobre prácticas y métodos revisábamos la famosa imagen (1) en la cual se presentan los valores, principios, prácticas y frameworks,

Imagen adaptada de Ahamed Sidky

y que si la giras un poco, vas a ver los elementos visibles e invisibles de la cultura,


aquellos que consisten en "Hacer" y "Ser", y en nuestro contexto "Hacer Ágil" y "Ser Ágil".


En donde, todo viaje de transformación parte desde los elementos visibles hacia los invisibles, transformándonos de afuera hacia adentro,


o ¿Quién cambia por arte de magia? La verdad, desde mi punto de vista y experiencia, no creo en los cambios repentinos, creo en los procesos, todo cambio requiere un esfuerzo, un delta que me permita pasar de un estado A a un estado B, y parte de algo afuera que te lleva a mover cosas adentro.

Pero bueno, el punto acá es como ha sido mi jornada de cambio, recuerdo mucho a mis inicios en el mundo ágil me reencontré con un gran estudiante que tuve en la clase de Taller de Ingeniería de Software en Eafit, Jorge Luis Valderrama, recuerdo que estaba por Colombia, pues vivía en Londres, y en varias charlas suyas y conversaciones a la que asistí, hablaba siempre desde el Manifiesto Ágil - http://agilemanifesto.org/-, y recitaba sin titubear sus valores y principios, y ante cualquier duda buscaba que principios promovía o violaba aquello sobre lo que era cuestionado. Debido a esto, me animé a imprimir y pegar en frente mío, en mi escritorio de oficina los valores y principios del manifiesto ágil, y ante cualquier duda me remitía al manifiesto ágil, frase que repite constantemente mi gran amigo Juan Andrés Ochoa:


"Ante una duda en cómo actuar, remítase al Manifiesto Ágil" -Juan Andrés Ochoa

 

De esa manera, emprendí mi viaje desde los principios y valores, luego aprendí en orden Scrum, Nexus, el Modelo Spotify, Kanban, SAFe, LeSS, Scrum at Scale, Discipline Agile. No fue fácil esa jornada, recuerdo que me tomó al menos 6 meses dejar el micromanagement y hacer gestión de horas, para comenzar a confiar en los puntos de historia.


Y en ese viaje de ida, siempre la mentalidad ágil me ha acompañado, permitiéndome ser crítico y ver valor en prácticas tradicionales y flexibilizar mi mente y prácticas en procesos de transición organizacional que acompaño (les recomiendo leer Empático mas no Complaciente). Pero al toparme con SAFe y Kanban, observé que me faltaba algo, y era Lean (o el Modelo de Producción de Toyota escrito en términos occidentales). Comprendí que en mi jornada había olvidado las bases del mindset ágil, y comencé mi recorrido de regreso, centrándome en dos preguntas fundamentales: 

¿qué es el mindset ágil?

 ¿y qué rayos es lean?


En ese viaje de regreso, he tenido bastantes libros, charlas y conversaciones como compañeros, y recomiendo revisar detalladamente:

  • El corazón de la agilidad, promovido por Alistair Cockburn (2)
  • La Agilidad Moderna, promovido por Joshua Kerievsky (3)
  • Lean (4)


 
El Corazón de la Agilidad (2)

Agilidad Moderna (3)

A este punto de la historia, he logrado sintetizar lo que es para mí el mindset Lean-Agile, la clave que desencadena la productividad, la felicidad y alto desempeño:

  • Flujo
  • Entrega de Valor
  • Reflexión (Inspección y Adaptación)
  • Colaboración
  • Mejora Continua
  • Eliminación de desperdicios
Pilares de la mentalidad Lean-Agile. Elaboración propia.

Al tuétano, al núcleo de este asunto que me apasiona y por el cual llegaste hasta este punto del artículo, lo comparto constantemente, lo considero fundamental, para poder desenvolverse en este mundo disruptivo y exigente; mis entrenamientos y conversaciones tienen un énfasis en el mindset lean-agile y cómo este funciona independiente del framework, marco, metodología o proceso y con esta perspectiva acompaño a equipos y organizaciones en su jornada de transformación.

Sé que no hay que dejar de hacer una cosa sin descuidar la otra, es decir, avanzar en el conocimiento de nuevas aproximaciones y marcos, pues hace parte de "estamos descubriendo formas mejores de"(5),  sin dejar el corazón, el corazón te permite moverte con propósito y libertad entre las diferentes interpretaciones, implementaciones o, más aún, desarrollar tu propia versión de la agilidad y de lean.

Yo no sé cómo será tu viaje, te he compartido el mío, con seguridad en tantos ires y venires nos terminaremos encontrando. Solo te quiero hacer tres preguntas:


¿En dónde estás en tu viaje hacia la agilidad, como Scrum Master, como Agile Coach, o como líder en tu organización?

¿Qué tanto conoces y dominas Lean?


¿Ves útil o inútiles artículos sobre mindset o atraen más los marcos complejos e hiperconectados con flechas?


Hasta acá este compartir, bienvenidos sus comentarios.


Saludos Ágiles

Jorge Abad

Notas, Referencias, Aclaraciones, Comentarios y Observaciones

  1. Imagen de Ahamed Sidky
  2. Corazón de la Agilidad - https://heartofagile.com/
  3. Agilidad Moderna (Modern Agile) - https://modernagile.org/
  4. Lecturas recomendadas sobre lean
  5. Agile Manifesto - http://agilemanifesto.org/iso/es/manifesto.html


viernes, mayo 07, 2021

Las historias de usuario no son requisitos de software, son solo necesidades de usuario. Un poco de Ingeniería de Software y Requisitos


Hola a todos

Recuerdo hace más de 15 años cuando enseñaba taller de ingeniería de software, casos de uso, programar en Java en Eafit y otras cosas antiguas, que le explicaba a los estudiantes que las especificaciones de software según el estándar IEEE 830-1998 (1) deberían ser:

  • Completas. Todos los requisitos deben estar reflejados en ella y todas las referencias deben estar definidas.
  • Consistentes. Debe ser coherente con los propios requisitos y también con otros documentos de especificación.
  • Inequívocas (no ambiguas). La redacción debe ser clara de modo que no se pueda mal interpretar.
  • Correctas. El software debe cumplir con los requisitos de la especificación. Se tienen que cumplir y construir.
  • Trazables. Se refiere a la posibilidad de verificar la historia, ubicación o aplicación de un ítem a través de su identificación almacenada y documentada.
  • Priorizables. Los requisitos deben poder organizarse jerárquicamente según su relevancia para el negocio y clasificándolos en esenciales, condicionales y opcionales.
  • Modificables. Aunque todo requisito es modificable, se refiere a que debe ser fácilmente modificable.
  • Verificables. Debe existir un método finito sin costo para poder probarlo.
Lo cierto, es que el tiempo pasó, las historias de usuario se hicieron populares dentro del mundo ágil y luego dentro del desarrollo de software, y esto sucedió  debido a que cada vez evidenciamos más que ser rigurosos en la especificación no aumenta la precisión del desarrollo, que es mejor un breve enunciando con criterios de aceptación, o un boceto y una conversación cara a cara para sincronizar las expectativas del cliente con los desarrolladores, que documentos grandes y estrictos que nos demorábamos meses construyendo, verificando y validando, para luego llegar tarde construir la solución incorrecta.

No volví a toparme mis amados Caso de Uso, con sus relaciones de inclusión y exclusión, ni sus flujos básicos y alternativos, ni con sus diagramas respectivos, todo eso pasó, y pasó para darle lugar a una interacción fluida que nos está permitiendo entregar valor de forma temprana y continua, y reduciendo radicalmente los errores de implementación debido a que nunca adivinábamos todo lo que el usuario tenía en mente.

Constantemente le insisto a las empresas y equipos con los que trabajo:


    "Ágil es:
        Definición continua
            Desarrollo continuo
                Despliegue continuo y
                    Validación continua de valor"(2)


Pero este artículo no es sobre nostalgias, su propósito es dar claridad sobre las historias de usuario y que estas no cumplen con los criterios requeridos para ser especificaciones de software como lo pide la norma, pues:
  • No están completas: son dinámicas y se actualizan cada que se requiera.
  • Algunas son ambiguas: puede que al momento de redactarse falten algunos aspectos (3) y en el momento de la planning (en el mundo Scrum) o durante el desarrollose hagan preguntas que logren resolver la ambigüedad y esto permita una mejor comprensión de lo que quiere el usuario. Lo anterior muchas veces es más valioso que creer correctamente entendido y no se hacen preguntas que permitan validar lo expresado.
  • No todas son correctas: no necesariamente se van a construir dentro del software, algunas quedarán en el olvido o se decidirá libremente no hacerlas pues ya no generan valor.
  • Probablemente no sean trazables: no siempre habrá trazabilidad pues probablemente se registró en un post-it y este luego se tiró a la basura y, por lo tanto, la única evidencia que quedó de esa historia de usuario es el software funcionando aprobado en producción.
Es por esto, que continuamente en los entrenamientos que imparto en los cuales debo hablar de las historias de usuario, lo primero que enfatizo es en que:

"Las historias de usuario no son requisitos de software, son solo necesidades de un usuario",

 

Para cerrar los dejo con esta frase de Jeff Patton, quien ideó el User Story Map:

"No necesitamos un documento preciso, necesitamos un entendimiento compartido",- Jeff Patton 



-----

¿Quieres saber más sobre historias de usuario?


En junio mi gran amigo Lucho Salazar y yo estaremos facilitando un curso donde te contaremos de nuestras experiencias en este y otros asuntos sobre lo esencial de las historias de usuario. Encuentras más información en:


¡Te esperamos!


Notas, Aclaraciones, Referencias y Comentarios

  1. https://es.wikipedia.org/wiki/Especificaci%C3%B3n_de_requisitos_de_software 
  2. Lo escribo escalonado pues no se da de forma paralela, sino de forma escalonada y más cercana en el tiempo, desde unas cuantas horas hasta máximo dos meses.
  3. http://www.lecciones-aprendidas.info/2018/07/aclarando-sobre-historias-de-usuario.html