Scrum


Los Roles

  • Product Owner (dueño del producto)
  • The Team (el equipo)
  • ScrumMaster (Maestro Scrum ).

Product Owner

  • El propietario del producto decidir qué será construído y en Qué orden
  •     Definir las características del producto o los resultados esperados del proyecto
  •     Opta por fecha de lanzamiento y el contenido
  •     Garantiza la rentabilidad (ROI)
  •     Da prioridad a las características / resultados de acuerdo al valor de mercado
  •     Ajusta las características / resultados y la prioridad según sea necesario
  •     Acepta o rechaza los resultados del trabajo
  •     Facilita la planificación de la ceremonia scrum

ScrumMaster

El Scrum Master es un líder del equipo facilitador que asegura que el equipo cumple con su proceso elegido y elimina problemas de bloqueo.

  •     Asegura que el equipo es completamente funcional y productivo
  •     Permite una estrecha colaboración en todos los roles y funciones
  •     Elimina las barreras
  •     Protege al equipo de interferencias externas
  •     Asegura que el proceso es seguido, incluidas las invitaciones a la emisión diaria scrums, revisiones sprint, y planificación del sprint
  •     Facilita el scrum diario

El equipo

  •     Es multi-funcional
  •     Es del tamaño adecuado (el tamaño ideal es de siete – más / menos dos – los miembros)
  •     Selecciona el objetivo del Sprint y especifica los resultados del trabajo
  •     Tiene derecho a hacer todo dentro de los límites de los lineamientos del proyecto para alcanzar el objetivo del Sprint
  •     Se organiza a sí mismo y su trabajo
  •     Demos trabajo como resultado al dueño del producto y cualquier otra parte interesada.

El Scrum Master tiene tres responsabilidades principales, además de líder en el scrum diario:

El ScrumMaster tiene que saber qué tareas se han completado,  las tareas que han comenzado, las nuevas tareas que han sido descubiertas, y las estimaciones que puede haber cambiado. Esto hace que sea posible actualizar la tabla de quema, un artefacto que muestra el trabajo acumulado restante día a día. El ScrumMaster también debe considerar cuidadosamente el número de tareas abiertas en curso. Trabajo en curso tiene que ser minimizado para lograr la máxima productividad.
El ScrumMaster tiene que dar a conocer las dependencias y los bloques que son impedimentos para el sprint. Estos asuntos deben ser priorizados y seguimiento. Un plan de remediación debe ser implementado por los obstáculos en orden de prioridad. Algunos se pueden resolver con el equipo, algunos se pueden resolver a través de los equipos, y otras van a necesitar la participación de la gestión, ya que puede haber problemas de la empresa que bloquean a todos los equipos para alcanzar su capacidad de producción. Por ejemplo, una compañía de telecomunicaciones implementado recientemente Scrum y encontró dieciocho artículos en su lista de impedimento, sólo dos de los cuales estaban relacionados directamente con los equipos de Scrum. Los otros fueron los temas que la empresa necesita atención de la administración.
Por último, pero no menos importante, el ScrumMaster puede notar problemas personales o conflictos dentro del equipo de Scrum que necesitan solución. Estos deben ser aclaradas por el Scrum Master y se resuelvan mediante el diálogo dentro del equipo. A veces, el ScrumMaster puede necesitar ayuda de la administración o recursos humanos con el fin de resolver estos problemas. Certificado ScrumMaster James Coplien desarrollado más de 200 estudios de caso de proyectos importantes, mientras trabajaba en los Laboratorios Bell ATT. Se informa que más del 50% de las pérdidas de productividad causadas por las cuestiones de personal. El Scrum Master debe prestar atención a ellos para que el equipo es completamente funcional y productiva

Scrum Principios

El éxito de los equipos de Scrum abrazar los valores en que se basa Scrum (paráfrasis del Manifiesto Agile):

Valoramos

Individuos e interacciones sobre procesos y herramientas
Funcionalidad completa sobre documentación completa
Colaboración con el cliente sobre negociación de contratos
Respuesta al cambio sobre seguimiento de un plan

Es decir, mientras hay un valor en los elementos de la derecha, los elementos de la cuestión que se deja más.

El verdadero éxito con el marco de Scrum viene de los equipos y las organizaciones que comprenden estos valores y los principios que forman la base de todos los procesos ágiles.
A pocas definiciones detalladas

Cartera de productos: Un atasco de productos es dinámica: Los artículos pueden ser borrados o añadidos en cualquier momento durante el proyecto. Es prioridad: Los elementos con la más alta prioridad es completar primero. Es progresivamente refinado bajo los temas prioritarios son intencionalmente de grano grueso.

