Mostrando las entradas con la etiqueta agile practices. Mostrar todas las entradas
Mostrando las entradas con la etiqueta agile practices. Mostrar todas las entradas

martes, abril 29, 2025

Video Keynote Comunidad Scrum Latam: Principios sobre prácticas - Una fórmula mas allá de los frameworks

Hola a todos,

Hoy quiero compartirles una de las reflexiones más potentes que surgieron en el reciente keynote que compartí con mi amigo y colega Lucho Salazar: la necesidad urgente de dejar de recitar prácticas ágiles vacías y comenzar a liderar desde los principios. Esta charla, titulada “Principios sobre Prácticas: Una fórmula para ir más allá de los frameworks”, fue una sacudida para muchos… y con toda la intención.

Cuando la agilidad se convierte en rutina… hay que despertar

La agilidad nació como una respuesta a la rigidez. Sin embargo, muchas organizaciones han convertido sus prácticas ágiles en nuevos rituales sin alma. Daily Scrums que son reuniones de control, PI Plannings hechos por cumplir, equipos que siguen Scrum sin cuestionarse si sigue siendo útil. ¿Y lo más grave? Coaches y líderes que se aferran a estas prácticas porque “así lo dice el marco”.

En nuestra charla planteamos una idea sencilla pero poderosa:

Agilidad real = Principios + Contexto – Resistencia

Sí, una fórmula. No matemática, sino heurística. Un recordatorio de que los principios son la brújula que nos permite navegar cualquier entorno, incluso en tiempos de crisis e incertidumbre.


El entorno cambió… pero ¿y tú?

La Inteligencia Artificial, la disrupción digital, las expectativas cambiantes de clientes y empleados, todo está cambiando. ¿Por qué seguimos haciendo lo mismo de siempre?

Muchos de los frameworks actuales nacieron hace más de 20 años. ¿Sirven? Sí. ¿Son suficientes? No. Como dijimos en la charla:

“La receta de la abuela funcionó, pero los ingredientes de hoy son otros.”

Por eso, no se trata de desechar todo, sino de revisar, adaptar, reinventar. Una práctica no es sagrada. Lo sagrado es el propósito que persigue: entregar valor, colaborar, adaptarse, aprender.


Redescubrir la esencia: 16+ principios para una agilidad viva

Durante la charla, compartimos más de 16 principios que consideramos esenciales en este nuevo entorno. Algunos de ellos:

  • Gestión impecable de dependencias

  • Equipos pequeños, empoderados y en sinergia con el negocio

  • Entrega temprana, continua y con excelencia técnica

  • Transparencia radical

  • Priorizar impacto sobre entregables

  • Reflexión e inspección frecuente

  • Reducción implacable del desperdicio

  • Cultura de aprendizaje y mentalidad experimental

Estos principios no son nuevos. Lo que es nuevo es la urgencia de vivirlos.


La invitación: menos dogma, más discernimiento

Lucho lo decía con fuerza: “El marco perfecto es un mito que paraliza el cambio.”
Y yo agregaría: el verdadero agilista no es el que mejor repite, sino el que mejor interpreta.

Esta charla es una invitación a cuestionar. A salir de la comodidad del “así se hace”. A leer el entorno como un jardinero, entendiendo qué semillas sembrar, qué malas hierbas cortar y cómo adaptar nuestra forma de trabajar para que florezca el valor.


¿Y tú? ¿Qué tan libre eres para adaptar?

¿Tus prácticas sirven a tus principios… o ya son cárceles del conformismo?

Si quieres profundizar en esto, mira la presentación y el video abajo al finalizar este artículo.

Y recuerda:

“Los frameworks son puntos de partida, no de llegada.”

Saludos ágiles,
Jorge Abad


