User Agile Development

Story Points vs Hours

noreply@blogger.com (Iván) — Sun, 08 Jan 2012 04:28:05 PST

Llevo meses mascando este post, la verdad es que he tenido varios debates con otros ingenieros, y no hay una opinión convencida por ninguna de las dos alternativas. Lo mismo se puede deducir de una búsqueda rápida en google por: Story Points vs hours ... veréis que no son pocos los post relativos a esta temática.

Creo que lo más razonable es exponer pro's y contra's de ambas posibilidades y a posteriori explicaré que decisión hemos tomado en Tritium y las motivaciones.

En cualquier caso, no voy a poder ser muy objetivo, por que no he vivido ninguna implementación por el momento basada en Story Points, en los equipos en los que he trabajado trabajamos con esfuerzo.

Story Points

Como bien podéis deducir del nombre se trata de otorgar una valoración a la tarea, en general suelen ser aplicados a historias (Story) Y ese es para mi el enfoque ideal de aplicación.

Uno de los factores más importantes a considerar es que los Story Points valoran la complejidad, ni el esfuerzo ni la duración. Y para mi ese es uno de los puntos más importantes para, en función de tus necesidades, descartar esta opción.

No existe una definición clara en relación al proceso de estimación en ninguna de las metodologías ágiles, suele ser habitual para facilitar la asignación de complejidades utilizar la serie de fibonnaci 1 3 5 8 13 21 34 ... por ejemplo.

En general se consideran, y me sumo a la consideración, una perfecta herramienta de valoración/estimación a largo plazo. Pero poco recomendable para gestionar el SPRINT PLAN.

Existen pero equipos que se sienten cómodos haciendo uso de estos, y obteniendo métricas de velocidad de sus equipos en base al número de puntos que son capaces de resolver en cada SPRINT.

Esta métrica, primordial para los equipos ágiles, tiene un pero, y es que no pueden ser extrapoladas a otros equipos, la velocidad en puntos, es algo subjetivo, en función del valor que le des a una historia. Un equipo puede otorgar una complejidad 3 a una historia que para otro sea complejidad 8...

Este factor es, desde mi entender, contraproducente cuando la organización dispone de más de un equipo, no obtienes métricas que te ayuden a identificar puntos de mejora en la organización. La velocidad es algo atómico para cada equipo. En cambio puede ser suficiente para una organización monoteam.

Otro factor contraproducente es como resolver la pregunta, al más puro estilo "The Simpsons" de "¿Cuánto falta?" Recuerdo que los Story Points es una métrica de complejidad, no de duración ni esfuerzo ... por lo que de nuevo nos encontramos con falta de herramientas a la hora de resolver esta habitual pregunta.

Siempre podemos optar por, viendo el número de puntos restantes para cumplir con el objetivo y la velocidad del equipo, deducir el número de SPRINTS que nos faltan para cumplir como el hito requerido. Pero dificulta la transparencia de la información.

Hours

La estimación por tiempo tiene otras complejidades, pero tiene la ventaja de la transparencia, la comunicación es en una unidad temporal que otros miembros externos al equipo de producción entienden, el tiempo.

Eso sí, hay que dejar muy claro en cualquier caso, que las estimaciones son sobre esfuerzo, jamás sobre duración, la duración es otra herramienta de estimación que se convierte en peligrosa ...

Voy a tardar 8 horas, por tanto lo tendrás mañana. !!!ERROR!!!!

Como diría mi profesor de lógica, A si B, no A --> no B ... ya sabemos que es imposible trabajar sin interrupciones, para que nos vamos a engañar. Las tareas deben estimarse en esfuerzo, cuanto tiempo estimado requiere esta tarea para ser desarrollada.

La duración la establece el SPRINT, hay que evitar en la medida de los posible realizar entregas parciales dentro de una unidad de planificación. Las entregas se realizan al final del SPRINT. Por lo que la duración no es representativo en esta situación.

En cualquier caso existen muchos contras de fundamentar las estimaciones en horas. Es algo que sucede de manera habitual en entorno "Consultoría", las estimaciones no se realizan en base a complejidad, si no en base "al tiempo disponible". Es decir se suele planificar en base a un budget definido de tiempo provocando las indeseadas situaciones que muchos de nosotros conocemos.

En ese sentido, medir la complejidad del proyecto a nivel global, y conociendo nuestra velocidad en puntos, nos puede dar un horizonte muchísimo más fiable que nuestras estimaciones basadas en duración o esfuerzo (Vamos a tardar 1800 horas, o lo vamos a tener en 2 meses... qué escalofríos!!!)

Solución Mixta

Creo que en este post podéis encontrar una explicación perfecta de mi opinión. Me parece una solución equilibrada y es utilizar ambas métricas para diferentes necesidades.

Estimar las historias del PRODUCT BACKLOG con Story Points, que nos ayuden a estimar la complejidad de la historia, pero una vez aplicamos el breakdown en tareas y trabajamos en el SPRINT PLAN utilizar horas en base a esfuerzo.

Cito textualmente:

No discussion of story points. No discussion of velocity. It’s just about commitment and we decide how much we can commit to by breaking product backlog items into tasks and estimating each. This is called commitment-driven sprint planning.

Poco más me queda añadir

El año ágil en Tritium

La adopción de las metodologías ágiles en Tritium sigue un paso lento pero firme, durante el presente año, integrando la herramienta Assembla, hemos dado un primer salto de calidad.

Además de herramientas imprescindibles como son el repositorio de código, la wiki (que aún infra-utilizamos) la herramienta de management ha empezado a dar sus frutos.

Iniciamos el proceso de adopción con SPRINTS de 14 días, que redujimos a 7 por que estamos en un momento de iteración de producto que nos exige más flexibilidad en la adopción de cambios de prioridad y liberación de nuevas features.

Ese cambio, pese a que inicialmente supuso un aumento de tensión, fue algo positivo que ahora está completamente adoptado por el equipo.

Es habitual que planifiquemos siguiendo con las recomendaciones de SCRUMBAN, dejando lacks de tiempo para incidencias/imprevistos y investigación (si es necesario) por lo que nuestro límite de planificación suele rondar las 120h

En estos meses, dado nuestro volumen de equipo, y el trabajo tan continuo, no ha sido necesaria la adopción de los StandUp meeting, pero sucederá tarde o temprano.

Otra de las conclusiones a las que hemos llegado es que disponer de un SPRINT Cardwall digital es perfecto, compartes la situación a tiempo real del SPRINT, es distribuido (puedes consultarlo en casa o en cualquier lugar) y además actualiza en tiempo real en función del reporting de dedicación de cada persona.

En cambio, no resulta tan práctico y tenemos sin duda que mejorar, la toma de decisiones en la definición de nuevos sprint PLAN. Tenemos que trabajar más en mejorar el PRODUCT BACKLOG para tener toda la información en los SPRINT meetings.

Y para este próximo año vamos a crear un STORY BOARD que represente el product backlog de Force Manager, y que nos ayude en la priorización y la toma de decisiones.

Otro de los objetivos que nos marcamos para este inicio de 2012 es el despliegue de un entorno de integración y la configuración de un entorno de integración continua.

Step by step ...

Referencias:

Un fuerte abrazo,

Nuevos horizontes - Tritium Software

noreply@blogger.com (Iván) — Wed, 06 Jul 2011 13:29:14 PDT

Bueno, llevaba semanas queriendo escribir este artículo, pero no había encontrado el momento.

Como alguno de vosotros ya sabéis hace ya unas semanas que acepté un nuevo reto profesional, después de una larga y, por que no decirlo, dura pausa. Durante este tiempo he aprovechado para estudiar mucho, cumplir una de mis cuentas pendientes - User Agile Development), y cuidarme menos de lo que me habría buscado.

La incertidumbre te atenaza, más de lo que jamás habría pensado.

He participado en multitud de, agotadores, procesos de selección, y la decisión no fue nada fácil. Me siento muy afortunado, en primer lugar por poder haber podido decidir, y además por haber encontrado un lugar en el que, pese que voy a currar de lo lindo (es lo que quiero, lo que me gusta, y lo que me llena) voy a seguir trabajando en un start-up, dentro del ámbito de producto, y teniendo la oportunidad de crear y liderar el equipo de trabajo.

Tritium Software, S.L. es una compañía catalana, que acaba de cerrar su primera ronda de financiación, y que dispone de un producto CRM (para los no iniciados - una herramienta de gestión de clientes (Customer Relationship Management) ofreciendo una clara orientación a movilidad, ofreciendo clientes para iPhone, Android, BlackBerry y próximamente para iPad y Playbook.)

Como buena startup todos tenemos que empujar en todas direcciones, pero mi responsabilidad es la de dirigir el equipo de producción, consolidar el uso de buenas prácticas (basándome dentro de lo posible en metodologías ágiles, perfectas en este contexto)

Para ello, después de evaluar diferentes herramientas TeamBox, GoPlan, Assembla ... y como no JIRA, la decisión ha sido continuar con el mismo sistema que utilizamos en Grouxo, y no es otro que Assembla.

Los motivos son los siguientes:

Ofrece un repositorio SVN integrado con la herramienta colaborativa. Git es una propuesta de lo más interesante, y mucho más potente que SVN, pero exige cierta disciplina y experiencia en el uso de repositorios (Algo que no tiene por que estar asegurado en nuestro contexto)
Dispones de herramienta wiki integrada en el portal
Dispones de issue traking totalmente adaptado para metodologías ágiles, con un Cardwall que hace las delicias como un perfecto Task Board, unas gráficas BurnChart suficientes, y una sección StandUp para los informes matinales de actividad de todo el equipo
Además los planes básicos, aunque se me antojan algo limitados ya que solo permiten 1 espacio y 1 Gb de espacio, tienen un precio de lo más razonable 9$ /mes (90$ / año)

A medio/largo plazo mi opción predilecta es JIRA, que en su versión cloud integra confluence, greenhopper, subversion, fisheye, bamboo ... es decir lo ideal para tener un entorno de integración continua completo. No se si es buena opción en cloud o gestionado por nosotros mismos si disponemos de los recursos necesarios, eso nos permitiría por ejemplo incluir Sonar, etc.

En fin, una aventura muy interesante.

Estamos en un momento de consolidación/constitución del equipo, no dudes en hacernos llegar tu CV si te gusta la iniciativa y consideras que puedes aportar tu granito de arena.

Un abrazo,

Actualidad emprendedora / Ágil

noreply@blogger.com (Iván) — Wed, 08 Jun 2011 06:18:04 PDT

Hace ya unos días leía en el interesantísimo blog Pensamientos Ágiles una noticia relativa a la creación de un proyecto web nacional para dar soporte a la gestión ágil.

El proyecto es Scrumrf que permite mediante en entorno web gestionar proyectos ágiles. Vale la pena echar un vistazo. El artículo completo de pensamientos ágiles aquí.

A esto hay que añadir la noticia, en otro orden de magnitud, de Rally Software, la podéis leer en TechCrunch, compañía con un foco total en la creación de aplicaciones para la gestión del ciclo de vida ágil ... mmmm interesante ¿verdad?

Podéis obtener más información de esta compañía en su web Rallydev.com

Saludos,

Metodologías Ágiles

noreply@blogger.com (Iván) — Thu, 02 Jun 2011 04:11:40 PDT

