Parametrización de Scrum - Teórico

Transcripción

1 1 de 5 07/09/ :10 p.m. Parametrización de Scrum - Teórico 1 Added by Limay Fortunato, last edited by Adriana de Celis on Apr 05, 2011 Table of Contents Qué es parametrizar Scrum? Glosario Metodología Manual de Calidad Mapa de Procesos PCS.IS - Information Security PCS.COAD - Compras y Administración PCS.COM - Comercial PCS.CON - Consultoría PCS.DDS - Diseño y Desarrollo de Software DDS.Artefactos DDS.Diccionario de Roles Iteración 0 Crear Plan de Releases AUX.HWT - Definir Visión del Proyecto Setup de Infraestructura para el proyecto Armar Product Backlog QA.HWT - Armar Plan de Calidad Configurar Metodología de Trabajo Parametrización de Scrum Parametrización de Scrum - Teórico Parametrización Scrum - Template Confluence Modelado de Dominio Inicial Tomar Metricas Iniciales Implementar POC IMP.HWT - Entorno y Guía de Desarrollo Sprint Preliminar Objetivos de Iteracion 0 Sprint En cada proyecto de desarrollo deben decidirse varios aspectos sobre cómo se va aplicar Scrum. Por ejemplo: Qué tipo de Item de Backlog nos conviene usar?, A qué hora y lugar vamos a hacer las daily meetings?, etc. Todos estos aspectos no los establece Scrum y pueden pensarse como "parámetros" que nosotros tenemos que definir. Entonces, la actividad de Parametrizar Scrum para un proyecto determinado, consiste en definir todos estos parámetros. El Scrum Master, como el impulsor del proceso y las prácticas de Scrum, tiene una responsabilidad central en esta parametrización, su consenso con el equipo y comunicación (ej usando lista del proyecto, espacio de trabajo, etc) Cómo hago para parametrizar Scrum? El significado de los distintos parámetros se describe en Parametrización Teórico. Para realizar la parametrización, hay que usar alguno de los dos templates: 1) excel 2) Template del Confluence es un templatete global que se llama "Parametrización de Scrum" y puede usarse desde cualquier espacio (ver más info) La parametrización puede realizarse "desde 0" y/o pueden usarse las recomendaciones dadas en esta página Parámetros a definir de Scrum Roles y Equipo Quién/es jugará/n el rol de Scrum Master? División de Tareas Operativas de Scrum Master Product Owner Integrantes del Equipo / armado de lista de correo Configuración General Metodología y Herramientas Product Back-Log-Items del Backlog Solapamientos entre roles e iteraciones Definir Criterio de Terminado/DONE Análisis, Desarrollo y Testing en la misma iteración Análisis Defasado de Desarrollo y Testing Análisis, Desarrollo y Testing en distintas iteraciones Forma de medir la velocidad Espacio de Trabajo Informativo Duracion del Sprint Parametrizacion de Reuniones Sprint Planning StandUp Meetings Demo Retrospectiva Parámetros a definir de Scrum Roles y Equipo Quién/es jugará/n el rol de Scrum Master? División de Tareas Operativas de Scrum Master Ser Scrum Master implica: ser "Coach de Proceso" como se describe en Liderazgo Agil ejecutar las Tareas Operativas de Scrum Master En la práctica, el rol de Scrum Master puede ser jugado en parte por el PM y/o en parte por el líder técnico (o referente técnico o persona con habilidades de coordinación). Si esto ocurre, entre las distintas personas que hagan una parte de Scrum Master deberán acordar cómo se dividirán las Tareas Operativas de Scrum Master Es bueno que alguien pueda jugar de reemplazante del Scrum Master, por si éste por ejemplo no puede estar en la Daily. Product Owner Idealmente este rol, debería ser cubierto por un representante de los StackeHolders del proyecto. Muchas veces en los proyectos de GlobalLogic, alguien del equipo del proyecto tiene que ser la "voz del cliente" y jugar el rol de "Product Owner", en estas situaciones generalmente el que toma este rol es el Analista Funcional o en algunos casos el Focal Point u otro.

