TECNOLOGIA DE DESARROLLO DE SOFTWARE - SCRUM
La programación extrema (XP) es un enfoque de desarrollo de software que toma lo que generalmente designamos como buenas prácticas de desarrollo de software y las lleva al extremo. ◦ XP define con rapidez un plan global, ◦ Desarrolla, ◦ Libera rápidamente el software ◦ Después lo revisa de manera continua para agregarle características adicionales. Los programadores de XP trabajan en parejas para desarrollar sistemas de calidad. Los cuatro valores de XP que son compartidos por el cliente comercial así como también por el equipo de desarrollo son: ◦ Comunicación, ◦ Sencillez, ◦ Retroalimentación y ◦ Valentía.
Los cinco principios básicos de XP consisten en : ◦ proporcionar una retroalimentación rápida; ◦ adoptar la simpleza al abordar una nueva tarea de programación. ◦ Cambiar el código, el diseño, e incluso al equipo de desarrollo, de manera gradual; ◦ aceptar el cambio como un estado normal del trabajo, ◦ hacer un trabajo de calidad.
Las cuatro prácticas esenciales de XP son: ◦ (1) liberación limitada; ◦ (2) semana de trabajo de 40 horas; ◦ (3) cliente en el sitio, y ◦ (4) programación en parejas.
Dichas prácticas distinguen a la programación extrema de otros procesos de desarrollo de sistemas.
Las cinco fases amplias en el proceso de desarrollo de XP son la: ◦ exploración, ◦ planeación, ◦ las iteraciones a la primera versión, ◦ puesta en producción y ◦ mantenimiento.
Hay seis lecciones que aprender del enfoque de XP son: las liberaciones en corto permiten evolucionar a los sistemas. la programación en parejas refuerza la calidad global. los clientes en el sitio y el equipo de XP se benefician mutuamente. la semana de trabajo de 40 horas mejora la eficiencia. los recursos y actividades equilibrados apoyan las metas del proyecto. los valores de XP son fundamentales para el éxito.
Scrum es una metodología 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 esta 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.
Es un proceso en el que se aplican de manera regular un conjunto de mejores practicas para trabajar en equipo, y obtener el mejor resultado de un proyecto.
BENEFICIOS QUE PROPORCIONA SCRUM:
Entrega mensual de resultados, lo cual proporciona gestión regular de las expectativas del cliente, resultados anticipados, flexibilidad y adaptación, gestión de sistemática del retorno de inversión.
Productividad y calidad.
Alineamiento entre cliente y el equipo de desarrollo.
Equipo motivado.
ROLES DE SCRUM: Se definen varios roles divididos en 2 grupos: ROLES “CERDO” – son los que están comprometidos con el proyecto y el proceso scrum. ROLES “GALLINA” – en realidad no son parte del proceso Scrum, pero deben tenerse en cuenta.
BENEFICIOS QUE PROPORCIONA SCRUM:
Entrega mensual de resultados, lo cual proporciona gestión regular de las expectativas del cliente, resultados anticipados, flexibilidad y adaptación, gestión de sistemática del retorno de inversión.
Productividad y calidad.
Alineamiento entre cliente y el equipo de desarrollo.
Equipo motivado.
ROLES DE SCRUM: Se definen varios roles divididos en 2 grupos: ROLES “CERDO” – son los que están comprometidos con el proyecto y el proceso scrum. ROLES “GALLINA” – en realidad no son parte del proceso Scrum, pero deben tenerse en cuenta.
Ellos son los que “ponen el jamón en el plato”.
Product owner – representa la voz del cliente. Se asegura de que el equipo scrum trabaja de forma adecuada desde la perspectiva del negocio.
ScrumMaster – su trabajo es eliminar los obstáculos que le impiden al equipo alcanzar sus objetivos del sprint.
Equipo – tiene la responsabilidad de entregar el producto.
Un aspecto importante de una aproximación ágil es la practica de involucrar en el proceso a los usuarios, expertos y otros interesados. Es importante que esa gente participe y entregue retroalimentación con respecto a la salida del proceso a fin de revisar y planear cada sprint.
Usuarios – es el destinatario final del producto.
Stakeholders – es la gente que hace posible el proyecto y para quienes el proyecto producirá el beneficio acordado que lo justifica.
Managers – es la gente que establece el ambiente para el desarrollo del producto.
En scrum un proyecto se ejecuta en bloques temporales cortos y fijos.
Planificación de la iteración que consta de 2 partes: - selección de requisitos - planificación de la iteración
Ejecución de la iteración
Inspección y adaptación - demostración - retrospectiva
Daily scrum - Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto se llama "daily standup". El scrum tiene unas guías específicas:
La reunión comienza puntualmente a su hora. A menudo hay castigos -acordados por el equipo- para quien llegue tarde.
Todos son bienvenidos, pero sólo los "cerdos" pueden hablar.
La reunión tiene una duración fija de 15 minutos, de forma independiente del tamaño del equipo.
Todos los asistentes deben mantenerse de pie.
La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días
Scrum de scrum - Cada día normalmente después del “Daily Scrum”
Estas reuniones permiten a los grupos de equipos discutir su trabajo, enfocándose especialmente en áreas de solapamiento e integración.
Asiste una persona asignada por cada equipo.
Reunion de planificación del sprint - Al inicio del ciclo Sprint (cada 15 o 30 días), una “Reunión de Planificación del Sprint” se lleva a cabo.
Seleccionar qué trabajo se hará.
Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que tomará hacer el trabajo.
Identificar y comunicar cuánto del trabajo es probable que se realice durante el actual Sprint.
Ocho horas como límite.
Reunión de revisión del sprint - Revisar el trabajo que fue completado y no completado.
Presentar el trabajo completado a los interesados (alias “demo”).
El trabajo incompleto no puede ser demostrado.
Cuatro horas como límite.
Retrospectiva del sprint - Después de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los miembros del equipo dejan sus impresiones sobre el sprint recién superado. El propósito de la retrospectiva es realizar una mejora continua del proceso. Esta reunión tiene un tiempo fijo de cuatro horas.
Product backlog - es un documento de alto nivel para todo el proyecto.
Contiene
descripciones
genéricas
de
todos
los
requerimientos, funcionalidades deseables, etc. priorizadas según su retorno sobre la inversión (ROI) . Es el qué va a ser construido. Es abierto y cualquiera puede modificarlo. Contiene estimaciones grosso modo, tanto del valor para el negocio,
como
del
esfuerzo
de
desarrollo
requerido.
Esta
estimación ayuda al product owner a ajustar la línea temporal y, de manera limitada, la prioridad de las diferentes tareas. Por ejemplo,
si dos características tienen el mismo valor de negocio la que requiera menos tiempo de desarrollo tendrá probablemente más prioridad, debido a que su ROI será más alto.
Sprint backlog - El sprint backlog es un documento detallado donde se describe el cómo el equipo va a implementar los requisitos
durante el siguiente sprint. Las tareas se dividen en horas con ninguna tarea de duración superior a 16 horas. Si una tarea es mayor de 16 horas, deberá ser rota en mayor detalle.
Burn down - es una gráfica mostrada públicamente que mide la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una línea que conecte los puntos de
todos los Sprints completados, podremos ver el progreso del proyecto. Lo normal es que esta línea sea descendente hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado.
Aunque
surgió
como
modelo
para
el
desarrollo
de
productos
tecnológicos, también se emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de software.
La ficha adjunta incluye una descripción sinóptica del proceso y sus elementos que son:
Roles: Propietario del producto, Gestor o Manager del Scrum, Equipo e Interesados.
Componentes del proceso: Pila del producto (Product Backlog), Pila del sprint (Sprint Backlog), Incremento.
Reuniones:
Planificación del sprint, Revisión diaria, Revisión del sprint.
Sprint
En grupos de 3 alumnos para repartirse los roles del “cerdo” es decir, el rol de product owner, scrumMaster y equipo.
Ellos realizaran el proceso del proyecto con las siguientes etapas, por ahora deben discutir los roles que tendrán y las bases para el proyecto.
También se pueden asignar los 3 roles de la “gallina” los cuales son usuarios, stakeholders y manager.
La falta de atención a los detalles :
Muchas equipos fracasan en la implantación de Scrum porque desatienden los detalles. ◦ Los detalles son vitales en Scrum. ◦ Sin Daily Scrum, no hay Scrum. ◦ Sin Product Backlog, no hay Scrum. ◦ Sin Product Owner, sin Equipo y sin Scrum Master, no hay Scrum. ◦ Sin Sprint Planning Meeting, no hay Scrum. ◦ Sin Sprint Review, no hay Scrum.
Entender y formar el equipo multidisciplinar :
Construir un equipo es muy difícil y construir uno multidisciplinar aun más.
Un equipo multidisciplinar es sumamente productivo y además minimiza los riesgos asociados a la rotación de personal y las 'parcelitas' de conocimiento, por todos conocidos.
Entender y comprender como funciona un buen equipo.
Crear y mantener un product backlog :
Construir el product backlog y estimarlo es algo complejo.
Se trata de capturar los requisitos del sistema y esto siempre ha sido problemático para los implicados en el desarrollo de software.
La mayor dificultad surge a la hora de mantenerlo actualizado e ir refinándolo de manera continua.
El Scrum Master debe 'persegir' al Product Owner para conseguir su implicación total en el mantenimiento del Product Backlog.
Recursos no dedicados :
Los cambios de contexto son el problema silencioso de muchos equipos de
desarrollo. Cuando un equipo es sometido a continuos cambios de contexto, a continuos cambios de enfoque, difícilmente será productivo.
En este caso el antídoto es difícil de aplicar, pues pasa a menudo por un cambio de cultura en la empresa, a menudo acostumbrada a tratar todas las tareas de manera prioritaria, atendiendo en cada momento el asunto que más 'ruido'
provoca y renunciando con este comportamiento a la posibilidad de establecer una planificación razonable.
La ausencia de una planificación razonable siempre lleva a mermas de productividad relacionadas con la ausencia de objetivos a corto plazo.
Integración de las tareas de soporte y mantenimiento :
Muchos equipos tienen dificultad a la hora del mantenimiento de versiones o productos anteriores con el desarrollo de nuevos proyectos.
La problemática es similar a la comentada para los recursos no dedicados. La idea es, en este caso también, perseguir el minimizar los cambios de contexto. En esta línea la mejor táctica es que sean equipos diferentes los que hacen mantenimiento y los que desarrollan nuevos productos.
Pero esto no es siempre posible. Otra táctica habitual es repartir el día entre actividades, por ejemplo utilizar las mañanas para desarrollar un nuevo producto y las tardes para las tareas de mantenimiento o soporte de versiones o productos anteriores. Evidentemente a la hora de planificar un Sprint tendremos que restar de la capacidad de nuestro equipo el esfuerzo que estimamos que tendremos que dedicar a tareas de mantenimiento y soporte
Estimación: Que la estimación es un aspecto complicado del desarrollo del software es por todos conocido y un tema que he tratado recurrentemente en este blog. En Scrum la estimación es aspecto central. Estimamos el Product Backlog y estimamos las tareas de cada Sprint. La estimación es el primer paso para todo el proceso de planificación tanto a medio como a corto plazo. Aquí el principal problema con el que me suelo encontrar es que los equipos no tienen experiencia en estimar, y por lo tanto se les hace difícil. Esta dificultad hace que muchos equipos recorten las actividades relacionadas con la estimación que Scrum propone. Es imposible hacer una planificación realista sin realizar las actividades de estimación. Además el realizar los procesos de estimación explicita que Scrum propugna conseguimos no solo una estimación realista sino que además aprovechamos el propio proceso de estimación para lograr información sobre qué debemos construir. Una obra indispensable para comprender la estimación y la planificación en las metodologías ágiles es Agile Estimating and Planning de Mike Cohn.
Si bien Scrum tiene sus dificultades a menudo es fácil diagnosticar si estamos funcionando en el marco de Scrum o no. Basta con comprobar, una a una, si estamos siguiendo las reglas de Scrum:
Las reglas de Scrum (I)- El Sprint Planning Meeting Las reglas de Scrum (II)- Durante el Sprint Las reglas de Scrum (III)- El Sprint Review Meeting Las reglas de Scrum (y IV)- El Sprint Retrospective Meeting Además de esto, las retrospectivas son un excelente momento en el que podemos averiguar si Scrum está funcionando o no: basta con escuchar al equipo para saber si Scrum les ayuda o no . Cuando Scrum no ayuda al equipo es que no está funcionando. Toda metodología que no ayude al equipo de desarrollo a trabajar mejor y con más facilidad, sufrira el rechazo de los desarrolladores. Con el rechazo de los desarrolladores, el grupo más numeroso en cualquier proyecto, ninguna metodología llega para quedarse, por mucho que alguien la empuje.
Integración de las tareas de soporte y mantenimiento :
Muchos equipos tienen dificultad a la hora del mantenimiento de versiones o productos anteriores con el desarrollo de nuevos proyectos.
La problemática es similar a la comentada para los recursos no dedicados. La idea es, en este caso también, perseguir el minimizar los cambios de contexto. En esta línea la mejor táctica es que sean equipos diferentes los que hacen mantenimiento y los que desarrollan nuevos productos.
Pero esto no es siempre posible. Otra táctica habitual es repartir el día entre actividades, por ejemplo utilizar las mañanas para desarrollar un nuevo producto y las tardes para las tareas de mantenimiento o soporte de versiones o productos anteriores. Evidentemente a la hora de planificar un Sprint tendremos que restar de la capacidad de nuestro equipo el esfuerzo que estimamos que tendremos que dedicar a tareas de mantenimiento y soporte
En grupos de 3 alumnos para repartirse los roles del “cerdo” es decir, el rol de product owner, scrumMaster y equipo.
Ellos realizaran el proceso del proyecto con las siguientes etapas, por ahora deben discutir los roles que tendrán y las bases para el proyecto.
También se pueden asignar los 3 roles de la “gallina” los cuales son usuarios, stakeholders y manager.
En grupos de 3 alumnos para repartirse los roles del “cerdo” es decir, el rol de product owner, scrumMaster y equipo.
Ellos realizaran el proceso del proyecto con las siguientes etapas, por ahora deben discutir los roles que tendrán y las bases para el proyecto.
También se pueden asignar los 3 roles de la “gallina” los cuales son usuarios, stakeholders y manager.
En grupos de 3 alumnos para repartirse los roles del “cerdo” es decir, el rol de product owner, scrumMaster y equipo.
Ellos realizaran el proceso del proyecto con las siguientes etapas, por ahora deben discutir los roles que tendrán y las bases para el proyecto.
También se pueden asignar los 3 roles de la “gallina” los cuales son usuarios, stakeholders y manager.
En grupos de 3 alumnos para repartirse los roles del “cerdo” es decir, el rol de product owner, scrumMaster y equipo.
Ellos realizaran el proceso del proyecto con las siguientes etapas, por ahora deben discutir los roles que tendrán y las bases para el proyecto.
También se pueden asignar los 3 roles de la “gallina” los cuales son usuarios, stakeholders y manager.