viernes, diciembre 27, 2013

¿Plan Driven (conducido por el plan) o Value Driven (conducido por el valor)?

Que prefieres ser:

¿Un gerente de proyecto dirigido por el plan?
o
¿Un gerente de proyecto orientado al valor de negocio?







Producto/Proyecto


Dirigido por el Plan
(Plan Driven)
Dirigido por el  Valor
(Plan Driven)
Enfoque
·         Cumplir el plan a como dé lugar (cueste lo que cueste)
·         Su preocupación constante será el alcance
·         Darle el valor al Negocio, satisfaciendo las prioridades dadas por del Product Owner (Dueño del producto)
·         su preocupación no será el cronograma sino dar el mayor valor posible

Éxito
·         Su herramienta para medir el éxito será el cumplimiento del plan (aunque  lo realizado no sirva)
·         El proyecto/producto tendrá mas opciones de terminar más pronto debido a que se encuentra enfocado en las características de mayor valor valor.

Equipo
·         se encargará de realizar seguimiento a su equipo en vez de liderarlo
·         Se enfocará en empoderar al equipo para activar la comunicación y la innovación.
·         El equipo se gestionará así mismo
·         El equipo se hará completamente responsable de los compromisos adquiridos
Alcance
·         La preocupación será cumplir con lo pactado
·         El alcance es un insumo pero no es la herramienta de éxito.
Cambios
·         para cambiar el plan requerirá de un procedimiento

·         se verá de mal gusto un plan con muchos controles de cambio
·         Aunque realice un plan, podrá modificarlo cuantas veces lo necesite sin poner en riesgo su reputación

jueves, diciembre 12, 2013

Elaborando el Plan de Mejora: Obteniendo la Pila del Producto (Product Backlog) o Alcance.

Cuando las organizaciones deciden comenzar un plan de mejora con miras a cumplir alguna normatividad o alguna meta planteada, sugiero se sigan los siguientes pasos con el objeto de construir lo que se va a realizar de una manera eficiente y de alto valor:


1. Identificar la meta a cumplir (TO-BE) (DEBER SER)

Consiste en decidir que se va a cumplir, hacia que meta se está apuntando ya sea:

  • cumplir una norma, conjunto de normas y/o estándares
  • lograr algún / algunos objetivos organizacionales

Tabla 1. Aspectos de la norma o mejora.

2. Identificar el estado actual de la organización respecto al objetivo (AS-IS) (COMO ES ACTUALMENTE)

Respecto a cada aspecto a mejorar se debe identificar el valor evaluado y el cumplimiento del mismo.

Tabla 2. Estado Actual vs la  Norma o Mejora


3. Identificar el GAP (diferencia) entre la norma (o mejora) y el estado actual


Tabla 3. Análisis GAP

Nota: Pueden existir aspectos que se cumplen en los cuales no existe GAP.


4. Calificar el estado del GAP

De acuerdo al resultado del GAP, se puede calificar el estado en que se encuentra el cumplimiento del aspecto a mejorar, se sugiere una calificación con la siguiente escala:

1. no re realiza
2. se realiza con deficiencias
3. se realiza satisfactoriamente
4. se realiza  sobresalientemente


Tabla 4. Calificación del estado actual vs la Norma o Mejora


5. Determinar la calificación objetivo

Para cada aspecto se debe determinar el valor objetivo a alcanzar. Existen casos en los que las organizaciones no están satisfechas con cumplir la norma, estándar o mejora propuesta, sino que quieren ir más allá, de igual forma pueden existir aspectos en los cuales no hay interés de avanzar o mejorar debido a razones económicas, técnicas, jurídicas, ambientales, etc.



Tabla 5. Valor deseado de calificación respecto a la norma o mejora.


6. Identificar las mejoras a realizar

Determine cuales son las mejoras que va a realizar. Es probable que una mejora soporte varios aspectos.


Tabla 6. Mejoras a realizar respecto a cada aspecto de la norma o mejora


6. Califique las Mejoras

A cada mejora realícele una calificación ya sea por:

  • mayor impacto menor esfuerzo
  • menor valor
  • mayor ROI (Retorno de inversión) en el corto plazo
  • mayor ROI en el mediano plazo 
  • etc.
El ejemplo muestra una calificación de 1 a 4 para el concepto "mayor impacto - menor esfuerzo" (para esto se puede realizar un taller donde los involucrados en el proyecto de mejora califiquen cada mejora de acuerdo a parámetros establecidos)

Tabla 7. Mejoras Calificadas de acuerdo a su Mayor impacto-Menor Esfuerzo

Ordene de acuerdo a la calificación


Tabla 8. Mejora Calificada


Y de acuerdo a su criterio o al criterio de expertos priorice, recuerde que siempre existirá una mejora más importante que otra, por lo tanto no permita que queden dos o más con la misma prioridad.


Tabla 9. Mejora Priorizada