2 2 de 5 07/09/ :10 p.m. PCS.DIR - Dirección PCS.NOC - Infraestructura PCS.OPE - Operaciones PCS.PMO - PMO PCS.RRHH - Recursos Humanos PCS.SGC - Gestión de Calidad PCS.SSPP - Servicios Profesionales PCS.SYM - Soporte y Mantenimiento Organization Charts Integrantes del Equipo / armado de lista de correo Es muy útil tener una lista de correo que contenga a todos los miembros del equipo ( convocar reuniones, compartir info, etc). Agregar en esta lista a los integrantes de QA y de ADG para que puedan participar en las retrospectivas. Configuración General Duración del Sprint. Ver los Criterios para elegir la duración de las Iteraciones Metodología y Herramientas Product Back-Log-Items del Backlog Los parametros a definir en relación al Producto Back-log y los items del Backlog que lo componen se describen y analizan en la siguiente tabla. Se resaltan en rojo aquellos parámetros que es prioritario definir durante la Iteración 0 Parámetro Cómo se representarán un IB? El Product Backlog se componen de Items del Backlog. Esto es reponder a la pregunta Qué técnica de requerimientos vamos a usar? O sea... Qué será para mí Proyecto un Backlog Item? Dónde se gestionarán los IB? Por gestion entendemos administración: en qué estado está, quién lo tiene asignado, si hay dudas asociadas a él. La documentación de los Items del Backlog no se realiza necesariamente en la misma herramienta que la gestión Análisis de Alternativas Ver en esta página tipos de items utilizados (Caso de Uso, User Story, etc )y criterios para decidir cuál usar En las sucesivas iteracciones pueden surgir nuevos tipos de Backlogs Items como ser: Bugs, Change Request, etc Jira / Jira + Green Hopper: es la opción que se debería usar salvo que exista alguna razón importante para no hacerlo Ver más info en HWT. Administración del Backlog en Jira Y... si El cliente/ Product Owner no conoce el Jira? Sin duda, vale la pena invertir un tiempo en "venderle" la herramienta. Organizar demo/capacitacion (usar video?) Jira de Globallogic con proyecto definido como "Proyecto Velocity" Velocity es un conjunto de plugins desarrollados por Globallogic que agregan muchas funcionalidades al Jira. Ver espacio de velocity Ver Requirements Management y Manejo de Requerimientos en Velocity Si no puede ser el Jira: Planilla Google Docs: lo bueno es que maneja concurrencia Excel: es una opción práctica si se actualiza en forma centralizada Dónde se documentarán los IB? Jira: es adecuado siempre y cuando haya muy poco para documentar (una descripcion textual simple). Cuando la funcionalidad es más compleja, y si las dudas se manejan por Jira como idas y vueltas de issues, termina generándose mucha confusión porque la funcionalidad no queda clara: hay que andar rastreando la historia del issue para entender. En estos casos considerar usar el Confluence Confluence: la opción más recomendable para funcionalidades con cierta complejidad. Features a destacar: Ver Prácticas de Confluence para documentar los Items del Backlog Soporte colaboracion y Documentación Agil, facilidad publicación, preguntas como comentarios a páginas, versionado, linkeo modelo de dominios, manejo de permisos ventaja para trabajo remoto: ej fono-conferencia sobre documentos --> dudas y actualizacion on-line Exportacion a PDF sofisticada (pasemos a la version 3! ) y Word Es tambien el enfoque que utilizan en Globallogic Doc en Repositorio. documento Word/Open Office en SVN/CVS. Habría que usar esta opción cuando hay una demanda del lado del cliente y el formato de exportación del Confluence no resulta adecuado Cómo se medirá el tamaño de los IB? Ver formas de medir el tamaño en MET.DDS - Tamaño Workflow de los IB Si se usa el Jira para gestionar los IB... Que Workflow se utilizará para los IB? Default Customizado Ver Customizar Workflow Item del Backlog Dónde se gestionarán las tareas asociadas a los IB? Tablero de Tareas: es muy recomendable usarlo ya que funciona como un Radiador de Información y las daily meetings son mucho más efectivas.es más complicado de llevar con equipos distribuídos (ver tips) Jira: como contra se pierde visibilidad de la iteracion para el equipo y las ventajas para las daily. A favor, si se carga consistemente, se puede obtener el burdown. También se puede tener el Tablero de tareas del GreenHopper No se gestionan tareas. Se corre el riesgo de no tener visibilidad temprana de desvios y de no