En anteriores artículos hemos repasado algunas metodologías ágiles, en realidad he hablado de un par alejándome de las más populares. Y estoy reflexionando sobre un artículo en relación a cómo plantearía yo la adopción de las metodologías ágiles en una organización. En un tema complejo, pero apasionante, que muestra que lo importante es conocer lo que te pueden aportar las diferentes metodologías ágiles, y tradicionales diría yo, para ir creando el escenario optimizado para tu organización.

Es decir, de la siguiente lista, lo importante no es elegir uno, si no entender que nos puede aportar cada uno de ellos, según nuestra situación puntual.

SCRUM
XP
Crystal
Lean Software Development - Descripción en el Blog
Kanban - Descripción en el Blog
Dynamic System Development Method (DSDM)
Feature-Driven Development (FDD)
SCRUMBAN
User-Center Design - Artículos previos

SCRUM

SCRUM es problablemente una de las metodologías ágiles que más se han extendido, en la última presentación que vi de Angel Medinilla su nivel de adopción se situaba entorno al 58%, más un 20% más fruto de híbridos con KANBAN o XP.

Fue creada por Ken Schwaber y Jeff Sutherland. Que publicaron una breve colección de prácticas o guías a seguir, y una relación de roles predefinidos, imponiendose rápidamente en un standard de facto dentro de la gestión ágil.

La simplicidad y sencillez de sus prácticas facilitan eses interés y justifica la fácil adopción, pese a necesitar en algunos casos ser ampliado o reforzado en ciertos ámbitos mediante otras metodologías, algo para lo que, cómo comentaba en la introducción, nos debe parecer parece perfecto.

The Scrum Alliance Website
Scrum (development) (Wikipedia)
Mountain Goat Software
Agile Software Development with Scrum (Ken Schwaber & Mike Beedle)

EXTREME PROGRAMMING - XP

XP creado originalmente por Kent Beck, ha sido y sigue siendo uno de las más destacadas metodologías ágiles, especialmente orientada al desarrollo, cosa que lo hace especialmente complementario a otros frameworks más genéricos que abarcan el ciclo de vida completo del desarrollo software.

Al igual que el resto de metodologías ágiles promueve la implicación del cliente, iteraciones rápidas que faciliten el feed-back, testing y planificación continuada, etc.

Los cuatro pilares de XP son:

Simplicidad
Comunicación
Feedback
Valentía

Las 12 prácticas que promueve son las siguientes, algunas de ellas cambiaron por completo el desarrollo, y ahora forman parte de cualquier equipo de desarrollo preocupado por la excelencia y la calidad del producto:

Planning Game
Small Releases
Customer Acceptance Tests
Simple Design
Pair Programming
Test-Driven Development
Refactoring
Continuous Integration
Collective Code Ownership
Coding Standards
Metaphor and Sustainable Pace

Algunas referencias:

Extreme Programming Website
What is Extreme Programming (xprogramming.com)
Extreme Programming (Wikipedia)
"Extreme Programming Explained - Embrace Change (Kent Beck)

CRYSTAL

Es una familia de metodologías de desarrollo creadas por Alistair Cockburn, se auto denominan autoadaptables, la más reconocida es Crystal Clear, personalmente no he trabajado nunca con ellas en ninguna de mis anteriores experiencias.

Crystal recomienda una metodología específica en función de cada proyecto particular, basándose en tres factores críticos:

Densidad de comunicación (Volumen de personas involucradas)
Criticidad del sistema
Priorización del proyecto

Crystal está fundamentalmente enfocada en la comunicación, con una especial atención en la interacción, la comunidad, el equipo, las personas y sus perfiles y habilidades.

Las diferentes metodologías Crystal se basan en los dos siguientes fundamentos:

Los equipos pueden racionalizar los procesos a medida que van madurando e integrándose
Los proyectos son únicos y dinámicos. Y requieren de métodos específicamente diseñados para cada esfuerzo.

Alguna referencia:

Crystal Methodologies (Alistair Cockburn)
Crystal Clear Software Development (Wikipedia)
Crystal Clear: A Human-Powered Methodology for Small Teams (Alistair Cockburn)

DYNAMIC SYSTEM DEVELOPMENT METHOD - DSDM

Está considerada una de las metodologías ágiles iniciales, desarrollada en 1994 por DSDM Consortium. Según sus propios creadores se define cómo:

Un marco de ejecución de proyectos que ayuda al desarrollo y suministro de soluciones de negocio en plazos ajustados y presupuestos fijos.

El enfoque se basa en entender que los clientes no pueden predecir en detalle el trabajo que se espera que cubra su producto a priori. Por lo que plantea una metodología incremental e iterativa en común evidentemente con las metodologías ágiles.

Sigue un modelo de Consorcio, donde los miembros pagan una cuota anual por seguir acreditados en el uso de la metodología ( 2.000$ / año)

As such, it has the most developed training, support, templates, tools, and accreditation services of the agile methods (although Scrum, with its Scrum Master series of certifications, is close).

El método consiste en tres fases iterativas que se repiten: Modeling, Design-Build, e Implementation. Contrasta con otras metodologías ágiles en lo estricto de sus timeboxes, las funcionalidades pueden cambiar, pero no la fecha de entrega.

DSDM provee un sistema de priorización, todavía no hemos hablado en el Blog de MosCoW, lo haremos pronto, las categorías propuestas son:

Must have
Should have
Could have
Want to have

Siendo importante que las prioridades se asignen en función del valor de negocio que aportan al cliente, para mejorar la eficiencia y la simplicidad del desarrollo.

DSDM está basado en 9 principios clave que giran principalmente al rededor que las necesidades y el valor para el negocio del cliente, participación activa del usuario, equipos empowered, entregas frecuentes, testing integrado, colaboración con promotores.

Siendo la primera metodología que hace referencia al criterio de priorización en favor del valor para el cliente, y la regla del 80/20 (El 20% del desarrollo aporta el 80% del valor para el cliente)

Algunas referencias:

DSDM Website
DSDM: Business Focused Development (DSDM Consortium)

FEATURE-DRIVEN DEVELOPMENT (FDD)

Es una metodología de desarrollo software propuesta por Jeff De Luca y Peter Coad’s. Que se diferencia del resto de métodos ágiles por un diseño up-front design.

Se considera una metodología model-driven, de iteraciones cortas. Se establece un modelo global de dos semanas, de diseño de funcionalidad / construcción de funcionalidad. Intentado que estas sean pequeñas y de un valor tangile, visible, para el cliente.

Se basa en 8 prácticas:

Domain Object Modeling
Developing by Feature
Component/Class Ownership
Feature Teams, Inspections
Configuration Management
Regular Builds
Visibility of Progress and Results

Algunas referencias:

Feature Driven Development (Wikipedia)
Feature Driven Development (dedicated site)
A Practical Guide to Feature-Driven Development (Stephen R. Palmer and John M. Felsing)

SCRUMBAN

Es una matedología propuesta por Angel Medinilla (Al menos yo la he conocido a través suyo), me parece una propuesta muy interesante que refleja muchas de las necesidades de la mayoría de organizaciones IT locales. Nadie mejor que él, o en este caso su matrial didáctico para presentárnoslo.

Me gustaría estudiar qué conceptos del user-center design podemos incorporar, aunque algunos ya están reflejados. Pero definitivamente me parece un punto de partida inmejorable.

110506 - scrumban - XP2011

View more presentations from Proyectalis

Referencias

AgileSHERPA - Artículo
NOOP.nl - Artículo podéis ver una relación mucho más extensa que la expuesta aquí
Stevens Balagan - Artículo
TechRepublic - Artículo

Métricas ágiles

noreply@blogger.com (Iván) — Thu, 26 May 2011 01:06:07 PDT

Uno de los puntos fundamentales cuando nuestra organización quiere adoptar una gestión del cambio, sea cual sea la metodología a implantar, son las métricas.

Al igual que suceden con las KPI en el ámbito Internet, disponer de métricas tiene infinitos beneficios, nos permitirá identificar oportunidades de mejora, identificar una reducción del rendimiento, controlar la calidad, controlar la satisfacción...

He leído al respecto esta interesante herramienta, con una categorización desde mi punto de vista acerta, aunque nada fácil, como veremos a continuación.

La verdad es que la categorización es muy adecuada, pero voy a centrarme en las que considero más interesantes.

Velocidad. La velocidad expresa la capacidad de esfuerzo productivo que tenemos a cada sprint, son las tareas que se han finalizado satisfactoriamente en el sprint, y finalizadas quiere decir finalizadas, testeadas y, a ser posible, validadas por el cliente/product owner.
Focus factor. Una métrica a trabajar con cariño, pero que es fundamental en nuestra adopción de una metodología ágil. Es el resultado de dividir las horas que se esperaba durasen las tareas de dicho sprint, entre las horas reales que ha dedicado el equipo. Es medir la diferencia entre esfuerzo y duración, generalmente provocado por multi-asignación, por interrupciones, etc. en ningún caso por falta de interés o profesionalidad (de ahí que alerte que debe tratarse con cariño) En cualquier caso, es una métrica, un porcentaje, que nos alerta de oportunidades de mejora ... quizá el cliente está saltando el product owner, quizá el SAU utiliza en exceso el equipo técnico, quizá la oficina no ayuda a la concentración ... etc
Earned Value. Teniendo en cuenta la relevancia que le da el manifiesto ágil al valor que aportamos al cliente, es interesante medir qué valor generamos al cliente para cada iteración, es habitual que este valor sea resultado de sumar los valores de prioridad que ha dado el usuario a los user stories que se han liberado durante el Sprint.
Número de incidencias detectadas por el cliente. Es un valor complejo de gestionar, y sobretodo es difícil que lo podamos tener en consideración en las retrospectivas, por que la detección de una incidencia no tiene un espacio de tiempo definido. En cualquier caso, és una métrica de referencia que nos puede ayudar a fomentar en el equipo la preocupación relativa a la calidad de lo producido. Y alertarnos de problemas en la gestión de la calidad interna. Si disponemos de una herramienta de gestión (por ejemplo JIRA) que permita al usuario registrar incidencias, el cálculo será más sencillo.
Número de incidencias detectadas por el equipo. De igual modo a la métrica anterior, puede llegar a ser un dato relevante, puede indicar relajación en el control de calidad, o necesidad de mejora de los mecanismos automáticos.
Tiempo de despliegue por release. Tiempo requerido para tener en producción una release, es una métrica que nos puede indicar si necesitamos un entorno de integración contínua, o si este está funcionando o dejando de funcionar adecuadamente
Calidad del código. Aplicación de herramientas como PMD, CheckStyle o el famoso Sonar qué también se estuvo evaluando durante mi colaboración con Alliaria/IN2
Lead Time (Ciclo de vida de una petición) Tiempo que pasa desde que recibimos una nueva petición, por ejemplo un cambio, hasta que este está en producción. Esta métrica nos da la agilidad real del equipo. Pero es importante poder discriminar por urgencia o importancia del cambio.

U otras igualmente importantes que nos ayuden a garantizar el ritmo de trabajo (dedicación del equipo, felicidad del equipo, ... )

----- Update 26/05/2011

Un concepto interesante a introducir, aunque su aplicación como he podido comprobar durante mi investigación, ha sido el "Value Stream Mapping" propuesto por Lean Development. Es un concepto que invita a la reflexión del valor que se aporta durante la cadena productiva de cara a la primera regla de lean ... elimina residuos

Veamos que métricas o conceptos propone:

Touch Time & Cycle Time. Touch: Tiempo que dedica el equipo a trabajar en una tarea, pensar, diseñar, desarrollar, testing, etc. sin incluir emails, coffee time, y otras interrupciones. En resumen esfuerzo. Cycle: Hace referencia a la suma del tiempo desde que recibimos una tarea hasta que la liberamos completamente. Es decir duración (Es una métrica muy similar al focus factor)
Value Added & Non Value Added. A la finalización del sprint, que tareas que hemos ejecutado representan un valor para el cliente, y cuales no. Nos servirá para medir cuanto estamos focalizado a cliente (Pero no creo que nos deba obsesionar en las fases iniciales, sobretodo en proyectos grandes que nos exigen cierto trabajo interno de arquitectura)
Be Brutal & Be Conservative. Es la definición de cómo te vas a posicionar a la hora de decidir si una tarea es o no de valor añadido. Así como para decidir el Cycle y Touch time aceptable para una tarea (si es que podemos llegar a definirlo)

----- End

En resumen, toda métrica que nos aporte control a la hora de medir como de beneficiosa está siendo la adopción de una mejora en nuestro proceso de trabajo, es de interés. O planteándolo de otro modo, sí ... no sabemos como de buena va a ser una medida o decisión ... si no vamos a poder medir su beneficio, tenemos un problema!!

Pero, tampoco es importante obsersionarse con tener todas las métricas, las retrospectivas nos daran ese aliento de mejora, y cada organización necesita unas métricas específicas.

Podéis encontrar una relación bastante completa en Proyectos ágiles

Referencias

Appropriate Agile Mesurement | Article
Principles for Agile Metrics | Blog
Se hace camino al Andar | Blog
ABetterTeam | Metrics Tool
Proyectos Ágiles | Blog
Presentación SlideShare | Deepak Mittal
Metrics in Agile Development | Blog

Saludos,

Kanban

noreply@blogger.com (Iván) — Wed, 25 May 2011 10:35:06 PDT

El Kanban tiene su origen en el Lean, por lo que de algún modo también proviene del Lean Manufacturing, comparte los conceptos de producto backlog, de user stories, pero no el concepto de iteración. Se considera un subsistema del Just-In-Time.

Contrariamente aplica el concepto WIP (Work In Progress) la unidad de gestión es el trabajo actual, y antes de iniciar el trabajo siguiente se vuelve a analizar la prioridad para iniciar siempre el trabajo más prioritario de toda la pila restante.

Es un concepto aplicado más en entornos de mantenimiento, que en entornos de desarrollo de productos. Personalmente he vivido una integración de Kanban en Alliaria,/IN2 dónde todos los equipos en su sprint almacenaban un buffer de tiempo (% de su capacidad productiva) para la posible inclusión de tareas más prioritarias (incidencias, estimaciones, participación en propuestas, cambios de prioridad). El tamaño del buffer variaba en función del equipo, pudiendo ser casi del 100% para equipos de mantenimiento.

Kanban además propone un modelo en el que las tarjetas, como explica perfectamente Medinilla en su artículo, son testigos que se transfieren entre los miembros del equipo a medida que van cubriendo el lifecycle del proceso.

Si evaluamos siguiendo las recomendaciones Lean, la verdad es que Kanban propone un modelo que reduce mucho la burocracia, sin meetings diarios, sin sprints etc. la verdad es que si tienes una organización suficientemente madura como para aplicarlo ... el nivel de desperdicio que consigues suprimir es elevadísimo.

Personalmente creo que puede llegar a ser muy arriesgado, por la tendencia al Kaos que tenemos dentro de los equipos de desarrollo. Y que es posible que requiera perfiles muy Seniors.

En Programania se hace referencia a esta ilustración gráfica, de lo más interesante, que podéis encontrar en el Blog de Henrik Kniberg's.

Otras consideraciones

Por último me gustaría recomendaros el siguiente artículo de Programania, es muy interesante. Podéis verlo aquí

Referencias

Ángel Medinilla - Presión Blogosférica. Kanban vs SCRUM
Wikilearning.com - El Kanban
Programania - Desarrollo ágil con Kanban
Luis Bonilla - Introducción al sistema Kanban
Henrik Kniberg's - On day in Kanban land

Estimación de esfuerzo

noreply@blogger.com (Iván) — Wed, 25 May 2011 00:13:24 PDT

Uno de los puntos críticos de nuestra profesión, y una de la fuentes mayores de problemas es la estimación, existen muchos factores de riesgo, rotación de los equipos, trabajo con tecnologías nuevas, falta de procedimientos claros a la hora de estimas, sin olvidar que en ocasiones el alcance del proyecto lo marca el presupuesto de licitación.

La importancia del esfuerzo

En general todas se basan en el tiempo que puede durar una tarea, y en ese punto es donde radica la diferencia de nuevas propuestas de estimación. Dado que dos tareas una fácil y una de dificultad máxima pueden tardar lo mismo en tiempo ... pero ¿Tiene sentido a nivel de planificación que la consideremos igual a nivel de esfuerzo? La respuesta es NO

Uno de los problemas habituales es que cuando desarrollamos nos resulta difícil predecir cuanto tiempo va a necesitar la tarea. Más si cabe con variables inciertas como el nivel de interrupción que se va a tener, si va a paralelizarse con otras tareas, etc.

Una primera recomendación es estimar en esfuerzo y no en duración.

La velocidad

La velocidad en sí misma es una métrica beneficiosa para el equipo, y es importante no variar la fecha de finalización de una iteración o sprint, ni contabilizar en la velocidad tareas que no esten "DONE DONE", para que la métrica tenga ese impacto positivo indirecto.

En primer lugar para conseguir si el equipo trabaja por debajo de lo previsto, la velocidad se ajusta para la siguiente Iteración, adaptándose por tanto a la capacidad del equipo. Y a la inversa, en el caso de conseguir más historias de las previstas.

No hay que perseguir con desmesura una velocidad excesiva como premio, recordemos que uno de los principios ágiles es la de tener un ritmo de trabajo sostenible!!

La estimación

Existe cierta ansiedad compartida a la hora de que un miembro del equipo de una estimación, la realidad es que la mejor manera de hacer buenas estimaciones es hacer muchas estimaciones y seguramente equivocarte un un porcentaje elevado de las mismas. Aplicando Slack si el riesgo es excesivo para conseguir los compromisos adquiridos.

Es por ello que resulta importante que todo el equipo participe en las estimaciones, es importante que se justifiquen, ya que fomenta la compartición de conocimiento y el razonamiento de la valoración.
Volviendo a la hacer referencia al esfuerzo, es una buena opción valorar de manera optimista y considerando que no van a producirse interrupciones, durante el proyecto nuestra experiencia nos permitirá ajustar mejor en base a la situación real del proyecto. Y como recomendación de granularidad siempre mejor horas que días.

Planning Poker

Considerando los puntos anteriores, así como la influencia que tienen el product owner, el cliente, o los miembros más séniors del equipo de desarrollo, uno de los procesos más consolidados en la estimación es el denominado Planning Poker.

El proceso es sencillo:

El product owner o cliente enuncia la funcionalidad
Todos los presentes muestran sus estimaciones simultáneamente con una carta, pizarra, papel ...
Se debaten las diferencias de estimación, y se vuelve a realizar la estimación hasta que las estimaciones del equipo se alinean

Este método funciona por lo divertido que puede llegar a ser, tratándose de un juego, pero también por la aportación intelectual que comparten los recursos y el cliente.

Esta técnica puede ser utilizada para definir los story points, necesarios para que el Product Owner priorice su Product Backlog y defina que funcionalidades van a incorporarse al Sprint. Y también para la estimación propia de cada tarea del Sprint Backlog.

Referencias

James Shore - Estimating
VersionOne - Feature Estimation
AgileSoftwareDevelopment - Estimation
ScrumMethodology - Estimation and Story Points
ProyectosAgiles - Estimación y planificación ágil
Presentación de SlideShare de estimación con SCRUM

Saludos,

Lean software development

noreply@blogger.com (Iván) — Wed, 11 May 2011 08:51:59 PDT

Una de las "metodologías" o interpretaciones del manifiesto ágil, es Lean software development, no es tan conocida como XP o SCRUM, pero suele integrase con estas dos para complementarla en la vida real. Cuando no encontramos solución a nuestros problemas en XP, SCRUM, etc por ejemplo.

Su origen es fruto del Leam Manufacturing, adaptado del sistema de producción de Toyota, de donde también se ha adoptado Kanban.

Dedicaremos algunos artículos a enumerar y reflexionar sobre los principios de las "metodologías" más conocidas, con el objetivo de ver que nos puede ser más interesante para cada caso concreto.

¿Qué es Lean software development?

Como siempre, repasemos de wiki-definició: Lean sofware development, siguiendo con su versión original, busca eliminar los desperdicios en la producción, originalmente se hablaba de:

sobreproducción
tiempo de espera
transporte
exceso de procesado
inventario
movimiento
defectos

Principios de Lean

Veamos como trasladamos esto al mundo Software. Los siete principios del Lean Software Development son:

Eliminar los desperdicios. Es decir todo aquello que no añade valor al cliente debe ser eliminado (funcionalidades innecesarias, burocracia, comunicación interna lenta ...) Si una actividad del proceso de desarrollo puede ser excluida ... es un residuo. Pero también lo es la baja calidad de software, la gestión extra ... Podemos aplicar la técnica stream mapping para identificar el flujo de valor óptimo. Siendo además un proceso iterativo (Parece una métrica candidata a ser incluida en las retrospectivas ¿no creéis? ;D )
Ampliar el aprendizaje. Debemos fomentar el aprendizaje del equipo, dando mayor relevancia a la creación y ejecución de test, que a la elaboración de documentación o planificación. Las iteraciones cortas que permiten interacción con el usuario, la presentación de pantallas al usuario para recibir su feed-back, nos repercuten en un conocimiento que enriquece al equipo (es un punto claramente promovido por user-center design, así que ya es algo que teníamos en cuenta, pero que además vemos una reflexión del beneficio que tiene internamente)
Decidir lo más tarde posible. Ante la incertidumbre se deben tomar decisiones, que en muchos casos son apuestas arriesgadas puesto que no se basan en hechos, si no en estimaciones que nos llevan a pronósticos inciertos. Atrasar todo lo posible estas decisiones nos permitirá reducir la incertidumbre durante la propia vida del proyecto, durante la propia auto-definición del cliente y de sus necesidades.
Reaccionar lo antes posible. Menores iteraciones, más pronto se recibe el feed-back, y se convierte en aprendizaje. Y nos permite ofrecer la posibilidad al cliente de expresar sus nuevas necesidades, así como de reaccionar y reflejar los cambios en el trabajo previsto. Personalmente creo que hay que encontrar un equilibrio las reuniones de definición de Sprint y de retrospectiva no son tan ágiles como podemos creer a priori, y suponen precisamente ese tipo de burocracia a la que hacíamos referencia en el primer punto
Potencial el equipo. Dar espacio a tu equipo para que aporte opiniones, ellos son los que más en contacto están con la tecnología y con el cliente. Además de promover su crecimiento, fomentas su compromiso, implicación y motivación. El gestor en muchas ocasiones debe ser un facilitador del equipo que le rodea y fomentar el espíritu de equipo.
Crear con integridad y calidad interna. Es un concepto complejo que viene a referirse a la integridad conceptual de la solución final, que sea homogénea, y alineada a la necesidad del cliente. Para ello es conveniente una comunicación fluida, por encima de la generación de vasta documentación que permita el aislamiento del equipo. Así como dar espacio a la refactorización, a la filosofía del cambio en relación a la incorporación de mejoras.
Visión de conjunto / Mejora el proceso. "Piensa en grande, actúa en pequeño, equivócate rápido; aprende con rapidez" es una de las frases que encontramos en la definición de éste punto. Alienar a todos los players involucrados en el proyecto en esta filosofía es clave para el éxito del mismo. Vamos, que no pensemos en utilizarlo como excusa

