domingo, 14 de diciembre de 2014

¿Dónde encaja el testing en proyectos de TI con Scrum?

Testing OK
Recordemos que los incrementos solo están finalizados si los desarrollos están acabados, probados y documentados y eso implica que sea el propio equipo el que realice el testing y el control de calidad. En el equipo puede haber perfectamente un rol de tester, y de no haberlo, recordemos que se trata de equipos multidisciplinares y que en su conjunto, y si han sido formados, pueden tener perfectamente las habilidades y la independencia de un tester.

Scrum no es un modelo que ha surgido de arriba a abajo: de la teoría a la práctica, sino al revés: ha tomado forma y cuajado desde las prácticas empleadas por algunos equipos como antítesis a los modelos de procesos. Esto tiene sus ventajas y sus inconvenientes: no es un modelo diseñado para cubrir todas las áreas al estilo de una ISO 12207 o un modelo de procesos tipo CMMI o ISO 15504. Por esta razón, no hay un procedimiento (ni debería haberlo) para prescribir cómo hacer testing (dentro del área de SQA). Si existen una serie de patrones de testing que son más o menos cercanos a la agilidad, mi más ferviente recomendación es la integración continua y las pruebas automatizadas.

Si a pesar de ello se requiriese de un procedimiento de calidad institucionalizado, el que resultaría válido para proyectos con niveles de integridad bajo correspondería al control de calidad considerado de independencia mínima (estándar IEEE 1012). Para proyectos con niveles de integridad elevado puede (debería) resultar aconsejable emplear modelos de mayor independencia. A quien interese puede encontrar un desarrollo en ese sentido en el artículo Scrum y aseguramiento de calidad.

martes, 9 de diciembre de 2014

¿Se puede aplicar Scrum en un proyecto con un equipo de 2/3 personas?

Realmente lo que me preguntaba el jefe de proyecto, uno de mis alumnos, era si Scrum es aplicable a pymes con un equipos de 2/3 personas y muchos proyectos pequeños.

Reunión diaria de un equipo de dos
En un equipo pequeño la dinámica de grupos es muy leve, ya que esta se da generalmente en equipos a partir de 3 personas, por tanto hay menos interacción entre personas distintas y menos probabilidad de que surjan buenas ideas o golpes de inspiración. Por otro lado un equipo pequeño tiene sus riesgos, ya que tiene un bus factor muy bajo, si un miembro enferma o se va del equipo, este se ve seriamente afectado, lo que impacta fuertemente en las fechas de entrega o en la calidad por la pérdida de conocimiento.

Pero como todo en agilidad, depende de lo adaptado que esté la empresa a Scrum. Si el equipo de 2/3 personas tiene todos los roles y habilidades necesarias, por tanto es multidisciplinar en la medida justa para sacar adelante el incremento del sprint, entonces perfecto, la empresa es ágil y aplica Scrum en su medida.

En un equipo pequeño la interacción con el cliente/usuario suele ser muy fuerte, el nivel de comunicación y cercanía que tienen proyectos pequeños hace que en cuanto aparezca un problema no se tarde más de unas horas en sacar la solución a producción, lo mismo ocurre con cualquier cambio pequeño.

Por otro lado el entorno suele dejar vía libre para que el equipo se pueda autoorganizar y saque el trabajo a buen ritmo. La parte de negocio marca la dirección a seguir y a la vez da mucha capacidad de decisión al equipo, y como todo suele funcionar bien, nadie empuja para tener resultados para ayer... lo que ocurre es que el propio equipo termina empujando de vez en cuando para tener las cosas cuanto antes.

También suelen ser equipos que no tienen kilos de "papel" acumulados ni procedimientos megalíticos a seguir, se basan en el conocimiento de las personas, hacen la documentación justa y sus procedimientos emergen de ellos mismos.

Uno de mis jefes me decía que antes de aplicar Scrum, ya lo hacíamos, hacíamos la reunión diaria cuando los jefes de proyecto nos sentábamos diariamente con el equipo para hablar de la situación de proyecto y decidíamos en equipo que haría cada uno. Aunque no es lo mismo, ejercíamos "Scrum" y no lo sabíamos. Pienso que las pymes al ser pequeñas, y habiendo rodado sus equipos, pueden acabar aplicando "agilidad" de forma intuitiva y emergente.

domingo, 7 de diciembre de 2014

¿Cuál es la unidad de tiempo empleada en Scrum técnico para calcular la velocidad del equipo?

Fórmula de la velocidad en Scrum
La velocidad del equipo es la magnitud determinada por la media de la cantidad de trabajo o esfuerzo completada (terminada y entregada) en un periodo de tiempo, y en Scrum técnico es la media de la cantidad de trabajo realizada por el equipo en los sprints.

La fórmula de la velocidad es la que vemos en la imagen de la derecha, la unidad de trabajo en el dividendo y la unidad de tiempo en el divisor.

En equipos maduros, que ya hayan transicionado a Scrum avanzado, puede darse el caso de que se realicen sprints de diferentes duraciones o con un número de miembros variable en el equipo. En ese caso, para poder tener una medida independiente, se puede expresar la velocidad refiriéndose a la media por persona, por ejemplo: "La velocidad media de una persona del equipo es de 5 puntos por día".