Con esta última tabla ya se tiene el Product Backlog / Pila de Producto (listado de necesidades) de lo que se desea realizar. Esta pila de producto o ítemes del proyecto de mejora se puede ejecutar empleando SCRUM -Ver guía acá- ( el cual es un marco de trabajo para ejecución de proyectos -construcción de productos- de forma iterativa e incremental en ciclos cortos para escenarios adaptativos complejos.)

Si se desea también este es el insumo para la EDT - Estructura de Desglose de Trabajo - (WBS -  work breakdown structure. ) en el esquema tradicional de gestión de proyectos en el cual la EDT es la pieza clave (es la definición del alcance) para la elaboración del cronograma.



Siguiendo la sugierencia de Lucho Salazar (bloguero de gazafatonarioit ) realizo la siguiente adición:

7. Califique las Mejoras considerando la criticidad

Adicional al criterio del punto anterior (ROI, rentabilidad o impacto, etc) se puede adicionar la columna de criticidad, pues hay unas mejoras que son más criticas que otras en un proceso de mejora. Bajo este criterio la tabla 7 quedaría de la siguiente forma:


Tabla 10. Mejora con criticidad asignada


Por lo tanto reorganizando, el listado de mejoras a realizar teniendo como primer criterio de ordenamiento la criticidad y segundo el impacto, la Pila de Producto (Product Backlog) de la mejora quedaría:

Tabla 11.  Mejora priorizada por los criterios de criticidad e impacto.

.


domingo, diciembre 01, 2013

En búsqueda de la felicidad laboral

Esto está radicalmente con el principal enunciado del  manifiesto ágil

PERSONAS E INTERACCIONES sobre procesos y herramientas [1]

y uno de sus principios


Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.[2]




Tomado de: http://www.portafolio.co/portafolio-plus/busqueda-la-felicidad-laboral

En búsqueda de la felicidad laboral

La última tendencia en el mundo empresarial consiste en aumentar la productividad, haciendo más felices a los empleados y procurando un ambiente laboral satisfactorio. Algunas compañías ya han creado un nuevo cargo: Director de la felicidad.

Cuando el trabajador está feliz y satisfecho, la empresa es más productiva y próspera. Así podría sintetizarse la idea que está llevando a algunas compañías líderes a innovar, dejando de lado los puestos de trabajo tradicionales y dando paso a cargos fuera de lo común, cuyo objetivo es generar una cultura de optimismo y cooperación dentro las corporaciones.

Entre las funciones del Director de la Felicidad (DF) se incluyen crear iniciativas de motivación, dinámicas de fortalecimiento de equipos, y actividades que subrayan y promueven los valores de la empresa, señala desde Open English, una escuela de inglés online, con sede en Miami, y presente en 23 países, que también es pionera en incorporar a su plantilla este cargo, ocupado por Alain Lagger.

Según la compañía, las actividades dirigidas por su DF incluyen, desde trabajar con los ejecutivos de la empresa, hasta sesiones grupales y personales de asesoría, pasando por mantener líneas de comunicación abiertas en toda la empresa para fomentar la felicidad y la satisfacción en el trabajo, incluso la organización de grandes dinámicas de grupo para toda la compañía.

Según Lagger, “la mayoría de las empresas tiene valores fundamentales, como ‘confianza’, ‘comunicación’ o ‘trabajo en equipo’ y el cometido del Director de la Felicidad es crear una cultura que represente esos valores, y asegurarse de que todos los que trabajan tengan la mejor experiencia de valor en esa compañía”.
Como responsable en este cargo, Alain Lagger trata de mantener una relación cercana con todos los empleados, lo cual le lleva a viajar a las sedes de Open English en Miami, Bogotá, Sao Paulo, Caracas, Buenos Aires y diversas ciudades de Europa, donde organiza actividades como meditación, conferencias y talleres artísticos.

Según este ‘coach’ y orador motivacional, “trabajar en algo ‘intangible’ como el bienestar de los empleados casi parece una utopía, pero quizás sea al revés, ya que la felicidad es tan visible como una sonrisa”.
“La gestión del DF se mide, sobre todo, a través de la satisfacción de los propios trabajadores, cuantificando el número de empleados que han abandonado la compañía y cuántas personas quieren trabajar en ella, junto con los comentarios de los clientes y de cómo estos califican la calidad del servicio”, explica Lagger.

“Sentirse realizado, tanto profesional como personalmente, se traduce en una mayor productividad, y este enfoque centrado en la felicidad del trabajador es el secreto de la estabilidad y del éxito dentro del lugar de trabajo”, explica el DF de la empresa de idiomas.


SIN CONFLICTOS
Para Lagger, la aplicación de esta filosofía empresarial repercute positivamente en la compañía, porque “una persona feliz tiene menos probabilidades de atraer conflictos y estará menos estresada; por lo tanto será más productiva”.

