Lecciones Aprendidas en Desarrollo de Software
Blog donde se publican las lecciones aprendidas en todas las actividades de desarrollo de software. Busca ser una base de conocimiento para todos aquellos que queremos no repetir nuestros errores ni los de otros. La idea es ayudarnos entre todos, gerentes de proyectos, programadores, arquitectos, tester etc. Adicionalmente en los últimos años con mucho enfoque a las metodologías agiles, scrum, kanban, etc.
domingo, diciembre 04, 2022
Frase sobre priorización
Anti-patterns (bad practices) in prioritization of Product Owners, PMO and VMO
Hello everyone
One of the factors that most destroys agility is the lack of adequate prioritization patterns according to the context in which it is located, that is, both upstream (1) and downstream (2) practices are used (which even from the good intention) destroy value for the organization. In general, we can incur:
- Building unnecessary things
- Building things that are necessary but worthless
- You don't build what's important
- We let ourselves be carried away by intuition
- We let ourselves be carried away by authority
- We let ourselves be carried away by feelings of friendship or enmity
- etc.
We destroy value and generate waste by dedicating time, effort and money from business areas, execution areas and suppliers in things that should not have been developed and relegating others, which would allow better financial performance or customer satisfaction.
Below, I share some of the anti-patterns that I have observed when prioritizing both PMO - Project Management Office -, VMO -Value Management Office- and Product owners, and that I promote to be removed in processes of agile transformation or team agile coaching.
I hope they will help you advance in the knowledge of better ways to prioritize the work to be done.
Expect more articles on this topic.
Agile greetings,
Jorge Abad.
References, notes, or comments
- Upstream: where the project, product or initiative is prioritized by the PMO, VMO or those who are responsible for prioritizing the portfolio.
- Downstream: where the product is being developed, and the solution team builds the different functionalities.
sábado, diciembre 03, 2022
De Colección: Antipatrones (malas prácticas) en priorización de Product Owners, PMO y VMO
Hola a todos,
Uno de los factores que más destruye la agilidad es la carencia de patrones adecuados de priorización de acuerdo con el contexto en el que se encuentre, es decir, tanto aguas arriba (upstream) (1) como aguas abajo (downstream) (2) se emplean prácticas (que aun desde la buena intención) destruyen valor para la organización. En general podemos incurrir en:
- construir cosas innecesarias
- construir cosas necesarias pero carentes de valor
- no se construye lo realmente importante
- nos dejamos llevar por la intuición
- nos dejamos llevar por la autoridad
- nos dejamos llevar por los sentimientos de amistad o enemistad
- etc.
--- Ver video explicativo aquí ---
Referencias, notas o comentarios
- Upstream: donde se prioriza el proyecto, producto o iniciativa por parte de la PMO, VMO o quienes se encargan de priorizar el portafolio.
- Downstream: donde se está desarrollando el producto, y los equipos de solucionadores a construyen las diferentes funcionalidades.
viernes, diciembre 02, 2022
Definición de Ágil, en mis Propias Palabras
Hola a todos
Confieso que me gusta mucho ir a las fuentes, e investigar qué dijeron, qué opinaron y cómo nacieron los conceptos. Dentro de esa búsqueda y entendimiento de lo ¿Qué es Ágil?, siempre uso la definición oficial de la Agile Alliance:
Traducido de (1) |
-----
¿Qué es Ágil?
Tomado de (1) |
What is Agile?
Agile is the ability to create and respond to change. It is a way of dealing with, and ultimately succeeding in, an uncertain and turbulent environment.
The authors of the Agile Manifesto chose “Agile” as the label for this whole idea because that word represented the adaptiveness and response to change which was so important to their approach.
It’s really about thinking through how you can understand what’s going on in the environment that you’re in today, identify what uncertainty you’re facing, and figure out how you can adapt to that as you go along.
Pero cuando me piden que lo diga en mis propias palabras, lo expreso más o menos de la siguiente forma:
Llamado a la acción
¿Te animarías a crear tu propia definición de ágil? Es un buen ejercicio individual y de equipo. Eso sí toma siempre el manifiesto ágil, los principios ágiles y la definición de ágil de la Agile Alliance, puede que te lleves grandes excelentes sorpresas.Saludos ágiles
Jorge Abad.
Referencias
- Agil 101 - https://www.agilealliance.org/agile101/
domingo, noviembre 27, 2022
Agile Manifesto. Lost in Translation (and Business Areas Lost in Context)
En estos más de 12 años de trabajar directamente con la agilidad y más de 20 como profesor universitario, constantemente en entrenamientos y cursos he hablado del manifiesto ágil, y cuando lo hago sigo el siguiente proceso:
- Muestro el manifiesto en inglés (no difiero mucho con la traducción) - agilemanifesto.org
- Lo presento en español - agilemanifesto.org/iso/es/manifesto.html
- Lo explico y discuto.
- Explico quiénes son los que firmaron el manifiesto ágil e invito a que los busquen y sigan en redes, blogs, empresas, Twitter, Facebook, Youtube, LinkedIn (como dicen modernamente, los invito a stalkear).
- Luego paso a los principios en español - agilemanifesto.org/iso/es/principles.html y similarmente los explico y discuto en detalle.
- Business people and developers must work together daily throughout the project.
- Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
- Los responsables de negocio y los desarrolladores debemos trabajar juntos diariamente durante todo el proyecto.
- Los responsables de negocio y los desarrolladores tenemos que trabajar juntos diariamente durante todo el proyecto.
- Los responsables de negocio y los desarrolladores tenemos la obligación de trabajar juntos diariamente durante todo el proyecto
- Working software over comprehensive documentation
- Software funcionando sobre documentación extensiva
- Software funcionando sobre documentación completa
- Software funcionando sobre documentación integral
Pongamos foco en el punto de dolor
Áreas de negocio perdidas en el contexto del desarrollo de software
- El proceso de desarrollo software es un proceso de adquisición de conocimiento (4), entre más se interactúa con el cliente, mejor se entiende su necesidad y lo solución es moldeada de acuerdo con el entendimiento de esta.
- Como lo afirmaba Watts S. Humphrey (conocido como padre de la calidad del software) "Para un nuevo sistema de software, los requisitos no serán completamente conocidos hasta después que los usuarios hayan usado el sistema", por lo tanto, implica una validación de la constante del software para descubrir la solución deseada (5).
- La complejidad creciente del software, la cantidad de conexiones de este y las posibles interacciones y comportamientos requiere de un proceso de acompañamiento de quien lo solicita.
- De una solución de software solo el 20% es usado frecuentemente, 30% usado algunas veces, 50% poco o nunca usadas (6). Por lo tanto, si queremos llegar a construir software más rápido debemos evitar a toda costa construir software que no será usado y esto solo se logrará con un ejercicio constante de priorización y validación por parte del cliente del área usuaria.
- Los requisitos de software son inestables en un mundo cambiante o VUCA (7). Actualmente los requisitos tienen una vida útil de seis meses o menos (8). Ver imagen continuación
Define un poco* de software a ser construido
↪ Construye lo poco anteriormente definido
↪ Entrega a los usuarios lo construido lo antes posible para validar si es lo requerido o no
Cerrando
![]() |
Imagen generada con Dall-e (9) |
- Participa activamente en las sesiones del marco de trabajo
- Prioriza por valor el trabajo a realizar o Product Backlog
- Proporciona retroalimentación sobre el software funcionando
- Interactúa diariamente con el equipo
- Interactúa con tus usuarios y conócelos, valida sus expectativas y valida el uso de la aplicación una vez la comiencen a usar
- Si careces de tiempo para estar con el equipo solucionador, y quieres entregar los requerimientos y que otros lo construyan sin tu compromiso; la agilidad y el construir soluciones de software de alto valor y retorno no es lo que tu o tu organizacion están buscando; y con seguridad construirás software de desperdicio.
- Involucra y compromete al cliente
- Muéstrale el valor de participar con el equipo
- Enséñale a priorizar
- Garantiza a que comprenda el valor de las entregas tempranas
- Compártele experiencias de otras personas en la industria acerca de usar marcos ágiles
- Instrúyele como puede generar valor más rápido con menos alcance
- Convéncelo que en escenarios de incertidumbre su interacción diaria y continua es garantía de éxito.
- Demuestra progreso con software de valor funcionando en periodos de un mes o menos, con preferencia al periodo más corto.
Ahora, respecto a las traducciones del tercer principio del manifiesto,
usa la que mejor se adapte a tu entorno.
Nota de agradecimiento
- Openess, traducido como apertura normalmente, pero una traducción más fiel sería Franqueza
- Accountability: que significa responsable de que algo se haga, aunque no sea el ejecutor, pero en español no tiene traducción directa y quedó con la palabra de responsabilidad que significa lo mismo, sea que se delegue o no.
Comentarios, referencias y aclaraciones
- Sí, es cierto, si estás haciendo cuentas, luego de firmado el manifiesto en el 2001 comencé a compartirlo en las clases de ingeniería de software y taller de ingeniería de software en la Universidad Eafit en Medellín www.eafit.edu.co
- Cotidiano, na: diario - dle.rae.es/cotidiano
- Comprehensive - https://www.oxfordlearnersdictionaries.com/definition/english/comprehensive_1?q=comprehensive
- Esta frase se la escuché a mi gran amigo y agilista Hernán Wilkinson y resueno bastante con ella.
- https://es.wikipedia.org/wiki/VUCA
- https://www.infoq.com/articles/contract-model-failure
- Imagen generada con Dell-e https://labs.openai.com/s/ml4XX2e8frHQ8yc2sRidpG9u
- Algunas imágenes de referencia
viernes, noviembre 18, 2022
Master Class: Desde la Visión hasta las Historias de usuario
Enlace a Mural - Clic aquí -