Sprint Backlog: Un sprint backlog es un conjunto negociado de los elementos de la acumulación de productos que un equipo se compromete a completar durante el timebox de una carrera de velocidad. Artículos en el sprint backlog se dividen en tareas detalladas para los miembros del equipo completo. El equipo trabaja en conjunto para completar los elementos de la cartera de sprint, la reunión todos los días (durante un scrum al día) para compartir las luchas y los avances y actualizar el sprint backlog y tabla de quema en consecuencia.

Potencialmente productivo: significa potencialmente productivo que el incremento / entrega podría ser liberado a un propietario deun producto customer. La toma de decisión sobre cuándo liberar realmente ninguna funcionalidad o prestaciones.

Scrum Terminología

Hemos introducido algunos nuevos términos para describir el marco de Scrum. Veamos con más detalle. Scrum se compone de tres funciones, cuantro ceremonias y tres artefactos.

Tres funciones

  1.     Propietario del producto: responsable del valor de negocio del proyecto
  2.     Scrum Master: garantiza que el equipo es funcional y productiva
  3.     Equipo: se auto-organiza para hacer el trabajo

Cuatro reuniones

  1.     Sprint de planificación: el equipo se reúne con el dueño del producto a elegir un conjunto de trabajos para entregar en un sprint
  2.     Scrum Diario: el equipo se reúne cada día para compartir luchas y el progreso
  3.     Revisiones Sprint: el equipo muestra al dueño del producto lo que se ha completado durante el sprint
  4.     Retrospectivas de Sprint: el equipo busca la manera de mejorar el producto y el proceso.

Tres artefactos

  1.     Cartera de productos: lista priorizada de los proyectos, los resultados deseados / características
  2.     Sprint Backlog: conjunto de trabajo de la cartera de productos que el equipo se compromete a completar en una carrera de velocidad, divididos en las tareas
  3.     Tabla de quema: de un vistazo, ver el trabajo restante (puede tener dos cartas: una para el sprint y otra para el proyecto en general)

A continuación les comparto info complementaria, feliz lectura.

Definición

Scrum es un marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software.

Aunque Scrum estaba enfocado a la gestión de procesos de desarrollo de software, puede ser utilizado en equipos de mantenimiento de software, o en una aproximación de gestión de programas: Scrum de Scrums.
Principios

1. Transparencia

Desde que contamos con elementos visuales, como el taskboard o los burndown charts, estamos incentivando la transparencia dentro del equipo; estos elementos no sólo sirven para realizar seguimiento al proyecto sino que también es una forma tácita de decir “Ésto estoy haciendo, no escondo nada”, “Así va el proyecto en realidad, no te digo bien cuando está mal”, y muchas otras cosas más.

Pero esos elementos visuales, tal como su nombre lo indica, son simplemente elementos, objetos, cuadros y gráficas cuya interpretación se basa en la información que reside en ellas y que a su vez depende de la transparencia con que esa información es generada. De nada sirve, por ejemplo, tener en el taskboard cinco tareas en progreso cuando en realidad se está haciendo una, de nada sirve que el burndown chart sea una diagonal perfecta cuando estoy omitiendo los retrasos, de nada sirve tener estos elementos visuales cuando el valor de la transparencia no está presente en el equipo.

2. Compromiso

Debido a que scrum propone la auto organización sobre un esquema jerárquico de jefe – subalterno (que usualmente se convierte en un esquema de opresor – oprimido), se necesita en todo momento que el equipo esté comprometido. Además, en cada iteración el equipo se compromete a realizar cierta cantidad de PBIs (requerimientos), en donde la excusa de “tú me lo impusiste” no existe.

Si no existe compromiso, los plazos no se cumplen; si no existe compromiso, la confianza (próximo valor a tocar) se pierde; si no existe compromiso, el proyecto tiene una gran probabilidad de fracasar. ¿Por qué? Porque simplemente, sin compromiso, se pierde la idea de “todos estamos en esto juntos”, se pierde la capacidad de asumir responsabilidades y no escudarnos en otras personas. Porque se pierde algo que en el “mundo real” se está perdiendo, se pierde el valor de la palabra.

3. Confianza

Particularmente creo que este punto es el más importante dentro de los cuatro mencionados en esta entrada. Debido a que en scrum tenemos equipos auto organizados, buscamos compromisos y se espera transparencia, hay un aspecto que puede corromper todo lo anteriormente mencionado: la falta de confianza. Para poner en concreto ésto utilizaré una serie de ejemplos.

