Entradas archivadas en Empresas

El dueño de producto debe hacer también el papel de escultor con las ideas del cliente. Normalmente este aparece con un documento o idea con la que quiere abarcar “todo”, “la inmensidad del mercado”, el cliente piensa que cuanto más aspectos cubra mas rendimiento le sacará a su inversión.

Si el cliente hiciera él solo la pila de producto, exagerando, más o menos sería como en la ilustración de arriba. Es aquí donde el dueño de producto debe aplicar todos sus conocimientos y experiencias, no solo en Scrum, si no en la gestión de proyectos.

El primer paso es definir bien el mercado, al igual que hacemos disgregando la ideas de los clientes en historias y tareas, debemos conseguir que nos fragmente el mercado objetivo en segmentos, así construiremos nuestra pila de producto tomando los aspectos más relevantes. Los principios que deben regir esta segmentación son: geográfica, demográfica y sicográfica.

El segundo paso es fijar unos costes reales para el primer lanzamiento, con lo que una vez adelgazada la pila de producto gracias a la segmentación del mercado, se debe hacer un análisis de costes. Fijar un precio objetivo conlleva volver a analizar las historias que son vitales y las que no, para que luego el coste del mismo no influya en los consumidores. En este paso, el product owner debe aconsejar al cliente sobre la circunstancia de que cuantas mas historias vitales tenga el proyecto, mayor coste terminarlo, tanto de inicio, como de nuevas tareas que surjan durante los sprints.

El último paso es poner un valor estratégico de cada historia, no nos referimos al coste, si no al valor añadido que supone para los consumidores cada parte del producto. Conocer cuales son los elementos mas valorados por el usuario será la guía que nos oriente a la hora de priorizar la pila de producto.

Si el dueño de producto trabaja en estos tres aspectos con el cliente, la pila de producto será mucho mas coherente, tanto para el equipo de producción como para todos los interesados en el proyecto. Los productos o servicios tienen un fin comercial o de uso y por lo tanto, tener en cuenta los valores del mercado es una de las acciones que conlleva a definir mejor la pila de producto.

El Scrum Master es la persona encargada de que el equipo mantenga su unión y su armonía, es por esto que debe tener unas cualidades especiales.

El Scrum Master, aparte de estas de estas cualidades especiales, debe tener una mentalidad distinta, que se entrena desde pequeño, debe saber dar soluciones a todas las circunstancias que suceden en el día a día, valer para ello. Muchas personas se preguntan si se entrena o si estas cualidades se tienen desde pequeño. Para poder responder a esta pregunta hay que retroceder a la pubertad de las personas, que es cuando se va definiendo el carácter, su forma de ser, la cual ya definen plenamente en sus principios de vida adulta.

Un Scrum Master debe haber ejercido como tal ya en sus otras facetas de la vida, ser esa persona que encuentra soluciones sencillas en todos los momentos, es por eso que desde pequeño se puede ver si una persona cumple el perfil de Scrum Master o no.

Si este perfil no se encuentra dentro de una organización, lo mas recomendable es buscarlo en el mercado, que transformar a un miembro del equipo actual a representar un papel para el que no esta plenamente preparado. El rol de Scrum Master es eje fundamental sobre el que se asienta toda la creación, toda la producción, asignar esta labor a una persona que nunca ha ejercido como tal, supone una merma, una reducción de la producción, algo que puede afectar de forma directa al balance económico de una empresa u organización.

El Scrum Master ideal no se crea de la nada, debe tener las cualidades y un curriculum ya hecho en otras facetas de su vida, como tal, solo se moldea para que se integre en un equipo y en un sistema de desarrollo ágil. Cualquier otra solución que se tome, como asignar este rol a una persona cualificada pero sin cualidades, conlleva un deterioro en la producción y una ralentización en todos los procesos. En definitiva, si no se dispone de ese perfil dentro de una empresa que quiere abrigar las metodologías ágiles, se debe buscar en mercado laboral para incorporarlo.

Cuando se desarrolla un proyecto empleando Scrum, una de las críticas es que se basa en historias y tareas, con una visión muy genérica y sin un plan bien definido.