jueves, 4 de diciembre de 2014

¿Cómo han de ser las personas que integran los equipos de trabajo?

Una de los motivos que en un primer momento crea confusión, es cuando les digo a mis alumnos que el equipo ha de ser multifuncional, cada persona ha de estar abierta a hacer de todo. Ocurre que suelen asociar esa afirmación a que todos hacen de todo y que no son necesarios los especialistas, y luego viene la inevitable pregunta ¿cómo puede funcionar sin especialistas?

Representación de las dos características
Hay dos características en las personas que están más o menos desarrolladas según cada persona. Tim Brown introdujo en 2009 el concepto de "t-shaped person", persona tipo T, en que utilizando la letra "T" se representan dos características de la persona. La vertical representa la profundidad del expertise y habilidades en un campo concreto y trabajado (programador java, DBA Oracle, arquitecto funcional...), y en la horizontal el interés que tiene la persona por lo que le rodea y la disposición a colaborar en otras disciplinas.

Las personas de tipo T tienen ambas características, son especialistas en su campo y tienen una alta empatía que les ayuda a ver y a imaginar problemas desde otras perspectivas y así poder contribuir con su opinión en áreas en las que a priori no son expertos, y tienden a ser personas muy entusiastas y curiosas que se interesan por los campos de los demás y sienten el impulso de aprender y colaborar. Este es el tipo de persona ideal para formar cualquier tipo de equipo, sea ágil o no.

Normalmente las empresas tienen personas con diferentes profundidades en las dos características. Cuando un equipo formado por personas que en su mayoría tienen básicamente habilidades verticales, personas tipo "I", se suelen producir dificultades en la colaboración. Cada uno solo aporta el punto de vista que deriva de su especialidad y las reuniones se convierten en negociaciones en las que se busca más ser "ganador" que una solución al tema planteado. Scrum, y la agilidad en general, promueven la conversión a personas tipo "T", pero deben estar abiertas al cambio cultural que implica. Si tienes un equipo lleno de personas tipo "T" ya no necesitas supervisores, facilitadores y controladores, todo el mundo hace esas funciones en alguna medida, colaboran por ellos mismos allí donde más aportan.


Aqui os dejo una comparativa entre tipos "I" y "T":
Tipo "I" versus "T"
Cortesía
Clipartbest
Mencionar que también existen personas tipo "π" (Pi), personas con profundidad en dos especialidades, una primaria y otra secundaria. Las mayoría de personas tenemos la habilidad de manejarnos con dos especialidades, a veces un cambio profesional puede convertirnos en personas tipo "π", especialistas secundarios en nuestro pasado como de un buen jefe de proyecto, y especialistas primarios en la profesión actual como de un buen Scrum Master.

lunes, 24 de noviembre de 2014

¿Cuál es el mejor soporte para escribir las historias de usuario?

Como en todo lo referente a agilidad el mejor formato es el que se adecua al equipo/proyecto/empresa. Si el equipo es distribuido, el formato ha de ser digital, igual que el tablero kanban. Pero en este post hablamos de equipos locales con pizarras kanban físicas.

El formato ha de ser el que le resulte más cómodo y útil al Propietario del Producto para la organización y gestión de su pila de producto. Algunos Propietarios de Producto gestionan su pila digitalmente, con un excel, por ejemplo. Otros tienen su propio tablero kanban con su propio flujo de trabajo y por tanto tienen sus historias de usuario escritas en post-its o tarjetas.

Utilizar post-its es muy ágil, pero cuando los campos de las historias de usuario que tratamos siempre, o casi siempre, son los mismos, vale la pena utilizar tarjetas preimpresas, ya que nos ahorramos de escribir los nombres de los campos y aumenta la sensación de orden (Algunos escribimos como los médicos y así al menos se sabe de qué trata lo que hemos escrito :-P).

Googleando me encontré una empresa americana, Braintrust, que ha diseñado sus propias tarjetas, muy bien diseñadas, con los campos recomendables y que adicionalmente dan un look profesional. Están preparadas para que se escriba la historia con el patrón "Como [rol del usuario], quiero [objetivo], para poder [beneficio]" y la aplicación del método de aseguramiento de calidad INVEST.

Aquí os dejo una imagen de las tarjetas, a mi me encantan...

Tarjetas para historias de usuario de Braintrust

viernes, 21 de noviembre de 2014

¿Cuál es la diferencia entre valor, prioridad y orden en la pila de producto?

Uno de mis alumnos, un jefe de proyecto PMP, participó en el curso de forma muy proactiva y llegados a la pila de producto no entendía la diferencia entre prioridad y orden, y le dimos bastantes vueltas al tema...

El campo prioridad es uno de los que se consideran necesarios en las historias de usuario y se podría definir como un sistema de priorización que nos permite determinar el orden en el que las historias de usuario deben de ser implementadas.

