Hola a todos
Les comparto esta divertida entrevista a Freddie Mercury (vocalista de Queen), aprovechando que todos los estamos recordando por estos días.
Lo más interesante es la definición de banda (equipo) que tienen ellos, ¿les parece conocida?. Espero la disfruten
----
viernes, diciembre 28, 2018
martes, noviembre 13, 2018
¿Por qué NO DEBES contratar en Cascada un proyecto a ser desarrollado con metodologías ágiles? (o ¿Por qué no puedes contratar en alcance, tiempo y costo fíjo un proyecto ágil?)
Lucho Salazar (@LuchoSalazarC) y Jorge Abad (@Jorge_Abad)
Aunque en varios foros hemos compartido que contratar en Cascada (o tradicional, o con alcance, tiempo y costo fijos) un proyecto (o mejor, producto) ágil es completo dolor de cabeza para ambas partes, es como querer jugar rugby con las reglas del del fútbol, en este post, quisiéramos compartirte unas ideas claves de por qué no te conviene hacer esto tanto desde del punto de vista del Cliente como del Proveedor, vamos pues:
Saludos Ágiles
Lucho Salazar (@LuchoSalazarC) y Jorge Abad (@Jorge_Abad)
Problemas desde el punto de vista del Cliente
- El alcance no puede ser fijo en estos tiempos de alta disrupción (VUCA (1)) y es un error tratar de definir los requisitos a priori dada esta misma volatilidad(2)
- El proceso de control de cambios (no te agregaría ningún valor)haría muy lenta las decisiones, y retrasaría el Time to Market, considerando que en ágil existe una continua repriorización y modificación de los requisitos en función del valor.
- Tal vez (la verdad, muy seguramente) te obligues a construir lo innecesario.
- Como la responsabilidad no es compartida, se genera una relación de competencia en vez de una relación de colaboración, impidiendo maximización del valor del producto.
- Las estimaciones y costos con seguridad estarán inflados debido a la incertidumbre
- Quemarás al proveedor y al equipo de trabajo, pues estos fallarán continuamente en sus estimaciones.
- Los contratos tradicionales se basan en la desconfianza. Esto aumenta la incertidumbre y maximiza los riesgos. La incertidumbre y los riesgos nunca son buenos para el cliente, generan presión y desgaste. Se pierde el foco en lo que es realmente importante: el valor para la organización y la oportunidad.
- Los planes se basan la percepción y no en la realidad. Lo que conduce a que haya una dedicación exclusiva a "cuidar" esos planes. Esto es desperdicio. Pérdida de dinero. Dinero del cliente.
- La realidad es lamentable: con un contrato tradicional siempre o casi siempre hay desviación por sobrecostos, esto “hiere” mortalmente la confianza interna del cliente, es decir, entre las áreas involucradas.
- Los continuos cambios pueden ocasionar modificaciones en las cláusulas en el contrato. Allí surgen roces entre las partes, proveedor y cliente.
Problemas desde el punto de vista del Proveedor
Nota: este tipo de espantajos metodológico-contractuales por lo general se contratan bajo la siguiente forma: un alcance definido o que se define durante los primeros dos o tres meses y luego se hace una estimación que se parte en sprints.- De entrada sabes que la estimación es fallida, que debes incrementar costos y tiempos y no tienes como justificarlo, y aunque lo justifiques el cliente no te creerá haciendo reducir costos y tiempo (pues el alcance lo dejan fijo) y exponiéndote a un riesgo financiero, reputacional o de penalidades.
- Aunque estimes a priori el proyecto y ejecutes por sprint, te atrasarás debido a la incertidumbre de reinante en el mundo del software, incrementando la presión sobre el proyecto y la ejecución
- Te la pasarás reunión tras reunión justificando por qué no estás cumpliendo el plan (sabiendo que trabajas en scrum con sprints) y tratando de reacomodar el plan
- Los controles de cambio son un dolor de cabeza que no te permite realizar priorización por valor que le conviene más al cliente y al proyecto (producto)
- Las métricas de seguimiento cascada aplicadas al proyecto (o producto) en ágil generan un desgaste pues no hacen match con las métricas de seguimiento ágil.
- Quemarás a tu equipo tratando de ponerte al día con el cronograma de sprints comprometido al principio del proyecto.
Soluciones
- Contrata en ágil los proyectos ágiles (ver nuestro video sobre contratos ágiles - https://www.youtube.com/watch?v=872uF0dPYd8)
- Pon cláusulas de terminación anticipada, que te sirvan cuando decidas no continuar con el cliente o con el proveedor según el caso.
- En un contrato ágil nunca pongas el alcance fijo.
- Si te preocupan los ANS o SLA, en Scrum tienes software funcionando cada dos semanas lo que permite validar si el proveedor está construyendo el producto de forma satisfactoria.
Saludos Ágiles
Lucho Salazar (@LuchoSalazarC) y Jorge Abad (@Jorge_Abad)
Referencias, comentarios, notas y aclaraciones
- VUCA. Las siglas en inglés de Volatilidad, Incertidumbre, Complejidad, Ambigüedad. Más en https://hbr.org/2014/01/what-vuca-really-means-for-you
- Radioactividad de los requisitos - La necesidad de un enfoque ágil en la industria del desarrollo de software - http://www.lecciones-aprendidas.info/2015/04/radioactividad-de-los-requisitos.html
- Este artículo fue escrito a cuatro manos, y fue publicado en el Gazafatonario IT en http://www.gazafatonarioit.com/2018/11/por-que-no-debes-contratar-en-cascada.html
lunes, noviembre 12, 2018
Algunos Tweets Importantes sobre Historias de Usuario
Stop worrying about writing perfect users stories. As @jeffpatton writes in User Story Mapping, stories are meant to be told, not written.— Jim Constant (@TheAgilePO) May 28, 2014
"stories aren't a different way to write requirements, they're a different way to work!" @jeffpatton pic.twitter.com/cT91mB2ERe— Andy de Vale (@andydevale) October 30, 2018
@jmbeas @jeffpatton @david_caicedo http://t.co/nZu7d99Va2http://t.co/pcRLrNfs48— Ron Jeffries (@RonJeffries) May 23, 2015
Key point: User Stories are TOLD, not written.
Agile stories don't rely on the document as the primary mechanism for building shared understanding, they rely on the story telling. https://t.co/j735QrOCE9— Jeff Patton (@jeffpatton) October 27, 2016
"We don’t need an accurate document, we need a shared understanding." - @jeffpatton— Rich Rogers (@RichRogersIoT) April 18, 2018
As an author of the Agile Manifesto
— Ron Jeffries (@RonJeffries) April 7, 2016
I want that stupid story format to go away
So that people can get to the essence of user stories.
@keithb_b if your user story begins "As a", you haven't understood user stories.
— Ron Jeffries (@RonJeffries) October 1, 2016
De Colección: Algunas frases que sirven para el desarrollo de productos
"No hay nada más inutil que hacer eficientemente aquello que no debería haberse hecho en absoluto" [Peter Drucker]— Lucho Salazar (@luchosalazarc) November 12, 2018
"La perfección no se alcanza cuando no hay nada más que añadir, sino cuando no hay nada más que quitar" Antoine de Saint-Exupéry— Jorge Hernán Abad L. (@jorge_abad) November 13, 2018
jueves, noviembre 08, 2018
Dos razones del cambio
“We generally change ourselves for one of two reasons: inspiration or desperation.”― Jim Rohn
"Generalmente cambiamos por una de estas dos razones: inspiración o desesperación"― Jim Rohn
----
#DeColección— Jorge Hernán Abad L. (@jorge_abad) November 17, 2017
“We generally change ourselves for one of two reasons: inspiration or desperation.”
― Jim Rohn
miércoles, noviembre 07, 2018
Todos estamos jugando a ganar.
Una Reflexión
De las cosas que mas me han servido laboralmente (y hasta en el ámbito personal) en los últimos años, es comprender que TODOS SIEMPRE (es cierto, es una generalización) ESTAMOS JUGANDO A GANAR.
La clave es entender que la DEFINICIÓN DE GANAR de los otros, algunas veces es la misma nuestra, otras veces es no (y eso no es malo). Saber alinearse, saber entender o encontrar esa definición del otro, me ha ayudado a ser más empático y a generar mejores resultados donde hay más abundancia para las partes.
Esta habilidad me ha permitido ser mejor #influenciador y mejorar altamente la colaboración.
Saludos ágiles
Jorge Abad
De las cosas que mas me han servido laboralmente (y hasta en el ámbito personal) en los últimos años, es comprender que TODOS SIEMPRE (es cierto, es una generalización) ESTAMOS JUGANDO A GANAR.
La clave es entender que la DEFINICIÓN DE GANAR de los otros, algunas veces es la misma nuestra, otras veces es no (y eso no es malo). Saber alinearse, saber entender o encontrar esa definición del otro, me ha ayudado a ser más empático y a generar mejores resultados donde hay más abundancia para las partes.
Esta habilidad me ha permitido ser mejor #influenciador y mejorar altamente la colaboración.
Saludos ágiles
Jorge Abad
martes, noviembre 06, 2018
Suscribirse a:
Entradas (Atom)