Una de las labores principales del product owner, aparte de la gestión de la pila de producto y la atención al cliente, también realizar una pequeña hoja de ruta, una senda por la que debe caminar la visión hasta la meta. Esta hoja debe ser un documento simple, donde se refleje el enfoque que se le tiene que dar al trabajo. Una persona ve un mapa y en el tiene los caminos y las paradas, nada más, no suele tener ni demandar documentación sobre los lugares, cuando llegue a los mismo ya se interesará por cada uno, pero en la ruta lo único que le interesa es el camino, las paradas y el tiempo en llegar a la meta.

Los contenidos principales que debe tener la hoja de ruta son:

  1. Decidir la meta: Si es una fecha en concreto o si el objetivo, es tener un objeto o funcionalidad terminada. Hay que tener muy en cuenta la posibilidad de que la fecha de entrega este condicionada por una feria, convención o evento.
  2. En un segundo determinar la frecuencia con la que se le va a mostrar al cliente las historias terminadas.
  3. Recoger las circunstancias especiales de los clientes u otros actores.
  4. Revisar y actualizar esta hoja de ruta después da cada entrega.

El camino nunca es como el cliente ha planificado (color naranja), es por ello que después de cada entrega, la hoja de ruta se pueda modificar. Al final el objetivo no es llegar a un resultado sin importar su eficiencia y efectividad, si no que se el resultado sea el óptimo para el cliente (color azul) siguiendo una hoja de ruta alterable.

Es difícil hacer un resumen para que se entienda fácilmente la diferencia entre ambos planteamientos, por ello, hemos dibujado dos gráficos que unidos ayudan a explicar mejor la diferencia entre las estas dos opciones de metodologías.

En el planteamiento en cascada se realiza un plan estimando la documentación de seguimiento de un programa y el coste de ejecutarlo. Como resultado se tienen que dar una características y sobre ella se van desarrollando el plan y el resultado.

En la metodologías ágiles el planteamiento es distinto.

Se realiza una estimación sobre las características, lo cual da como resultado una visión, no un plan de ejecución, como ocurre en la planificación en cascada, y luego se trabaja sobre el programa y el coste.

La gran diferencia entre las dos formas es el corazón, lo que se encuentra dentro del triángulo, en la planificación en cascada es el “plan”, en la metodología ágiles es la “Visión”. La otra diferencia  es que en una el coste esta totalmente cerrado, sobre el mismo se ha realizado un programa y se ejecuta, y en la otra como se abrigan los cambios, no hay un coste cerrado.

Que no exista un coste cerrado no significa que sea malo para el proyecto ni perjudicial para terceros, normalmente se tiende a pensar en que va a costar mas de lo que se planificó, pero puede ocurrir lo contrario, que la visión lleve a ejecutarse un producto mas sencillo de hacer y con unos costes menores de los previamente previstos. Los costes se irán definiendo mejor cuanto mas se acerque uno al final del proyecto, es muy difícil en muchas ocasiones saber al 100%  el coste total, y si además, el proyecto se atañe a unas cantidades fijadas, perderá eficiencia y eficacia, dado que estos valores se colocarán por debajo en importancia del cumplimiento de unos costes ya firmados.

Las metodologías ágiles, lo que ponen sobre la mesa es que se trabajaba sobre una estimación de las características que se quieren crear en un producto, con una visión que va enfocando el camino, una visión que crece y se enriquece con el paso del proyecto y que, la mejor definición de la misma puede hacer variar el coste y el programa cuando se reciben los primeros resultados de las entregas parciales del producto.

Ya se ha anunciado la primera conferencia nacional sobre metodologías ágiles en España. Será el 10 y 11 de junio de 2010 en Madrid, en el Campus de la E.U. Informática de la U.P.M.

Toda la información sobre la misma se encuentra en la web de Agile Spain de la conferencia 2010.

Como invitado principal estará Henrik Kniberg autor de “Scrum y XP desde las trincheras” y de “Kanban vs. Scrum – Obteniendo lo mejor de ambos”.

Es una gran noticia la organización de este evento, por primera vez todos los profesionales que emplean metodologías ágiles tendrán una cita ineludible en España.

Todos podemos ayudar a que el evento sea un éxito, la mejor manera es participar activamente y para ello puedes hacerlo de tres maneras distintas:

Desde este blog apoyamos esta iniciativa activamente, iremos comunicando todas las novedades sobre el evento, ni que decir tiene que ya hemos enviado nuestras propuestas de conferencias.