El campo valor, normalmente numérico, representa el valor de negocio que la historia de usuario aporta al cliente o usuario. El objetivo del equipo es maximizar el valor y la satisfacción percibida por el cliente en cada sprint. Este campo servirá junto con la estimación del esfuerzo, que mide una mezcla de tamaño y complejidad técnica de la historia, para determinar la prioridad con el que las historias deben de ser implementadas. 


Una forma para el Propietario del Producto de guiarse y determinar la prioridad es a través del ROI, la división del valor por el esfuerzo. Además en base al ROI obtenido podrá preguntarse si vale la pena construir una historia de usuario, o si hay varias opciones podrá decidir la mejor opción teniendo en cuenta la perspectiva económica.

El orden representa la urgencia de una historia, deriva de la prioridad que fuerza al Propietario del Producto o cliente a refinar el entendimiento de la pila de producto: solo puede haber una sola historia siguiente más importante. Resaltar que si mostramos las historias de usuario en formato de lista, la columna orden resulta claramente necesaria para cuando valor y esfuerzo de diferentes historias resultan en el mismo valor de prioridad.

Relación entre valor, prioridad y orden
Comentario en off: tengo de la absoluta convicción de que cualquier lista, desplegable, listado, select... deben de estar ordenados, por el criterio que sea, pero siempre estar ordenados.

viernes, 14 de noviembre de 2014

¿Qué significa eso de "cambio cultural"?

Los valores de Scrum
El cambio cultural en la transformación hacía la agilidad son los cambios de mentalidad que se deben de producir en la forma de pensar y de hacer de aquellos, que habiendo trabajado en grupos de trabajo, en que cada miembro solamente se responsabiliza de su parcela de trabajo, no hayan experimentado el verdadero trabajo en equipo. El cambio consiste adquirir los valores de Scrum, valores que tienen relación con los pilares Lean de trabajo en equipo y mejora continua. Son valores que crean equipos ganadores, valores de los que depende el equipo y a la vez se crean en el día a día de:
  • Foco: Poniendo el foco en unas pocas cosas a la vez, conseguimos entregar antes, trabajamos mejor juntos y obtenemos resultados de mayor calidad.
  • Coraje: Formando equipo, sintiendo el apoyo de este, aceptamos nuevos retos confiando en que podremos alcanzar el resultado deseado.
  • Franqueza: Expresamos con sinceridad cómo lo estamos haciendo, y manifestamos nuestras preocupaciones y dificultades con las que topamos.
  • Compromiso: Tenemos la sensación de controlar nuestro destino y nos comprometemos con el resultado esperado.
  • Respeto: Al trabajar juntos, compartiendo éxitos y fracasos, promovemos el respeto mutuo.
Valores -> Scrum, gracias Alejandro
Estos valores construyen sobre el propósito, la motivación intrínseca más potente que se produce en las personas que trabajan con Scrum. Ese sentimiento de estar participando y aportando valor con nuestro trabajo a lo que nos rodea, la compañía, el negocio, los usuarios... es el mayor impulsor de creatividad y calidad.

Estos valores los podéis encontrar en documento Core-Scrum de Scrum Alliance.

Si queréis indagar un poco más alrededor del tema os invito a que echéis un vistazo a los principios activos del artículo de Juan Palacio: "Excipientes y principios activos de la Scrum".

martes, 11 de noviembre de 2014

¿Cómo implantar agilidad en una empresa?

Agilidad - Scrum
El tema de la transición de gestión de proyectos de metodología tradicional (predictiva) a agilidad (evolutiva) es tema de amplio debate e interés en los cursos. No se trata de un simple cambio de metodología, de nuevas reglas y prácticas, sino que va acompañado de un cambio cultural muy profundo que ha de producirse en la mentalidad de cada uno de nosotros.

El cliente ha de ser consciente de que parte de una visión incompleta de lo que necesita, sabe lo que quiere pero no lo que necesita, y por tanto no ha de pensar en términos tradicionales de cerrar en alcance-plazo-coste. El enfoque ágil es construir a cachos, con entregas frecuentes, de manera que entre cacho y cacho pueda redefinir según le marque su mercado. Construirá mientras los cachos le den valor a su negocio o mientras el presupuesto lo permita. Hay que cambiar esa forma de pensar que trata de buscar un proveedor como si de una "novia" se tratase, para luego "casarse" con ella y darle el proyecto. Hay que aprender a buscar un partner, alguien que camine a nuestro lado y nos haga crecer. La confianza y el compromiso se irán construyendo con cada sprint, y si no engarzáramos con ese partner, hay que ser ágil y buscar otro partner. Todo ello sin prejuicio para ambas partes, simplemente cliente y proveedor no han engarzado.

El proveedor ha de ser partícipe de la misma perspectiva; no ofrecer un proyecto a alcance-plazo-coste cerrados, sino dar la bienvenida a los cambios y dar respuesta rápida en la puesta en el mercado de lo que le da valor al cliente.


