Autor: vejeta

Este año 2015 he comenzado una nueva etapa en 47Degrees, una empresa de desarrollo de software con sedes en Seattle y San Fernando, con el ambiente de trabajo con el que siempre he soñado, aparcando de momento mis proyectos como Universidad Quantum hasta encauzar esta nueva etapa. Éste artículo refleja mi opinión personal sobre esta metodología.

Entre las cosas que estoy aprendiendo a base de practicarlas es a trabajar en equipo usando Scrum. De esta metodología ágil podrían beneficiarse grandemente las empresas en las que he estado hasta ahora, en las cuales los desarrollos en los que participé se organizaban en cascada, es decir,
el gerente o jefe de proyecto organizaba el tiempo sin tener en cuenta las estimaciones dadas por el equipo.

Aquí traduzco un artículo de scrummmethodology del cual cualquier equipo puede sacar grandes beneficios al aplicarlo en el desarrollo de sus proyectos.

* Estimaciones en Scrum y Puntos de Historia.

En el desarrollo en cascada, los mánager determinan la capacidad de trabajo de alguien del equipo en terminos de tiempo. Es decir, los mánager estiman cuanto creen que un trabajo dura en terminos de tiempo y asignan el trabajo según el tiempo libre de este miembro del equipo. Esto es problemático ya que esto no distingue entre una ‘historia’ que es dificil de completar de una historia que no requiere mucho esfuerzo, sólo tiene en cuenta el tiempo que va tomar. Para decirlo de otra manera, programar una nueva funcionalidad y organizar los documentos de tu mesa son considerados como tareas que llevan el mismo tiempo, sin embargo no hay dudad de que la primera requiere un grado mucho mayor de concentración y esfuerzo. Por este hecho, se deberían de reconocer como tareas totalmente diferentes que requieren distintos niveles de esfuerzo.

Scrum toma un enfoque diametralmente opuesto para determinar la capacidad de un miembro del equipo. Para empezar, Scrum asigna el trabajo al equipo completo, no a un individuo. En su filosofía se pone el énfasis en el esfuerzo colectivo. En segundo lugar, los equipos Scrum prefieren no cuantificar su trabajo en terminos de tiempo ya que esto puede socavar la auto-organización que es el pilar base del éxito de Scrum. Ésta es la mayor diferencia del estilo en cascada: En lugar de tener un mánager estimando el tiempo de otros miembros del equipo y asignando estas tareas según esta estimación, son los propios miembros del equipo los que estiman su propio trabajo en función del esfuerzo y grado de dificultad.

¿Cómo es este proceso de estimación? Scrum no prescribe una manera única de estimar éste trabajo. Lo que hace es delegar en el equipo ésta estimación sin usar términos de tiempo, y usar, una métrica abstracta para medir el esfuerzo.
Entre los métodos más comunes para cuantificar esto se encuentran: El uso de tallas numéricas (del 1 al 10), tallas de camisetas (XS, S, M, L, XL, XXL y XXXL), la secuencia de Fibonacci (1, 2, 3, 4, 5, 8, 13, 21, 34, etc.) o incluso razas de perros, en el que un Chihuahua representaría la historia más pequeña y un Gran Danés la más grande. Lo importante de todo esto es que el equipo comparta y entienda la misma escala de manera que todo el equipo se sienta cómodo con sus valores.

Durante la sesión de planificación del Sprint, el equipo se sienta para estimar el esfuerzo requerido por cada una de las historias del ‘backlog’. El Product Owner necesita estas estimaciones para poder priorizar de manera efectiva las tareas en el ‘backlog’, y como resultado, estimar la publicación del proyecto en función de la velocidad. Para ello, el Product Owner necesita una evaluación honesta de la dificultad de un trabajo. Entonces, incluso cuando un equipo hace la estimación conjuntamente, se han de tomar acciones para reducir la influencia de como un equipo estima. Por eso, se recomienda que todos los miembros del equipo muestren su voto simultáneamente. De esta manera, cuando los individuos «muestran sus cartas» a la vez, el proceso de votación es como un juego de poker. Algunos equipos han desarrollado sus propios mazos de cartas expresamente para este proceso. Algunos equipos llaman a esto una «ronda de poker de planificación»

A pesar de todo, incluso cuando los equipos comparten la numeración de las escalas que utilizan, estos pueden estimar de manera distinta. Para llegar a un acuerdo que refleje la dificultad de una historia, con frecuencia se requieren varias rondas de estimaciones. Los equipos ya veteranos que estan familiarizados con el proceso suelen alcanzar el consenso en unas pocas rondas de poker de planificación.

Fuente: http://scrummethodology.com/scrum-effort-estimation-and-story-points/

Créditos: Imagen de portada obtenida de: https://flic.kr/p/aehXAi con licencia https://creativecommons.org/licenses/by-sa/2.0/