¿Qué nos aporta Lean como valor añadido respecto al resto?

Algunas organizaciones ven claramente las ventajas de las metodologías ágiles, y intentar cambiar sus organizaciones basadas en metodologías estrictas, como pueden ser CMMI, METRICA, ESPRIT, etc ... a metodologías ágiles.

Pero hay que ir con cariño, y por eso dedicaré un algún que otro artículo al caso concreto de las grandes organizaciones. Tenemos que tener clara la diferencia entre normas a seguir, doctrina ... a unas guías o recomendaciones.

Las metodologías ágiles son guías, y en ningún caso son validas para todas las situaciones, para todas las circunstancias, y todos los contextos. Simplemente aplicando sobre nuestra implementación ágil el primer principio Lean, ya nos puede aportar un valor diferencial. En cada retrospectiva deberíamos analizar cuales de las actividades NO aportan valor y considerar su supresión.

Creo personalmente que el resto de principios pueden ser inherentes en equipos ágiles, aunque la reflexión sobre potencial al equipo, especialmente a algún que otro HiPPo ...

;-)

Referencias

Lean Institute
ProyectoAgiles.org - Principios de Lean Software Development

Saludos,

User Stories

noreply@blogger.com (Iván) — Tue, 10 May 2011 13:08:55 PDT

Otra de las "herramientas" clave de las metodologías ágiles son las historias de usuario. Empecemos como habitualmente con su wiki-definición.

Podemos entender las historias de usuario como una representación de un requerimiento de software escrito en una o dos frases utilizando el lenguaje común del usuario.

Las historias de usuario son utilizadas para la especificación de requerimientos incluyendo, a ser posible, las condiciones de aceptación, las pruebas de validación, para dar como buena la historia.

Podemos entrar en detalles cómo deben estar escritas por el usuario, deben poderse escribir en un post-it, o características similares que, pese a poder ser beneficiosas, para mi son superfluas (no estamos escribiendo un tweet ;D).

Para mi lo realmente importante, tal y como expresa Xavier Quesada en el post de proyectosagiles.org es que, una vez completada, representen un incremento de valor para el usuario. Y me parece importante por que establece la granuralidad con la que debemos considerar una historia, esa es la diferencia fundamental entre historia y tarea, para ser concretos.

¿Qué información debe contener?

Como viene siendo habitual en los artículos previos, no podemos dar una respuesta por valida para todas las situaciones. Simplemente una solución común y alguna reflexión que pueda ser de utilidad.

Identificador. Nos debe permitir identificar por ejemplo numéricamente la tarea, útil por ejemplo cuando necesitamos indicar dependencia entre historias
Nombre o Título de la historia, a ser posible una breve descripción del requisito
Valor de la historia para el cliente. En el plan de proyecto deberíamos tener una escala de valoraciones, al fin y al cabo nos ayudaran a resolver la prioridad de las tareas
Esfuerzo estimado, siguiendo las diferentes técnicas de estimación que presentaremos, debemos aportar un valor cuantitativo a la historia, este valor en base a la capacidad productiva del equipo, nos debe servir para analizar su incorporación al Sprint
Riesgo, no se trata de un campo utilizado siempre, en ocasiones podemos utilizar post-its de diferentes colores para diferencias su riesgo ... nos debe servir igualmente para intentar balancear el riesgo de cada Sprint
Prioridad, al igual que sucede con el riesgo, la prioridad debe venir definida de la reunión de definición de Sprint, y debe ayudar al equipo a seleccionar la siguiente historia a ejecutar del Sprint Backlog. Nos podemos por ejemplo ayudar de colores para diferenciar la prioridad de cada historia (En próximos artículos veremos el método de priorización MoSCoW)
Dependencia, relación de historias que deben ser finalizadas previamente al inicio de ésta, nos debe permitir identificar el camino crítico o potenciales bloqueos
Pruebas de validación, o condiciones de aceptación. Relación de pruebas de validación que debe cumplir el producto para dar como superada la historia

Veamos un ejemplo gráfico (imagen de la web Agile Modeling referenciada al final de post)

La planificación y la estimación

Las historias de usuario se definen durante la fase de captación de requisitos, de user research, pero también durante las fases de planificación y estimación.

Una vez finalizada la fase de captación de requisitos, disponemos de una lista de historias, el product backlog, que podemos ordenar por prioridad según el criterio del cliente.

El proceso disciplinado ágil recomienda aplicar la visión del iceberg, y diseñar con gran detalle los historias próximas (las más prioritarias) y en menor detalle las de baja prioridad, por ser más lejanas.

A cada finalización de sprint, cuando se detectan nuevas historias, estás son priorizadas e incorporadas al product backlog.

El ejercicio de planificación queda claramente representado en el siguiente esquema, que también podéis encontrar en Agile Modeling.

Una vez priorizado y planificado el product backlog, debemos volver a revisar las historias para su estimación, y debe ser el equipo de desarrollo el responsable de la estimación (veremos en próximos artículos diferentes métodos de estimación) a partir de las estimaciones de las historias más prioritarias, y de la capacidad disponible para el Sprint que vamos a iniciar, podremos definir el Sprint Backlog, es decir las historias objetivos para el siguiente Sprint.
Referencias:

Proyectosagiles.org - Introducción a la estimación y planificación ágil
Wiki - Definición de historia de usuario
Blog David Bonilla - Estructura de una historia de usuario
DEVNETTIPS - Definiendo historias de usuario en Scrum
Agile Modeling - Introduction to User Stories

Saludos,

LinkedIn discussions

noreply@blogger.com (Iván) — Mon, 09 May 2011 13:34:25 PDT

Estos días ha habido mucha actividad en LinkedIn, pero centrada en unos pocos hilos, hay uno especialmente que se lleva la palma:

Do you agree or disagree that Scrum is not Agile? - Una "feroz" conversación de un compañero que está viviendo una frustrante experiencia. Realmente interesante, por que cuando aparece la discrepancia es cuando más razonamientos se comparten
PMI is developing Agile certification - El Project Management Institute parece posicionarse con una certificación ágil
Agile self-organized teams – is the team self-organized or not? - Debate relativo a la autonomía de los equipos, tal y como debería ser según el manifiesto ágil

Seguiremos informando.

Saludos,

Burndown chart

noreply@blogger.com (Iván) — Mon, 09 May 2011 00:17:13 PDT

De vueltas con una de las herramientas ágiles más habituales, el diagrama burn down o diagrama de quemado, lo que sería una traducción literal poco afortundada, que podéis encontrar en la wiki. Vamos en tal caso a empezar con su definición:

Es una representación gráfica del trabajo por hacer en un proyecto en el tiempo.

Usualmente el trabajo remanente (Backlog) se muestra en el eje vertical y el tiempo
en el eje horizontal. Por lo que el diagrama representa el trabajo pendiente, útil para predecir el trabajo pendiente.

Ejemplo de Burndown chart que podéis encontrar en la wiki.

Se trata de una herramienta útil para no perder el punto de vista global del proyecto. Partes de una estimación de punto /horas disponibles desde inicio. Y del límite temporal disponible. A cada Sprint sabes el número de puntos que deberías completar para llegar en plazo (media o backlog ideal en la gráfica superior)

A este gráfico se le suele dar dos usos:

Product burndown - Visión global del producto, realizada a partir del product backlog
Sprint burndown - Visión concreta de cada Sprint

Existen herramientas digitales que permiten ver Burndow chart, una de las más conocidas es GreenHopper

Podemos ver imágenes en los siguientes puntos de esta útil herramienta integrada con JIRA.

Imágen del planning board, una herramienta que todavía no hemos utilizado en el blog y que, de no disponer de una herramienta digital, es posible que no lleguemos a utilizar.

El Task Board de GreenHooper muestra las tres columnas habituales como ya vimos en el artículo de StoryBoards

Imágen del Burndown Chart de GreenHooper, que permite ver si nos estamos desviando del plazo final del proyecto, la velocidad efectiva del equipo.

Por último el release board, que tampoco hemos explorado aún en el blog.

Las métricas

Estas herramientas nos deben permitir extraer insights de referencia para la salud del proyecto. Existen muchas, incluso infinitas como sucede con la analítica web, pero ¿cuales realmente nos ofrecen un valor? Pues como siempre depende de tu proyecto. Subjetivamente voy a enumerar las que más relevante me parecen a mi.

Earned Value. % de completitud del proyecto respecto a los requerimientos iniciales del mismo. Es importante especificar que damos como valor completado, debería ser objetivos validados por el cliente/usuario final.

En la gráfica superior podemos ver la inversa del Earned Value (% still to go) y además como visualizamos en el burn down chart la aparición de tareas no previstas gráficamente.

Development Speed. Una de las variables más complejas de analizar (por la incertidumbre con la que trabajamos) pero de las más útiles nos va a permitir re-planificar el proyecto a futuro, y prever si existe una desviación para su finalización. De igual modo, nos va a permitir ver el grado de aprendizaje que está obteniendo el equipo ... así debería ser, debería incrementarse la velocidad de desarrollo.
En función de alguna incidencia o necesidad concreta podemos necesitar más métricas, pero estas dos pueden ser suficientes. En alguna situación podemos valorar económicamente los objetivos y obtener una métrica ROI, pero no creo que estén necesariamente dentro del ámbito de la gestión, así que dejaremos esos puntos para artículos más especializados.

Saludos,

User Agile development. Best practices

noreply@blogger.com (Iván) — Thu, 05 May 2011 09:29:54 PDT

Fruto de las muchas y recientes adopciones de las metodologías ágiles por parte de la industria, los partidarios de UCD han debido pensar en cómo plantear su integración. A continuación expongo una relación de buenas prácticas iniciadas por Patton en 2008, y que Pirkka Rannikko expone en su Tesis.

UCD debe adoptar la mentalidad ágil. Es imprescindible ese cambio de mentalidad de cascada a ágil para poder garantizar el éxito. Los expertos en UCD deben verse así mismos como miembros del equipo ágil.
UCD debe estar cerca del Product Owner. Deben trabajar cerca, incluso en algunos casos ser el product onwer. Ese camino ayudará a influenciar para que los objetivos del proyecto estén alineados con los usuarios
UCD debe estar físicamente. Es bueno que el especialista en UCD co-habite con el resto del equipo de desarrollo para enfatizar la buena comunicación entre ambos.
Cross-functional Team. El equipo debe participar de manera conjunta en todos los pasos del ciclo de vida, de manera complementaria, pero conjunta, para compartir el conocimiento del por qué en las tomas de decisiones.
Gestión común del proyecto. La gestión del proyecto debe ser común para todos, por lo que las tareas que no sean de desarrollo, deben igualmente romperse, estimar su velocidad. Esto unifica el modo de trabajo de todo, y facilita la gestión
Diseñar un programa de socios. Existen algunos usuarios del proyecto que participaran en las fases iniciales de estudio, o en las finales de validación, pero otros usuarios representativos pueden convertirse en 'socios' y comprometerse durante todo el proyecto, reclutar este tipo de usuarios es muy recomendable y ayuda la logística de los test de usabilidad
UCD trabajos previos de interfaz. Existen trabajos que pueden y deben adelantarse al inicio del desarrollo, en caso contrario pueden convertirse en cuello de botella, y crear riesgos indeseados. Requisitos de alto nivel, diseño conceptual de la solución, diseño UI inicial, incluso la guía de estilos.
Desacoplar investigación de usuario. Fuera del ciclo de vida ordinario del proyecto, se deben paralelizar algunas investigaciones de usuario, para adelantar o cubrir futuras necesidades del proyecto
Diseños pequeños / Just InTime. Los diseños se dividen en tareas menores, a ser realizadas incrementalmente tal y como sucede con historias de requisitos o funcionalidades. Para paralelizar trabajos de desarrollo y diseño en un mismo sprint. (Aunque sea en ciclos cruzados como hemos visto en anteriores artículos)
Desarrollo paralelo. Tal y como adelantamos en el punto anterior, el UCD trabaja en paralelo pero iniciando los diseños 1 o 2 sprints antes de su desarrollo.
Historias de usuario mejoradas. Las historias de usuario deben reflejar los requisitos de diseño y usabilidad, por lo que los criterios de aceptación deben incluirlos.
Solución enfocada a pruebas de usabilidad. Además de las pruebas automáticas unitarias y de integración, y además de las pruebas de validación, se deben incluir tempranas y periódicas pruebas de usabilidad. Se debe ayudar al equipo a solucionar de manera eficaz los problemas (RITE)