La estructura se vuelve más plana, un jefe de proyecto si tiene cabida y sabe adaptarse se vuelve básicamente facilitador, ya que para un equipo comprometido y autogestionado el rol del jefe de proyecto puede anular al equipo ágil. También los miembros del equipo han de cambiar su forma de pensar, han de sentir que van en el mismo barco, que están comprometidos con el objetivo y éxito de todo el equipo, no solo con el particular. No ha lugar a especialistas con su reino, se requiere actitud de colaboración y compartición de conocimiento, tanto técnico como funcional. Hemos de estar abiertos a ser un equipo multifuncional, especialistas en lo nuestro pero interesados en lo que nos rodea.


Visto lo anterior se puede comprender que no es trivial transformar en una empresa ágil. La agilidad se basa en 
cambiar de mentalidad, implementar gestión de personas (motivación, compromiso, fidelización...), rodar, coger experiencia, revisar, adaptarse y mejorar continuamente, por tanto se trata de empezar para ir evolucionando y madurando hacia la agilidad.

Ese punto de partida es donde entra Scrum
. Scrum se concibió como una marco de trabajo para llevar a las empresas hacia la agilidad. Todo los elementos de Scrum, sus roles, sus artefactos y sus reglas están pensados para iniciar a las empresas en la agilidad y crear el ambiente propicio para que se den los cambios de mentalidad necesarios. Las propias reglas de Scrum, como no poder intervenir en el equipo durante un sprint, ya se encargarán de "romper" los hábitos culturales.

Por tanto es tan simple como suena, tomar la decisión de implantar Scrum y aplicarlo al 100% (al 100%, no al 99%...), sus reglas son pocas y fáciles de entender, de hecho pensándolo un poco son de sentido común.

¿Qué ocurrirá? Que de repente habrá entregas cada dos semanas y eso hará que el estrés propio de un proyecto se traiga al principio del proyecto. De igual manera todos los riesgos se trasladarán al principio del proyecto, de pronto habrá una fecha a la vista en que posiblemente habrá que subir algo a producción, si no es en el primer sprint será en el segundo o tercero. Todos, interesados, negocio y equipo entrarán en una fase de aprendizaje en que todos los problemas se harán visibles y se deberán de resolver a corto. Eso es algo buenísimo, porque equivocarse al principio permite aprender, mejorar y crecer, aunque al principio siempre va a haber mucha resistencia al cambio.

Los beneficios de Scrum no se hacen patentes enseguida, usualmente sus bondades se ven a partir del tercer sprint. Los beneficios son muchísimos, entregas cada dos semanas, con lo que todos los ciclos se reducen a dos semanas, cada segundo viernes el equipo se va a casa para el fin de semana con sensación de trabajo bien hecho y acabado, lo que redunda en equipos motivados, igual que los clientes y negocio que sienten que el producto avanza y que tienen el control sobre rumbo del producto. Una vez maduros, los equipos habrán incrementado su productividad en hasta un 400%, y eso ¡sin sobreesfuerzos!

El mensaje que quiero dar es, que aunque Scrum sea muy fácil de entender y hagamos todos los preparativos estratégicos, puede ser muy difícil de poner en marcha, eso dependerá de la cultura de la compañía.
¡La cultura se merienda a la estrategia!

Se puede poner en marcha de hoy para mañana, habrá un bajón en la productividad pero como mucho durante 2 sprints. Lo importante antes de iniciar Scrum es dotarse de un Scrum Master experimentado, asegurarse de formar a los equipos, al Propietario del Producto y al cliente, y muy importante, abrir canales de comunicación entre equipo y cliente/usuarios, y no me refiero a nada tecnológico, sino hacer que se conozcan, si no es en presencial hablándoles a unos de los otros. Es importante que usuarios y equipo sepan quien hay al otro lado, que sientan empatía los unos por los otros, eso abre canales y hará que tomen mejores decisiones.

Una vez la empresa haya rodado y esté madura en Scrum, será el momento de introducir nuevas prácticas ágiles que hagan que las cosas funcionen aún mejor y hagan que Scrum se adapte a la empresa. En Scrum Manager conocemos estos dos estadios como Scrum técnico y Scrum avanzado, estos están representados en el cuadro de Niveles de Scrum que se encabeza con la frase "Has aprendido a avanzar en scrum cuando sabes romper las reglas".

Cierro con un texto del libro Lean from the Trenches de Henrik Kniberg que resume la vivencia de empresas y equipos una vez han transicionado a agilidad.
Henrik Kniberg - Lean from the Trenches

jueves, 6 de noviembre de 2014

¿Qué hacer con los móviles en la reunión de planificación de sprint?

Planning poker en baraja y como app
En el último de los cursos que di, hice, como siempre, el ejercicio de la estimación de póker. Saqué la baraja de planning poker y repartí los ejercicios. Los alumnos siempre se lo pasan muy bien, es un ejercicio ameno que suscita mucho debate, pero esta vez vi a uno de los alumnos que tenía la baraja intacta y ponía boca abajo su móvil cada vez que estimaban una tarea... Estaba utilizando la aplicación planning poker para Android de 10 pines

Una forma de ganar tiempo y conseguir que te dejen tranquilo es dar trabajo, sea con un compañero o con un cliente. De forma análoga, para "silenciar" los móviles en la reunión de planificación de sprint, una buena opción es "ocupar" el móvil, en este caso utilizarlo como herramienta para la estimación.