3 3 de 5 07/09/ :10 p.m. tomar acciones a tiempo. No se pueden cuantificar desvíos en las estimaciones. Las dailies pierden foco (si no divido en tareas como reporto el avance?) Si se usa Jira y Tablero de Tareas, cómo se va articular la información? Esto implicaría alguna redunduncia de información y por eso es importante pensar en algo práctico En Jira se cargan solamente los IB y las tareas se llevan solamente en el Tablero de Tareas. esta opción es bastante recomendable ya que se tiene visiblilidad de la iteracion en el espacio de trabajo y se tienen las ventajas para las daily. También agiliza el Sprint Planning ya que las tareas se cargan en el Tablero durante dicha reunión. Además, la redundancia es baja porque lo único que se repite en Jira y Tablero son los items del backlog * En Jira y en el Tablero se cargan IB y tareas. Hay más redundancia que el Scrum Master tiene que mantener (ver tips) Dónde se va a llevar el Sprint Burdown Chart? Tablero de Tareas. Tiene gran la ventaja que el equipo siempre tiene visible el estado de la iteración. ver tips para dibujarlo Jira. ver GreenHopper. Esto es compatible con llevar las tareas solamente en el Tablero: cuando se termina un IB, se actualiza el jira y se queman las horas/sp correspondientes. O sea, se admite un poco de retraso en la actualización del jira para simplificar la carga Excel: las contras que tiene son que hay que armar planillas ad-hoc y que, en la práctica como hay que andar imprimiendolo para pegarlo, muchas veces esto no se hace, y el equipo no tiene la visibilidad que da el gráfico No se lleva. los mismos riesgos y problemas de no gestionar tareas. Solapamientos entre roles e iteraciones Cómo se solapa el trabajo de los distintos roles? A continuación se analizan 3 esquemas, del más orientado a Scrum al menos orientado a Scrum: Análisis, Desarrollo y Testing en la misma iteración: Esta es la opción de trabajo que porpone Scrum, en la cual se hace un poco de todo, todo el tiempo. Todos los roles trabajan con mucho solapamiento sobre la misma funcionalidad Análisis Defasado de Desarrollo y Testing: muchas veces no hay un Product Owner suficientemente involucrado, o llegar definir la funcionalidad es más complejo que interactuar con un único Product Owner. En estos casos, y también más en general, puede ser conveniente que el Analista se "adelante" algo para ir digiriendo el análisis y allanando el camino Esta opción no hay que entenderla como "todo el análisis tiene que estar detallado y escrito" antes de que empiece la iteración. El analista, como todos los miembros del equipo, deben poner el foco en cumplir el objetivo de la iteración actual. la idea es que el analista dedique parte de su tiempo a adelantarse Análisis, Desarrollo y Testing en distintas iteraciones: La menos recomendada de todas las opciones, porque traspasa la cultura de la metodología en cascada a Scrum, y muchas veces, este esquema se da cuando no hay un equipo interdisciplinario como propone Scrum. Podría ser una opción para arrancar, pero habría que ir dando coaching al equipo para salir de este esquema Definir Criterio de Terminado/DONE Cuando decimos que al final de una iteracion un determinado Item de Backlog va a estar terminado... qué queremos decir exactamente?: qué va a estar desarrollado pero falta testearlo? qué va a estar listo para poner en producción, dado que ya se realizo el test? Entonces, esta pregunta está directamente relacionada con cómo se sopala el trabajo de los distintos roles. Estas opciones que se detallan en las siguientes secciones Análisis, Desarrollo y Testing en la misma iteración Análisis Defasado de Desarrollo y Testing

4 4 de 5 07/09/ :10 p.m. Análisis, Desarrollo y Testing en distintas iteraciones Forma de medir la velocidad Las formas posibles de medir la velocidad se discuten en la página MET.DDS - Velocidad Espacio de Trabajo Informativo El Espacio de Trabajo Informativo es el espacio destinado a publicar y comunicar el estado y progreso de cada backitem del Iteración (Sprint) y el Product Backlog. En el mismo también, se recomienda incorporar la comunicación de las metricas asociadas al proyecto (Velocidad, bugs, etc) Cuáles de las Prácticas de Espacio de Trabajo Informativo aplican para nuestro proyecto? Algunas de las practicas que se han estado utilizando son: Pizzaron Jira Jira + Green Hoper Tablero de Tareas Duracion del Sprint Tendremos que definir la duración que tendrán los Sprints (Iteraciones) en el proyecto. Es importante recordar que la duración de la misma deberá ser constante, pero pueden darse casos en los cuales la misma se deba ajustar. Si la duración es corta (ej 2 semanas) se obtiene feed-back más rápido y en consecuencia se puede aprender más rápido. Como desventaja está que el overhead

5 5 de 5 07/09/ :10 p.m. (Sprint Planning + Retro) que implica el uso de Scrum es mayor. También con iteraciones más cortas hay menos probabilidades de recuperarse de los errores. Parametrizacion de Reuniones Sprint Planning Estimacion y asignacion Estimamos y después asignamos? Esto lleva a estimaciones compartidas por el equipo lo cual favorece la mentalidad "Estamos todos en el mismo barco", que se promueve en los proyectos ágiles. Otra forma de organizar las estimaciones, quizás más clásica, es "estima la persona que lo va hacer" Vamos a usar Planning Poker en el Sprint Planning? StandUp Meetings Una clave para implmentar exitosamente Scrum es hacerlo un hábito, entonces es fundamental la regularidad. Por esto conviene que el grupo acuerde los siguientes parámetros: Demo lo recomendado es hacerla a la mañana temprano o al final del día siempre en el mismo horario. Las preguntas/la forma de hablar, cambia un poco según el horario. si se elige a la mañana se puede implementar la alcancia como protocolo para cumplir horario Frecuencia Daily sería la práctica "default" Si el proyecto es chico podría hacerse con una frecuencia menor, pero hay que tener cuidado que esto no lleve a degradar la práctica, ni a problemas que no se ataquen a tiempo Lugar de StandUp Meeting Las demos se deben realizar antes de dar por terminado el Sprint o Iteración y es conveniente predefinir los siguientes parámetros para apoyar la realización de las mismas: Lugar de realización: Maquina de..., Sala X, en el Cliente, etc Invitados externos posibles: Ejemplo: Socios, Personas de otros equipos, ADG, Calidad, PMO, etc. Retrospectiva Se deberán definir los siguientes parámetros para su realización: Lugar de realización: Maquina de..., Sala X, en el Cliente, etc Invitados externos posibles: Ejemplo: Socios, Personas de otros equipos, ADG, Calidad, PMO, etc Children (3) Criterios para elegir la duración de las Iteraciones Definición Parametricación de Scrum Solapamiento Roles Printed by Atlassian Confluence , the Enterprise Wiki.