miércoles, julio 15, 2015

Diferencia entre Gerente de Proyecto, Scrum Master y Product Owner

Hola a todos

Hace días tenía pendiente construir esta tabla en la que  se observa la diferencia de responsabilidades entre un:

  • Gerente de Proyecto -  GP -
  • Scrum Master -  SM -  (Maestro de Scrum*) y
  • Product Owner - PO - (Dueño de Producto)


ROLES SCRUM
Áreas de Conocimiento de la Gerencia de Proyectos del PMBOK 5
Gerente de Proyecto
Scrum Master / Maestro de Scrum*
Product Owner / Dueño de Producto
Equipo de Desarrollo
Integración del Proyecto
Se cumple



Alcance
Se cumple

 -Priorización del Backlog
 -Especificacion de funcionalidades
 -Rápido ROI** de las funcionalides

Tiempo
Se cumple

 - Tiene un Plan de liberación del producto que garantice el ROI

Costo
Se cumple



Calidad
Se cumple
Aseguramiento de calidad (garantiza que se realice principalmente Scrum y procesos organizacionales)

Control de Calidad sobre el producto
Recursos Humanos
Se cumple
Coach del Equipo y del Product Owner

Equipo Auto Gestionado
Comunicaciones
Se cumple



Riesgos
Se cumple
Hace gestión de impedimentos que algunas veces consiste en prevenir riesgos y/o futuros problemas que se observan para el proyecto/producto.

La mayoría de las veces es más reactivo que proactivo.


Adquisiciones
Se cumple



Interesados
Se cumple

Relacionamiento con los interesados del proyecto que poseen requisitos del proyecto

Por lo tanto,
  • No se cumplen las siguientes igualdades o transiciones
    • Gerente de Proyecto = Scrum Master  
    • Gerente de Proyecto = Product Owner
  • Si un GP quiere hacer la transición a SM deberá suprimir varios aspectos de su normal disciplina (8 en total) y soltar el comando-control y comenzar a creer en la auto-organización y en el Product Owner. Las preocupaciones de un SM son radicalmente otras.
  • Una persona con los roles de Product Owner y Scrum Master*** al tiempo es casi un gerente de proyecto, tiene demasiado poder y le quita uno de los aspectos claves de Scrum, que consiste sana tensión entre el PO y el SM.
  • Es requerido un GP o alguien que se encargue de:
    • Contrataciones
    • Otros interesados
    • Costos
    • Riesgos
    • Comunicaciones
    • etc


Notas y Aclaraciones
* Maestro de Scrum: Me da la sensación que nos suena más claro y contundente en español (muchas veces usamos palabras en inglés y no las cargamos de su significado)
** ROI : Retorno de la Inversión.
*** Una de las recomendaciones para hacer Scrum




Saludos Ágiles y hasta la próxima

Jorge Abad



Cuatro Recomendaciones Claves para hacer Scrum

Hola a todos

Siempre en mis entrenamientos de Scrum doy las siguientes 4 recomendaciones* para implantar y hacer scrum:

  1. No combinar roles
  2. No acortar, ni alargar los Sprints
  3. No suprimir reuniones/ceremonias de Scrum
  4. Retrospectivas, retrospectivas, retrospectivas, retrospectivas
* Lo leí por ahí en un tweet hace muchos años pero no he podido reencontrarlo.


Saludos Ágiles

Jorge Abad. 

domingo, julio 05, 2015

Leído y Recomendado: Diseño colaborativo: un proceso en dos etapas

Este post de Diego Fontdevila

Sobre del diseño colaborativo del software, en donde existe un momento divergente donde el equipo explora opciones y luego otro convergente donde elige la que le parece adecuada

https://diegofontdevila.wordpress.com/2015/07/01/diseno-colaborativo-un-proceso-en-dos-etapas/

Saludos ágiles
Jorge Abad

Video: Frases e imágenes para programadores

Les comparto este excelente video Cualquier parecido con la coincidencia es pura realidad ...

 

y bueno mucho de estas imágenes serían borradas si hicieramos bien las cosas...

Leído y Recomendado: Como NO hacer retrospectivas #DETROSPECTIVA

Hola a todos

les comparto este paso a paso de lo que NO debe ser una retrospectiva

se llama DETROSPECTIVA por parte de Thomas Wallet


---------------------

tomado de: http://www.elproximopaso.net/2015/07/detrospectiva.html


Detrospectiva



Es mi deber compartir esta dinámica deretrospectiva llamadaDetrospectiva.