Estoy valorando proponer en mis cursos futuros utilizar el móvil en vez o a la vez de la baraja, creo que amenizaría aún más el ejercicio.

sábado, 1 de noviembre de 2014

¿Qué hacer con los móviles en la reunión de diaria?

Móviles aparcados
Una Scrum Master me comentó en un curso presencial que estaba desesperada con la gente que en plena reunión diaria estaba por el móvil. Tiene ganas de prohibirlos, pero claro, no puede tratar al equipo como si fueran niños...

Es un tema complicado, el equipo son profesionales responsables y puede haber llamadas urgentes que requieren ser respondidas, o llamadas o mensajes de trabajo que sean importantes... por tanto no se pueden prohibir directamente. Hay hacer algo pero dejarles una vía abierta hacia el móvil.

La idea que le propuse fue hacer que los miembros del equipo dejasen el móvil en una pila, y el primero que cogiese el móvil durante la reunión debía de invitar al resto a copas al finalizar la jornada de trabajo. Quedan exentas llamadas de trabajo urgentes o mensajes realmente importantes. :-)

miércoles, 29 de octubre de 2014

¿Para gestionar un equipo que trabaja bajo TDD se puede añadir una columna de "refactorización" en la pizarra Kanban?

Ciclo TDD
Como sabréis Test-Driven Development (TDD) se basa en la programación orientada a objetos en que se escriben las pruebas unitarias primero y se desarrolla después, siendo guiados por estas pruebas. El ciclo de codificación acaba cuando el código pasa todas las pruebas. Finalmente se refactoriza el código escrito para lograr un código limpio y homogéneo que funcione.

Usualmente se incluye la refactorización dentro de la programación, el que efectúa las pruebas unitarias al fin y al cabo es el programador, por tanto cuando este acaba con la codificación puede dedicarse a la refactorización para terminar la tarea. Incluir una columna de refactorización en nuestra pizarra implica que se va a refactorizar cada tarea recién programada en otra etapa y esto a primera vista parece una "muda", un desperdicio.

Kanban lo que hace es gestionar flujos de trabajo, sea el que sea, por tanto una columna de refactorización puede perfectamente ser necesaria. Imaginémonos una empresa como Microsoft, que aún trabaje de forma distribuida con factorías en la India, y que cada tarea que reciba la refactoriza en la central para asegurarse que el código sigue los patrones establecidos y es homogéneo con el resto del software.


La cuestión clave es ¿la refactorización aporta valor?

sábado, 25 de octubre de 2014

¿Scrum al tratar equipos multifuncionales no requiere de especialistas?

Especialista contándoles de su especialidad
a sus compañeros de equipo
De entrada decir que no se debe de confundir equipo con persona, un especialista es una persona con conocimientos y habilidades en un determinado campo, y un equipo multifuncional es un equipo integrado por personas cuya suma de conocimientos y habilidades cubre todas las necesidades que requiere el desarrollo del producto: el equipo es quién ha de saber construir el producto, no las personas.

Más allá de esta distinción Scrum requiere actitud además de aptitud, miembros especialistas y a la vez interesados en lo que les rodea. Entre los miembros del equipo puede haber especialistas, incluso puede ser que el proyecto requiera de especialistas muy concretos y de forma puntual. En un equipo ágil todo miembro puede en algún momento hacer cualquier tipo de tarea, sea su especialidad o no. Gracias a la autogestión es muy probable que una tarea determinada la haga quien tenga más habilidad o facilidad para ella, en este caso el especialista encuentra fácilmente su tarea, pero en situaciones de sobrecarga, el especialista debe de estar abierto a formar a un compañero para que le eche una mano, y de la misma manera, si no hay tareas de su especialidad, dedicarse a otras tareas que puedan no ser de su gusto, pero absolutamente necesarias para el sprint. Recordemos que el objetivo del sprint es un objetivo del equipo.

De esta manera la transmisión de conocimiento se da a todos los niveles, no solo funcional sino también técnica y por tanto de especialidades. Recordar también que la multifuncionalidad del equipo permite responder a fluctuaciones en el flujo y resolver bloqueos y dependencias de una estructura horizontal como la que se crea con los departamentos (definición, desarrollo, sistemas, QA).

Una nota para los que contratéis a técnicos: la actitud es difícilmente reconducible,
 una persona inadecuada puede romper un equipola solución es crear un ambiente propicio para el cambio y si este no se produjera hay que plantearse reemplazar a la persona. En cambio la aptitud es mucho más fácil de tratar, se soluciona con simple formación, con un curso especializado.

martes, 14 de octubre de 2014

¿De dónde viene la iniciativa de implantación de Scrum en las empresas?

A lo largo de los diferentes cursos de este año he ido preguntado, a aquellos alumnos que en su presentación mencionaban que en su empresa utilizaban Scrum, como había entrado Scrum en su empresa.

He identificado 4 vías:

Distribución de las vías de entrada de Scrum
  1. Visión desde gerencia: en algunos casos la implantación de Scrum forma parte de la estrategia empresarial, son los menos, pero es significativo que ya haya empresas en que la agilidad forme parte de su naturaleza.
  2. Control de una situación complicada: en estos casos Scrum se implantó en empresas para intentar dar solución a situaciones de descontrol en la ejecución y gestión de proyectos, suelen haberse desviado en horas y haber entrado en una espiral de modificaciones constante para intentar enderezar la situación.
  3. Condición del cliente: en estos casos, y cada vez más, la implementación de Scrum viene ¡como metodología a aplicar al proyecto solicitada por el propio cliente! Este caso está en alza, se están impartiendo cursos de agilidad en grandes consultoras para dar cobertura a proyectos en que el cliente demanda agilidad.
  4. Prácticas desde el equipo: en muchos casos es el propio equipo el que introduce prácticas ágiles en la empresa. Es un camino arduo, ya que el proceso para convencer a la gerencia de la empresa y al cliente es lento, aunque en los casos que me han contado, siempre ha sido exitoso.
Sin duda la vía más significante es la en que el cliente solicita agilidad, a un nivel abstracto hasta se puede hacer un paralelismo con la manufactura lean, el cliente está estirando "pull"... por tanto es el mercado el que está demandando metodologías ágiles. Pienso que la crisis tiene que ver, es época de vacas flacas en la que se busca alternativas y se innova.

lunes, 15 de septiembre de 2014

¿El Propietario del Producto ha de participar en la reunión de scrum diario?

No, no es necesario que el Propietario del Producto asista al scrum diario, es una reunión propia del equipo de trabajo, en la reunión de planificación de sprint ya ha expuesto todo lo que compone la pila de sprint al detalle necesario, y no es hasta la reunión de revisión de sprint donde debe de formar parte de nuevo.
Reunión de scrum diario
Los casos en que el Propietario del Producto asiste suelen ser cuando el cliente es interno, de un departamento de la empresa, o un jefe de proyecto que representa un cliente y actúa como Propietario del Producto. En todo caso el Propietario del Producto asiste en calidad de interesado, sin voz ni voto.

Hay casos en que la asistencia del Propietario del Producto es muy positiva, puede resolver dudas del equipo y por experiencias de alguno de mis alumnos, sé de un caso en que fue muy motivante para el equipo que el Propietario del Producto los mantenga al día de las actividades comerciales relativas al proyecto y al cliente y de cómo se mueve el mercado del producto que están desarrollando.

En uno de los equipos que acompañé recientemente el Propietario del Producto venía a los scrums diarios sin interferir, y después de la reunión se quedaba un rato más mientras el equipo le enseñaba como iban avanzando con el producto, mostrando lo que estaban haciendo en un ordenador de desarrollo. No hace falta mencionar que ese proyecto fue un gran éxito, el éxito depende en gran medida de liderazgo desde el punto de vista del producto del Propietario del Producto.

Pero el Propietario del Producto que asiste debe de estar alineado con la mentalidad ágil, podría ser contraproducente que asistiera, ya que pudiera estar tentado a influir en el equipo, rompiendo la autogestión, la autoorganización, y por ende el compromiso.

martes, 9 de septiembre de 2014

¿Son más exitosos los proyectos ágiles o los tradicionales?

Uno de mis alumnos mencionó un post de Mike Cohn respecto a este tema que me pareció interesantísimo y que traduzco a continuación.

De acuerdo con el 
CHAOS Report de 2011 del Standish Group, los proyectos ágiles son tres veces más exitosos que los proyectos no ágiles. El informe llega tan lejos como para decir: "La metodología ágil es el remedio universal para el fracaso de proyectos de desarrollo de software. Las aplicaciones de software desarrolladas con metodología ágil tienen una tasa de tres veces más éxito que cuando se aplica metodología tradicional en cascada, así como un porcentaje mucho menor en las desviaciones por exceso de tiempo y costes" (página 25).

The Standish Group define el éxito de un proyecto como entregado a tiempo, dentro del presupuesto, y con todos los requisitos y funcionalidades planificadas desarrolladas. No informa en cuántos proyectos se ha basado, pero dice que los resultados son de proyectos llevados a cabo entre 2002 y 2010. El siguiente gráfico muestra los resultados específicos reportados:
Agile Succeeds Three Times More Often Than Waterfall

jueves, 4 de septiembre de 2014

¿Cómo asignar las tareas de la pila de sprint?

Decidiendo que tarea autoasignarse
Las tareas se autoasignan por el equipo o sus miembros en cada reunión de scrum diario, concretamente ocurre cuando cada miembro dice lo que va a hacer para el día siguiente. De esta forma cada miembro toma las tareas que le corresponden según su motivación, sus habilidades o su especialidad, permite desarrollar el talento de cada persona y encontrar su lugar en el equipo.

La autoasignación también contempla que para tareas concretas, el equipo en su conjunto, decida asignar la tarea a un miembro o grupo de miembros en particular. Por ejemplo, en caso de urgencia asignarle la tarea a un experto para que la resuelva cuanto antes, o en caso de que no haya ninguna criticidad o haya tiempo, asignársela al menos experto, quizá guiado por un experto, con el fin de que el primero ruede y adquiera know-how (un buen nivel know-how hace, entre otras, equipos ganadores).