Para lograr este objetivo, se centra en construir una cultura positiva dentro de la corporación a través de entrenamientos, eventos motivacionales, visitas a los centros de trabajo y sesiones de ‘coaching’ personales, tanto con managers como con empleados.

“Mi equipo de la felicidad también organiza concursos mensuales y actividades semanales por equipos de trabajo. Además, mantengo relaciones personales con todos los empleados de todos los niveles y respondo diariamente a sus correos, con los que piden apoyo en una época difícil o, simplemente, quieren compartir una victoria”, indica.

Lagger también ha creado el ‘Open English Life Changers’, un entrenamiento a lo largo del cual cada nuevo empleado pasa por siete experiencias que le ayudan a conocer más profundamente la cultura empresarial y reflejan sus valores clave.


UN CASO REAL
“Una estudiante llamó para cancelar sus clases porque se había mudado fuera del país. Nuestro empleado le preguntó sobre sus razones para dejar el curso. Dos días antes este empleado había recibido un ‘training’ conmigo en el cual había aprendido cómo crear relaciones personales más profundas y usó estas técnicas recién aprendidas, que hicieron que la estudiante se abriera.
Ella explicó que se acababa de casar y que se había mudado a otro país con su marido, quien no la estaba tratando bien. Estaba triste.
El empleado pasó una hora al teléfono escuchando a la estudiante, apoyándola y compartiendo algunas de las cosas que había aprendido sobre felicidad y las elecciones en la vida.
Un mes más tarde, la estudiante llamó y nos contó que esa llamada le cambió la vida. Se había mudado otra vez a su país de origen, y estaba muy feliz y agradecida. Continuó con ‘Open English’ y, hoy en día, aún es una de nuestras estudiantes”.


MOTIVACIÓN, LA CLAVE PARA LA SATISFACCIÓN
Preguntado sobre las características que debe reunir el ambiente profesional para producir satisfacción en el empleado, Lagger señala: “Más allá de los beneficios materiales, como un buen salario, vacaciones o pagas extras, existen otras características intangibles, como un sentimiento de unión con los valores de empresa o con la responsabilidad social de la misma”.
“Es de vital importancia crear vías de comunicación, mediante las cuales los empleados puedan compartir los sentimientos de insatisfacción en su trabajo o incluso en su vida, como cuando están tristes, por ejemplo, porque han tenido una pérdida en la familia, o cuando simplemente necesitan algo de apoyo”, explica.
Según el DF, la satisfacción del trabajador “puede ser reforzada tratándolo de manera respetuosa. Es fundamental que los líderes de una organización se den cuenta de la responsabilidad que tienen, ya que sus acciones repercuten profundamente en la experiencia de los trabajadores”.

“Motivar a la gente a través del apoyo y la validación tendrá un efecto de fuerza que hará al equipo mucho más efectivo. Esto también creará una mayor confianza en los grupos de trabajo y una mayor compenetración entre sus miembros”, añade.

Comunicar la misión y los valores claves de la compañía a los empleados es otro de los pilares de la satisfacción laboral, según Lagger, ya que “es importante para la gente sentirse conectada con dichos conceptos y esto puede ayudar a generar motivación”.

“Si tus empleados creen en tu misión, valores y productos, serán mejores embajadores de la compañía, mejores comerciales y mejores proveedores de servicios”, remarca.

Comunicar claramente qué se espera del empleado y apoyar un ambiente en el que se promueva la comunicación también es positivo, ya que según Lagger, “un manager que tiene una política de puertas abiertas tendrá una mejor idea de lo que ocurre en el interior del equipo y en el campo de trabajo, y los directivos que promueven la comunicación son capaces de dirigir sus equipos de forma mucho más eficiente y efectiva”.

Para aumentar la felicidad laboral, también hay que “valorar el esfuerzo y la contribución de los empleados, ya que a todos nos gusta que nos valoren, y escuchar que hacemos algo bueno que ha contribuido al proceso de una manera valiosa. Cuando existe valoración, hay más compromiso, crecimiento y motivación”, matiza el experto.

Según el directivo, también se puede crear un ambiente de trabajo más positivo y divertido mediante elementos como la decoración, creando un área de relajación, poniendo plantas y color en las paredes, porque “un ambiente de trabajo feliz contribuye a una experiencia laboral más grata”, destaca.


GOOGLE YA LO APLICA

El DF de Open English señala que se han inspirado en Zappos -una gran tienda de ropa norteamericana-, que consiguió “crear una cultura increíble dentro de la compañía reflejada en su impresionante servicio al consumidor y el éxito de su negocio, y en Google, que tiene dedicado personal a una función similar, si bien este es un terreno bastante nuevo y buscan su propio camino para entregar el mismo mensaje: crear felicidad para el empleado y conectar el trabajo de las personas con el objetivo de crear un negocio sano y un impacto positivo en la sociedad”.

Una pequeña diatriba: ¿quién/cómo van a reponer ese tiempo?