Como sucede con las metodologías ágiles en general, estamos hablando de guidelines, siento insistir mucho en este punto, pero es importante entender que no estamos hablando de reglas a seguir sí o sí, como pasaría con CMMI, por poner un ejemplo. Si no líneas maestras que deberás aplicar o no en función del equipo, el cliente, tu organización, etc.

Saludos,

User Agile development. Lifecycle

noreply@blogger.com (Iván) — Thu, 05 May 2011 04:09:03 PDT

Podríamos dividir los procesos UCD en cuatro momentos dentro del framework ágil.

Trabajo previo, investigaciones, analítica web, previa al inicio de la implementación
Trabajo específico del Sprint, diseños específicos y evaluaciones de usabilidad específicas
Trabajo paralelo a los objetivos estrictos del sprint, workshops con clientes, investigaciones adicionales, etc
Trabajo post-sprint, validación de usabilidad, re-diseño

Si analizamos el siguiente ejemplo de Nodder & Nielsen, vemos gráficamente esta integración.

La pregunta sería, si no puede ser muy arriesgado intentar diseñar el objetivo del sprint, durante el mismo Sprint. Evidentemente depende totalmente del proyecto, pero a priori lo podemos tomar como una buena práctica, para que el camino crítico del propio Sprint no sea excesivo.

También basándonos en gráficos de Nodder & Nielsen, el trabajo sería modelo funcionaría del siguiente modo.

Podemos entender los ciclos como sprints perfectamente, o como release, según convenga y hacer un breakdown acorde.

Lo importante es que la investigación se realiza 2 ciclos antes, el diseño 1 ciclo antes, se implementa, y un ciclo después se valida.

Para los primeros ciclos, como ya hemos comentado en alguna otra ocasión, el equipo de desarrollo se puede focalizar en solucionar retos tecnológicos de backend, funcionalidades de baja carga gráfica, pruebas de concepto de plug-ins o componentes, etc. O incluso para participar de manera conjunta el experto en usabilidad, usuarios, stakeholders y el equipo de desarrollo en un diseño común inicial, en los guidelines que van a marcar el producto.

¿Cómo sabemos si necesitamos iterar nuestro modelo?

Qué complejo verdad, cuando el bosque no te deja ver los árboles, algo va mal, pero no siempre es fácil identificar posibles soluciones.

Podemos enumerar cierta relación de síntomas a tener en consideración, como si de un análisis de riesgo se tratara, como mitigarlo depende de tu organización, del proyecto, y de toda la semántica que te rodea en general.

No tenemos tiempo suficiente de diseño. Diseñar es un ejercicio creativo, y en multitud de ocasiones no es fácil planificar y darle una estimación, sobretodo si es temporal. Si el diseño está en el camino crítico ... tenemos un problema, situaciones de bloqueos, cuellos de botella ... baja calidad (separar los ejercicios en sprints separados es muy razonable, así como revisar el tamaño de lo sprints)
El feedback de los usuarios, promotores no es el suficiente, no llega a tiempo, tan habitual como grave, creo que exige escalarlo a nivel de comité de dirección. La implicación de los usuarios es crítica en las metodologías ágiles
El experto en usabilidad no trabaja full-time, si además participa en las reuniones ... su capacidad de producción se reduce, y potencialmente la calidad de los diseños
Se ignora el feedback de los usuarios en revisiones, PELIGRO! Puede ser bien por falta de tiempo, falta de budget ... pero en cualquier caso las consecuencias pueden ser nefastas
Falta de visión de la imagen global. Esto es un punto muy habitual, y de los que más me preocupa en las metodologías ágiles, partir de una hoja de ruta con los sprints y lo que esperamos hacer a alto nivel, puede ser fundamental
Fallos de comunicación, o de interpretación de los diseños ... debemos implicar o comunicar adecuadamente los diseños al equipo de desarrollo.
Gestión de dependencias, gestión del camino crítico ... el SCRUM MASTER debe facilitar la gestión de dependencias en cada sprint, garantizando la ejecución secuencial de tareas en función de prioridades.

El ejercicio anterior, me parece curioso, pero poco realista, creo que está bien conocer los problemas que puedes tener, pero creo también que aplicar bien las retrospectivas, y escuchar y ver a tu equipo es la clave para identificar, y consensuar soluciones para estos problemas. Me parece muy adecuado aplicar ejercicios similares a las gestión de riesgos de las metodologías estándar.

Saludos,

Agile Story Board

noreply@blogger.com (Iván) — Wed, 04 May 2011 12:51:56 PDT

Empecemos por la definición de la wiki, un StoryBoard es una serie grande de viñetas que ordenan la narración de los hechos de una película. Se utiliza como planificación previa a la filmación de escenas y secuencias; en él se determina el tipo de encuadre y el ángulo de visión que se va a utilizar. Sirve cómo guia al director, no obstante este puede desglosar y segmentar su filmación sin seguir estrictamente el orden lógico de la trama.

Esta definición viene del mundo del cine, pero creo que nos sirve perfectamente para ilustrar su valor a la hora de ayudarnos en la gestión de un proyecto. Se trata de visualizar y compartir el grado de avance del proyecto en unos grandes gráficos mostrados en la pared de la habitación del equipo de proyecto.

Tienen una interpretación diferente para UCD y para AD, para UCD se trata de la definición de un flujo de navegación (User Interface Flow Diagrams) pero este post lo dedicaremos al StoryBoard de AD, los cuadros de mando ágiles. Dónde también los podemos conocer cómo Taks Board.

¿Qué tiene un StoryBoard?

Al igual que sucede con la metodología ágil en general, cada maestrillo tiene su librillo, es decir que cada organización y proyecto tienen personalizaciones y adaptaciones ad-hoc, una vez presentemos la estructura estándar compartiré algunas referencias concretas como ejemplos ilustrativos.

En general, suelen compartir lo siguiente:

Columnas básicas

Stories. Historias o Casos de Uso a desarrollar. Las historias se dividen en 1 o más tareas (breakdown(1)) que cambian de columna en función del siguiente ciclo de vida
ToDo. Tareas pendientes de ejecución
In Progress. Tareas iniciadas, en curso
Complete. Taras finalizadas

Filas. Una para cada historia

(1) La subdivisión de Entregas/Release, Stories y Tareas se ve muy cláramente en el siguiente esquema visual, propio de la estructuración Kanban, que también analizaremos en el Blog.

Evidentemente podemos complementarlo incluyendo una columna para indicar que están pendientes de verificación, o la estimación de horas, o lo que se más requerido para nuestro equipo. También puede ser interesante reflejar la prioridad y si existe alguna dependencia (aunque finalmente esto se traduce en prioridad / estar o no estar en el camino crítico)

¿Cuándo y cómo usar los StoryBoards?

Suele ser habitual que sean públicos, recordemos el compromiso de comunicación que tenemos, pese a todo, en ocasiones puede ser más interesante disponer de un StoryBoard digital, da privacidad, disponibilidad distribuida (por ejemplo si tenemos miembros que trabajan en otras sedes o remotamente) y por encima de todo trazabilidad y control histórico.

Un problema de tener ambos sistemas es que puede minimizar el impacto o la relevancia que le de el equipo al sistema. Y para que no se hospede una tendencia a delegar a las figuras de Scrum Master y Product Owner la gestión del estado del Sprint. O dedicarse únicamente a su versión digital, desactualizando hasta morir la versión visual.

Otra práctica discutible es obviar el StoryBoard, muchos equipos ágiles trabajan con track tools, no utilizando el StoryBoard, pierden de vista lo siguiente:

El StoryBoard ayuda a estar focalizado. Es la herramienta perfecta sobre la que realizar los daily meetings.
El StoryBoard muestra de manera evidente la realidad del proyecto, la velocidad de desarrollo del equipo, y el progreso completo del proyecto (Burndown chart)
Ayuda (para ello es imprescindible que sean digitales) a equipos remotos, para compartir el trabajo y reducir la complejidad, o la falta de contacto personal en esas situaciones
En resumen, es el jugador nº8 (Es que yo soy jugador de balonmano ;D )

Crear tu StoryBoard

Cómo os comentaba con anterioridad es vuestra obligación, como en todo en la vida, encontrar la configuración idonea para vuestro equipo, para vuestro proyecto, para el contexto concreto en el que os encontréis.

Existen equipos a los que les funciona trabajar con historias y sin tareas, o con bugs, las motivaciones son subjetivas y no debatibles, la velocidad te permite demostrar que es lo más conveniente para tu equipo, en caso contrario, después de la siguiente retrospectiva, pensar en soluciones y llevarlas a cabo durante el siguiente Sprint.

Os pongo un ejemplo interesante aquí

Ejemplos

Ejemplos gráficos de los muchos que podéis encontrar en Internet

El segundo de los ejemplos incluye un BurnDown Chart, que explicaremos específicamente en otro artículo.

Me parecen muy interesantes el artículo de Kenji Hiranabe y de manera especial todo el Blog de Xavier Quesada

Saludos,

LinkedIn discussions

noreply@blogger.com (Iván) — Tue, 03 May 2011 03:44:38 PDT

Estos días estoy siguiendo alguna que otra conversación interesante en LinkedIn. Periódicamente os iré reflejando aquí las que considero más interesantes.

Agile development in fixed-price projects. Super interesante hilo que refleja uno de los graves problemas que sufren compañías IT cuando intentan dar el salto al desarrollo ágil y abandonar sus metodologías clásicas en cascada
We started to us agile metodology a few months ago. Experiencia durante el proceso de implementación por parte de una compañía, con los habituales problemas de gestión del cambio
Is the role project manager in agile development dead?. Tachan!!!! La primera a la yugular, pero me parece una reflexión fantástica, si tenemos equipos auto-organizados, y aunque requieren de liderazgo y coaching/mentoring, el role de product owner en ocasiones puede ser más recomendable para un UCD expert, o un marketing guy ... ¿que pasa con el perfil project manager puro?

Saludos,

User Agile development. Is it posible?

noreply@blogger.com (Iván) — Tue, 03 May 2011 03:36:57 PDT

Existen diferentes propuestas existentes de la integración de ambas iniciativas, aunque lamento deciros que en realidad es un ejercicio que deberéis hacer para vuestra organización personalmente, o incluso en función del cliente y los recursos disponibles.