Cuando nos autoasignamos las tareas ante los demás miembros establecemos la conexión con los demás miembros, después del scrum diario todos sabemos lo que hacen los demás con lo que se fomentan entre otras la colaboración, la difusión y transferencia del conocimientoel ayudar a un compañero que está en un cuello de botella y el no hacer las mismas cosas dos y más veces.

lunes, 25 de agosto de 2014

¿Cómo gestionar un bug que se ha detectado en la fase de pruebas usando un tablero Kanban con incremento continuo?

Los bugs forman parte del software
En Scrum simplemente se incorporaría el bug a la pila del producto, probablemente para tratarlo en el siguiente sprint. El caso de Kanban, gestionando incremento continuo y regulado por límites WIP, es distinto.

Dependiendo de la crititicidad del bug, este entraría en el backlog o pila de entrada del tablero, o, en caso de existir, en el carril "expedite".

La solución ideal es que bugs críticos entren en un carril de nado especial denominado "expedite", este tiene la característica de aumentar el límite WIP de todas las columnas de estado, usualmente en un +1. En cuanto un miembro del equipo queda libre se pone a trabajar en el bug, este tiene prioridad sobre las demás tareas. Adicionalmente se puede relacionar el bug con la tarea/historia/petición que lo ha puesto sobre la mesa.
Tablero Kanban con carril expedite y visualización de la petición que lo ha detectado
Si se tratara de un bug no crítico o no tuviéramos carril "expedite", este debería de entrar como tarea en la columna "in process" si el WIP de esta lo permitiese, sino en la columna de "backlog", y si el WIP de "backlog" tampoco lo permitiese consideraría aplazar la corrección del bug para más adelante, o sacar una tarea del backlog para colocar esta. Sería un error dejar el bug en "testing", no le corresponde ya, o ponerla en la columna "in process" o "backlog" cuando el WIP no lo permite, rompería el flujo de trabajo que trata de regular el tablero, estando este perfectamente regulado podrían aparecer de nuevo cuellos de botella y tiempos muertos.

domingo, 24 de agosto de 2014

¿Qué tiene que ver Scrum con la melé de rugby?

Jugadores en melé (foto cortesía de Peter Dean)
La melé es un término de origen francés, scrum en inglés, que representa una jugada de rugby en la que dos equipos compactos se empujan mutuamente para disputarse la posesión del balón. Los miembros de cada equipo están fuertemente compenetrados y se adaptan en conjunto, como una unidad, a la jugada.

En 1986 Hirotaka Takeuchi e Ikujiro Nonaka realizaron un estudio sobre procesos de desarrollo muy exitosos utilizados en ciertos productos en Japón. Se trataba de productos que partían de requisitos muy generales y que afrontaban equipos reducidos y multidisciplinares. El estudio comparaba la forma de trabajo de estos equipos con la colaboración entre los jugadores de rugby y su formación de scrum. Takeuchi y Nonaka lo llamaron un enfoque de "rugby", "donde un equipo intenta recorrer toda la distancia como una unidad, pasando el balón hacia atrás y adelante".
Equipo de Scrum
En 1993, usando este estudio como base, Jeff Sutherland creó el proceso Scrum para desarrollo de software adoptando la analogía con los equipos de rugby, y finalmente trabajó con Ken Schwaber para formalizar la primera versión de Scrum en la OOPSLA'95 (Object-Oriented Programming, Systems, Languages & Applications).

Destacar también que el grupo de cada equipo para la melé de rugby ha de estar formado por un mínimo de cinco y un máximo de ocho jugadores en tres líneas, y que en Scrum se recomienda que un equipo tenga entre 4 y 8 miembros, ya que más allá de 8 resulta difícil mantener la comunicación directa, primordial para mantener la agilidad.

jueves, 21 de agosto de 2014

¿Cómo actuar en caso de equipos que varían a lo largo de los sprints por la necesidad de adquisición y liberación de especialistas?

Especialista técnico de AS/400
Este sería el caso en que se requieran especialistas en momentos puntuales para determinadas tareas, como por ejemplo expertos en un tema muy concreto como maquetadores, analistas o técnicos de sistemas como en el caso de un técnico de AS/400 de la imagen de la derecha ;-). Esta situación suscita otras preguntas como ¿invitamos a los especialistas a la reunión de planificación del sprint? ¿Forman estos parte del equipo?...

Scrum implica un cambio de chip en todos los miembros del equipo, cambio que se puede resumir en "vamos todos a la una". Un equipo multidisciplinar es clave, debe incorporar a los especialistas que hagan falta para los diferentes aspectos del proyecto y con mentalidad de interés por todo lo que les rodea. Recordemos que se autogestionan, por tanto un maquetador o un experto será el especialista en su campo, pero como estos sienten que forman parte de un equipo y que el producto resultante es como "un hijo suyo", no les importa hacer tareas que no son de su especialidad. Son personas tipo "T" que simplemente suman.