Recopile en esta dinámica varias practicas que pude observar o que me comentaron y que me impactaron fuertemente. 





  • Nombre: Detrospectiva
  • Participantes: cuando más numeroso el grupo mejor. Funciona mejor con equipos muy distribuidos. 
  • Duración: agendar o planificar 1 hora y ejecutarla en 3 horas. Puede ser útil hacer la reunión en varias veces. Un buen horario para empezar la reunión es el viernes a las 17h.
  • Alcance: al finalizar una iteración corta (lo ideal es cada semana)
  • Propósito: generar una minuta para los niveles jerárquicos superiores
  • Facilitador: es clave su participación, y es particularmente útil que sea hábil en acortar las intervenciones de los participantes para poder expresar claramente su punto de vista superador.
  • Objetivos: Esta dinámica permite formatear y dirigir el espacio de retrospectiva para evitar intercambios, debates y construcción de mejora en grupo, sin impedir la formalización de una buena minuta para los niveles jerárquicos
  • Material y Preparación: tener abierto en la maquina del facilitador el email-minuta de la retrospectiva anterior. Se usará como base para la minuta de la retrospectiva.

    • Pasos
    1. En este dinámica no es necesario explicar el objetivo, es auto-explicativa si se siguen bien los pasos.
    2. El facilitador lee en voz alta las acciones de mejora de las minutas de todas las retrospectivas anteriores, comenta y registra en que estado está cada acción a su criterio (Pendiente, En Curso, Realizada).
    3. El facilitador pregunta a cada participante de a uno:
      • ¿Qué hicimos bien en la ultima iteración?
      • ¿Qué hiciste mal en la ultima iteración?
      • ¿Qué acción de mejora se te ocurre?
      • El facilitador registra las respuestas a estas 3 preguntas que les parezcan pertinentes en forma resumida.
    4. El facilitador pregunta si alguien tiene algo más para aportar, y si le gusta lo que digan lo puede sumar en la minuta.


    • Variantes
      • Se puede saltear la parte de ¿Qué hicimos bien? del paso 3, o eventualmente copiar y pegar esta parte de la minuta anterior si no hay tiempo.
      • En lugar de escuchar a los participantes de a uno, se puede acelerar la dinámica pidiendo que manden previamente sus aportes por email al facilitador. En tal caso, el facilitador podrá filtrar los puntos que le guste y leerlos el mismo en la reunión. 
      • En el caso mencionado de mandar los aportes por email, puede ser útil que sean aportes anónimos (usar una casilla de email creada para la ocasión). Sirve cuando los participantes no se animan a hablar y/o cuando quieren identificar culpables sin que se sepa de donde viene la denuncia. 
    • Tips
      • Empezar muy puntual con los participantes que ya llegaron. Los participantes atrasados se perderán escucharlos, pero lo importante es que quedé registrado en la minuta, no que todos escuchen a todos. 
      • Está bueno empezar el paso 3 con la persona más tímida del grupo, así pierde la timidez y anima a los otros a hablar (peor que esta persona tímida no les puede salir).
      • Sobre las acciones de mejora: cuando más ambiguas mejor. Nunca ponerle fecha ni responsable, lo cual podría provocar que se hagan. Acuerdense que el objetivo de esta dinámica es la minuta, no la mejora. 
      • No aporta mucho que los participantes vean lo que está escribiendo el facilitador en el email-minuta. Se suelen distraer leyendo y a veces podrían no estar de acuerdo con el facilitador. .
      • Es importante registrar el autor de cada respuesta en el paso 3, así quedan bien claro los culpables y los motiva a mejorar.
      • Lo más efectivo es que se documenten los resultados en el email-minuta. Si se puede imprimir en el momento para que todos lo firmen, se gana mucho tiempo y se puede mandar directamente al o a los Gerente(s) correspondientes (cuando más numerosos son mejor). 
    • OrigenCualquier similitud con la realidad es pura coincidencia. 


    Les pido por favor ayudar al mundo a erradicar lo antes posible las detrospectivas. Por favor compartir este post a todos sus contactos y en particular a los que facilitan (o participan) retrospectivas parecidas. 

    Un mundo de retrospectivas mejores es posible, depende de cada uno...

    #DetropectivasNuncaMás

    Multitasking : No somos capaces de hacer dos cosas BIEN a la vez

    Hola a todos

    Les comparto tres artículos y un ejercicio en el que se demuestra que el multitasking es la forma más ineficiente de hacer las cosas.

    Realmente en agilismo  no nos preocupamos por hacer muchas cosas, nos preocupamos por hacer una sola cosa bien hecha y a la vez, es mucho más eficiente.

    Espero los disfruten, apliquen y difundan.

    Saludos ágiles

    Jorge Abad

    --------
    Artículo 1: Es imposible hacer bien más de dos tareas a la vez
    Neurocientíficos coinciden en que la llamada 'multitarea' compromete la eficiencia y la creatividad.

    Tomado de: http://www.eltiempo.com/estilo-de-vida/salud/es-imposible-hacer-bien-mas-de-dos-tareas-a-la-vez/16045023?ts=93


    El ser humano no puede hacer multitasking (tareas múltiples). A esa conclusión llegó Earl Miller, neurocientífico del Departamento del Cerebro y de las Ciencias Cognitivas del MIT, reconocido por su trabajo en procesos como la concentración y la memoria.
    Aunque el cerebro pueda almacenar información de toda una vida y una gran cantidad de conocimiento, por alguna razón solo puede expresar uno o dos pensamientos conscientes al tiempo”, dice desde Boston.

    La masificación de internet, los smartphones y las tabletas, y la tendencia a comunicarse por WhatsApp y a estar pendientes de las redes sociales han llevado a los científicos a investigar cómo esta sobrecarga de información afecta el cerebro. Y lo que han descubierto es que, desde el punto de vista biológico, es poco lo que se puede hacer. El cerebro humano tiene capacidades limitadas y el sistema de vida actual lo pone a prueba. “Tenemos un dilema: la sociedad espera que hagamos multitasking, pero no somos buenos en eso”, resume.
    Cerebro más lento
    Antes de que la neurociencia conociera el auge que tiene hoy, los psicólogos ya se habían interesado en los efectos de la era de la información sobre la mente. Uno de ellos es el doctor Glenn Wilson, quien acuñó el término ‘infomanía’. A petición de Porter-Novelli, la agencia de publicidad de Hewlett Packard (HP), en el 2005 este exprofesor del Gresham College, de Londres, supervisó un experimento para medir los efectos negativos de estar permanentemente conectados.
    El estudio, restringido a ocho empleados de HP sometidos a distintos tests –primero en un ambiente tranquilo y luego en uno interferido por el sonido de teléfonos y la llegada de e-mails–, llamó la atención porque indicó que “las distracciones tecnológicas” de las que habla Wilson hacían bajar el coeficiente intelectual de 143,38 puntos en situación de calma a 132,75 en un ambiente “ruidoso”.
    Cinco años más tarde, un equipo del Instituto Nacional de Salud e Investigación Médica (Inserm), en París, realizó, bajo el liderazgo de Etienne Koechline, un trabajo con base en resonancias magnéticas que explicaba por qué el cerebro solo puede dedicarse a dos tareas a la vez.
    La hipótesis establecida por estos científicos es que al dedicarse a dos tareas mentalmente costosas, nuestro cerebro se divide:automáticamente, el lado izquierdo del córtex prefrontal (que gobierna las funciones ejecutivas) se dedica a una tarea, mientras el lado derecho se ocupa de la otra.
    “Uno puede cocinar y hablar por teléfono al mismo tiempo. El problema surge al tratar de hacer tres cosas a la vez: el córtex prefrontal siempre desecha una”, le comentó Etienne Koechline a Science. Otros estudios –entre ellos uno de Russ Poldrack en la U. de Stanford– confirmaron la incapacidad del ser humano de ser eficiente en más de dos tareas a la vez, y revelaron que cuando se hace multitasking la información nueva no va al hipocampo, donde habitualmente se almacena, sino al lugar equivocado del cerebro. Otra investigación de la misma universidad mostró, además, que la gente regularmente bombardeada con información electrónica no puede prestar atención, recordar información y terminar una tarea para empezar otra de la manera en que logran hacerlo quienes se concentran en una cosa a la vez. En breve, son menos eficientes.
    Cuando la gente cree que está haciendo multitasking, lo que hace en realidad es pasar permanentemente de una tarea a la otra”, lo que le quita tiempo al proceso de pensar, sentencia Earl Miller. En consecuencia, “el cerebro se ralentiza y comete errores, los pensamientos son más superficiales y uno se pone menos creativo”, concluye. Eso es lo que él llama los “costos del cambio” (switch costs).
    La trampa
    Si los efectos del multitasking sobre la capacidad de pensar ya son preocupantes, los expertos le suman otro problema: el cerebro tiene la capacidad de hacernos trampa. Miller habla de la “ceguera inatenta”, que hace que cuando creemos estar conscientes de lo que estamos haciendo, en realidad no lo estamos.
    Cuando cambiamos de una tarea a otra, le prestamos atención a una de ellas y no a la otra, aunque creamos que estamos concentrados en todas. Por ejemplo, siempre veo a gente manejando con manos libres y creen que eso resuelve el problema, pero no es así. Cuando uno está concentrado en una conversación por teléfono, no se está concentrando en el camino. Pero el cerebro da la ilusión de que sí lo está”, afirma.
    Miller explica que existe un “ancho de banda” limitado, el “pensamiento consciente”, y que el cerebro en modo multitasking no logra incorporar todo en ese ancho de banda. Entonces construye una ilusión, tomando “pedazos de información” cada cierto tiempo y juntándolos para darnos la impresión de una información completa.
    Nadie puede ser entrenado para el multitasking. De hecho, estudios señalan que quienes creen ser buenos en este campo resultan ser los menos eficientes en la realización de múltiples tareas a la vez. Una investigación que da cuenta de eso es la de la Universidad de Sussex, que reveló que los multitaskers tienen una menor densidad de materia gris en el córtex del cíngulo anterior (CCA).
    “El rol más importante de esta región cerebral es lidiar con el conflicto. Por ejemplo, cuando hay distintas maneras de responder a un estímulo (como leer la palabra “rojo” escrita en verde), el CCA especifica qué información debe ser procesada e instruye a otras partes del cerebro para que eliminen la distracción. Por tanto, es una región involucrada en el esfuerzo consciente de enfocarnos en lo importante”, explica desde Inglaterra el investigador Ryota Kanai. Por eso, añade, los multitaskers tienen menos capacidad de resolver tareas más complejas y de jerarquizar la información.
    La pregunta que surge es por qué, si nos vuelve más lentos en el plano cognitivo y –de manera general– menos eficientes, seguimos haciendo multitasking. “Es porque el cerebro encuentra gratificante la información, pues está diseñado para buscar conocimiento”, contesta Miller.
    El problema, agrega, es que evolucionamos en un ambiente más simple, cuando no existían todos estos smartphones, tabletas y computadores. “Hemos creado una sociedad con la que nuestro cerebro ya no puede lidiar de manera eficiente. Hay demasiada información”, insiste.
    Y no podemos evitarlo. “Como la información es gratificante para el cerebro, todos somos, en cierta medida, adictos al multitasking –advierte Miller–. Yo soy consciente de cuán malos somos trabajando en varias cosas al tiempo, pero si mi celular está cerca o hay una ventana abierta con internet en mi computador, voy a entrar a la web. Por eso, cuando quiero concentrarme dejo mi teléfono fuera de alcance o de mi vista, y solo una ventana de pantalla abierta, sin internet. Hay que ser disciplinado”.
    Somos adictos a la desconcentración
    Daniel Levitin, autor de ‘The Organized Mind, Thinking Straight in the Age of Information Overload’, profesor de psicología en la Universidad McGill (Canadá) y consultor de la serie de TV ‘El mentalista’, ha analizado el proceso químico que genera “adicción” a la ‘multitarea’. En enero, escribió en ‘The Guardian’: “El ‘multitasking’ crea un círculo de adicción a la dopamina, premiando al cerebro por perder el foco y por estar buscando estimulación externa.
    Para empeorar las cosas, el córtex prefrontal tiene un sesgo hacia lo novedoso (...). La ironía para los que tratan de concentrarse es que la misma región cerebral de la que dependemos para mantenernos enfocados es la que se distrae fácilmente”.
    DANIELA MOHOR W.
    El Mercurio (Chile)
    ----------------
    Artículo 2: Multi-tasking makes you stupid: Give it up before you get brain damage!




    Tomado de: http://scrum.jeffsutherland.com/2010/12/multi-tasking-makes-you-stupid-give-it.html


    We know multitasking causes project delays but it is even worse than we thought. Psychology Today reports on new research that shows it builds up a stress response that damages cells in your brain.
    The Difficulties of Multi-tasking
    Doing too much makes you slower and dumber.
    By Colin Allen, published on March 01, 2003 - last reviewed on December 20, 2010

    Multi-tasking, the mental act of juggling, may not actually be the best way to save time or get things done well. A new body of research has found that multi-tasking makes people less efficient and reduces the level of brainpower used for each task. Also, people who overburden their minds with too many tasks at once can have problems with short-term memory. One study, in the Journal of Experimental Psychology, found that the mind slows down when it switches back and forth between tasks. The only way to turn off this mental friction is to put more time, even just a few seconds, between tasks. A second study, in the journal NeuroImage, also notes that the mind does not cope well with multitasking. It asked participants to listen to sentences while comparing two rotating objects. Even though these tasks use different parts of the brain, visual input dropped 29 percent and listening success fell 53 percent.

    For people doing too many things at once, additional worry can build up into a stress response. This adrenalin rush can damage the cells that form new memories. It can also weaken attentiveness and alertness. So what can people to get their act together? Focus on fewer tasks.

    Trad: La multitarea , el acto mental de malabares, en realidad no puede ser la mejor manera de ahorrar tiempo o hacer las cosas bien hechas . Un nuevo cuerpo de investigación ha encontrado que la multitarea hace que la gente menos eficiente y reduce el nivel de la capacidad intelectual utilizada para cada tarea. Además , las personas que sobrecargan sus mentes con demasiadas tareas a la vez puede tener problemas con la memoria a corto plazo . Un estudio, en la revista Journal of Experimental Psicología, encontró que la mente se ralentiza cuando se avanza y retrocede entre tareas. La única forma de desactivar esta fricción mental es poner más tiempo, incluso unos pocos segundos , entre las tareas . Un segundo estudio , en la revista NeuroImage , también toma nota de que la mente no lidiar bien con la multitarea. Se pidió a los participantes a escuchar frases al comparar dos objetos en rotación . A pesar de que estas tareas utilizan diferentes partes del cerebro , entrada visual se redujo 29 por ciento y el éxito de escuchar cayó 53 por ciento .

    Para las personas que hacen demasiadas cosas a la vez , preocupación adicional se puede acumular en una respuesta de estrés . Esta descarga de adrenalina puede dañar las células que forman nuevos recuerdos. También puede debilitar la atención y el estado de alerta . Entonces, ¿qué puede la gente a conseguir su desempeño ? Centrarse en un menor número de tareas.


    ----------------
    Artículo 3: Trabajar en más de un proyecto a la vez genera perdidas de tiempo y disminuye la productividad


    Tomado de: http://www.javiergarzas.com/2013/11/trabajar-en-mas-de-un-proyecto-la-vez-genera-perdidas-de-tiempo-y-disminuye-la-productividad.html

    Un libro con datos bastante interesantes sobre gestión de proyectos y el comportamiento humano es el de Gerald Weinberg, el  Quality Software Management, Volume 1: Systems Thinking, famoso, principalmente, por un estudio que exponía el desperdicio de tiempo que conllevaba tener a las personas en más de un proyecto.
    Concretamente, Weinberg lo sintetizaba en esta tabla:
    Número de proyectos simultaneos% de tiempo disponible para el proyectoPerdida debida al cambio de contexto
    1100%0%
    240%20%
    320%40%
    410%60%
    55%75%

    Según el calculo de Weinberg, añadir un solo proyecto más, adicional a aquel en que estamos trabajando, genera perdidas de un 20% del tiempo. Agregar un tercer proyecto, crea perdidas de casi la mitad del tiempo.
    Estas perdidas de tiempo vienen del cambio de tareas, de “trasladar los pensamientos” de un proyecto a otro distinto. El efecto que se produce es muy similar a las interrupciones, aquello que ya comentamos de queinterrumpir a quien programa, o al que realiza cualquier actividad intelectual, hace que su productividad caiga (mas de lo que imaginas).



    ----
    Un Juego: Escribir 10 nombres


    Tomado de: Lo aprendí de Verónica Vera @verovera78

    1. Escribe 10 nombres, todos al mismo tiempo - o sea que siempre escribes una letra de un nombre distinto -. Mide cuánto tardas por nombre y suma el total.
    2. Luego escribe 10 nombres, uno cada vez. Mide de nuevo.
    3. Asómbrate del costo de la multitarea..









    martes, junio 30, 2015

    Video: Siete principios de diseño ágil con objetos - Hernán Wilkilson



    Excelente charla, con grandes planteamientos de Hernán Wilkinson (@HernanWilkilson) de 10 pines dictada para @agilescolombia.

    Va de lo básico, pasando por lo  reflexivo y terminando en lo avanzado, sin perder el hilo y de una forma magistral.

    Diría que es de estudio obligatorio para cualquier desarollador y equipo de software.


    Los siete principios son:
    1. Favorecer el uso de objetos inmutables
    2. Crear Objetos Completos
    3. Los objetos tienen que ser válidos
    4. No usar setters
    5. usar modificaciones atómicas
    6. no usar NULL
    7. Usar metáforas

    Saludos ágiles

    Jorge Abad

    miércoles, junio 03, 2015

    Meetup: Impact Mapping/ Impact Map / Mapa de Impacto y ejemplo para Soluciones de Software

    Hola a todos:

    El pasado 2 de Junio en la comunidad Ágiles Colombia realizamos un meetup de Impact Mapping (ver links - convocatoria - fotos - )

    El Impact Mapping es una excelente herramienta ideada por Gojko Adzic (@gojkoadzic) para garantizar que lo que construimos se encuentra alineado con las necesidades u objetivos del negocio.

    Esta herramienta se basa en responder en un mapa mental.


    • Por qué -  Why -  ( Objetivo )
    • Quienes - Who -  (Quienes serán afectados con el objetivo)
    • Cómo - How - (Impacto que afectará a los "quienes" del punto anterior, mi sugerencia en este caso es comenzar a redactar los impactos utilizando el verbos  gerundio  o verbos en infinitivo, de forma que queden en acciones y no en resultados - de esta forma se evita que se confunda con el punto posterior)
    • Qué -  What - (qué ENTREGABLES se construirán para generar esos impactos)


    Ver poster a continuación en el cual se resume la técnica:





    Cómo resultado se obtuvieron 5 excelentes mapas que comparto a continuación.

    • Evitar el sacrificio de animales domésticos (clic aquí)
    • Optimizar el tiempo de entrega de medicamentos (clic aquí)
    • Reducir el tiempo de atención el las EPS (empresas prestadoras de servicios de salud) en un 50% (clic aquí)
    • Aumentar la recolección de cartera (clic aquí)
    • Reduccir accidentalidad en Medellín (clic aquí)



    Dentro de las conclusiones de la sesión se tuvo:

    • Respecto a la forma de priorizar los entregables, se puede hacer una calificación identificando
      1. Los más críticos
      2. Los de bajo costo y alto impacto
      3. Los que más personas impacten
    • Respecto a los beneficios de la técnica se tienen:
      1. Salida del pensamiento puramente técnico de TI
      2. Se desarrollan soluciones que tienen un objetivo tangible
      3. Permite visualizar con claridad qué se va a hacer y por qué
      4. Permite entender el problema y las diferentes soluciones propuestas
      5. Es un excelente ejercicio para lograr el consenso de los interesados
      6. Permite visualizar el ecosistema de las soluciones.

    Dentro de los pendientes que me quedaron:

    1. Plublicar los Mapas (¡Hecho !- acá tuve ayuda de los fotógrafos-)
    2. Publicar el link hacia una presentación donde se vincula el Impact Mapping con el User Story Map (-http://es.slideshare.net/chassa/2014-0618srdimpact-mapsstorymapsen - clic aquí) - (¡Hecho!)
    3. Publicar un Mapa de impacto completamente orientado a software.Ver mapa a continuación. (¡Hecho!)






    En este mapa se evidencia la posibilidad de escribir historias épicas y por ende ir construyendo el Product Backlog a partir del Mapa de Impacto, usando el formato:

        Yo como QUIEN
        Deseo un QUE
        para un IMPACTO / COMO


    Ejemplos:
        Yo como PACIENTE
        Deseo conocer  el LISTADO DE MÉDICOS Y CITAS DISPONIBLES
        Para ACCEDER A UNA CITA DE FORMA RÁPIDA

        Yo como PACIENTE
        Deseo conocer  el CANCELACIÓN DE MI CITA VIA SMS
        Para LIBERAR MI CITA PARA OTROS


    ---

    Gracias a la comunidad por asistir y por permitirme aprender más. Definitivamente la mejor forma de aprender es enseñando y practicando.

    Gracias a los compañeros que co-facilitaron la sesión:
    - Lucho Salazar (@luchosalazarc) - (el ministro)
    - Leonardo Agudelo (@sweepnoise) - (el magnánimo)
    - Guillermo Trujillo - (el patrón)
    - Robinson Rico Mendez (@rimerz77) - (el coste)


    Saludos ágiles
    Jorge Abad

    domingo, mayo 31, 2015

    Calculando el Costo y Tiempo Estimado de un Proyecto Ágil Usando un User Story Map

    Hola a todos

    Una pregunta constante en las capacitaciones y cuando un equipo comienza a trabajar con metodologías ágiles es:

    ¿Cómo determino el costo de mi proyecto ágil?

    Pues bien, una de las formas es utilizando mapas de historias de usuario (user story maps) y luego asignar valores a las historias épicas encontradas

    A continuación les comparto la hoja de cálculo y los tips para usarla.

    ---
    Para hacer uso de esta hoja de cálculo debes saber que es un User Story Map, te recomiendo estos links


    Luego de elaborar tu User Story Map, debes tallar las historias épicas con tallas de camiseta  y tu propia tabla de equivalencia de tallas (a continuación te comparto una posible)


    S es el pivote o punto de comparación
    M Equivale a 2 "s"
    L Equivale a 5 "s"
    XL Equivale a 10 "s"
    XXL Equivale a 20 "s"
    XXXL Equivale a 40 "s"




    Este tallaje es de acuerdo a la percepción de tamaño que les de el equipo de desarrollo a las historias épicas y buscando que las que son de similar talla queden con misma asignación, por ejemplo así


    Paso seguido determinar la cantidad de  "S" por cada release, de acuerdo a la tabla anterior.

    Por lo tanto, luego de determinar que en Release "0" tienes  10 historias épicas talla "S" y 3
    historias épicas talla " L", equivale a 25 "s"y así hacer con el resto de releases.


    ---
    De la hoja de cálculo recordar que todo lo que esta en Amarillo puede ser modificado.
                       
    De igual forma, un estimado no es algo preciso, y por ejemplo afirmar "UNA ESTIMACIÓN EXACTA"es un completo contra-sentido (u oxímoron).

    _
    Esta hoja de Calculo te ayudará a saber el costo y duración de tu proyecto ágil de forma aproximada.

    No olvides leer el los derechos de autor y si tienes mejoras, pues publícalas y compártelas



    Saludos ágiles
    Jorge Abad

    domingo, mayo 24, 2015

    Como Jugando Fútbol - Un Símil con Scrum



    Hola a todos

    Muchas veces cuando comienzo a hablar del marco de Scrum, recuerdo uno de los símiles que escuché en el Ágiles 2014 (sino estoy mal se lo escuche a Pablo Tortorella - @Pablitux), y era que Scrum se parece a jugar fútbol (similar a como Ken Schwaber dice que es como jugar ajedrez [1]).

    Se tienen:

    • unas reglas a seguir
    • una cancha
    • un arco
    • un árbitro y unos auxiliares
    • la forma en que se hacen goles y las faltas, 
    • dos equipos
    Y dentro de ese marco los equipos juegan, ganan, pierden, se divierten y quien no siga esas reglas - obvio -  no estará jugando fútbol.



    Pero la parte en que noto más similitud es en que:

    • se tienen estrategias
    • hay equipo
    • hay un entrenador que motiva y orienta al equipo, 
    • los equipos se adaptan según el transcurrir del partido y el comportamiento del otro equipo.
    • y de igual forma los jugadores interactuan con un objetivo común,  y ese objetivo común logra que se regañen entre ellos, se reprendan, se griten de cancha a cancha pasándose la pelota, se hagan señas y hasta cometan faltas.
    Hay pasión, hay sufrimiento, hay coraje y compromiso cada minuto del partido...


    Iniciando a Jugar y el Modelo de Tuckman
    Observo también, que cuando un equipo inicia a jugar fútbol por primera vez los jugadores no saben mucho del estilo del otro, de sus habilidades y falencias, pero a medida que juegan partidos juntos aumenta la confianza, el lenguaje, la amistad y aparecen estrategias de juego que son útiles para ganar, aun para decidir si necesitan hacer cambios al interior o no.

    Similar ocurre cuando un equipo Scrum se comienza a desarrollar, en los primeros sprints no saben quién es quién, quien tiene mejores habilidades, y ni como lograr mejor el backlog comprometido, pero a medida que pasan y pasan los sprints, en los equipos scrum comienza a aparecer la comunicación, el objetivo común, la meta que une, el esfuerzo grupal, el "gritarse" cuando al otro el pasaste el balón y estaba mirando para otro lado - léase, "llamarse la atención mutuamente entre team members  durante el sprint y/o la retrospectiva  por que el otro no estaba  conectado con el Sprint o no colaboró adecuadamente"- . y aquello que no era evidente en la gestión tradicional (dónde cada cual es responsable de su porción de Diagrama de Gantt) y hasta ella misma lo aplastaba si le veía muy revolucionario,  permite Scrum que aparezca: EL EQUIPO AUTOGESTIONADO - El Santo Grial del Agilismo -  responsable de lo que se compromete, un equipo que tiene coraje de superar sus propio estado incial, buscando dar siempre lo mejor de sí, logrando mayor y mejor desempeño en todos sus planos: productivo, técnico y de equipo. 


    Nota: les recomiendo leer este excelente post de Martin Alaimo - @MartinAlaimo sobre el modelo de Tuckman  - http://www.martinalaimo.com/es/blog/equipos-estables -  que enlaza perfectamente con lo expresado acá


    Bueno esta fue mi corta reflexión de hoy

    Hasta la próxima

    Saludos ágiles

    Jorge Abad


    Referencias
    [1] <<The word “framework” means that much is not specified and must be devised by those using the framework. I equate Scrum to the game of chess. You can read the official rulebook for chess. The moves, players, sequences, scoring, etc. are all specified. Learn them. Then you can play chess. Maybe your chess game isn’t so good, but you can study great games, strategies, and tactics, and practice to get better and better. However, you are playing the game of chess, so you don’t have the option of changing the rule book. If you change the rules, it’s not chess any longer. Just learn how to play the game with excellence, which is enough of a challenge.>> https://kenschwaber.wordpress.com/2010/09/08/scrum-as-a-framework/ 

    martes, mayo 12, 2015

    Para los fanáticos de los formatos / plantillas / templates de gerencia de proyectos

    Hola a todos

    Les comparto esta lista de tres links donde encontrarán templates  por montones:



    Saludos ágiles

    Jorge Abad

    miércoles, abril 22, 2015

    ¿Y por qué dudamos de la auto-organización de los equipos?

    Hola a todos

    Hay algo que he notado que es recurrente cuando he dictado entrenamientos o charlas sobre Scrum y es en específico el rol del TEAM /DEVELOPER TEAM / EQUIPO DE DESARROLLO / EL EQUIPO, la primera pregunta que surge por alguno de los presentes es:

    ¿y cómo logran que se vuelvan auto-organizados?

    Es como si dudáramos de nuestra capacidad de

    • jugar en equipo
    • jugar fútbol, baloncesto, rugby, voleibol
    • armar un paseo
    • realizar un asado
    • preparar entre varios una cena
    • jugar un juego de mesa
    • entre otros.


    Pero para ser franco, yo siento esa pregunta hecha desde el temor, desde la desconfianza, desde un lugar de la memoria o experiencia  donde a alguien (incluso el mism@ que lanzó la pregunta) que le encomendaron algo no lo entregó a tiempo y para acabar de ajustar todos se dieron cuenta que despilfarro el tiempo en otras cosas sin importancia que no le aportaban al objetivo.

    Yo comprendo esos temores - he estado allí - , y es por eso que tal vez:

    • nos aferramos al comando-control, 
    • asignamos tareas
    • asignamos filas de Gantt (hechas en ms project) a diestra y siniestra
    • ponemos "recursos" (que en realidad son personas, y trabajadores del conocimiento), 
    • les imponemos un tiempo calculado por un experto (que no fueron ellos)
    • hacemos micro-seguimiento, o micro-gestión cada ciertas hroas
    • y si se demoran más les decimos que deben pagar o/y mirar como reponer el tiempo.
    La verdad tiene sentido, nos han fallado, hemos fallado y nos dominan los temores, y esos temores nos llevan al lado oscuro [1] - como diría Yoda - (al de comando-control - ver más)


    Pero Scrum tiene herramientas que enganchan, empoderan y comprometen al equipo:

    • un objetivo de construir cosas listas (Done) a corto plazo.
    • Un planning que establece compromisos
    • El review que verifica si se logró el compromiso o se quedó en deuda  -(ver más en :  La cara del santo hace el milagro. Efectividad del Planning y Review - )
    • la retrospectiva que con su inspección y adaptación nos lleva hacia nuevos retos, y nos saca de zonas cómodas.
    • y el Scrum Master, que es el agente de cambio que esta cuestionando, ayudando a que el Equipo Scrum ( Product Owner, Team Members, y Scrum Master) salga de su zona de confort

    Yo veo Scrum, como un buen juego de equipo, como el fútbol que establece:

    • Cancha, roles, y arbitro //unas cuantas reglas claras ( 3 roles, 4 reuniones, 3 artefactos,  ver más),
    • personas que se divierten jugando // un equipo que se trabaja motivado
    • una táctica para ganar // un tablero kanban y un burndown que muestran lo que tenemos que hacer en un ciclo corto de tiempo y si podemos o no lograr la meta.
    • el deseo de meter gol //un objetivo común y claro "generar el mayor valor en el cliente con la menor cantidad de software posible, en el periodo más corto de tiempo"

    Observo en los equipos de desarrollo y en especial de scrum la capacidad innata a auto-organizarse. y dudar de eso, es dudar del niño interior que llevamos dentro, de nuestra capacidad de inventar de poco a poco, de ir mirando como dentro de las reglas establecidas todos nos vamos adaptando, de como podemos jugar mejor sin romper las reglas y meter la mayor cantidad de goles/puntos/aciertos/historias de usuario posibles en un periodo de tiempo.

    Es dudar de nuestra voluntad de querer hacer un muy buen el trabajo, de querer dar resultado en equipo, es dudar de la capacidad humana y tribal de relacionarse, trabajar juntos y de querer avanzar en conjunto.

    Y si alguien no quiere jugar bien

    Creo que todos en diferentes circunstancias cuando alguien no juega correctamente en equipo

    • en el partido de futbol/baloncesto/voleibol el equipo llama la atención del que no está conectado
    • en el asado si alguien solo esta allí para ser servido y no colabora "ni siqueira" a recoger, le llaman la atención o no lo siguen invitando
    • la tía regañona que daña el paseo o la cena juntos deja de ser invitada.

    Los equipos al verse empoderados, cuestionan a los miembros que no ayudan en el objetivo común, y poco a poco los equipos van encontrando su forma, número, miembros,  modo, identidad y estilo; y es trabajo del scrum master lanzar las preguntas para que el equipo se conecte, reflexione, inspeccione, adapte y avance.

    Cerrando

    A mi modo de ver dudar de la auto-organización es dudar de nuestra naturaleza humana.

    Cierro con esta frase :"La auto-organización no es una opción en Scrum; es un principio básico. Sin ella  nunca tendremos equipos de alta performance [2]




    ¿Ustedes que piensan? Queda abierta la discusión

    Saludos Ágiles

    Jorge Abad


    ----------
    Otra lectura recomendada de este blog: Cualquiera puede ser ágil / Cualquier equipo puede ser ágil


    --

    [1] "El miedo es el camino al Lado Oscuro.
    El miedo lleva a la ira.
    La ira lleva al odio.
    El odio lleva al sufrimiento.
    El sufrimiento al Lado Oscuro.
    Cuidado con el miedo, joven padawan." - Maestro Yoda

    [2] Hundermark, Peter (traducido por Cyment, Alan) . Un mejor Scrum  -  http://www.scrumsense.com/wp-content/uploads/2012/03/Un-mejor-Scrum-2.pdf