A partir de lo expuesto hasta la fecha, hay evidentes e interesantes goals compartidos, que podemos resumir con desarrollar software de calidad. En cualquier caso, quizá analizando sus diferencias obtengamos los puntos que debemos atar con cariño.

El proceso iterativo es uno de los puntos de divergencia que dificultan la integración de ambas metodologías, las metodologías ágiles buscan maximizar trabajo finalizado, por lo que entendemos la iteración como una entrega de software validado, y en la siguiente iteración se buscar incrementar la cantidad de software finalizado disponible. En el ámbito UCD el concepto iteración se basa en mostrar una versión ligera al usuario a ser madurada en las siguientes iteraciones, en función del feed-back recibido.

Aplicando diseños iterativos, e iniciar desarrollos en base a esos diseños no definitivos, nos conduce al camino del cambio continuo, algo que como todos sabemos penaliza enormemente.
Otro punto de divergencia es el usuario en las metodologías ágiles, el product owner es habitualmente un promotor o stakeholder seleccionado, pero no tiene por que ser un usuario final de la aplicación (Situación clara de riesgo) mientras que para UCD el usuario está entendido como el usuario final.

Es importante implicar a usuarios finales en la fase de diseño y de validación de la plataforma, por lo que parece recomendable reflejar las recomendaciones propuestas por UCD.
Definición de alcance. Una potencial situación de riesgo detectada en las metodologías ágiles, es que partimos de la premisa de encontrarnos en situaciones de baja definición, en los que esta agilidad nos ayuda a avanzar optimizando recursos. Pero no existe una clara definición de cómo elaborar detallados diseños.

Una de las reflexiones más interesantes que propone UCD, es la de a través de la fase de Consultoría o Análisis inicial poder discernir, diferenciar entre lo que el usuario quiere y lo que realmente necesita.

En las metodologías ágiles, en las que el cliente on-site es responsable de especificar las historias, corremos el riesgo de desarrollar un producto en base a "lo que el cliente quiere"

Una potencial solución es contratar un UCD expert y establecerlo como enlace entre los usuarios y el equipo de desarrollo. Parece otro buen punto de sinergia entre ambas iniciativas.
Diseño de front-end. Este gran punto de divergencia es crítico, está relacionado con alguno de los puntos anteriormente descritos. Y es la relevancia que le damos al diseño. Realizar diseños detallados estudiando las necesidades del cliente puede ralentizar la velocidad de producción, pero no hacerlo nos puede llevar a desarrollos que necesiten ser modificados con posterioridad (minimizando las mejoras aportadas por la metodología ágil)

Un posible punto de encuentro, pero a estudiar con mucho cariño, sería el de partir de un diseño de alto nivel, definir patrones de diseño o pantallas tipos, wireframes, guía de estilos y story boards, y renunciar al diseño detallado (a excepción de casos que realmente lo requieran)

Así mismo, debería considerarse oportuno iniciar los desarrollos por el back-end para dar tiempo maduración de los diseños, y las iteraciones de diseño se deberían finalizar siempre durante el mismo sprint, para ser coherentes con la metodología ágil.
Testing. Podríamos considerar un punto de divergencia también las fases de validación, pero considero que realmente la convergencia en este punto es clara. Las metodologías ágiles hablan de dos tipos o fases de test, los automatizados durante el desarrollo (unitarios e integración) y los de validación de usuario. Estos segundos serían perfectamente compatibles con los test de usabilidad que propone UCD.

Igualmente podríamos llegar a considerar los test de usabilidad sobre prototipos o wire-frames, dentro de cada sprint, los resultados del test deben intentar solucionarse dentro del sprint en su mayor parte (por ejemplo estableciendo un buffer KANBAN) o ampliando el backlog de release para próximos hitos.

Seguiremos analizando en detalle las vías de integración.

Saludos,

4 aplicaciones de management para iPad

noreply@blogger.com (Iván) — Sun, 01 May 2011 11:24:32 PDT

A estas alturas, siguiendo los principios ágiles, no hay que darle excesiva importancia a las herramientas, y sí a la comunicación, al equipo. En cualquier caso, me ha parecido interesante un artículo de la web de noticias readwriteweb.

Este portal ha evaluado las diferentes aplicaciones existente para la gestión de proyecto/producto y muestran las 4 que consideran mejores según sus criterios. Reflejando eso sí únicamente las disponibles para iOs, obviando las disponibles para otros sistemas tablet.

Son las siguientes:

Project Planner HD
Projector
SG Project
Trackerbot

Project Planner HD

Aplicación integrada con el servicio opensource de Gantt Project, del cual se puede importar y exportar archivos. exportar en PDF, gestión de múltiples tareas y proyectos simultáneos. Con un set de features de gestión, comunicación y monitorización de proyectos.

Podéis descargarla en iTunes (4,99€)

Más información

Projector

Projector es una aplicación disponible para dispositivos móviles iOS y escritorio. Lista para seguimiento de tareas, costes de un proyecto, totalmente orientada a aprovechar las capacidades de los dispositivos táctiles.

Su precio es de 23,99€

Más información

SG Project

SG Project es una herramienta está alineada con ofrecer una relación de herramientas dirigidas a la gestión de producto, integrado además con Microsoft Project.

Es extraño, por que siendo aplicaciones iOS sea compatible con Microsoft Project, que es un producto para el cual no existe versión compatible con iOS.

Su precio es de 7,99€

Más información

Trackerbot

Cliente para iOS que forma parte del proyecto PivotalTracker como SaaS. Es de sencilla gestión y igualmente optimizado para aplicaciones táctiles.

Más información

Espero que sea de vuestra utilidad, no dudéis en hacerme llegar sugerencias o nuevas herramientas de interés.

Saludos,

Agile Software Development - Conclusiones Pro's y Contra's

noreply@blogger.com (Iván) — Fri, 29 Apr 2011 02:56:47 PDT

Las metodologías de desarrollo ágil surgieron como remedio a los problemas vividos con métodos tradicionales. Focalizándose en reducir los riesgos de crear un mal producto por no trabajar bien los requerimientos con el cliente, no mostrar rápidamente resultados para obtener su feedback, estar predispuesto y preparado al cambio basado en ese feedback.

A partir de ahí, métricas de calidad como la integración continua, orientación del código al test, etc. que bien pueden tener cabida en un modelo tradicional.

Inherentemente las metodologías ágiles mejoran el control del proyecto, para gestores y clientes. Pero también enfatizan la visibilidad del grado de avance para el equipo, algo igualmente beneficioso.

Así mismo, promueve un elevado de comunicación mediante organización de equipos unidos, reuniones diarias, y posteriores a cada hito de interés (sprint, entrega, etc) haciendo transparente la situación del proyecto y facilitando una correcta toma de decisiones. Anticipar el feedback del cliente reduce el coste y el impacto, incluso diría yo el desgaste, que supone identificarlo a posteriori.

Según una encuesta de VersionOne 2008 la percepción de beneficio se centra en puntos como:

Mejora de la visibilidad del proyecto
Mejora la moral del equipo
Mejora de la productividad
Simplificación del proceso de desarrollo
Mejora de la calidad, la mantenibilidad del código
Mejora la alineación entre producción y negocio
Acelera el time-to-market
Reducción del riesgo
Mejora la capacidad de gestión en cambios
Mejora las buenas prácticas de Ingeniería

¿Hay puntos negativos o críticas?

Veamos una enumeración de puntos:

La auto-organización de los equipos, es efectiva a nivel de proyecto ... lo que puede dificultar la optimización a nivel de organización, si la forman más de un equipo.
Así mismo en proyectos de elevada exigencia de rendimiento, donde el diseño inicial de arquitectura es crítico en relación al rendimiento posterior, no encontramos un reflejo claro formalmente de como integrar esta fase en un modelo iterativo orientado a dar visibilidad desde el minuto 0
Personalmente, en los proyectos con un presupuesto inicialmente pactado, gestionar las expectativas del cliente en relación al número de iteraciones disponibles, y no perder de vista el alcance global de la solución vs. la recogida de feedback para mejoras de la solución, resulta ciertamente inquietante
Otro punto a tener en consideración, mencionado en anteriores artículos, es la gestión de la responsabilidad, teóricamente compartida por todo el equipo, pero en realidad los equipos cada vez son más multi-disciplinares (analista web, dba, usability master, front-end dev, back-end dev, etc) por lo que difícilmente vamos a conseguir configurar un equipo que pueda realmente asumir la responsabilidad común del resultado

Volviendo a los resultados de la encuenta VersionOne del 2..8, se identificaron los siguientes puntos o causas de error en proyectos:

La cultura o filosofía a nivel de compañía entra en conflicto con los valores ágiles
Falta de experiencia con los métodos ágiles
Presión externa, incluso obligación (si es una imposición del cliente) a seguir métodos y prácticas tradicionales
Dificultad por parte del equipo para seguir las nuevas prácticas. La gestión del cambio interna
Falta de formación, de soporte a la gestión

Pese a todo, ser una metodología integrada específicamente a cada organización, con puntos de mejora inherentes en la metodología, hacen que muchas de las deficiencias identificadas hayan sido resueltas en el día a día, por los mismos equipos.

Aunque parece más que recomendable, planificar correctamente una correcta gestión del cambio, comunicar que se quiere hacer, analizar la organización, y implicar a todo el equipo en el cambio.

Saludos,

Agile Software Development - Prácticas y métodos

noreply@blogger.com (Iván) — Fri, 29 Apr 2011 02:15:43 PDT

La totalidad de metodologías ágiles incluyen una relación de prácticas y técnicas que definen como deben generarse requerimientos, diseños, desarrollo, test y gestión de proyecto.

Una de las más recientes sería la de Jurgen Appelo, 2009. Pueden existir tantas listas diferentes como organizaciones que implementen una metodología ágil. Por compartir una con vosotros, voy a extraer la propuesta de por Pirkka Rannikko en su Tesis.

Project Management

Pequeñas entregas. Iteraciones cortas, que producen funcionalidades completas y con tareas no variables durante la ejecución del Sprint.
Planificación. Se trata del trabajo de creación, elección del siguiente Sprint, a partir del backlog, la lista priorizada y estimada de tareas. Elementos o conceptos requeridos:

Product, Release y Sprint Backlog
Sprint Burndow chart / Story Cards

Ritmo sostenible. El trabajo debe ser realizado bajo un ritmo que sea sostenible indefinidamente. El equipo crea código mejor y de mayor calidad cuando se encuentran en situaciones "saludables", están motivados y disfrutan de su trabajo. La sobrecarga suele suponer un impacto inverso y causar problemas mayores
Equipos auto-organizados. Durante el Sprint el equipo es responsable para lograr los objetivos del Sprint, y tienen la autoridad/responsabilidad para ejecutar ese trabajo y planificar para conseguirlo, no siendo responsabilidad del project manager dirigir al equipo, si no ayudar a cumplir los objetivos
Retrospectiva. Reuniones realizadas después de cada Sprint, Entrega o Proyecto donde el equipo comparte sus experiencias y deciden posibles medidas de mejora
Meeting diario. Breve encuentro diario para que el equipo coordine su trabajo, el esfuerzo diario, revise el sprint y comparta bloqueos o problemas.

Research

On-site customer. Todo el equipo trabaja en una misma sala con representación por parte del cliente (product manager) que es quien trabaja con el equipo en los requisitos, y en la toma de decisiones sobre éstos. Esta presencia mejora la comunicación y reduce la necesidad de documentación. Elementos a generar:

Story Cards

User stories. Se trata de la herramienta de Ingeniería en los proyectos ágiles. Son descripciones cortas usadas para planificar y de recordatorio del alcance para analizar su completitud. Estas reflejan adicionalmente una estimación de esfuerzo.

Story Cards

Design

Simple Design. El objetivo es disponer de un diseño lo mínimo posible para posibilitar la entrega de funcionalidades según la necesidad del cliente. Simple no quiere decir incompleto, simplemente disponer de exclusivamente lo justo y necesario
Metáforas. Las metáforas dan soporte a la idea de disponer un diseño simple al proveer un marco de referencia de cómo el equipo debe pensar en el proceso y ayudar a la comunicación sobre el diseño

Programming

Programación en parejas. Práctica en la que dos desarrolladores programan juntos, compartiendo un ordenador, alineado con aumentar la calidad del código y la comprensión del código. Uno de ellos desarrolla, mientras el otro revisa su código, ayuda a la solución de problemas, y periódicamente alternan sus roles
Refactoring. El código, en un entorno ágil, es continuamente revisado y restructurado para conseguir diseños más simples y mejores que no alteren el comportamiento externo
El código pertenece al equipo. El código pertenece a todo el equipo, toda pareja de desarrolladores puede modificar cualquier parte del código. Se trata de una responsabilidad colectiva que debe motivar la resolución de errores, las situaciones de cuello de botella dejan de existir
Estándares de codificación. Los equipos pactan y siguen una relación de buenas prácticas de como escribir el código para mejorar su mantenibilidad y su lectura.

Testing

Test-Driven Development (TDD). En TDD los test unitarios se escriben previamente al código. Y cuando disponemos de los test disponibles, y solo entonces, se escribe el código. Este enfoque ayuda a crear una relación comprensible de test y asegura un buen nivel de calidad de código.
Integración Continua. Todo el código registrado en el control de versiones es automáticamente re-integrador y testeado en un entorno específico. Aplicando este ciclo conseguimos que los problemas se detecten cuando el equipo está creándolo, y elimina el trabajo manual y tedioso que supone una posterior integración manual
Customer acceptance testing. Representación escrita de los criterios de aceptación por parte del cliente, que pueden llegar a ser automatizados por el equipo. Sirven para validar la coherencia entre lo especificado y lo desarrollado
Sprint review. A la finalización de cada sprint, tiene lugar un meeting dónde se demuestran los avances a los promotores, con el objetivo de recibir feed-back, analizar el diseño y compartir decisiones futuras.

No la totalidad de estas prácticas son aplicadas siempre, como os podéis imaginar el desarrollo en parejas, pese a beneficioso, está muy poco extendido. También resulta complejo, y esto sí que es más preocupante, tener al cliente con el equipo. Por otra parte, los desarrollos son complejos y requieren de miembros multi-disciplinares ... experto en bd, experto en front-end, experto en back-end ... la responsabilidad colectiva puede existir, pero en realidad no podemos obviar situaciones de cuello de botella de difícil resolución mediante otros miembros del equipo, así como no entender parte del código como del experto que lo ha desarrollado. Otro punto preocupante de baja adopción es que los test conduzcan al desarrollo.

Existen igualmente estudios relativos a las medidas más efectivas, lideradas sin lugar a dudas por la Integración Continua, de manera diferencial por encima de los meetings diarios, el concepto de sprint plan, etc.

Intentaremos, aunque sea mencionar o hacer referencia a otros medios especializados, que hagan mención a qué herramientas (sí sí ... ya se que el principio de la programación ágil es dar prioridad al equipo y no a las herramientas, pero creo que puede ser interesante, sobretodo en el ámbito de la automatización requerida para la integración continua, algunas referencias de interés) como Bamboo, Continuum, etc. se utilizan para implementar un entorno de integración continua.

Por último, las prácticas, como ya he comentado con anterioridad, son personales para cada organización, para cada equipo, y además ... es algo vivo que debe madurar de la mano de la maduración del equipo. Es habitual iterar, modificar, adaptar durante un proyecto las reglas en función del progreso, o la nuevas necesidades del equipo.

Saludos,

Agile Software Development - Ciclo de vida

noreply@blogger.com (Iván) — Thu, 28 Apr 2011 04:27:47 PDT

Trabajar con una metodología ágil, aplicando modelos iterativos e incrementales requiere disciplina, mucha disciplina a seguir. El proceso está compuesto de mini-proyectos y entregas.

En otras palabras, se deben realizar múltiples entregas antes de la entrega definitiva del sofware, por lo que debemos dividir el proyecto en esa cantidad de entregas parciales con su propio alcance y planificación.

(Consideraciones: Las entregas no tienen que ser siempre externas, ni tienen por que ser desplegadas, pero sí deberían ser desplegables)

Paralelamente a la evolución de las iteraciones incrementales, el proyecto debe seguir su propio ciclo de vida global. Para mi este es el punto más complejo de gestionar. Ya sabéis eso de que "los árboles no te dejan ver el bosque" es decir, cuando te encuentras en situaciones de micro-gestión ... existe un elevado riesgo de perder de vista el alcance temporal y en coste global del proyecto.

Estas fases, aunque existen diferentes denominaciones, son:

Inception. Creación - Fases iniciales de definición de requisitos, análisis y constitución del equipo
Elaboration. Elaboración - Continuación sobre el análisis y el diseño, inicios de las iteraciones de construcción (con sus respectivos test)
Construction. Construcción - Continuación con los mini-proyectos pero con inicios de despliegues y gestión de la configuración
Transition. Fase final en la que se dedica más esfuerzo en las iteraciones finales, despliegues finales, y gestión de la configuración

Se puede observar mucho más claramente en el siguiente diagrama de Leffingwell y Widrig, 2003.

En el fondo las fases son simplemente nombres para describir la evolución del proyecto, pero no deja de parecerme interesante tener esa foto en mente, teniendo claro el número de SPRINTS que debería tener el proyecto, el resultado esperado de cada uno de ellos, y identificar lo antes posible situaciones de desviación de presupuesto (Siempre que hablemos de proyecto llave en mano)

El Sprint 0 debe estar destinado a descubrir los requisitos iniciales, planificar el proyecto y configurar las infraestructuras de desarrollo y trabajo. La elaboración de un primer backlog de producto con tareas estimadas, así como guías de desarrollo y buenas prácticas a ser mantenidas durante todo el proyecto.

La planificación en los proyectos ágiles es también iterativa, cada Sprint va acompañado de una hipótesis de progreso, de valor que va a ser entregado a la finalización al cliente. Es un tema que me parece interesante ... olvidando la sobrevaloración (suicida) de las estimaciones de los modelos tradicionales, cuando ni tan siquiera tienes el equipo configurado ni conoces su velocidad de desarrollo.

Cada Sprint se inicia con un meeting donde se define los objetivos del mismo Sprint Backlog, y se actualiza el Release Plan (visión más general del proyecto) correspondientemente. Este plan se realiza de acuerdo con todo el equipo, pero siempre alineado con las prioridades o las decisiones del Product Owner.

Los Sprints contienen tareas de diversa tipología como vemos en la figura anterior, según las necesidades. Al final cada Sprint se efectúa un Review meeting para demostrar los avances, como medida de progreso del proyecto, y recoger feedback de los promotores. El equipo realiza igualmente un Sprint Retrospective para compartir las experiencias vividas y poder mejorar el proceso.

Los Sprints tienen un periodo de vida conocido y limitado (i.e. 30 días) durante el cual el equipo intenta ejecutar la totalidad de tareas previstas en el Sprint Backlog, no pudiendo este ser modificado por los promotores (no deberían) El tamaño recomendado de los Sprints es como siempre, entre más corto mejor, siendo entre 1 - 4 semanas lo recomendable.

En ocasiones se considera que, el trabajo derivado de la "burocracia" del proceso, es excesiva, y puede llevarnos a la tentación de alargar los Sprints con el objetivo de minimizarlas. Es un error, teniendo en cuenta que a cada iteración, recibes feedback de promotores y una validación por tanto del producto, debemos tomarlo como beneficioso. (Buscando un equilibrio en relación a la velocidad, en este punto es cuando hay que entender la semántica de cada organización)

Un punto a considerar y que será objetivo de este blog, es que las metodologías ágiles se concentran en el desarrollo de software, dejando fuera de su alcance puntos de interés como la definición de portfolio, el mantenimiento o la gestión de producto (cuando el proyecto es un producto en sí mismo) intentaremos hablar de KANBAN y sus integraciones con SCRUM para la gestión de mantenimiento, y como podemos reflejar la realidad de un producto con estas metodologías (cuando las iteraciones y el feedback viene de usuarios anónimos web por ejemplo)

Saludos,

Agile Software Development - SCRUM

noreply@blogger.com (Iván) — Thu, 28 Apr 2011 03:04:09 PDT

SCRUM es una metodología que enfatiza una relación de valores y prácticas relativos a la gestión de proyecto por encima de los orientados a requisitos, la implementación etc. Y puede ser utilizado conjuntamente con otras metodologías, por ejemplo con XP.

Personalmente he vivido una interesante integración con KANBAN, que explicaremos en siguientes artículos.

SCRUM fue creado por Jeff Sutherland y Ken Schwaber con una primera publicación en 1995. Siendo una metodología dirigida por 5 valores principales: compromiso, foco, franqueza, respeto y coraje. El ciclo de vida de un proyecto SCRUM se divide en iteraciones de 30 días denominadas SPRINT, con reuniones de diarias para tener seguimiento del progreso y posibles bloqueos del equipo. (Daily SCRUM)

En un proyecto SCRUM tenemos 4 roles diferenciados:

Product owner. Representante de los promotores ante el equipo, todo requisito debe canalizarse a través de él. Se encarga de mantener el product backlog (relación de tareas pendientes) así como priorizar, decidir el contenido de cada SPRINT y revisar el producto con el resto de promotores después de cada SPRINT (Stakeholders)
Scrum master. Se trata de un desarrollador a tiempo parcial y un leader el resto del tiempo, que trabaja para salvaguardar el progreso y el seguimiento de las prácticas SCRUM.
Scrum team members. Responsables de entregar evoluciones de producto potencialmente entregables en cada SPRINT, así como actualizar la el backlog de tareas o el WBS.
El resto.

Imagen extraída de Wikipedia

WBS - Work breakdown Structure, es un modo de romper unidades de trabajo, en otras unidades de menor coste temporal, para facilitar la gestión y minimizar la falta de control sobre el progreso. Es muy recomendable romper las historias de cliente (unidades funcionales) en tareas de menor tamaño, siempre alineados con que las unidades de trabajo supongan un incremento de valor del producto en sí mismas, o como mínimo, que la suma de unidades de trabajo durante un SPRINT lo supongan, para facilitar la medición del grado de avance al final de cada SPRINT.

Lista de reglas de SCRUM:

Cada SPRINT debe dar como resultado un código totalmente funcional, testeado que ofrezca valor tangible al cliente
Al inicio de cada SPRINT se debe celebrar una Sprint Planning Meeting
El equipo colectivamente decide la cantidad de trabajo a incluir en cada SPRINT
El product owner prioriza el product backlog
El product backlog puede ser incrementado o re-priorizado en cualquier momento
Una vez el SPRINT ha sido iniciado solo el equipo puede añadir trabajo al backlog del SPRINT
Un breve Scrum meeting se celebra cada día donde los miembros del equipo comparten su progreso del día anterior, los objetivos del día actual y si tienen algún obstáculo en el camino
Solo pigs (término asociado a Product Owner, Scrum master y Scrum team members; El resto son denominados chickens) pueden hablar durante el meeting diario
El resultado del sprint debe ser demostrado en una Sprint Review Meeting a celebrar a la finalización de cada SPRINT
No se debe dedicar más de dos horas al Sprint Review Meeting