Scrum es una forma excelente de difundir el know-how, tanto técnico como funcional. Hay una máxima que funciona, que es "never change a winnig team", y scrum crea justamente equipos ganadores. Entendido esto, evidentemente el equipo puede variar, un maquetador podría no hacer falta a partir del tercer sprint... aunque este es un mal ejemplo, ya que para crear un incremento que funcione, la maqueta ya es el producto, y el producto estará presente en todo el proyecto. Un analista hará falta siempre, ya que el producto está en constante rediseño, y un especialista posiblemente también, ya que el producto se va construyendo al mismo tiempo que se modifican y aparecen nuevos requisitos.

Es importantísimo dejar de la lado la idea de grupos de trabajo con especialistas en una tecnología y dedicados a tareas de especialista. Lo importante es el equipo, formado por especialistas, si, pero por personas con actitud de sumar al equipo y de arremangarse para lo que haga falta. Yo he hecho entrevistas a muchos candidatos, y más que buscar a personas mastersdeluniverso, para mí lo importante es una buena base técnica y "buen rollo" para integrarse al equipo. Una necesidad técnica nueva se soluciona muy fácilmente: con un curso a la persona adecuada. Construir un equipo con personas comprometidas es lo difícil.

A todo esto puede aparecer una tarea "atípica" e infrecuente, no habitual en el proyecto y tampoco en los proyectos de la empresa. Un buen planteamiento sería considerarla como un servicio externo, como una adquisición con un coste y una fecha de entrega que debería ser adecuada para la integración en el sprint correspondiente. En este caso la realización de la tarea es cosa del especialista, un proveedor freelance subcontratado para ese trabajo concreto. Off-the-record mencionar que esta forma de gestionar a un especialista es la ideal para incorporar temporalmente a un gurú. Estos suelen ser tipos algo freakys y con esta manera de gestionarlo, en que estos no forman parte de equipo, se evita que resten. Es recomendable también que un miembro del equipo adquiera los conocimientos, aunque sea de forma superficial, de la solución al problema que ha requerido la intervención del especialista.

viernes, 18 de julio de 2014

¿1 punto de historia = 1 día ideal?

En charlas, foros y otros ambientes de discusión, hay debates sobre la unidad a utilizar para estimar el tamaño de las historias de usuario. XP, eXtreme Programming, por ejemplo, utiliza el story point, y lo define como la cantidad de trabajo que se realiza en un día: 1 punto = 1 día ideal.

Realmente la unidad que se utilice es irrelevante. Lo que importa es que el equipo la conozca, signifique lo mismo para todos y que todo miembro sepa estimar con esa misma unidad.

Usar el tiempo, en el caso de XP los días, también es tema de debate, ya que en los proyectos medimos tamaño en unidad de tiempo, usualmente en horas/hombre o días/hombre. Algún comercial o jefe podría, o bien inconsciente o bien caer en la tentación de hacerlo conscientemente, condicionar al equipo en la estimación de las tareas. Cuantas veces nos han dicho al estimar "el proyecto han de ser tantas horas aproximadamente, por encima de eso el cliente no lo aceptará....". Por otro lado solemos caer en considerar la medida de trabajo "tiempo ideal" equivalente a la medida de tiempo real, no es fácil entender que por ejemplo 4 horas de tiempo ideal se han realizado en 6 horas reales y que eso es puede ser una muy buena productividad.

Página de login, algo común a muchas aplicaciones
Lo ideal es que cada equipo defina el punto de historia como algo que le sea representativo, por ejemplo en pantallas maestro-detalle, en listados de 10 columnas y totales, páginas de login... Toda aplicación suele tener una página de login, por tanto es un buen referente común de los equipos para una unidad de tamaño. He trabajado con un cliente con una buena experiencia en que un punto de historia es media jornada y consideran la jornada de 6 horas en tiempo ideal, por tanto realizable en 8 horas reales... para concluir cualquier elemento con el que el equipo se sienta cómodo es válido.

martes, 15 de julio de 2014

¿En qué poder apoyarse para registrar la evolución de los sprints de un proyecto?

Evolución de un sprint en forma de gif animado
Por diversos motivos puede ser interesante registrar como van evolucionando los sprints, ya sea por trazabilidad o por necesidad de reporting a una oficina de proyectos o directamente a gerencia, como pordria ser en caso de empresas de pequeña envergadura.

Tradicionalmente cogeríamos nuestros inventarios de tareas, con la situación diaria de las mismas, y las podriamos sobre la mesa para responder a las peticiones y preguntas que nos harían. En el marco de Scrum podríamos pensar en el diagrama burndown, pero este es una representación gráfica de la evolución del trabajo dentro de un sprint dado, da información pero no de la evolución completa, puede ser útil, pero sería parcial.


Una solución simple y fácil de implementar es tomar una foto del tablero Kanban con una cámara digital todos los días. Quien tenga interés en la trazabilidad o analizar la evolución de los sprints tiene así una excelente fuente de información visual y diaria. Reportaríamos en base a una serie de fotografías que mostrarían la situación día a día.

Evolución de un sprint con fotografías periódicas