Este blog comparte estrategias y aprendizajes sobre desarrollo de software, marcos, metodos y metodologías ágiles como Scrum, Kanban y XP, con un enfoque en escalamiento ágil y Business Agility. Su propósito es ayudar a profesionales de la gerencia de proyectos y productos a mejorar sus procesos y promover la experimentación como motor de innovación, facilitando su adaptación en entornos empresariales cambiantes.
jueves, diciembre 25, 2014
Leído y Recomendado: Feedforward
Excelente artículo para aplicar tanto en el escenario profesional como personal
http://www.marshallgoldsmithlibrary.com/docs/Spanish/Intente-el-FeedForward.pdf
Éxitos
martes, diciembre 23, 2014
¿y las horas de dónde las saco? – Casos de la vida real.
Hola a todos,
Miremos el siguiente escenario
-----
INTRODUCCIÓN
Cliente: ¿tengo unos requisitos* que necesito me cotices?
Proveedor: Claro Mauricio, ¿pásamelo yo lo analizo?
Cliente: Claro que sí. Estímalo tranquilo y dime cuantas horas son.
Poco tiempo después en la oficina del proveedor…
- Carlos. Necesito me estimes estos requisitos
- Vale, déjame los miro y analizo con calma.
Al día siguiente…
-Jefe, le tengo la estimación, son 3 semanas más o menos 140 horas.
- Ok, Carlos muchas gracias. ¿Pero ves algún riesgo, algo que pueda alargar la ejecución?
- No Juan, todo está ok. Con ese dato podemos irnos tranquilos, hasta le puse unas holguras por si algo no sale como lo planeado.
- Excelente unas horas a nuestro favor - que tanta falta nos hacen - .
Luego con el cliente telefónicamente
Proveedor: Hola Mauricio, Ya te tengo la estimación son 140 horas** , y podemos comenzar a trabajar en los requisitos el próximo lunes, la entrega será en 20 días hábiles.
Cliente: Perfecto Juan, quedemos así, hago entonces la reserva en el presupuesto e informaré a los de infraestructura para que preparen el ambiente para el despliegue de esas funcionalidades.
NUDO
Semana 1
Gerente de Proyecto (GP): ¿qué tal el avance, Carlos***?
Carlos: vamos bien, sin ningún lío,
GP: vale, hablemos en una semana
Semana 2
GP: ¿qué tal el avance, Carlos?
Carlos: tengo un problemita con una librería pero entre hoy y mañana lo soluciono
GP: vale, hablemos en una semana. Si necesitas algo o a alguien no dudes en decirme.
Semana 3
GP: ¿qué tal el avance, Carlos, recuerda que esta semana entregamos?
Carlos: el problema tomo más tiempo y el desarrollo creo que estará en 2 semanas más a las estimadas
GP: seguro no puedes terminarlo antes
Carlos: No
GP: ¿y fue error nuestro (1) la mala estimación?
Carlos: la verdad si, aunque el alcance está claro hubo cosas que no vi y me están tomando más tiempo estimado
GP : ¿Seguro no podemos hacerlo en menos tiempo? Vamos a quedar mal con el compromiso
Carlos: pues comenzaré a quedarme al final del día dos horas diarias para ver si lo termino una semana antes (2)
GP: Gracias Carlos, personas como vos son las que necesitamos
Un momento más tarde:-
Proveedor: Mauricio, la entrega la vamos a realizar para la semana 5, no la 4 como te la había informado
Cliente: ¡Que mal Juan!, ¡que problema!, bueno será mover a IT, y cuadrar reasignar a la gente ¿y qué fue lo que paso?¿qué saló mal?
Luego con el cliente telefónicamente
Proveedor: Hola Mauricio, Ya te tengo la estimación son 140 horas** , y podemos comenzar a trabajar en los requisitos el próximo lunes, la entrega será en 20 días hábiles.
Cliente: Perfecto Juan, quedemos así, hago entonces la reserva en el presupuesto e informaré a los de infraestructura para que preparen el ambiente para el despliegue de esas funcionalidades.
NUDO
Semana 1
Gerente de Proyecto (GP): ¿qué tal el avance, Carlos***?
Carlos: vamos bien, sin ningún lío,
GP: vale, hablemos en una semana
Semana 2
GP: ¿qué tal el avance, Carlos?
Carlos: tengo un problemita con una librería pero entre hoy y mañana lo soluciono
GP: vale, hablemos en una semana. Si necesitas algo o a alguien no dudes en decirme.
Semana 3
GP: ¿qué tal el avance, Carlos, recuerda que esta semana entregamos?
Carlos: el problema tomo más tiempo y el desarrollo creo que estará en 2 semanas más a las estimadas
GP: seguro no puedes terminarlo antes
Carlos: No
GP: ¿y fue error nuestro (1) la mala estimación?
Carlos: la verdad si, aunque el alcance está claro hubo cosas que no vi y me están tomando más tiempo estimado
GP : ¿Seguro no podemos hacerlo en menos tiempo? Vamos a quedar mal con el compromiso
Carlos: pues comenzaré a quedarme al final del día dos horas diarias para ver si lo termino una semana antes (2)
GP: Gracias Carlos, personas como vos son las que necesitamos
Un momento más tarde:-
Proveedor: Mauricio, la entrega la vamos a realizar para la semana 5, no la 4 como te la había informado
Cliente: ¡Que mal Juan!, ¡que problema!, bueno será mover a IT, y cuadrar reasignar a la gente ¿y qué fue lo que paso?¿qué saló mal?
Proveedor: Una funcionalidad nos tomó más de lo esperado, nos tocó modificar los componentes x, y, z , que no se identificaron en la estimación , pero también quisiera aprovechar esta conversación para solicitarte el pago de esas horas adicionales
Cliente: Con respecto a la funcionalidad, comprendido, pero respecto al reconocimiento, no Juan, vos sabes que no puedo hacerlo contractualmente.
DESENLACE
- El desarrollador se demoró en total 6 semanas
- La empresa puso de su bolsillo 140 horas adicionales
- El desarrollador puso de su tiempo personal 30 horas (que no sabe si se las reconocerán)
- El cliente está molesto por la entrega tardía (6 semana)
- El proveedor perdió dinero y credibilidad.
- Se decide enviar a Carlos a un curso de Estimación
----
REFLEXIONES, DIATRIBAS Y NÚMEROS:
- El valor total del requisito en horas era 140 (estimado inicial) + 140 (ejecutado adicional) + 30 (horas aportadas por el desarrollador en su error) = 310 horas (un 121% más)
- El argumento que generalmente expone el cliente es:
- Ustedes son los expertos, yo confío y no cuestiono sus estimaciones – salvo que las vea muy desfasadas – por lo tanto, asuman ese error.
- Preguntó:
- ¿Las horas adicionales fueron “robadas”?
- ¿acaso no se dedicaron al objetivo planteado en el requisito?
- ¿el desarrollador la estimó mal, de pura mala intención?
- ¿habría alguien en el equipo en hacer su trabajo mal hecho?
- Si existe una relación de confianza cliente-proveedor ¿Por qué no se reconocen las horas justamente invertidas en los requisitos del cliente?
- ¿Por qué si algo toma menos tiempo es a favor del cliente pero si toma más es en detrimento del proveedor?
- ¿No es acaso esta la causa de que inflemos cronogramas, presupuestos y valor/hora que vendemos en el mercado? En donde tratamos de cubrir la INCERTIDUMBRE asociada al software con sobrecostos.
- ¿Por qué los clientes no pagan las horas, si son JUSTO lo que se invirtió en realizar el requerimiento con su complejidad asociada?
- ¿Por qué nos obstinamos en creer que hacer software es juntar piezas de lego (donde todas son uniformes, bonitas, lisas, y encajan perfectamente)?¿y creemos que cualquier desfase es falta de profesionalismo de cualquiera de los involucrados?
- Pienso que existen muchas formas de hacer y crear esquemas justos, tanto para cliente y proveedor:
- Reconocer el esfuerzo adicional
- La verdad esto no es deshonesto para ninguna de las partes, hora por hora fueron invertidas en el requisito o necesidad
- Pasar al cliente una pre-cotización y cerrarla con lo realmente ejecutado.
- Hay opciones más radicales
- Trabajar por tiempo y materiales con el cliente (en este caso el cliente asume todo el riesgo - ver este post sobre contratos ágiles )
- (la que más me suena) Pagar por sprint (alcance logrado en un ciclo, sea que se haga o no todo lo comprometido)
- (y la más radical de todas) cambiar de cliente.
- Tal vez si todos los proveedores funcionaran de esa forma, el juego de "si estimas mal tu pierdes y yo gano" se acabe
CIERRE
Quedan muchas preguntas por hacer y contestar, mucha cultura en el ambiente de desarrollo de software por cambiar.Espero estar poniendo con esto un pequeño grano de arena hacia ese cambio, hacia:
- un escenario justo,
- transparente y
- de riesgo compartido entre clientes y proveedores.:
Saludos ágiles y feliz navidad
Jorge Abad
----
*Semánticamente es más correcto usar requisito que requerimiento.
** En muchos casos se adicionan horas de riesgos e imprevistos, reservas de gestión, pero para efectos de ejemplo no lo haré, pero observaremos que el resultado será en términos generales el mismo.
*** La persona que estimó fue la misma que está desarrollando
(1) Por lo general le echamos la culpa a la estimación, lo grave es que una estimación no es un compromiso, es un número que tiene asociado una probabilidad de ocurrencia, tal vez sí, tal vez no, cumplamos, pero ojalá si.
(2) En este punto tanto Proveedor (Juan) como Desarrollador (Carlos) están poniendo tiempo de sus bolsillos
----
*Semánticamente es más correcto usar requisito que requerimiento.
** En muchos casos se adicionan horas de riesgos e imprevistos, reservas de gestión, pero para efectos de ejemplo no lo haré, pero observaremos que el resultado será en términos generales el mismo.
*** La persona que estimó fue la misma que está desarrollando
(1) Por lo general le echamos la culpa a la estimación, lo grave es que una estimación no es un compromiso, es un número que tiene asociado una probabilidad de ocurrencia, tal vez sí, tal vez no, cumplamos, pero ojalá si.
(2) En este punto tanto Proveedor (Juan) como Desarrollador (Carlos) están poniendo tiempo de sus bolsillos
domingo, diciembre 21, 2014
Haz pequeños experimentos en tu equipo Scrum
Una de las ventajas que ha traído Scrum al mundo del software (donde la complejidad reina) es la posibilidad de habilitar el aprendizaje y mejora continua de una forma emergente y natural.
En los equipos que siguen juiciosos el framework de Scrum (hay que hacer la claridad, pues hay quienes no, dejando por fuera elementos poderosos con la respectiva pérdida de sus beneficios) encuentran retrospectiva tras retrospectiva elementos que van incorporando en su mejora como :
En los equipos que siguen juiciosos el framework de Scrum (hay que hacer la claridad, pues hay quienes no, dejando por fuera elementos poderosos con la respectiva pérdida de sus beneficios) encuentran retrospectiva tras retrospectiva elementos que van incorporando en su mejora como :
- equipo
- en sus procesos
- y/o herramientas
Si de facto los equipos comenzaran en el Sprint 1 con lo que van a terminar empleando en el Sprint 15:
- ayudas,
- prácticas técnicas,
- formas de comunicarse entre sí y con el cliente,
- revisiones,
- registros,
- métricas
- etc
Quisiera invitarlos a realizar experimentos Sprint tras Sprint, ha realizarle seguimiento e identificar si fueron beneficiosos o no.
Con seguridad ese aprendizaje y mejora continua los llevarán como equipos a fronteras que no se habían imaginado al principio de su inmersión en la construcción del producto.
Saludos ágiles y navideños
Jorge Abad
miércoles, diciembre 10, 2014
Frase de gestión de proyectos: Una cosa no garantiza la otra.
“La buena gestión no puede garantizar el éxito del proyecto. Sin embargo, la mala gestión usualmente lleva al fracaso del proyecto” (Sommerville, 2005).
_
martes, diciembre 09, 2014
miércoles, diciembre 03, 2014
Leido y recomendado :ScrumMasters Should Not Also Be Product Owners
Hoy comienzo una etiqueta en mi blog
Leído y recomendado
Pondré el link al original y rezaré para que no sea removido el artículo.
------------------
ScrumMasters Should Not Also Be Product Owners -
http://www.mountaingoatsoftware.com/blog/scrummasters-should-not-also-be-product-owners
------------------
Saludos ágiles y
hasta el próximo post
Jorge Abad
Leído y recomendado
Pondré el link al original y rezaré para que no sea removido el artículo.
------------------
ScrumMasters Should Not Also Be Product Owners -
http://www.mountaingoatsoftware.com/blog/scrummasters-should-not-also-be-product-owners
------------------
Saludos ágiles y
hasta el próximo post
Jorge Abad
domingo, noviembre 30, 2014
Causas del "MANEJO" o dícese de "LA FALTA DE TRANSPARENCIA"
Siempre que tengo la oportunidad de dar clase, facilitar una charla o compartir con un grupo de desarrolladores de software pregunto:
¿Quiénes de ustedes han visto decir mentiras a su gerente/líder de proyectos?
o les pregunto a los gerentes de proyectos presentes:
¿ustedes dicen mentiras en sus proyectos?
La respuesta lamentablemente en ambos casos es abrumadora, es un rotundo
SI :(
Hemos visto decir en la gerencia tradicional frases como:
- a esto hay que "darle manejo"
- el avance es del "tanto" por ciento pero digamos mejor que es este otro número
- o la típica sensación de que decimos que vamos en el 90% y nos demoramos otro 90% para terminar el 10% que supuestamente nos faltaba
Pueden haber varias causas dignas de investigación, sin tener datos fiables pero de acuerdo a mi experiencia y a la de mis colegas diría, que la causa principal es que
"el proyecto se salió de control"
y es probable que sea considerado usted un mal gerente de proyecto o la culpa la tenga el equipo.
Pero viene una pregunta más fuerte,
¿se puede controlar lo que no se no es posible controlar?
¿se puede controlar lo que esta en el campo de lo complejo?
Yo pienso que NO, y esa es la causa de la falta de transparencia.
El modelo de Cynefin nos da luces al respecto (ver referencias 1 y 2 entre muchas otras)
En software todo hace que el proyecto se atrase y se vuelva impredecible:
- el cliente
- los desarrolladores (la falta o exceso de los mismos)
- los egos
- la inexperiencia
- los requisitos
- los servidores
- el software base
- la relaciones entre los componentes
- los componentes
- las buenas relaciones
- las malas relaciones
- los insumos en el momento inapropiado
- la retroalimentación tardía
- la retroalimentación de las personas inadecuadas
- lo nuevo o viejo de cierto tipo de una u otra tecnología
- objetivos poco claros
- y muchos más, (ver referencias 3,4 y 5)
Si de una vez por todas decimos con sinceridad:
- estamos resolviendo el problema del software con las herramientas incorrectas
- fallamos aplicando métodos predictivos que aplican perfectamente en escenarios donde podemos imaginar con tranquilidad los acontecimientos (escenarios complicados, según el modelo de Cynefin)
- cuando debemos ser adaptativos (o empleando el empirismo que propone Scrum), realizando inspección y adaptación (escenarios complejos, según el modelo de Cynefin) .
Espero que algún día mis compañeros Gerentes de Proyectos de Software obsesionados:
- en ser secretarios de MS PROJECT (como le dice un gran Scrum Master y Coach - Jorge Johnson)
- en darle "manejo" a las situaciones ocultando información y cayendo en la FALTA DE TRANSPARENCIA
- en controlar lo que no se puede controlar
Acojan el agilismo y abracen sus principios y valores.
Saludos ágiles
Jorge Abad
___________
Referencias:
- Sistemas Complejos Adaptativos: Modelo Cynefin (clic aquí)
- Cynefin: la complejidad que nos rodea (clic aquí)
- ¿Por qué fallan los proyectos? En: Navegapolis.net. Disponible en: <http://www.navegapolis.net/content/view/701/49/ > [citado 24 de Junio de 2014]
- STANDISH GROUP. Chaos Manifesto2013 - Think Big, Act Small. En: Version One [en línea]. Disponible en: <http://www.versionone.com/assets/img/files/CHAOSManifesto2013.pdf> [citado 24 de Junio de 2014]
- STANDISH GROUP. The Standish Group Report. [en línea]. Disponible en: <http://www.projectsmart.co.uk/docs/chaos-report.pdf> [citado 24 de Junio de 2014]
miércoles, noviembre 26, 2014
Diferencia entre SER y ESTAR. Una diatriba sobre la certificación de Scrum Master
Hola a todos...
Hace poco dicté un curso en la Universidad de Nariño (Pasto – Colombia) sobre gestión de proyectos informáticos (en la especialización de construcción de software), en esta materia vimos 40% gestión tradicional (Ms Project, Gannt, Planes, etc) y el otro 60% Agilismo y Scrum (iba a escribir gestión ágil pero lo considero un oxímoron – clic aquí – y eso la verdad no me cuadra) y al final me preguntaron ...
Lo cierto es que quiero presentar varias cosas que me dan vueltas.
Sea que elijamos
Hace poco dicté un curso en la Universidad de Nariño (Pasto – Colombia) sobre gestión de proyectos informáticos (en la especialización de construcción de software), en esta materia vimos 40% gestión tradicional (Ms Project, Gannt, Planes, etc) y el otro 60% Agilismo y Scrum (iba a escribir gestión ágil pero lo considero un oxímoron – clic aquí – y eso la verdad no me cuadra) y al final me preguntaron ...
¿profe y cómo nos certificamos?
Lo cierto es que quiero presentar varias cosas que me dan vueltas.
Sea que elijamos
- ScrumAlliance.org, y ScrumManager.net con:
- sus excelentes trairners y coaches - mis maestros - (y confieso que quiero ser uno de ellos)
- curso de 2 días
- certificación de 100 dólares
- la Scrum.org en el que por 100 dólares tienes acceso al examen (ver acá), sin necesidad de training
- u otro ente certificador ( www.scrum-institute.org/ , www.scrumstudy.com , scrumagileinstitute.org )
Con poco esfuerzo quedamos certificados, ya sea como:
- Scrum Master
- Product Owner
- o Scrum Developer
Y como en todas las certificaciones, solo pueden asegurar que SOMOS BUENOS PASANDO EL EXAMEN. y no nos hagamos tarugos (como diría un personaje de TV), el cuerpo de conocimiento de Scrum es muy pequeño como para darle más vueltas.
Además como bien sabemos, en TI por más que las critiquemos, es valioso tener una certificación.
Lo que yo veo es que SER Scrum Master y ESTAR certificado como Scrum Master dos conceptos lejanos en el e tiempo.
La certificación la veo como un momento cero (o la pequeña punta del iceberg), como el inicio del camino hacia la iluminación (el primer paso) y el SER Scrum Master es algo que vibra con uno, es un camino infinito, que te lleva a:
- leer
- intentar y fallar
- a perder y ganar
- a ratos preferir perder para que salgan las cosas que incomodan
- a preferir a las personas
- a preferir equipos
- a valorar a transparencia
- a querer generar valor en todo lo que se toca
- a buscar el coraje
- es tener el coraje para recibir retroalimentación
- es tener el coraje para darla
- a querer transformar vidas de ingenieros de sistemas o informáticos que son explotados por un sistema opresor que nosotros mismos nos inventamos (sone revolucionario, pero así lo veo)
- es levantarse cada mañana con el animo de compartir cosas nuevas, que se aprendieron y leyeron
- tratar de inspirar con el ejemplo
- en dejarse inspirar por sus compañeros
- en ser como dice Alan Cyment y mucho más UN LÍDER JARDINERO
- cortando allí,
- echando abono allá,
- agua aquí,
- tapando acá
- despegando
- moviendo raíces
- es buscar coaching constante
- es proporcionar humilde coaching
- conversar mucho con pares
- es ser un líder al servicio de toda la comunidad (no solo ágil)
- es ser humilde para comprender que SIEMPRE ESTAMOS APRENDIENDO Y DESCUBRIENDO NUEVAS FORMAS DE HACER SOFTWARE (como enuncia el manifiesto)
- Es querer ser algo que no se va a alcanzar
- Es mi utopía útil como diría Alan
Tal vez, en un futuro la certificación sea con el acompañamiento de otro (que no sabemos quien rayos lo certificó, o quien certificó al certificador), pero que luego de:
- un acompañamiento por varios días
- muchas horas de vuelo
- y quien sabe que otro requisito.
Por mi parte, la próxima vez que alguien me pregunte si soy Scrum Master, diré
NO SÉ SI LO SOY, PERO ASPIRO ALGÚN DÍA LLEGAR A SERLO
Saludos ágiles
Jorge Abad
Ser #ScrumMaster es como estar enamorado,nadie te dice si lo eres o no, solamente lo sabes. #Scrum // a ratos si pic.twitter.com/jgdTHYm7UY
— Jorge Hernán Abad L. (@jorge_abad) marzo 14, 2014
martes, noviembre 25, 2014
Cómo llevar al cliente a la agilidad - Un cambio en el plazo del contrato nos permite ser más flexibles
.Cuando un cliente dice:
Notas:
¿quiero ser ágil, pero no puedo salirme del tipo de contrato que manejamos en mi empresa?
Existe una salida, en la que poco a poco ir llevando el cliente a la agilidad, al nivel de la confianza y la colaboración. La clave consiste en cambiar el macro-proyecto por micro-proyectos
los macro-proyectos traen consigo:
- riesgos asociados al alcance, en los que con plena seguridad cuando estimamos o dimensionamos el proyecto no vimos todas las funcionalidades, y la ambigüedad (o amplitud de muchas palabras) y lamentablemente diremos:
- "pues se la forma como esta escrito, eso esta incluido y nos tocó hacerlo"
- "Comercialmente se había acordado eso aunque fallamos ponerlo en la propuesta"
- o peor "hagámoslo pues aunque es justo, eso nos haría perder al cliente"
- por lo general nos excedemos en costo, tiempo y alcance
- Llenamos los cronogramas iniciales de incertidumbres, costos y tiempos que no logramos determinar con certeza alguna
- nos toca inflar el presupuesto con un porcentajes (o valores) asociados a :
- los riesgos, generando reserva de riesgos
- y reservas de gestión, (esto lo saben mis amigos PMP y comerciales).
- creemos que ganándonos el proyecto de año y medio logramos tener un cliente, que tal vez al final ni queramos vernos mutuamente.
Cosa distinta pasa en los micro proyectos (máximo 3 meses), en los cuales:
- la incertidumbre es mucho menos
- los riesgos también son menores y disminuyen
- la estimación asociada a proyectos pequeños es mucho menor y por ende mucho mas certera (aunque asociada a la estimación hay una probabilidad de ocurrencia, y es posible que le atinemos o no, pero con seguridad la varianza será mucho menor que en proyectos grandes),
- podemos venderle al cliente la idea de:
- sino le gustamos puede cambiar de proveedor (cosa que no sucederá en la gran mayoría de los casos pues nos vamos a enfocar en conservar el cliente, y si sucede, con seguridad era lo mejor que nos podía suceder a ambas partes)
- puede incluir cambios más fácil en futuros contratos
- habrá menos insatisfacción de las partes y por ende más transparencia
- el proyecto costará menos pues los riesgos se disminuyen considerablemente y no tendrán que ser cargados en la propuesta económica
En el segundo marco irá emergiendo:
- la confianza cliente-proveedor
- El interés del proveedor de generar pronto valor en su cliente (Recordemos : "Nuestro trabajo no es hacer software, Nuestro trabajo es hacer la menor cantidad de software que le genere el mayor valor de negocio a nuestros clientes"), para ganar más proyectos.
- El cliente con este enfoque podrá ver valor de forma temprana y por ende poner en uso su producto/sistema/aplicación.
- la colaboración entre clientes y proveedores, entorno que tanto buscamos en los proyectos ágiles será cada vez más natural..
y éxitos en sus contratos
Notas:
- Este modelo es tan aplicable en el entorno privado como público.
- este post lo escribí en respuesta a una pregunta que me hicieron, espero les sirva
jueves, noviembre 20, 2014
La cara del santo hace el milagro. Efectividad del Planning y Review
Scrum tiene muchas fortalezas, esta cubierto de soluciones para años y años de heridas de guerra de equipos de software a lo ancho y largo del mundo, cada elemento esta puesto allí ayudando a que los otros funcionen.
Una de las cosas que he observado es la fortaleza que tienen el Planning y el Review, y el milagro que logra en el equipo:
El milagro del compromiso, coraje, foco y auto-organización poco a poco comienzan a emerger y ahí es cuando yo digo como el famoso dicho:
Una de las cosas que he observado es la fortaleza que tienen el Planning y el Review, y el milagro que logra en el equipo:
- En el Planning: El Team Developer con el P.O. (Product Owner - Dueño del Producto), entiende que se quiere construir y se compromete con unos ítemes de backlog que llevará a la DoD (Definition of Done - Definición de terminado). La clave acá es que al equipo nadie le impone el compromiso, es un acto de libertad, coraje y confianza en si mismos -un consenso libre entre sus integrantes -. En el esquema tradicional hay un GP (Gerente de Proyecto) que le impone unos tiempos y estimaciones a su equipo, sin otra opción que cumplir o cumplir , ya sea en el tiempo asignado o en el propio después de la jornada laboral.
- En el Review: El Team le presenta al P.O. y a los Interesados* lo construido, y pasan a la gloria, a una ligera vergüenza si algo no sale como lo esperado, o una "humillación" sino cumplieron con poco o nada de lo comprometido (con su respectiva DoD). El que siente la frustración o felicidad es el equipo al mostrar el resultado a sus directos interesados (sin intermediarios o gerentes que cuenten el "chisme" de la típica pregunta ¿como les fue en la entrega?) La cara del P.O. y los Interesados es lo que más compromete y le da propósito a un equipo.
El equipo toma poco a poco vida, reflexiona para si mismo y dice:
- tenemos que seguir dando la talla o
- no nos puede volver a pasar esta misma situación
(esta puesta la semilla para la retrospectiva)
La cara del santo** hace el milagro
Saludos ágiles
Jorge Abad.
* Interesados: Puede ser los líderes funcionales de los clientes, usuarios, o cualquier persona que le importe en obtener un buen producto
** P.O.+ Interesados
** P.O.
viernes, noviembre 14, 2014
Sobre la Anarquía, la Libertad, el Sistema y otros Enyerbes
Hola a todos
Cuando viví Scrum hace más o menos 2 años, siendo Scrum Master por primera vez, sentí en ese entonces mucha libertad, alegría y ganas de cambiar al mundo. Lo digo y lo sostengo, si no hubiera sido por Scrum, el manifiesto ágil y las metodologías ágiles estaba destinado a ver terminar mis días en software en "lo que mejor se pudiera hacer" pero no en lo que me apasionara.
Había perdido la fe en hacer software y estaba buceando entre tanto material, certificaciones, procesos, y tendencias, a ver en que rollo raro me metía para recuperar el amor por aquello que me hizo cambiar de ser un ingeniero civil (que por lo menos, por título lo soy) a un orgulloso ingeniero de software.
Pero volvamos, yo estaba extasiado (y aun lo estoy), muestra de eso son varios artículos que escribí en la época:
- mi experiencia con scrum - clic aquí -
- Scrum el camino al menor gasto de energía - clic aquí -
- cediendo el mando al equipo - clic aquí -
- entre otros
Y en ese entonces me sentía (y siento) cual prócer de la independencia de Colombia (o suramericano) con ganas de ir oficina tras oficina, evento tras evento divulgando que hay un nuevo modo, un modo transparente, comprometido y liberador de trabajar en nuestro entorno sin soñar con irnos a trabajar a Google u otros similares, que en definitiva se podía ser feliz haciendo software sin sacrificar nuestro tiempo, nuestros amigos y nuestra familia.
Creo que si mal no estoy, iba a escribir un llamado a la lucha, tumbar los esquemas mentales, a derrocar el status quo en que nosotros los ingenieros de software nos hemos metido (ver este post: ¿Compras / vendes /licitas proyectos problemáticos de software?) y que aun lo estamos, en romper paradigmas, etc, Pero fallé, me restringí, dije.
DIOS SANTO.. EL QUE ME LEA DIRA.. "A ESTE MAN SE LE SUBIO AGILE A LA CABEZA OREMOS MUCHO POR EL...."
Lo cierto es que por fin hoy terminé de leer Por un Scrum Popular, - clic aqui - (escrito por Tobias Mayer, traducido y ampliado por Alan Cyment y con un epílogo fabuloso de Angel Medinilla) el cual tiene elementos reveladores y prácticos sobre como adoptar este esquema (SCRUM), que nos permitirá tener mejores resultados. Recomiendo ampliamente este libro (se que me faltan leer muchos), pero vibré con el y me identifico.
Los invito a cuestionar todo lo que hacen, a intentar y fallar, a identificar y crear nuevos modelos y formas de trabajo donde la creatividad y la innovación estallen llevándolos y llevándonos a fronteras inimaginables
BIENVENIDA LA REVOLUCIÓN
SALVE LA ANARQUÍA
SALVE SCRUM
jueves, octubre 30, 2014
[notas Agiles2014] Frases destacadas
Nota introductoria: con este tag [notas Agiles2014] pondré las notas y el resumen de lo que aprendí en el pasado Agiles2014 - realizado en Medellín-Colombia.
Ángel Medinilla .
Javier Garzás - @jgarzas
Faltan más...
Ángel Medinilla .
- "Nuestro trabajo no es hacer software, Nuestro trabajo es hacer la menor cantidad de software que le genere el mayor valor de negocio a nuestros clientes"
Javier Garzás - @jgarzas
- "Si no te avergüenzas de la primera versión de tu producto… lo sacaste demasiado tarde." - #Agiles2014
Faltan más...
domingo, octubre 26, 2014
[notas Agiles2014] Sobre el riesgo en proyectos ágiles
Nota introductoria: con este tag [notas Agiles2014] pondré las notas y el resumen de lo que aprendí en el pasado Agiles2014 - realizado en Medellín-Colombia.
Le pregunte a Bob Galen y a Ángel Medinilla sobre la gestión de riesgos y las respuestas fueron - palabras más palabras menos - las siguientes:
Bob Galen
Le pregunte a Bob Galen y a Ángel Medinilla sobre la gestión de riesgos y las respuestas fueron - palabras más palabras menos - las siguientes:
Bob Galen
- En ágil no hacemos gestión del riesgo, reaccionamos y nos adaptamos a los eventos, si algo cree importante el product owner sobre lo que se tenga que tener cuidado pues lo pondrá en el product backlog.
- En ágil no podemos ignorar el riesgo, es cierto reaccionamos a los eventos - inspeccionamos y nos adaptamos - , pero no podemos ponernos como en el PMI a realizar una lista de todos los riesgos, pero si algo es un riesgo y es casi un evento inminente se deberá ayudar al product owner a priorizarlo en el backlog para que se trabaje en esto. Ángel me decía que si en 7 meses es la integración con SAP no podemos esperar los 7 meses para ver como reaccionamos, debemos poner en algún momento tareas técnicas en el Product Backlog para que esta integración no nos coja de sorpresa.
Me gusta más la respuesta de Ángel.
Cada cual saque sus conclusiones
Saludos ágiles
Jorge Abad
martes, octubre 14, 2014
¿Por qué prefiero las Historias de Usuario a los Casos de Uso?
o
Los casos de uso como fuente de insatisfacción entre analistas, desarrolladores, testers y usuarios
o
Los casos de uso como fuente de insatisfacción entre analistas, desarrolladores, testers y usuarios
--
Por mucho tiempo expliqué y empleé los casos de uso con todos sus elementos:
· Precondiciones
· Postcondiciones
· Flujo básico
· Flujos alternativos
· Flujos de excepción
· los misterios de los include y extend
· Y variaciones de acuerdo al autor y la empresa
Pero lo que siempre notaba es que:
· Los diferentes autores lo explican distinto la documentación de los casos de uso
· El mismo caso de uso queda escrito de forma diferente por diferentes personas
· En muchas ocasiones no quedan bien escritos
· En muchas ocasiones no quedan bien escritos
· Y lo que es peor los clientes/usuarios NO LOS ENTIENDEN - sabiendo que fueron creados para ellos y supuestamente están en lenguaje de usuario - (he notado que los casos de uso no los entendemos muchas veces entre los mismos ingenieros de sistemas)
Luego, tiempo después, con el agilismo aprendí dos lecciones importantes:
· la comunicación escrita tiene baja efectividad (ver imagen de Alistair Cockburn)
· De la comunicación solo el 7% es transmitido en las palabras, el 38% corresponde al tono de la voz y el 55% a la comunicación no verbal (ver más aquí)
Pero el punto que quiero presentar no es que los casos de uso hacen parte de la práctica de levantamiento de especificaciones funcionales donde el usuario aparece, se levanta información y luego desaparece por un tiempo hasta que por fin regresa a validar el sistema, lo que quiero evidenciar es que los Casos de Uso llevan consigo un problema de comunicación que genera una cantidad de insatisfacciones, reprocesos y hasta de bugs, miremos como sucede:
1. Se levanta el Caso de Uso por el Analista y se identifican 5 escenarios de uso.
Especificado por el analista
| |
Flujo básico
|
FB1
|
Flujo Alterno 1
|
FA1
|
Flujo Alterno 2
|
FA2
|
Flujo Alterno 3
|
FA3
|
Flujo de Excepción
|
FEx1
|
Flujos identificados
|
5
|
Flujos adicionales
|
0
|
Flujos totales
|
5
|
2. El desarrollador es creativo e identifica 6 escenarios adicionales que funcionan perfectamente dentro de los flujos identificados. El desarrollador tiene gran satisfacción por su proactividad y es posible que hasta su gerente de proyecto lo felicite.
Escenarios
|
Especificado por el analista
|
Desarrollados e identificados por el desarrollador
|
Flujo básico
|
FB1
|
FB1
|
Flujo Alterno 1
|
FA1
|
FA1
FA1.1
|
Flujo Alterno 2
|
FA2
|
FA2
FA2.1
FA2.2
|
Flujo Alterno 3
|
FA3
|
FA3
FA3.1
|
Flujo de Excepción
|
FEx1
|
FEx1
FEx1.1
FEx1.2
|
Identificados
|
5
| |
Adicionales
|
6
| |
Flujos totales
|
5
|
11
|
3. El tester, que es alguien que es experto en encontrar escenarios de fallo, encuentra adicionales a los especificados y los 6 adicionales hallados por el desarrollador. En este punto el dialogo del tester y desarrollador es en el mejor de los casos el siguiente:
· Tester: Mira encontré 5 incidentes, me toca devolverte el caso de uso
· Desarrollador: ¿Cómo así? No los vi, identifique 6 escenarios adicionales, pero bueno pásamelo y déjame reviso, si es del caso los corrijo.
(Para ser sensatos no son incidentes, ni bugs, ese golpe no lo veía venir el desarrollador(ni el especificador, ni el gerente de proyecto) por ningún lado, pero empezó a pagar los platos rotos de cuenta de esta cadena de errores involuntarios de cuenta de la metodología de trabajo)
Escenario
|
Especificado por el analista
|
Desarrollados e identificados por el desarrollador
|
Probados y otros nuevos identificados por el analista
|
Flujo básico
|
FB1
|
FB1
|
FB1
|
Flujo Alterno 1
|
FA1
|
FA1
FA1.1-
|
FA1
FA1.1-
|
Flujo Alterno 2
|
FA2
|
FA2
FA2.1-
FA2.2-
|
FA2
FA2.1-
FA2.2-
FA2.3-
FA2.4-
|
Flujo Alterno 3
|
FA3
|
FA3
FA3.1-
|
FA3
FA3.1-
FA3.2-
FA3.3-
|
Flujo de Excepción
|
FEx1
|
FEx1
FEx1.1-
FEx1.2-
|
FEx1
FEx1.1-
FEx1.2-
FEx1.3-
|
Identificados
|
5
| ||
Adicionales identificados
|
6
|
5
| |
Flujos totales
|
5
|
11
|
16
|
Nota: por lo general el Flujo básico es el que queda mejor especificado y no tiene lugar a malas interpretaciones
4. El cliente recibe el caso de uso y al probarlo se da cuenta que el producto está muy bien construido pero encuentra que 5 escenarios no especificados “pero obvios” no fueron considerados y al revisar la documentación junto con el analista, el cliente y el gerente de proyecto del equipo del proveedor concluyen que deben ser elaborados. Estos 5 escenarios son 5 incidentes que se le suman a los 5 anteriores detectados por el tester. A este punto tanto desarrollador como tester tienen cuestionada su “reputación” tanto con el cliente como con el gerente de proyecto.
Escenario
|
Especificado por el analista
|
Desarrollados e identificados por el desarrollador
|
Probados y otros nuevos identificados por el analista
|
Cliente usuario
|
Flujo básico
|
FB1
|
FB1
|
FB1
|
FB1
|
Flujo Alterno 1
|
FA1
|
FA1
FA1.1-
|
FA1
FA1.1-
|
FA1
FA1.1-
FA1.2-
FA1.3-
|
Flujo Alterno 2
|
FA2
|
FA2
FA2.1-
FA2.2-
|
FA2
FA2.1-
FA2.2-
FA2.3-
FA2.4-
|
FA2
FA2.1-
FA2.2-
FA2.3-
FA2.4-
FA2.5-
FA2.6-
|
Flujo Alterno 3
|
FA3
|
FA3
FA3.1-
|
FA3
FA3.1-
FA3.2-
FA3.3-
|
FA3
FA3.1-
FA3.2-
FA3.3-
FA3.4 -
|
Fujo de Excepción
|
FEx1
|
FEx1
FEx1.1-
FEx1.2-
|
FEx1
FEx1.1-
FEx1.2-
FEx1.3-
|
FEx1
FEx1.1-
FEx1.2-
FEx1.3-
|
Identificados
|
5
| |||
Adicionales identificados
|
6
|
5
|
5
| |
Flujos totales
|
5
|
11
|
16
|
21
|
A este punto 5 escenarios identificados por el analista, se han convertido en 21 debido a la ambigüedad y falta de precisión de los casos de uso, generando gran insatisfacción y reprocesos en toda la cadena.
---
Aquí es donde los comparo con las historias de usuario (ver más acá - la magia de las historias de usuario-) donde estas tienen:
· Una pequeña descripción funcional
· Y unos criterios de aceptación los cuales tiene la gran ventaja de:
o Discutirse hasta el completo entendimiento (hasta la saciedad) con el cliente (recordemos CCC – Card-Conversation-Confirmation)
o Si se olvida un criterio de aceptación se realizará el próximo Sprint o iteración (que comenzara a lo sumo en un mes)
o No hay lugar a bugs por “omisión funcional” o escenarios “obvios” no identificados, por lo tanto la probabilidad de éxito de un desarrollo satisfactorio es altísima pues no hubo lugar a ambigüedades, ni olvidos no intencionales
· Si hay algo que aclarar se resolverá durante la iteración o sprint con el cliente, el cual estará disponible para resolverla.
Por esta razón es que prefiero hoy en día las historias de usuario a los casos de uso.
Queda abierto el espacio para la discusión y las experiencias.
Saludos ágiles
Jorge Abad
Suscribirse a:
Entradas (Atom)