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:

  • 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)

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:

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

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:
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 .

  • "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

  • 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

--


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
·         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

martes, octubre 07, 2014

Listado de Desperdicios - Sobre Lean Software Development

Recordando los principios del Lean Software Development

  1. Eliminar desperdicios
  2. Amplificar el aprendizaje, cree conocimiento
  3. Decidir lo más tarde posible
  4. Entrega lo más rápido posible
  5. Capacitar, potenciar, al equipo. Empodere, energize al equipo y crea en el.
  6. Construir con integridad y incluya la calidad
  7. Ver el todo, la meta. No pierda de vista la meta y trabaje en alcanzarla.
  8. Enfóquese en el cliente
  9. Siga mejorando, (lo mejorado o aprendido puede cambiar y se puede mejorar)
El primero es "eliminar el desperdicio", revisando un post de Javier Garzas ( La velocidad de un equipo depende del rozamiento y del desperdicio ) , extraje esta lista de desperdicios típicos:

  • documentos que nadie leerá jamás, 
  • las especificaciones de cosas que nadie jamás implementará,
  • las especificaciones de casos de prueba que nunca nadie ejecutará,
  • las reuniones eternas sobre temas en los que nunca nadie se pondrá a trabajar, 
  • las funcionalidades programadas en una aplicación que ningún usuario utilizará, etc.
Unos que se me ocurren a mí:
  • documentar escenarios de uso que nadie usará
  • realizar diagramas de UML innecesarios y no mantenibles
  • reuniones desenfocadas, sin timebox

¿Cuales más se nos ocurren?¿pueden ayudarme a aumentar la lista? ¿que crees que hace perder tiempo y genera desperdicio en tu equipo de trabajo?



Saludos ágiles

Jorge Abad

sábado, octubre 04, 2014

¿Compras / vendes /licitas proyectos problemáticos de software? – Un pequeño deja vu

Usted o su empresa siendo el CLIENTE:
  • ¿Formula proyectos que sabe de antemano que NO se van a ejecutar en el tiempo que tiene pactado?
  • ¿Se busca quien haga su proyecto a pesar de tener expectativas irreales en cuanto tiempo y costo?
  • ¿Argumenta que si hay un proveedor que es capaz de postularse es porque la solución es posible?
  • ¿tiene reuniones afanosas donde todos se miran, sonríen, estrechan manos  diciendo que sí vamos a ser  capaces, vamos a poner todas las condiciones para que sea así?

Usted o su empresa siendo el PROVEEDOR:
  • Le jura a su cliente que va a cumplir aunque no tiene ni las personas, ni la expertise para hacerlo
  • Su gerente  general le dice a usted como gerente de proyecto:  tienes que hacer ese proyecto con las personas que tiene, pues el "no voy a contratar mas gente / - o mal llamados recursos -  "
  • Se mienten entre sí en el posible equipo ejecutor diciendo:” tranquilo yo sé que ustedes lo van a lograr, ustedes son muy buenos” aunque no falta el pesimista que dice – “hombre esta es la misma historia de siempre, vamos a caer en lo mismo”, lo ignoran y siguen adelante…
  • Se diseñan estrategias super-apretadas para cumplir algo irrealizable (el Project, el Gantt y el Power Point pueden con todo)
  • Estima proyectos grandísimos sin la participación del equipo ejecutará.

A ustedes dos (cliente y proveedor) ya lo saben:

El proyecto será:

  • un fracaso
  • o un eterno desgaste  muy difícil de cerrar
  • Reuniones y reuniones
  • Actas firmadas
  • Revisión de documentación
  • Y hasta invitación a revisión de los abogados


Alguien pagará los platos rotos
  • Lo más seguro es que sea el proveedor 
    • Estos platos los pagan los trasnochos del equipo de trabajo, de esta forma se pagará la “mala planeación” que si somos sensatos fue la mala venta o presentación a un proyecto problemático.
    • Y pasará a engrosar la lista de proyectos problemáticos que harán que nuestro valor hora de venta hacia el mercado aumente.
    • Su reputación estará nuevamente en juego.
  • En muy pocos casos los pagará el cliente, pero si es así, con seguridad le costará su puesto, o su reputación9