De las cosas que más me disgustan del modelo anterior (y que aún sigue sucediendo en algunos contextos ágiles) es cuando el PMO / Gerente de Producción / un mal Gerente de Proyecto / un mal Cliente / un mal Product Owner / un mal Scrum Master le hacen la dichosa y molesta pregunta al equipo o al encargado de turno:


¿Cómo van a reponer ese tiempo?

¿Quién va a pagar ese tiempo?



Lo peor es que lo dicen señalando el cronograma, como si este tuviera la respuesta a todas las preguntas y dentro de el estuvieran embebidos todos los posibles escenarios en un proyecto de software, el cual posee elementos cantidad de elementos cambiantes e incontrolables.


y yo me pregunto

  • ¿es que acaso creen que el equipo estuvo desocupado todo este tiempo?
  • ¿es que se la pasaron silvando mal hombre -como decimos en Colombia  - ( ver video de la canción http://www.youtube.com/watch?v=hS5iEP8SUKw )?
Hombre.. claro entraron de vez en cuando a facebook, pero "la madre", esta gente estuvo trabajando fuerte por el proyecto....y el atraso no se corrige poniendo a facebook en el firewall, les aseguro que el problema no se encuentra allí.


Lo simpático es que la respuesta que ellos esperan es:


Si, vamos a trabajar más duro estas próximas X semanas para reponer esas horas, para reponer lo que perdimos, o lo que se perdió. (que para ser sinceros no fue culpa del equipo)



Y para acabar de ajustar (en ese contexto) un "buen gerente de proyecto"  es el que logra comprometer a su equipo bajo presión por largas, largar jornadas hasta lograr reponer algo que pronto se volverá a perder y es el estar al día en el cronograma (el cpi y el spi cercanos a 1)  (Sugiero ver este post Recomendaciones sobre el sobre-esfuerzo - clic aquí)

Lo cierto es que un equipo de desarrollo honesto durante un mes, dos meses o el periodo que sea se la pasa enfocado en producir el resultado que se le encomendó, y ¿si no se cumple lo prometido donde esta la falla?


  • ¿en el equipo?
  • ¿en las personas?
  • ¿en el gerente de proyecto?
  • ¿en el cliente?
  • ¿en el scrum master?
  • ¿en el product owner?
  • ¿en el coach?
  • ¿en el comercial?
  • ¿la documentación?
  • ¿los casos de uso?
  • ¿la arquitectura?
  • ¿el involucramiento del cliente?
  • ¿en el modelo de contratación?
  • ¿en la metodología?
  • ¿en la falsa concepción de que los errores de planeación debe pagarlos el equipo?

o ¿quien en sus cabales va a querer hacer mal su trabajo?

Pienso y siento que la forma de trabajo actual (proyectos a valor cerrado y ejecución en cascada y/o RUP ) es un esquema deshonesto con los equipos de desarrollo, con las empresas de software, somos trabajadores del conocimiento, que volvemos información en innovación , que queremos hacer las cosas mejor, si algún tiempo no se cumple la falla no esta en el equipo (estoy bajo el supuesto que el equipo es el equipo adecuado para el proyecto), ni es el equipo el responsable de remontar esos retrasos inalcanzables, tengan la seguridad que los más felices de ver el proyecto funcionando son los que lo están construyendo.

El esquema tradicional de contratación de software ya demostró con creces durante bastantes años que falló, aunque hay rezagos en las mentes de muchos en su transformación hacia el agilismo, debemos soltar todos las antiguas concepciones y permitir que en un marco de trabajo como Scrum, con límites definidos y la capacidad de fallar de forma temprana permitan corregir el camino, hacer de esta profesión algo atractivo y creativo, algo motivador y que no sean los de sistemas los destinados a trabajar y trabajar a cambio de frustraciones.

Yo quisiera dejar de encontrarme con amigos, colegas, alumnos, exalumnos, que trabajan sin descanso en favor de los software sin ninguna recompensa, desgastándose y perdiendo tiempo valioso con ellos mismos, sus novi@s, sus familias. Hacer software debe ser algo chévere, motivador, creativo, que den ganas de ir a trabajar los lunes, que el jefe/líder/gerente de proyecto/novato scrum master sea alguien que no considere que el éxito del proyecto esta dado por la ejecución del plan (PLAN-DRIVEN) - lo cual no garantiza el éxito de lo construido-, sino alguien orientado al valor (VALUE-DRIVEN), en liberar las funcionalidades que más beneficio traigan al negocio lo antes posible con la calidad inmersa en cada iteración.

Esta esclavitud de proyectos de software gerenciados/liderados con MS PROJECT debe de cambiar/ tiene que cambiar / tiene que acabar, tenemos una oportunidad de oro para transformar de nuevo nuestra industria local y latinoamericana y ponernos a la par de los líderes mundiales.

Ojalá el agilismo, el buen agilismo, el que tiene excelentes prácticas técnicas y metodológicas juntas, el que cumple la DEFINITION OF DONE, llegue pronto a todas las universidades, a las entidades públicas, a las gerencias de TI de las diferentes industrias y a las empresas de software y volvamos a ver entre todos una industria donde se matriculan gran cantidad de estudiantes (en Colombia actualmente las universidades sufren una escasez de matrícula de estudiantes en ingeniería de sistemas y afines, y una deserción de la misma), a una industria que mueve masas, felicidad y ¿por qué no? millones de dólares para beneficio de todos los roles involucrados en esta profesión.

Hasta acá mi reflexión y diatriba, bienvenida la discusión

Saludos ágiles

Jorge Abad.

jueves, noviembre 28, 2013

La métrica de la felicidad - Un elemento clave para Scrum

Hola a todos

Dentro de mi curso de Gerencia de proyectos informáticos el cual dicto en la Universidad Eafit - www.eafit.edu.co para el pregrado de ingeniería de sistemas, tengo la costumbre de poner a escribir a los estudiantes un artículo sobre un listado de posibles temas que les proporciono que tienen que ver con gerencia de proyectos y /o agilismo.

A continuación les comparto el artículo escrito por Miguel Baquero, el cual es una buena aproximación a una métrica que debe llevar el equipo y que debe ser revisada cada retrospectiva, LA METRICA DE LA FELICIDAD.





---
link al documento original - Clic aquí


La métrica de la felicidad.

Gestión de proyectos informáticos.
Miguel Baquero
mbaquer6@eafit.edu.co
Departamento de Ingeniería de Sistemas
Universidad Eafit

Medellín, Colombia


Gerentes y consultores piensan que la gente está harta de trabajar infeliz. La gente más joven en particular se resiste a trabajar bajo el esquema de mando y control, ambientes basados en culpa y castigo. Un cambio importante está sucediendo. Harvard Business Review dedicó todo un número a la Felicidad porque empleados felices conllevan a clientes felices y mejores negocios. Sin embargo, nunca se debe subestimar la capacidad humana de cometer errores. Puede pasar que el equipo sea muy complaciente, tenga exceso de confianza o no vea oportunidades para mejorar. El patrón “un peldaño a la vez”, recomienda enfocarse en un punto a mejorar, de manera que sea claro su impacto. Sin embargo, existen muchas oportunidades para mejorar y es necesario tener una forma de trabajar en las cosas que den los mayores beneficios.



A menudo se genera una larga lista de cosas que se supone ayudan a mejorar la velocidad. Al ser muchos ítems, es posible que se trabaje en algo que no logre mejorar la velocidad, y sí lo hace, no presenta una mejora importante. La gente comúnmente no se siente identificada con largas listas, por lo que no están suficientemente motivados para que funcionen. Es necesario trabajar en la mejora adecuada de manera que el equipo sienta pasión. La gente siente gran satisfacción al hacer bien su trabajo, además tienen un gran sentido de responsabilidad por su trabajo, particularmente si se encuentran en un equipo autónomo. Por esto, hay que encontrar qué mejora va a incrementar en la mayor medida posible la felicidad del equipo, e implementarlo para el siguiente Sprint.

Típicamente, el equipo decide cuál es el nivel actual de felicidad y cada uno de sus miembros expresa qué podría aumentar este nivel al máximo, luego como equipo, se decide cual va a ser la mejora que va a producir la mayor felicidad para todo el equipo. 

Existen varias maneras de medir la felicidad del equipo, pero se ha encontrado que una forma simple y subjetiva de un puntaje de uno a cinco es suficiente. La mejora deseada debe ser parte de la meta del Sprint, por lo que este patrón además, puede ayudar a formular esta meta.

Hay cierta vulnerabilidad en la expresión de estos deseos. Algunas personas podrían sentirse incómodas haciéndolo públicamente. En este caso, podrían expresarlo anónimamente. Sin embargo, esto no es lo ideal; es mucho mejor reforzar una “comunidad de confianza”, donde las personas se sientan bien expresando sus deseos. 

Enfocarse en la felicidad del equipo tiene una extraña habilidad de descubrir qué problemas evitan que el equipo sea más efectivo, no solo más feliz. Probablemente se deba a que las personas obtienen gran satisfacción al hacer un buen trabajo. Además, a menudo están en una posición que permite entender qué pueden hacerlos más efectivos y que cosas se interponen en su camino. Otra razón para que la Métrica de la Felicidad permita un mejor desempeño del equipo, es que la gente siente una mayor conexión personal y compromiso a mejorar.       

La Métrica de la Felicidad puede ayudar a prevenir el agotamiento. El agotamiento ocurre cuando la gente trabaja por largas horas o gastan mucha energía mental durante mucho tiempo sin descanso. El agotamiento puede destruir la productividad (“Every hour of overtime is offset by an hour of undertime” – Tom DeMarco) o también provocar la deserción de la gente a un ambiente más sano. Sí el agotamiento es una amenaza, alguien probablemente va a proponer como Métrica de la Felicidad, “detener las horas de trabajo no sanas”.       

La gente puede tener distintas percepciones de la felicidad, por lo que es importante no dejar a una sola persona encargarse de la Métrica de la Felicidad; es una decisión del equipo qué es lo mejor para ellos. Al mismo tiempo, cada persona debe ser escuchada, haciéndolos parte de la decisión final. Algunas personas (como gerentes con mucho tiempo en el oficio), temen que el equipo “engañe” este sistema, decidiendo que la felicidad puede ser mejorada tomando los viernes libres, por ejemplo. Esto podría ser posible, sin embargo, como todos los aspectos de la anatomía del equipo, se debe confiar que el equipo siga el espíritu del juego. (Si no se confía en el

equipo, esto viola el espíritu del juego, por lo que se tiene problemas más serios). Así como todas las mejoras, la Métrica de la Felicidad debe ser medible, de manera que indique que realmente se han producido mejoras.       

Un ejemplo: Un equipo usa la Métrica de la Felicidad de forma que puedan identificar y priorizar las mejoras. En una escala de 1 a 5 se les pregunta cómo se sienten con su rol en la compañía y como se sienten acerca de la compañía. Luego comparten qué los haría sentir mejor y el equipo utiliza planning poker para estimar el peso de las cosas que los miembros del equipo consideran importantes para esto. El equipo estima el valor (opuesto al esfuerzo) de los ítems del backlog. El equipo estimó 50 puntos. “Mejores historias de usuario” fue la mejora más importante que consideró el equipo. Remover este impedimento tuvo más de 60 puntos. El product owner se preguntó si remover este impedimento podría doblar la velocidad al obtener un mayor puntaje que todo el product backlog para el Sprint. “Mejores historias de usuario” se agregó al Product Backlog para el siguiente Sprint y una nueva Definición de Done. Esta Definición de Done fue implementada como criterios de aceptación que tenía métricas que fueron calculadas en el siguiente Spring review. Estas incluyeron:      
  1. Cuantas historias de usuario estuvieron en el Sprint que no alcanzaron el criterio INVEST (immediately actionable, negotiable, valuable, estimable, sized to fit, and testable) este debe ser 0.
  2. ¿Cuántas veces los desarrolladores tuvieron que acudir al product owner para clarificar una historia durante el sprint?
  3. ¿Cuántas veces las dependencias forzaron una historia a estar en estado de espera durante un Sprint? 
  4. ¿Cuántas historias tuvieron una eficiencia de más del 50% en el proceso? 
  5. ¿Cuántas historias no fueron claras para los desarrolladores? Medir por el número de miembros que se quejaron de la historia 
  6. ¿Cuántas historias implicaron mayor implementación técnica que la aclaración de la experiencia de usuario deseada?
  7. ¿De cuántas historias de usuario los desarrolladores entendieron la relación entre una historia, el tópico que produjo la historia y las necesidades del negocio que la generaron? Medida por el número de miembros del equipo que tienen quejas que no entienden qué estaban haciendo durante la historia.   
Los resultados: Mientras que la mejora a la calidad de las historias de usuario nunca termina, el sprint review mostró la mejora significativa en este ítem del Backlog medido por los criterios de aceptación. Mejoras significativas resultaron en un incremento de la velocidad después de varios sprints. Después de doblar la velocidad, el impedimento cayó del encabezado de la lista y fue reemplazado por otro impedimento. Un equipo feliz es un equipo mucho más productivo.         

Referencias:
Sutherland, Jeff. SCRUM LOG JEFF SUTHERLAND. 2012 . En: http://scrum.jeffsutherland.com/2010/1 1/happiness-metric-wave-of- future.html (consultado en noviembre de 2013).
Harrison Neil B, Sutherland Jeff. PROCESS IMPROVEMENT. 2013. En: https://sites.google.com/a/scrumplop.o rg/published-patterns/retrospective- pattern-language/happiness-metric (consultado en noviembre de 2013).
Schwartz, Tony. Happiness is overrated. 2010. En: http://blogs.hbr.org/2010/10/happiness -is-overrated/ (consultado en noviembre de 2013).


------------
link al documento original - Clic aquí

martes, noviembre 26, 2013

Pruebas automáticas de código sin framework

Estas pruebas, dan cobertura al funcional al código.





Un excelente aporte de  Julian Vargas @app_config 
Sirve para TDD y ATDD
___

Scrum: Hoja del Sprint y los Riesgos


Una de las características de scrum y de las metodologías ágiles es la importancia que se le da a la visualización de información o radiadores de información, esto no implica que no haya seguimiento y elementos digitales pero se le da prelación a lo visual (preferiblemente papel) esto logra:
  • compromiso del equipo 
  • información instantánea (no se requiere ingresar a url para saber algo)
  • el equipo sabe el status del compromiso en el Sprint y en el Release de manera constante.
  • se visualiza la deuda técnica
  • se observan los bugs y problemas que han habido durante la construcción del producto
  • se visualiza la velocidad a través de los sprints.

Una de los elementos radiar es la "Hoja del Sprint" o "Página de Información del Sprint" la cual cuenta con los campos:
  • Nombre del equipo
  • Nombre del producto
  • Número del Sprint
  • Objetivo del Sprint
  • Pila del Sprint (debe estar en orden, arriba las historias mas prioritarias con su respectivo puntaje)
  • Velocidad estimada
  • Calendario (fecha y lugar de la diferentes reuniones)
    • Daily
    • Refinamiento
    • Review
    • Retrospectiva
  • Equipo (cada miembro con su dedicación)
    • Product Owner (PO)
    • Scrum Master (SM)
    • Cada miembro del team developer 




Un campo adicional que he observado que sirve a todo el equipo de Scrum (PO, SM y Team Developer) para poner atención a los elementos que pueden hacer fracasar el sprint, es el de RIESGOS.

La idea es poner este campo con los posibles riesgos priorizados que afectan al sprint y las historias que estan siendo afectadas por este riesgo en caso que aplique, por ejemplo:

  • Riesgos
    • No se llegue a un acuerdo sobre los campos (afecta historia: Depósito)
    • La migración no sea "transparente" (afecta historia:  Herramienta migración)
Aunque una cosa es cierta, el SM y todo el equipo deben procurar que al sprint no se entren historias con riesgos que hagan "caer" el sprint y los puntos comprometidos (por lo general se usa un SPIKE, que es una historia con TIMEBOX y salidas definidas que permiten resolver los riesgos durante un sprint anterior, ejemplo: "realizar pruebas de concepto de la migracion",valor asignado 2 puntos). Si inevitablemente se debe entrar al sprint con riesgos, la visualización de los mismos hace parte de una buena gestión de impedimentos en cabeza SM y de todo el equipo Scrum.

De todos modos, no se debe perder la oportunidad de la retrospectiva para aprender si fue efectiva o no la gestión de riesgos y los resultados obtenidos por permitir su ingreso al sprint.




Saludos ágiles

Jorge Abad









_

lunes, noviembre 25, 2013

Personalización del Manifiesto y Principios Ágiles para la Ejecución de Proyectos.

Hace unos días hablé sobre el Framework de Scrum a una empresa que trabaja planes y proyectos de prevención en salud, el objetivo primordial es aumentar la efectividad en la realización de estos.

Dentro de los temas que facilité, fue una adaptación del Manifiesto Ágil [1] y de los Doce Principios Ágiles para el Desarrollo de Software [1] al contexto de dicha empresa. En esta actividad invitaba a los participantes a reflexionar,  pintar y dramatizar como estos elementos les harían mejor su trabajo. Bueno el resultado fue excelente, las personas siempre reaccionan como: "¡CLARO, OBVIO, ESO ERA, ESTO ES LO QUE YO NECESITABA!",


A continuación mi adaptación:



MANIFIESTO PARA EJECUCIÓN EFECTIVA DE PLANES Y PROYECTOS
Estamos descubriendo formas mejores de ejecutar planes y programas tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas
Entregar Resultados sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.






PRINCIPIOS PARA PARA LA EJECUCIÓN EFECTIVA DE PLANES Y PROYECTOS
1.       Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de resultados con valor.
2.       Aceptamos que los requisitos cambien, incluso en etapas tardías de la ejecución del proyecto. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
3.       Entregamos resultados frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
4.       Los responsables de negocio (y de  la visión del proyecto) y el equipo ejecutor trabajamos juntos de forma cotidiana durante todo el proyecto.
5.       Los proyectos se desarrollan en torno a individuos  motivados. Hay que darles el entorno y el apoyo que  necesitan, y confiarles la ejecución del trabajo.
6.       El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
7.       Los resultados entregados frecuentemente son la medida principal de progreso.
8.       Los procesos Ágiles promueven el desarrollo sostenible. Todos los participantes en el proyecto (líderes y ejecutores) debemos ser capaces de mantener un ritmo constante de forma indefinida.
9.       La atención continua a la excelencia técnica y a la correcta ejecución mejora la Agilidad.
10.   La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
11.   Las mejores soluciones emergen de equipos auto-organizados.
12.   A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

---
Realizaré seguimiento a los resultados de la aplicación del framework y pronto estaré elaborando un paper sobre este asunto.

Saludos ágiles:
Jorge Abad.






Nota:
[1]Todo es una adaptación de El Manifiesto Ágil (http://agilemanifesto.org/iso/es/) y Los Principios Ágiles para el Desarrollo de Software (http://agilemanifesto.org/iso/es/principles.html) 



_

martes, noviembre 19, 2013

Cómo luce (se ve) una historia de usuario - un pequeño ejemplo

Cuando se explican las historias de usuario, las personas no creen que son tan simples de escribir y creen que hay quedan cabos sueltos. La verdad es que si son simples (es solo cumplir el criterio INVEST [2] ) y no quedan cabos sueltos debido a dos elementos:
  • Criterios de Aceptación
  • Conversación


Las historias de usuario tienen dentro de sus objetivos:
  • sincronizar las espectativas del PO (Product Owner) con el Equipo respecto a una funcionalidad
  • servir como elemento que dirigirá construcción del software
A continuación quiero compartir un ejemplo de como luce (o se vé) una historia de usuario:

Nota : todo lo referente al ejemplo de la historia de usuario, lo registraré en color azul.


TEMPLATE
Yo como  <usuario>
necesito / deseo / quiero  <funcionalidad>
para <beneficio de negocio>



USANDO EL TEMPLATE PARA UN SISTEMA DE PRESTAMOS CREDITICIOS

 SOLICITUD DE INFORMACIÓN LABORAL DEL CLIENTE
(Nota : El título no sobra, algunas veces también se le adiciona codificación a la historia)


Yo como  CLIENTE DEL BANCO
Deseo INGRESAR MI INFORMACIÓN LABORAL ACTUAL
Para QUE EL BANCO DETERMINE SI ME PUEDE PRESTAR O NO


Criterios de aceptación 
(se pueden manejar dos opciones)


Criterios de Aceptación
 en Prosa
Criterios de Aceptación
en Formato BDD

GIVEN – DADO
WHEN – CUANDO
THEN – ENTONCES

(La verdad, prefiero este formato, ayuda a que no queden cabos sueltos)
Que pida lo datos de la empresa
Escenario 1: Solicitar Datos de la empresa

DADO que me encuentro en la página de cliente
Y se haya registrado al cliente como empleado
CUANDO se soliciten los datos de la empresa
ENTONCES se pedirá el nombre de la empresa.


Que pida el nit (identificador único nacional para las empresas) y lo valide
Escenario 2: Solicitud de Nit

DADO que me encuentro en la página de cliente
Y se haya registrado al cliente como empleado
CUANDO solicite la información de nit
ENTONCES se verificará el número del nit que su estructura sea correcta.

Que pida salario actual
Escenario 3: Solicitud de Salario

DADO que me encuentro en la página de cliente
Y se haya registrado al cliente como empleado
CUANDO me encuentre ingresando el salario
ENTONCES verifique que el valor sea entero y positivo
Y menor a $100.000.000
Que pida fecha de ingreso a la empresa
Escenario 4: Solicitud de fecha de ingreso

DADO que me encuentro en la página de cliente
Y se haya registrado al cliente como empleado
CUANDO me encuentre ingresando la fecha de ingreso a la empresa
ENTONCES la fecha sea superior a 50 años antes a partir de hoy
Y la fecha sea inferior a hoy
Que pida tres comprobantes de pago
Escenario 5:  Solicitud de 3

DADO que me encuentro en la página de cliente
Y se haya registrado al cliente como empleado
CUANDO me encuentre ingresando los comprobantes de pago
ENTONCES solicite tres comprobantes de pago en formato imagen.




---------

Conversación
 (la conversación son aclaraciones realizadas por el PO durante el refinamiento o el planning, y muchas de esas aclaraciones son solicitadas por los miembros del equipo al entender las historias de usuario y comprender el negocio)
  • Los datos de la empresa son nombre, teléfono y dirección
  • Que la validación del nit sea contra el web service de la Direccion de Impuestos (DIAN)
  • El minimo valor de salario actual debe ser el salario minimo, el que debe ser leído de la tabla de parámetros
  • La fecha de ingreso a la empresa debe ser superior a 6 meses
  • Los comprobantes de pago deben ser en formato jpg, gif y máximo de 2 megas cada uno.
(Como fruto de una conversación puede resultar que se actualicen los criterios de aceptación o solo que se deje el registro aclaratorio.


-----
Durante el sprint no se cambiarán los criterios de aceptación y en caso de que se observen mas criterios de aceptación, estos harán parte de otra historia de usuario que se construirá en otro sprint)



Donde seguir

Ver más acerca de las historias de usuario en:





Importante:

La historia de usuario debe ser de un tamaño tal que a lo sumo tome 3 días una persona construirla, probarla  (quedando con cero errores) y desplegarla en el ambiente de pruebas (o el ambiente indicado), de majera que el equipo de trabajo pueda decir tranquilamente y sin ningún temor "¡ESTA LISTA PARA PRODUCCIÓN!"



Referencias:

[1] WHAT’S IN A STORY?  http://dannorth.net/whats-in-a-story/
[2] Características de una buena historia de usuario - http://lecciones-aprendidas.blogspot.com/2013/07/caracteristicas-de-una-buena-historia.html

-------- Ver más ejemplos