Imagen extraída de Wikipedia

Podéis encontrar una guía en castellano aquí.

Saludos,

Agile Software Development - Extreme Programming

noreply@blogger.com (Iván) — Thu, 28 Apr 2011 03:04:37 PDT

XP fue creado por Kent Beck entre otros mientras trabajaba para corporación Chrysler, publicada por primera vez sobre el 1999. El nombre refleja la idea que el modelo quería conceptualizar, los ingenieros debían llevar las buenas y probadas prácticas de ingeniería al extremo.

XP busca estresar la satisfacción del usuario, con rápidas creaciones de software operativo, con técnicas sostenibles de desarrollo buscando la agilidad ante la necesidad de respuesta ante el cambio.

XP aboga por los siguientes valores: Comunicación, simplicidad, feedback y valentía. Pudiendo ser caracterizado por 5 principios:

Feedback rápido
Asunción de simplicidad
Cambios incrementales
Aceptación del cambio
Realización de un trabajo de calidad

Así mismo, se elaboraron 12 practicas relativas al desarrollo software:

Pequeñas entregas
El juego de planificación
Preparación para la reprogramación (Refactoring)
Desarrollo dirigido por las pruebas
Programación en parejas
Ritmo sostenible de desarrollo
Responsabilidad colectiva del código
Cumplimiento de estándares de codificación
Simplicidad de diseño
Aplicación de metáforas
Integración continua
Integración en cliente

XP hace énfasis en la programación y en la calidad del software generado, pero también en la comunicación y la implantación del concepto de equipo por encima de todo. Dando prioridad al código desarrollado y a los test generados por encima de documentos de especificación.

La comunicación oral es la vía sugerida para el trabajo de requerimientos y diseño. Y se espera que tanto clientes, como gestores, como equipo de producción trabajen juntos en un mismo espacio común, para facilitar las entregas de software de elevado valor de negocio.

La responsabilidad del cliente es la de elaborar las historias, los requerimientos o especificaciones de funcionalidades (una descripción de las mismas) priorizando estas según el valor de negocio. Así mismo elaborar test que validen el correcto funcionamiento de la funcionalidad.

El desarrollador XP no distingue entre programadores, diseñadores o testers etc todos trabajan como equipo y comparten responsabilidades. Así mismo deben estimar el esfuerzo para cada historia recibida y entregar toda pieza de código con sus necesarios tests unitarios.

El gestor (XP coach/Project Manager) debe monitorizar la correcta aplicación de las prácticas XP y salvaguardar el progreso.

Podéis encontrar mucha más información en la web de eXtreme Programming

Saludos,

Agile Software Development - Introducción

noreply@blogger.com (Iván) — Thu, 28 Apr 2011 01:49:51 PDT

El concepto Ágil se focaliza no a la programación en si misma sino a la gestión de proyectos y el trabajo en equipo. Ágil está asociado a una relación de metodologías que comparten principios como la comunicación, el equipo, la habilidad de adaptarse a los cambios por encima de procesos, procedimientos o herramientas.

Surgieron en respuesta a las deficiencias vividas en el proceso tradicional, o en cascada. El término agile software development fue un concepto aceptado cuando en 2001 17 de esas nuevas metodologías escribiendo juntas el Agile Manifiesto que se fundamenta en los siguientes 4 estamentos:

Individuos e interacciones por encima de procesos y herramientas
Software operativo por encima de documentación comprensiva
Colaboración con el cliente por encima de negociación de contratos
Capacidad de respuesta ante el cambio por encima del seguimiento del plan

En base a estos 4 estamentos, se proclamaron los siguientes 12 principios compartidos hoy por toda metodología ágil:

Nuestra máxima prioridad es satisfacer al cliente con prontas y continuas entregas de valor
Los cambios de requerimientos son bienvenidos y deben ofrecerse al cliente como ventaja competitiva
Entregar frecuentes de trabajo, semanales o mensuales, dando prioridad a la minimización del periodo
Equipo de negocio y producción deben trabajar unidos durante todo el proyecto
Construir proyectos en equipos motivados, y dotados del entorno, el soporte y la confianza necesaria
El más eficiente método de comunicar es el CARA a CARA
Producto operativo es la unidad mínima de progreso
El desarrollo debe ser sostenible, tanto promotores, usuarios y equipo de desarrollo deben tener una dedicación constante
La agilidad mejora con la excelencia y los buenos diseños
La simplicidad es esencial
Las mejores arquitecturas, requerimientos y diseño son fruto de equipos auto-organizados
Regularmente los equipos reflexionan cómo ser más efectivos y ajustan/mejorar su proceso

Saludos,

User-Center Design. Conclusiones Pro's y Contra's

noreply@blogger.com (Iván) — Wed, 27 Apr 2011 08:31:50 PDT

Aplicar el proceso UCD sin lugar a dudas nos va a dar como resultado productos más usables. Pero no podemos tener datos cuantitativas de los beneficios de obtener un producto más usable, aunque de manera abstracta en la ISO 13407 se haga mención a beneficios económicos y sociales.

En cualquier caso, creo que nos estaríamos equivocando si dejáramos el concepto usabilidad en la subjetividad de un experto, tanto en proyectos web como en proyectos internos, desde mi punto de vista, la aplicación de UCD debe ir de la mano a una escucha contínua mediante herramientas como tests A/B, tests multivariantes, encuestas y similares. Dónde podamos cuantificar ese beneficio y optimicemos la web para maximizar los goals de nuestro producto (Deberíamos entender eso como usabilidad)

Por continuar con la reflexión de la ISO 13407, concluye que:

Si obtenemos facilidad de uso y comprensión --> reducimos costes de formación y soporte
Si mejoramos la satisfacción del usuario --> reducimos el estrés y mejoramos la confortabilidad
Mejoramos la productividad
Mejoramos la calidad del producto --> Obteniendo una ventaja competitiva

Aunque insisto, me parecen medidas peligrosamente no cuantitativas. Por lo que no me conformaría con creerlo pudiendo, con mayor o menor dificultad, demostrarlo mediante técnicas de analítica web (Avinash - Analítica Web 2.0 - 2010)

¿Y no hablamos de los puntos débiles?

Una crítica habitual sobre UCD es el potencial aumento de coste y en el tiempo sobre la velocidad de desarrollo. Deberíamos, pero, tener en cuenta que usabilidad y diseño NO es solo sentido común, en muchas situaciones puede ser preferible tener un retraso para entregar un proyecto usable, que un proyecto en plazos destinado a frustrar al usuario.

Otro pero es la falta de definición o concreción del proceso en sí mismo, cosa que complica su posible integración con los procesos de desarrollo de software existentes. Dejando bajo el criterio de la organización la selección de qué fases y en qué punto de nuestro proceso de desarrollo de software son más convenientes.

Si no orientamos y focalizamos a nuestro jinete, difícilmente moveremos a nuestro elefante (Switch - Heath Brothers - 2010)

Así mismo, las prácticas más interesantes como pueden ser la elaboración de prototipos, o los estudios de usuario, renunciando a fases de diseño tradicional ... nos pueden llevar a implementar los que el usuario quiere, y no lo que el usuario necesita.

Saludos,

User-Center Design. Prácticas y métodos

noreply@blogger.com (Iván) — Wed, 27 Apr 2011 07:42:23 PDT

Trabajar en UCD implica un trabajo continuo de investigación, diseño y evaluación del producto, además de tareas tan específicas como pueden ser la del diseño de la arquitectura de la información, establecimiento de objetivos de usabilidad, ejecución de test de usabilidad de la interfaz, etc.

He localizado una tesis doctoral muy interesante de Pirkka Rannikko, en la que propone una lista de estas actividades, divididas según la fase del ciclo de vida de un proyecto en la que convendría incluirlas.

Project Management

Cross Funcional Team. Disponer de un equipo que trabaja conjuntamente y comparte los requerimientos y diseños teniendo el compromiso de obtener un producto usable

Research / Investigación o Consultoría previa

User Reseach. Descubrir quiénes son los usuarios, sus objetivos, el contexto dónde va a ser desarrollado el producto buscando orientar el diseño y el desarrollo a cumplir sus necesidades. Para ello podemos utilizar técnicas como encuestas, entrevistas, consultoría, observación, visitas, entrevistas a promotores/stakeholders
Tasks Analysis. Estudio de tareas que realizan los usuarios para lograr cubrir sus necesidades. Orientando el conocimiento obtenido a identificar mejoras de flujo de trabajo y alinearlas con las necesidades de los usuarios. Técnicas similares al punto anterior
Competitor Analysis. Al igual que sucede durante la conceptualización de un modelo de negocio, es imprescindible analizar cómo lo soluciona la competencia, que funcionalidad buenas poseen y como de bien resuelven las mismas. Para ello puede ser conveniente la intervención de un experto, y algún test de usuarios
Setting usability goals. Marcar una relación de métricas cualitativas y cuantitativas esperadas como resultado del proyecto. Estas métricas además nos pueden ayudar a cuantificar el beneficio aportado por la aplicación de UCD y por tanto medir su ROI (Retorno de la Inversión)

Diseño

Concept Design. Diseño conceptual aproximativo, con arquitectura de la información, workflows de usuarios, bocetos de wire-frames y outputs similares. Podemos aplicar técnicas como el diseño en paralelo, diseño participativo, elaboración de prototipos, y elaboración de guías de estilo y patrones de diseño. Para ello sería conveniente considerar Diagramas, Casos de uso o escenarios, wire-frames y diagramas de flujo
User Interface Design. Una vez cerrado el diseño conceptual, hay que elaborar un diseño detallado de la interfaz, con un elevado grado de fidelidad, siendo conveniente incluso una guía de estilos por plataforma/producto, y a ser posible un prototipo que ayuden a avanzar cualquier necesidad de cambio o identificar oportunidades de mejora de la usabilidad. Para ello las técnicas del punto anterior son igualmente válidas, pero teniendo como objetivo otra relación de outputs además de wire-frames, imágenes mock-up, guía de estilos o un prototipo funcional

Testing

Expert Evaluation. La intervención de un diseñador senior (i.e. usability champion) debe permitir posibles problemas de usabilidad. Esta revisión debe realizarse contra una relación de principios o guías heurísticas a seguir. Podemos utilizar herramientas de evaluación de recorrido cognitivo, recorrido de usabilidad y heurísticas para generar un informe final de conclusiones
Usability Testing. De forma complementaria o alternativa, podemos utilizar un conjunto representativo de usuarios y seleccionar igualmente un conjunto representativo de funcionalidades y contrastar contra los objetivos de usabilidad establecidos en el punto 4 de la fase de Research. Para ello podemos aplicar técnicas de observación del taller de muestra, entrevistas, herramientas de eyetracking, testing remoto de la solución etc. para general un informe final de conclusiones

Cada día disponemos de más y más herramientas, ofrecidas en formato SaaS (Software as a service) que nos deberían permitir no tener que renunciar a muchas de estas fases, son efectivas y tienen un coste-beneficio más que rentable.

Intentaré complementar con artículos de productos en próximas fechas.

Saludos,