Se verán abocados (cliente y proveedor - gerente del lado del cliente y gerente del proyecto) a realizar reuniones continuas y constantes de re-planeación de proyecto donde se pasarán horas reformulando el proyecto, creando nuevos cronogramas  (donde el tiempo lo sacarán del tiempo de descanso correspondiente  a los desarrolladores) y firmando con sangre nuevas fechas (a ratos no sé de dónde sacan tanta sangre cierto tipo de empresas) y lo peor al no cumplirlas usted (ya sea cliente o proveedor) perderá credibilidad y la palabra dada ya no servirá.

 En esta circunstancia es probable que su Jefe o Gerente (los CEO, o plumas blancas como le decimos en mi país) tengan que ir a reuniones a repactar todo nuevamente.(y lo peor es probable que las reputación y palabra de ambos también se desgaste en este tipo de círculos viciosos)


Si usted es el cliente:
  • Su jefe le estará preguntando por qué eligió ese proveedor y tendrá constantes reuniones de seguimiento y de estrés con él.
  • Usted pensará de nada me sirvió haberme desgastado en la elección o haber confiado en la empresa “x” o en mi amigo “y” que trabajaba en esa empresa.

Si usted es el proveedor
  • El comercial dirá: “yo solo cumplí con vender el proyecto, acá lo aceptaron, nadie dijo NO, ni nadie me detuvo, además yo logrando otro estoy en otro proyecto si quieren me invitan a una reunión a ver que hacemos”. (la caricatura que sigue es.. inspiradora.)

(pero bien..sigamos con el tema)
  • Al gerente de proyecto le dirán
    • mire como planea mejor ese proyecto, para que salga adelante
    •  otras veces le dirán: Nos va tocar hacer ESO aunque no esté en el alcance para calmar al cliente (léase ESO como una nueva fuente de problemas pues va a estar muy seguramente mal especificado y como siempre este tipo de regalos salen caros).
    • El gerente hablará con los desarrolladores y todo su equipo.
      • "Muchachos tenemos que trabajar fuerte, el proyecto es un lío, ustedes saben que yo no lo vendí, pero estamos acá para sacar las cosas adelante. Vamos a trabajar duro, les daremos pizzas y pollo para que trabajen de noche y fines de semana. Yo sé que lo vamos a lograr, yo confío en ustedes, y si lo logramos voy a buscar como logro una bonificación de la gerencia general."
----
Y a todas estas, todos dicen en su interior… este es el mismo deja vu de siempre, repetimos y repetimos los mismos errores, acá en esta organización no aprendemos. De nada nos sirve tener procesos definidos y/o rigurosos como CMMi, certificados o no, todo es el mismo desgaste (por no querer decir todo es la misma m…).

Muchas veces el desarrollador o el gerente de proyecto  se va para otra empresa y allá vuelve y encuentra la misma historia.

---


La verdad no entiendo la industria de software, ni los clientes, ni los proveedores, no acogen muchas veces Procesos Ágiles que son transparentes porque les da miedo, pero ¿acaso todo este recurrente deja vú no es peor que una película de terror que se repite y reinventa con nuevos y/o los mismos protagonistas?

Esto es cómo jugar a la ruleta rusa entre 4 personas y con 5 balas en el tambor.

No entiendo ¿por qué los Clientes (aclaro "los malos Clientes") no quieren pagar el costo de un buen proyecto?, y  ¿por qué los que son/somos proveedores no aprendemos a decir que NO?

Hasta acá esta pequeña diatriba y desahogo... hasta la próxima.


----

¿Quieres jugar un juego?


Hagamos un proyecto a la forma tradicional con una metodología robusta, mirarás el RFP (la convocatoria, la licitación) y sabes que no lo lograrás, si no lo haces saldrás del mercado, pero si lo haces cortaré la libertad de tu equipo de trabajo y trabajarán horas y horas, perderás tiempo y dinero sin lograr el alcance, ni cerrar el proyecto. Tienes 3 días para presentar la propuesta… tic tac.. tic tac

miércoles, octubre 01, 2014

Tres frases

Dos que leí por ahí



Procesos no implica capacidad / habilidad / maestría

Documentación no implica entendimiento


y una muy cierta, dada por la experiencia



Agilidad no implica éxito
(también se puede fallar en ágil, pero tiene más probabilidad de éxito que el esquema tradicional)



__