Notas, aclaraciones, referencias y comentarios:

  • Presentación basada en el keynote “Principios sobre Prácticas” presentado por Jorge Abad y Lucho Salazar, abril de 2025.

  • Las ideas centrales se desarrollan a partir del documento: Principios sobre prácticas - Keynote - V1.0.20250301.pdf y la transcripción completa del evento.

  • Más información sobre el enfoque en principios: https://heartofagile.com

  • Para citar este artículo, usar: Abad, Jorge. “Principios sobre prácticas: la agilidad más allá del marco.” Lecciones Aprendidas, mayo 2025.







miércoles, noviembre 30, 2016

Tengo un proyecto en cascada y quisiera agilizarlo (1)



Hola a todos

Muchas veces cuando comparto en entrenamientos sobre Scrum o Agile, o en conversaciones con gerentes, gerentes de proyecto, sale la siguiente pregunta a relucir:

- [Cliente] Ok, genial, podemos adoptar esto de ÁGIL o SCRUM en el siguiente proyecto, pero 

¿que hacemos para agilizar los proyectos existentes que tenemos en cascada?

Lo que recomiendo es ensayar AGILIDAD ORGÁNICA (http://www.lecciones-aprendidas.info/2015/08/scrum-organico.html), que consiste en promover la agilidad de una forma natural y con feedback del entorno en que se encuentra inmerso el equipo o el proyecto.

Una posible secuencia de pasos a seguir para la agilidad orgánica sería:
  1. Existe un agente de cambio ágil - facilitador(2) - (que luego será el scrum master, o como deseen llamarlo)
  2. Propone al equipo hacer retrospectivas semanales o máximo cada 2 semanas (ver acá una guía de como realizar un retrospectiva - http://www.lecciones-aprendidas.info/2016/11/agenda-scrum-pasos-para-realizar-la.html - )
  3. En la retrospectiva el facilitador se enfoca en lo que más le duele al equipo (este enfoque se basa en encontrar dolores e ir sanándolos - Pain Driven Facilitator) y proponer un cambio, un experimento, y en la siguiente retrospectiva revisar el resultado del experimento.
  4. Un ejemplo, el facilitador en un momento apropiado propone como experimento para el próximo ciclo incorporar el Daily, y pregunta en luego del ciclo beneficios que observaron en este.
  5. Luego se preguntan sobre más dolores y se van incorporando prácticas, procesos o acuerdos  que el equipo las va "amando" pues fueron soluciones a sus problemas, que ellos mismos encontraron.
luego me dicen

- [Cliente] Perfecto, ¿y que hacemos con las entregas y los entregables?

mi propuesta ante esta situación es:
  1. Reprioricen las funcionalidades que están solicitando o esperando (3) en orden del valor que le pueden dar al negocio
  2. Hagan cascada de máximo dos meses, es decir, traten de generar u obtener valor lo antes posible de forma que se minimice el riesgo, esto lo logran reduciendo los tiempos de entrega de software con valor (software en el ambiente que será entregado el producto, ya sea en ambiente de calidad o preproducción, según el caso) al menor tiempo posible, 1 mes, 2 meses (exagerando 3 meses), de forma que ustedes puedan dar o recibir feedback sobre el producto y reaccionar sobre el mismo.
  3. Identifiquen si es obligatorio seguir con ciertos documentos y entregables que solicitan, o tienen la alternativa de volver el proceso más liviano, enfocándose en los que les generan más valor al proyecto. Es importante negociar este aspecto con la contraparte.

y la última pregunta

- [Cliente] ¿y los proyectos que tenemos muy adelantados?

respondo
  1. El punto final anterior se conserva igual: Identifiquen si es obligatorio seguir con ciertos documentos y entregables que solicitan, o tienen la alternativa de volver el proceso más liviano, enfocándose en los que les generan más valor al proyecto. Es importante negociar este aspecto con la contraparte.
  2. Realicen agilidad orgánica, pues la retrospectiva siempre será el motor de la mejora continua sin importar en que punto estemos del proyecto
  3. Y dentro de la agilidad orgánica habiliten el Daily que es valioso para dejar de trabajar como islas y comenzar a ser equipo.
Hasta acá este pequeño compartir, bienvenido el feedback.


Saludos ágiles

Jorge Abad



Notas, Referencias, Comentarios y Aclaraciones

  1. Este post podría llamarse también: "AGILIZANDO PROYECTOS EN CASCADA"
  2. Es importante que este facilitador conozca de prácticas ágiles para ir orientando al equipo en su proceso de agilización, recordemos El Paciente se Enferma de lo que el Médico Sabe
  3. Esto es, dependiendo si es cliente o proveedor quien hace la pregunta.

martes, septiembre 06, 2016

Algunos Tweets de Agilidad y Scrum















domingo, julio 05, 2015

Leído y Recomendado: Diseño colaborativo: un proceso en dos etapas

Este post de Diego Fontdevila

Sobre del diseño colaborativo del software, en donde existe un momento divergente donde el equipo explora opciones y luego otro convergente donde elige la que le parece adecuada

https://diegofontdevila.wordpress.com/2015/07/01/diseno-colaborativo-un-proceso-en-dos-etapas/

Saludos ágiles
Jorge Abad

martes, junio 30, 2015

Video: Siete principios de diseño ágil con objetos - Hernán Wilkilson



Excelente charla, con grandes planteamientos de Hernán Wilkinson (@HernanWilkilson) de 10 pines dictada para @agilescolombia.

Va de lo básico, pasando por lo  reflexivo y terminando en lo avanzado, sin perder el hilo y de una forma magistral.

Diría que es de estudio obligatorio para cualquier desarollador y equipo de software.


Los siete principios son:
  1. Favorecer el uso de objetos inmutables
  2. Crear Objetos Completos
  3. Los objetos tienen que ser válidos
  4. No usar setters
  5. usar modificaciones atómicas
  6. no usar NULL
  7. Usar metáforas

Saludos ágiles

Jorge Abad

domingo, enero 25, 2015

Leído y Recomendado: “Vamos a automatizar pruebas”. ¿Qué significa esto? ¿Realmente por dónde deberíamos empezar a automatizar?

Tomado de: http://www.javiergarzas.com/2015/01/automatizacion-pruebas.html

Excelente post de la página de Javier Garzas

Lo copio, pues lo considero de colección

--------
Hoy en día muchas empresas software, por su negocio quieren ser ágiles. Quieren sacar productos más rápido al mercado y adelantarse a la competencia, mejorando para ello la calidad de su proceso, producto y equipos software.
Una de las claves para agilizar ese proceso, detectar errores antes, en puntos del desarrollo en los que nos cueste menos solucionarlos y así desarrollar con más seguridad, es la optimización y automatización de ciertos procesos y pruebas (muy relacionado con Integración Continua).
Sé que no es un cambio sencillo y que automatizar pruebas tiene un coste (lo vivo en el día a día, ya que Integración Continua, testing ágil, automatización de pruebas, son campos en los que trabajo en dentro 233 Grados de TI.).
No obstante, creo que con recursos limitados, sin automatizar ciertas pruebas es complicado llegar al testing ágil.
Dentro de este día a día, me da cada vez más la impresión, de que al igual que ocurre con la calidad de software en general, en ciertas ocasiones no se tiene muy claro qué implica la automatización de pruebas. Ni qué implica el testing ágil.
De ahí que escuche cosas como:
– “Para el mes que viene estará todo automatizado, ¿no?”
– ¡Ah, genial! Si automatizamos las pruebas…¡Nos ahorraremos a los testers manuales!
– ¡Sí, automaticemos pruebas! Tú enséñanos a automatizar pruebas con eso de Selenium, que le das al botoncito, tocas cuatro cosas y vas grabando lo que haces.
Pero la automatización de pruebas implica más que eso. Ahora verás por qué.

¿Automatizaremos todo? ¡Así nos ahorraremos el testing manual! ¿No?

Como comenté en ¿Cómo enfoco el testing de forma ágil?, el objetivo de la automatización de pruebas no es eliminar por completo el testing manual, ni suplantar a los testers manuales.
Lo que automatizamos son chequeos, comprobaciones que los testers manuales previamente han detectado antes: ciertas pruebas de regresiónsmoke test etc.
En este enfoque de testing, durante la evolución de un sistema, un caso de prueba comienza siendo manual, para luego ser automatizado.
Así los testers manuales pueden dedicarse a buscar otros bugs más complejos o testear nuevas funcionalidades.
Incluso puede haber ocasiones en las que automatizar alguna prueba o generar las condiciones necesarias para ello sea tan costoso, que sea más rentable mantenerla manual.

¿Y por dónde empezamos a automatizar?

Por otra parte, la calidad del software tiene muchos ámbitos (Calidad del software es mucho más que el testing).
Y dentro de lo que es el testing, existen distintos tipos de pruebas, cada una orientada a detectar y prevenir ciertos tipos de errores en el software.
Probablemente lo que primero suele venirnos a la cabeza cuando oímos hablar de automatización de pruebas son automaciones de “record & play”, por ejemplo con herramientas tipo Selenium IDE, que te permiten simular y grabar tus interacciones con la interfaz de la plataforma, con el navegador web etc.
Depende de qué plataforma, a primera vista pueden resultar las más sencillas de automatizar.
Es cierto que son automatizaciones necesarias, pero no son las que más retorno de inversión aportan, ni las que deberían automatizarse en mayor cantidad.
Principalmente, porque la interfaz de usuario es la parte más propensa a cambios de toda la aplicación, y para automatizar pruebas y tener fiabilidad sobre lo que estamos ejecutando necesitamos cierta estabilidad: un cambio en la interfaz podría hacer fallar la prueba automática, y en ese caso, tendríamos que readaptarla para que volviera a funcionar.
Por eso este tipo de pruebas suelen tener un coste de mantenimiento mayor que el resto.
Sí que tenemos que automatizar las pruebas de interfaz, pero mi consejo es que lo hagas después de haber automatizado otras partes más estables de la aplicación, el núcleo en sí, que aporta más retorno de inversión.
Por ejemplo, un buen primer paso es automatizar los test de API (funciones, elementos que ofrecemos desde nuestro software para que otro software, u otras partes del nuestro, puedan interactuar con él).
Hay varios niveles a la hora de automatizar pruebas. El secreto está en automatizar en el grado adecuado y en los niveles adecuados para nuestra aplicación.

Pirámide de Cohn.

La pirámide de pruebas de Mike Cohn, descrita en su libro Succeeding with Agile, ha sido un referente en este campo durante mucho tiempo.
idealautomatedtestingpyramid
En ella Cohn establece que hay varios niveles de pruebas, y señala el grado en el que deberíamos automatizarlas. Lo ideal sería:
– Muchos tests unitarios automáticos, porque un primer punto primordial para detectar fallos es a nivel de desarrollador. Si una funcionalidad en este punto falla, podrían fallar pruebas de los siguientes niveles: integración, API etc.
– Bastantes tests a nivel de API, integración de componentes, servicios, que son los más estables y candidatos a automatizar.
– Menos tests de interfaz gráfica automatizados. Ya que estos tests son variables, lentos en su ejecución y con muchas dependencias con otros componentes.
Aún así, en este punto, no suelo utilizar esas herramientas de record & play para automatizar pruebas de interfaz de usuario, ya que el código autogenerado por algunas de ellas no es muy mantenible (existen alternativas como Selenium WebDriver, que hace lo mismo pero programando tu el código).
– Un nivel estable de pruebas automáticas, que vayan detectando los testers manuales y se vayan automatizando paulatinamente, para que llegue un momento en el que invirtiendo los mismos recursos logremos cada vez una cobertura mayor de pruebas.

Mala estrategia de automatización: el patrón del “cono de helado”

En la automatización de pruebas hay que tener cuidado, ya que en ciertas ocasiones se tiende a perder el foco y a invertir en automatización en el nivel y grado no adecuado.
Una mala estrategia en estos casos, es lo que llamamos el patrón “del cono de helado”.
softwaretestingicecreamconeantipattern
Como ves es lo contrario a la pirámide de Cohn: centramos el foco en muchas pruebas manuales y en automatizar pruebas de interfaz de usuario, y nada de pruebas unitarias. Con todos los problemas que acarrea no detectar errores en los otros niveles y dejarlo todo para la parte más visible de la aplicación.
Además ten en cuenta, que una buena estrategia de automatización de pruebas conlleva más cosas que solo automatizar las pruebas en sí: crear un buen framework de automatización, parametrizar los tests, las ejecuciones para los distintos entornos, lanzar los test con distintos datos de prueba y gestionar dichos datos, sistemas de logs, buenos reportes con información que sirvan para obtener conclusiones, montar una buena infraestructura contra la que lanzar esos tests, paralelizarlos etc.

domingo, agosto 31, 2014

Software funcionando sobre....¿pruebas exhaustivas e intensivas?

Siempre me he mantenido en algo que aprendí de tantas conversaciones con mis amigos y compañeros haciendo software, y de la experiencia:

LA CALIDAD DEBE TRABAJAR PARA EL SOFTWARE Y NO AL CONTRARIO

igual se podría leer en el contexto organizacional

LA CALIDAD 
Y/O PROCESOS DEBEN TRABAJAR PARA LA ORGANIZACIÓN Y NO AL CONTRARIO 


En Agile damos prioridad a software funcionando, pero es necesario hacer pruebas, ¿cuántas?¿cuáles?, la repuesta es: todas y cada una que le permitan entregar un software funcional y de valor, de modo que usted no pierda la tranquilidad y el sueño luego de terminar su jornada laboral, léase entonces:

  • pruebas par
  • pruebas unitarias
  • pruebas funcionales
  • pruebas de integración
  • pruebas de seguridad
  • pruebas de compatibilidad
  • pruebas de adaptabilidad 
  • pruebas de instalabilidad..
  • pruebas de stress
  • etc
  • etc
  • etc
Pero cuantas y cuales..vuelvo y lo repito  LAS NECESARIAS ni una más, ni una menos.

A que se refiere esto, por ejemplo dentro de las prácticas ágiles se encuentran:
  •  TDD : Test driven development - desarrollo dirigido por las pruebas
  • ATDD: Aceptance test driven development - desarrollo dirigido por las pruebas de aceptación
Y hablamos de cobertura (cuantas pruebas aseguran nuestro código).

Sobre lo que quiero llamar la atención es:
  • NO ES NECESARIO cubrir todo el código con pruebas unitarias (ejemplos los POJO, DTO, o VO no lo requieren), solo objetos que tengan lógica de negocio (es mi humilde recomendación, ahora si a tu equipo esto le agrega valor, lo acepto y difiero respetuosamente).
  • Ni es estratégico  volcarse a una cobertura de 100% de pruebas sobre el código.

Nuestro objetivo es proveer software funcional, las pruebas nos ayudan a hacer software funcional pero como tal:
  • Las pruebas no son un entregable que agregue valor al cliente, me explico, si hacemos pruebas o no al cliente no le interesa, a el solo le interesa que funcione y no falle..
  • Las pruebas codificadas se convierten en una pieza de código más para mantener
    • incluir en el servidor de integración continua
    • hacerle refactor
    • corregir,
    • adaptar,
    • etc
Por lo tanto,  hagamos las pruebas suficientes para estar tranquilos y que nos aseguren ENTREGAR SOFTWARE DE CALIDAD.


LA CALIDAD NO ES NEGOCIABLE...

Pero 

LA CALIDAD DEBE TRABAJAR PARA EL SOFTWARE Y el no software para cumplir con tdd del 100%, atdd del 100%, etc, etc.



Saludos ágiles
Jorge Abad