lineamientos.md

Scrum

Valores

• Valorar a las personas y las interacciones entre ellas por sobre los procesos y las herramientas: Las personas son el principal factor de éxito de un proyecto de software. Es más importante construir un buen equipo que construir el contexto. Muchas veces se comete el error de construir primero el entorno de trabajo y esperar que el equipo se adapte automáticamente. Por el contrario, la agilidad propone crear el equipo y que éste construya su propio entorno y procesos en base a sus necesidades.

• Valorar el software funcionando por sobre la documentación detallada: La regla a seguir es "no producir documentos a menos que sean necesarios de forma inmediata para tomar un decisión importante". Estos documentos deben ser cortos y centrarse en lo esencial. La documentación (diseño, especificación técnica de un sistema) no es más que un resultado intermedio y su finalidad no es dar valor en forma directa al usuario o cliente del proyecto. Medir avance en función de resultados intermedios se convierte en una simple "ilusión de progreso".

• Valorar la colaboración con el cliente por sobre la negociación de contratos: Se propone que exista una interacción constante entre el cliente y el equipo de desarrollo. Esta mutua colaboración, será la que dicte la marcha del proyecto y asegure su éxito.

• Valorar la respuesta a los cambios por sobre el seguimiento estricto de los planes: La habilidad de responder a los cambios que puedan surgir a lo largo del proyecto (cambios en los requisitos, en la tecnología, en el equipo, etc.) determina también su éxito o fracaso. Por lo tanto, la planificación no debe ser estricta sino flexible y abierta.

Principios

Los valores anteriores son los pilares sobre los cuales se construyen los doce principios de la metodología ágil SCRUM en la cual está fundamentada SCRUM/OAS. De estos doce (12) principios, los dos (2) primeros son generales y resumen gran parte del espíritu ágil del desarrollo de software, mientras que los siguientes son más específicos y orientados al proceso o al equipo de desarrollo: Nuestra mayor prioridad es satisfacer al cliente a través de entregas tempranas y frecuentes de software con valor. Aceptar el cambio incluso en etapas tardías del desarrollo. Los procesos ágiles aprovechan los cambios para darle al cliente ventajas competitivas. Entregar software funcionando en forma frecuente, desde un par de semanas a un par de meses, prefiriendo el periodo de tiempo más corto. Expertos del negocio y desarrolladores deben trabajar juntos diariamente durante la ejecución del proyecto. Construir proyectos entorno a personas motivadas, generándoles el ambiente necesario, atendiendo sus necesidades y confiando en que ellos van a poder hacer el trabajo. La manera más eficiente y efectiva de compartir la información dentro de un equipo de desarrollo, es la conversación cara a cara. El software funcionando es la principal métrica de progreso. Los procesos ágiles promueven el desarrollo sostenible. Los sponsors, desarrolladores y usuarios deben poder mantener un ritmo constante indefinidamente. La atención continua a la excelencia técnica y buenos diseños incrementan la agilidad. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial. Las mejores arquitecturas, requerimientos y diseños emergen de equipos auto-organizados. A intervalos regulares, el equipo reflexiona acerca de cómo convertirse en más efectivos, luego mejora y ajusta su comportamiento adecuadamente.

Información general

Figura 1-1 proporciona una visión general de flujo de un project Scrum.

Scrum es una de las metodologías ágiles más populares. Es una metodología de adaptación, iterativa, rápida, flexible y eficaz, diseñada para ofrecer un valor significativo de forma rápida en todo el proyecto. Scrum garantiza transparencia en la comunicación y crea un ambiente de responsabilidad colectiva y de progreso continuo. El marco de Scrum, está estructurado de tal manera que es compatible con los productos y el desarrollo de servicio en todo tipo de industrias y en cualquier tipo de proyecto, independientemente de su complejidad. Una fortaleza clave de Scrum radica en el uso de equipos multi-funcionales, auto-organizados, y con poder que dividen su trabajo en ciclos de trabajo cortos y concentrados llamados Sprints.

Historias de usuario

Las Historias de Usuario surgieron en eXtremme Programming (XP) como una respuesta a una situación habitual en los proyectos de desarrollo de software: los clientes o especialistas de negocio se comunican con los equipos de desarrollo a través de extensos documentos conocidos como especificaciones funcionales. A su vez, las especificaciones funcionales son la documentación de supuestos y están sujetas a interpretaciones, lo que causa malos entendidos y que finalmente el software construido no se corresponda con la realidad esperada.