Imagínense que no están seguros del comportamiento de una user story en un determinado escenario, han encontrado que existen dos posibles comportamientos A y B, y además personalmente creen que B es la respuesta más lógica. Sin embargo, deciden preguntarle a su product owner (puesto que él conoce la lógica del negocio) y él les responde que el comportamiento A es el que se debe seguir. Obviamente, ustedes (luego de una conversación que profundiza las razones seguramente) deciden implementar el comportamiento A. ¿Por qué le han hecho caso al product owner a pesar de que ustedes pensaban que el comportamiento B era el más lógico? Simple, confían en que su product owner hace bien su trabajo y su respuesta está alineada a lo que quiere el cliente.

Ahora pongámonos en el lado del product owner. Imagínense que estamos en un sprint planning y que ustedes piensan que el equipo puede hacer 5 user stories, sin embargo ellos le dicen que solo pueden hacer 4. Debido a que están utilizando una planificación basada en el compromiso (commitment-driven) aceptan lo planteado por el equipo. ¿Por qué aceptan que hagan 4 user stories cuando ustedes pensaban que podían hacer 5? Simple, confían en que su equipo (al ser ellos quienes van a realizar el trabajo) tiene una mejor capacidad para estimar el tamaño de las user stories y por ende su capacidad para realizarlas dentro de un sprint.

Ahora evaluemos escenarios cuando no existe la confianza dentro del equipo (me refiero al equipo scrum). Un product owner podría pensar que simplemente el equipo no quiere trabajar mucho y por ello se compromete a pocas user stories (story points), esto originaría que el product owner fuerce la inclusión de más story points. El equipo, podría comenzar a subirle el peso de la priorización a cada user story para evitar la sobre carga del product owner. Y así podrían desarrollarse miles de eventos sucesivos que solo llevan a un camino: el caos y fracaso del proyecto.

4. Coraje

Para poner en práctica los tres valores antes mencionados necesitan coraje. El coraje se debe utilizar para aceptar los errores y hacer notar los errores ajenos, para ser transparente y esperar transparencia; coraje se necesita para comprometerse y pedir compromiso, para confiar y no descuidar la confianza que otros depositan en uno. Al final, coraje es lo que necesita scrum de cada uno de los miembros del equipo.

Ahora que ya he explicado un poco los cuatro valores más importantes (en mi opinión) que sostienen a scrum, volveré a retomar el propósito de esta entrada que está descrita al inicio: las razones por las cuales me gusta scrum, utilizo scrum y trato de que mi entorno también lo haga. ¿Cuáles son estas razones?

Precisamente los párrafos anteriores responden esa pregunta. A mí me gusta scrum (aunque se podría ajustar a otros procesos ágiles) porque habla de personas y no de recursos, porque al plantear una base sobre ciertos valores no sólo se nos indica cómo ser más productivos, cómo dar mayor valor de negocio en menos tiempo o cómo adaptarnos al cambio; nos hace recordar que el desarrollo de un proyecto (y en el de software en especial) participan personas y que sobre ellas existe una cultura, que afecta inexorablemente al proceso.

Yo utilizo scrum, porque esa cultura que nos propone basada en transparencia, compromiso, confianza y coraje, se acopla perfectamente a mi propia cultura. Como seguramente lo habrán notado por mi nombre y apellido, soy nikkei (descendiente japonés) y, aunque no pretendo etiquetar a los nikkeis, personalmente creo que el hecho de haber sido criado con una influencia tan alta de esa cultura (la japonesa) me da el privilegio de tener ciertas creencias que hacen posible que comprenda y acepte aquellos valores en los que se basa scrum (esto no significa que otras culturas no puedan lograr lo mismo).

Finalmente yo trato de que mi entorno utilice scrum, porque vivo en Perú, y sinceramente no creo que todas estas ideas sean incompatibles con la idiosincrasia del peruano. Alguna vez un profesor de la universidad me dijo: “Scrum está bonito y seguro funciona en países desarrollados, aquí la gente funciona con látigo”. Personalmente no pienso lo mismo y creo que este tipo de pensamiento (peor en un educador) es el que genera este estigma de que no puede existir transparencia o confianza. Si bien es cierto que uno no puede estar andando por la vida confiando en todo el mundo, pero ¿no puedes confiar en la persona que esta a tu lado trabajando?. Yo creo que sí se puede, yo lo hago y eso genera un aire, un ambiente distinto.

Para concluir este post dejaré abierta una pregunta: Si alguna vez has pensado “Scrum no funciona” ¿Evaluaste la cultura y los valores dentro del equipo, antes de implantar técnica tras técnica? Si es así, ¿qué es lo que en realidad no funciona? Quizás el problema es el actual paradigma[2].

Ejercicio de simulación


FRAMEWORKS

OFICIALES

Extreme Programming
Kanban
Lean Software
Software Craftsmanship
DSDM (Dynamic Systems Data Modeling)
Crystal

NO OFICIALES

Mob Programming
FDD (Feature-driven Development)
Pragmatic Programming

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s