Componentes de historia de usuario

Una Historia de Usuario se compone de 3 elementos, también conocidos como “las tres Cs” de las Historias de Usuario:

• Card (Ficha): Toda historia de usuario debe poder describirse de manera corta en una ficha. Si una Historia de Usuario no puede describirse en ese tamaño, es una señal de que estamos traspasando las fronteras y comunicando demasiada información que debería compartirse cara a cara.
• Conversación: Toda historia de usuario debe tener una conversación con el Product Owner. Una comunicación cara a cara que intercambia no solo información sino también pensamientos, opiniones y sentimientos.
• Confirmación: Toda historia de usuario debe estar lo suficientemente explicada para que el equipo de desarrollo sepa qué es lo que debe construir y qué es lo que el Product Owner espera. Esto se conoce también como Criterios de Aceptación.

Redacción de historia de usuario

La redacción para una historia de usuario debe cumplir los siguientes criterios:

• Primera Persona: La redacción en primera persona de la Historia de Usuario invita a quien la lee a ponerse en el lugar del usuario.

• Priorización: Tener esta estructura para redactar la Historia de Usuario ayuda al Product Owner a priorizar. Si el Product Backlog es un conjunto de ítems como “Permitir crear un evento tentativo”, “Confirmar un evento tentativo”, “Notificar al responsable de logística”, “Ver el estado de inscripciones”, etc. el Product Owner debe trabajar más para comprender cuál es la funcionalidad, quién se beneficia y cuál es el valor de la misma.

• Propósito. Conocer el propósito de una funcionalidad permite al equipo de desarrollo plantear alternativas que cumplan con el mismo propósito en el caso de que el costo de la funcionalidad solicitada sea alto o su construcción no sea viable.

Definición de terminado

También conocido como Definition of Done, es el conjunto de características que una Historia de Usuario debe cumplir para que el equipo de desarrollo pueda determinar si ha terminado de trabajar en ella. Un típico criterio de “Terminado” podría ser:

Todos los criterios de aceptación funcionan correctamente Todos los archivos fuentes están en el repositorio de código fuente y el build se ejecutó exitosamente. El Product Owner da su visto bueno de la funcionalidad construida antes de llegar a la Review Meeting.

Proceso de Scrum

FASE	PROCESOS
1. Iniciar	1.1 Crear la visión del proyecto: En este proceso, crear un Declaración de la Visión del Proyecto que servirá de inspiración y proporcionará un enfoque de todo el proyecto.
	1.2 Crear documento plan general del proyecto: define los parámetros para realizar el direccionamiento y seguimiento al proyecto. Especifica los objetivos. Describe cómo está organizado el proyecto y cuales son los recursos requeridos para su consecución (Tiempo, Tecnológicos, Financieros, Físicos y Humanos entre otros).
	1.3 Modelo relacional: es la representación en tablas (esquema) del proyecto, el cual es prácticamente un paso antes del nivel físico debe ir aprobado por el comité conformado en la oficina, este se realizará por medio de la app dBeaver.
	1.4. Identificar al Scrum Master y al Stakeholder(s)): En este proceso, el Scrum Master y el Stakeholder se identifican utilizando criterios de selección específicos.
	1.5 Formación de un equipo Scrum: En este proceso, se identifican a los miembros del Equipo Scrum. Normalmente, el Product Owner es el responsable principal de la selección de los miembros del equipo, pero a menudo lo hace en Colaboración con el Scrum Master.
	1.6 Realizar un cronograma general: Se debe establecer un cronograma sencillo de todo el proyecto mostrando el tiempo de cada fase https://docs.google.com/spreadsheets/d/1hj1uVEhrfIl1-25Ayv4XknFHCc5cBuar-QF7cfSL0d8/edit
	1.7 Desarrollo de Epics: En este proceso, el Declaración de la Visión del Proyecto sirve como la base para el desarrollo de Epics.
	1.8 Creación de la lista priorizada de pendientes del producto. En este proceso, Epic(s) son refinados, elaborados, y luego priorizados para crear un Prioritized Product Backlog. Los Criterios de aceptación también se establecen en este punto.
	1.9 Realizar el plan de lanzamiento: En este proceso, el Equipo de Scrum revisa los Historias de Usuario en el Prioritized Product Backlog para desarrollar un Release Planning Schedule, que es esencialmente un programa de implementación por fases que se puede compartir con los socios del projecto
2. Planear y estimar	2.1 Levantamiento de proceso a desarrollar (flujograma, prototipo e historia de usuario): El flujograma debe estar en jbpm, el prototipo en pencil y la historia de usuario en Tuleap teniendo en cuenta las características de esta guía, de igual manera las historias de usuario deben estar relacionadas con un epic.
	2.2 Aprobar, estimar y asignar historias de usuarios: En este proceso, el Producto Owner aprueba los User Stories para un Sprint. Luego, el Scrum Master y el Equipo Scrum estiman el esfuerzo necesario para desarrollar la funcionalidad descrita en cada historia de usuario, y el Equipo Scrum se compromete a entregar los requisitos del customer en forma de Approved, Estimated, and Committed User Stories.
	2.3 Elaboración de tareas: En este proceso, los Approved, Estimated, and Committed User Stories se dividen en tareas específicas y se compilan en un Task List. A menudo, un Task Planning Meeting se convocará al efecto.
	2.4 Estimar tareas: En este proceso, el Equipo Principal de Scrum durante reuniones de Estimación del Labor estima el esfuerzo necesario para realizar cada tarea del listado de tareas. El resultado de este proceso es un Effort Estimated Task List.
	2.5 Elaboración de la lista de pendientes del Sprint (Create Sprint Backlog): En este proceso, el Equipo Principal de Scrum lleva a cabo un Sprint Planning Meeting donde el grupo crea un Sprint Backlog que contiene todas las tareas que deben completarse en el Sprint.
3. Implementar	3.1 Crear entregables: En este proceso, el Equipo Scrum trabaja en las tareas del Sprint Backlog para crear Sprint Deliverables. Se utiliza a menudo un Scrumboard para realizar el seguimiento del trabajo y de actividades que se llevan a cabo. Las cuestiones o problemas que enfrenta el Equipo Scrum podrían ser actualizadas en un Impediment Log.
	3.2 Llevar a cabo el Sprint Standup diario: En este proceso, todos los días se lleva a cabo una reunión que es Time-box altamente concentrada que se refiere como Daily Standup Meeting. Es aquí donde los miembros del Equipo Scrum se actualizan el uno al otro referente a sus progresos y sobre los Impedimentos que puedan enfrentar.
	3.3 Mantenimiento de la lista priorizada de pendientes del producto: En este proceso, el Prioritized Product Backlog se actualiza y se mantiene continuamente. Un Prioritized Product Backlog Review Meeting puede ser considerado, en el que se discute y se incorpora el Prioritized Product Backlog de forma apropiada.
4. Revisión y feedback	4.1 Demostración y validación del Sprint: En este proceso, el Equipo Scrum le demuestra el Sprint Deliverable al Propietario del producto y a los Socios relevantes en un Sprint Review Meeting. El propósito de esta reunión es asegurar la aprobación y aceptación del Propietario del producto de los Entregables creados en el Sprint.
	4.2 feedback de Sprint: este proceso, el Scrum Master, el product owner y el Equipo Scrum se reúnen para discutir las lecciones aprendidas a lo largo del Sprint. Esta información se documenta como las lecciones aprendidas que pueden aplicarse a los futuros Sprints. A menudo, como resultado de esta discusión, puede haber Agreed Actionable Improvements o recomendaciones actualizadas por parte del Cuerpo de asesoramiento de Scrum.
5. Lanzamiento	5.1 Envío de entregables: En este proceso, el Equipo Scrum le demuestra el Sprint deliverable al Propietario del producto y a los Socios relevantes en un Sprint Review Meeting. El propósito de esta reunión es asegurar la aprobación y aceptación del Propietario del producto de los Entregables creados en el Sprint.
	5.2 feedback del proyecto: En este proceso, que completa el proyecto, los socios, el product owner y el Equipo Scrum se reúnen para hacer una feedback del proyecto e identificar, documentar e internalizar las lecciones aprendidas. A menudo, estas lecciones llevan a la documentación de Agreed Actionable Improvement, que se aplicará en futuros proyectos.