• Author / Uploaded
• alecamsa0481

• Categories
• Scrum (Desarrollo de software)
• Software
• Tecnología
• Business
• Informática y tecnología de la información

Citation preview

Indice

Introducción………………………………………………………………………………3 Método de desarrollo Agile Scrum…………………………………………………….4 Historia…………………………………………………………………………………4 Características del método de desarrollo Agile Scrum……………………………...7 Componentes de Scrum………………………………………………………………...8 Métricas de Scrum………………………………………………………………………13 Conclusión……………………………………………………………………………….15 Bibliografía………………………………………………………………………………..16

1

Introducción

Scrum es un método de desarrollo ágil de software muy simple, especialmente enfocado para proyectos donde se necesita obtener resultados pronto y los requerimientos son cambiantes según la necesidad del cliente. Scrum tiene como base la creación de ciclos breves para el desarrollo, llamados iteraciones, en Scrum se llaman Sprint. Este sprint por lo general tienen una duración de 2 a 4 semanas cada uno. Los sprint, producen un incremento de funcionalidad terminado y operativo. Cada sprint tiene una fecha de finalización. Se centra en los requerimientos con más prioridad y que pueden ser ejecutadas en un periodo corto de tiempo. Scrum gestiona su evolución a través de reuniones breves diarias en las que todo el equipo revisa el trabajo realizado el día anterior y el previsto para el día siguiente. Scrum es adaptable más que predictivo. Se enfoca a las personas más que a los procesos. Scrum tiene los siguientes componentes (elementos) de la metodología. 

Reuniones:  Planificación del Backlog  Seguimiento del Sprint  Revisión del Sprint



Herramientas  Product Backlog  Sprint Backlog  Incremento

2



Roles y responsabilidades

A. Son parte fundamental del proyecto.  Scrum Master  Product Owner  Scrum Team

B. No son parte del proceso Scrum.  Usuarios  Stakeholders  Managers



Practicas:

      

Sprints Sprint Planning Meeting Daily Meetings Sprint Review Meeting Design Review Meeting Stabilization Sprints Meta Scrums

3

Método de desarrollo Agile Scrum

Historia

El nombre Scrum proviene del deporte de Rugby. Donde se adquiere la idea de formar un grupo de jugadores alrededor del balón y todos trabajan juntos, en ocasiones con violencia para poder moverlo a través del campo.

Método de desarrollo ágil de software concebido por Jeff Sutherland a inicios de loa años 90 y elaborado más formalmente por Ken Schwaber. Poco después Sutherland y Schwaber se unieron para refinar y extender la metodología SCRUM y ha llegado a ser conocida como una herramienta de hiperproductividad. Schwaber se dio cuenta de que un proceso necesita aceptar el cambio, en lugar de esperar predictibilidad, esto enfocado en el hecho de que procesos definidos y repetibles sólo funcionan para atacar problemas definidos y repetibles con gente definida y repetible en ambientes definidos y repetibles. Tomar el cambio como una forma de entregar al final del desarrollo algo más cercano a la verdadera necesidad del Cliente fue entonces su solución. Scrum es flexible para gestionar el desarrollo de software. Su base consiste en construir primero la funcionalidad de mayor valor para el cliente. Esta metodología de trabajo promueve la innovación, motivación y compromiso del equipo que forma parte del proyecto, por lo que los profesionales encuentran un ámbito propicio para desarrollar sus capacidades.

4

Scrum se utiliza para guiar actividades de desarrollo dentro de un proceso de análisis que tiene las siguientes actividades estructurales:     

Requerimientos Análisis Diseño Evolución Entrega

Dentro de cada actividad las tareas del trabajo ocurren con un patrón del proceso llamado sprint. El trabajo realizado dentro de un sprint se adapta al problema en cuestión, se define y es muy usual que se pueda modificar en tiempo real por parte del equipo. La siguiente imagen muestra el Proceso Scrum.

Scrum utiliza un conjunto de patrones de proceso del software que son muy eficaces para proyectos con plazos de entrega muy cortos, requerimientos cambiantes y negocios críticos. Cada uno de estos patrones de proceso define un grupo de acciones de desarrollo: 

Retraso: Lista de prioridades de los requerimientos del proyecto que dan al cliente. Es posible agregar en cualquier momento otros requerimientos al retraso; de ésta manera es como se introducen los cambios. El gerente del proyecto evalúa el retraso y actualiza las prioridades según se requiera.

5



Sprints (iteración): Unidades de trabajo que se necesitan para alcanzar un requerimiento definido en el retraso que debe ajustarse en una caja de tiempo predefinida (días). Durante el sprint no se introducen cambios. Permite a los miembros del equipo trabajar en un ambiente de corto plazo pero estable. Las reuniones de seguimiento de cada sprint deben ser diarias.



Reuniones Scrum: Son reuniones breves (15 minutos) que el equipo efectúa a diario, dirigida por un líder llamado Maestro Scrum, que también evalúa las respuestas de cada persona. Hay tres preguntas clave que se pide que respondan todos los miembros del equipo, las cuales son:  ¿Qué hiciste desde la última reunión del equipo?  ¿Qué obstáculos estás encontrando?  ¿Qué planeas hacer mientras llega la siguiente reunión del equipo?

La junta Scrum ayuda al equipo a descubrir los problemas potenciales tan pronto como sea posible. 

Demostraciones preliminares: Entregar el avance de software al cliente de modo que la funcionalidad que se haya implementado pueda demostrarse al cliente y éste pueda evaluarla. Es importante aclarar que las demostraciones preliminares no contienen toda la funcionalidad planeada, sino que éstas se entregarán dentro de la caja de tiempo establecida.

Una caja de tiempo: Término de la administración de proyectos que indica el tiempo que se ha asignado para cumplir alguna tarea.

Características del método de desarrollo agile-Scrum. Flexibilidad a cambios: Diseñado para permitir realinear el software con los objetivos de negocio de su empresa en cualquier momento, ya que puede introducir cambios funcionales o de prioridad en el inicio de cada nueva iteración sin ningún problema. Reducción del Time to Market: El cliente puede empezar a utilizar las funcionalidades más importantes del proyecto antes de que esté finalizado por completo. Mayor calidad del software: Versión funcional después de cada iteración, ayuda a la obtención de un software de calidad superior. 6

Mayor productividad: Scrum divide un proyecto en iteraciones 15-30 días. Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio que aportan al receptor del proyecto. Maximiza el retorno de la inversión (ROI): Producción de software únicamente con las prestaciones que aportan mayor valor de negocio gracias a la priorización por retorno de inversión. Predicciones de tiempos: Durante cada sprint, un periodo entre 15 y 30 días, el equipo crea un incremento de software potencialmente entregable (utilizable). Reducción de riesgos: Llevar a cabo las funcionalidades de más valor en primer lugar y de conocer la velocidad con que el equipo avanza en el proyecto, permite despejar riesgos eficazmente de manera anticipada. Interés departe del Cliente: Con la metodología Scrum el cliente se entusiasma y se compromete con el proyecto dado que lo ve crecer iteración a iteración. El equipo desarrollador tiene una comunicación constante con el cliente. Sencillo: Scrum es muy fácil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar. También se enfoca principalmente en la planeación iterativa y el seguimiento del proceso. Orientado a personas: Scrum es orientados a objetos y no orientado a procesos. Entre otras características:     

Equipos autodirigidos Utiliza reglas para crear un entorno ágil de administración de proyectos No prescribe prácticas específicas de ingeniería Los requerimientos se capturan como ítems de la lista Product Backlog El producto se construye en una serie de Sprints de un mes de duración.

Componentes de Scrum: 

Reuniones  Planificación del Backlog: Reunión previa al comienzo de cada sprint: a) Requisitos del sistema por prioridades. 7

b) En el Sprint 0 se indican los objetivos a cumplir en esta iteración. c) Intervienen todos los roles. d) Sprint Backlog o lista de tareas que se van a realizar y el objetivo más importante del Sprint. Seguimiento del Sprint: Breve reunión diaria para repasar cada una de las tareas y el trabajo previsto de la jornada. 1. Solo interviene el equipo de desarrollo. 2. Cada miembro responde a tres preguntas fundamentales: a) Trabajo realizado desde la reunión anterior. b) Trabajo que se va a realizar hasta la próxima reunión de seguimiento. c) Problemas que se deben solucionar para realizar el trabajo propuesto. Revisión del Sprint: a) Análisis y revisión al finalizar el generado.

Sprint del incremento

b) Presentación de resultados, como demo o versión, esto ayudará al mejorar el feedback con el cliente.

8

Elementos:  Product Backlog: a) Todos los integrantes del equipo de desarrollo pueden acceder a él y aportar ideas. b) Lista creada por el cliente con ayuda del Scrum Master. c) Lista de requisitos o necesidades del cliente. d) Funcionalidades o requisitos en forma de lista priorizada, que el producto irá adquiriendo en sucesivas iteraciones.

 Sprint Backlog: a) b) c) d)

Lista de trabajos que realizará el equipo durante el sprint. Incremento previsto para el sprint. Compromiso de ejecución. Asignación de tareas a cada persona, con estimaciones de tiempo y recursos necesarios. 9

 Incremento: a) Demostración de los objetivos alcanzados en cada sprint. b) Asistencia de todos los roles. c) Según los resultados mostrados, el cliente puede ir haciendo cambios necesarios e ir replanteando el proyecto. d) Solo el Scrum Master puede abortar un sprint debido a que la tecnología seleccionada no funciona o es incompatible con los objetivos definidos, cambian las circunstancias del negocio, el Scrum Team ha tenido inferencias.

10



a) b) c) d) e) f) g)

a) b) c) d) e) f) a) b) c) d)

Roles y responsabilidades Personas que están comprometidas con el proyecto y el proceso Scrum.  Scrum Master: Selecciona los procesos y trabaja de forma similar al director de proyecto. Los equipos son conformados por 10 personas con jerarquías, esta metodología es aplicada a proyectos que involucran a más de 600personas. Responsable del área de gestión de proyectos, tiene el conocimiento sobre desarrollo ágil y facilita los recursos necesarios. Comprueba que el modelo y metodología funciona. Interactúa con el cliente. Indica al cliente el coste estimado para completar cada requisito. Velar por el buen funcionamiento del equipo de desarrollo.  Product Owner: Conoce sobre el entorno del negocio del cliente y la visión del producto. Propietario del Producto. Responsable de la Financiación del Proyecto. Representa a los stakeholders (clientes externos o internos). Se encarga de escribir las ideas del cliente y las ordena por prioridad. Crea y mantiene en detalle el product backlog.  Scrum Team: Grupo pequeño que van desde 5 – 9 personas. Incluye a los desarrolladores. Se auto-gestionan y se auto-organizan. Cubren todas las habilidades necesarias para generar el resultado.

No son parte del proceso Scrum, pero son importantes para la retroalimentación de la salida del proceso y de esa manera planear y revisar cada Sprint. a) Usuarios: Destinario final del producto. 11

b) Stakeholders: Personas a las que el proyecto les producirá un beneficio. Participan en las revisiones de los Sprints. c) Managers: Toma las decisiones finales participando en la selección de los objetivos y de los requisitos.

Métricas de Scrum Las métricas constituyen un disparador para analizar la productividad y el desempeño del equipo con el fin de detectar falencias y aciertos. Estas métricas fueron útiles para ganar previsibilidad en los trabajos o proyectos a desarrollar y así cumplir los objetivos del proyecto y lograr sobre todo la satisfacción del cliente y evitar el fracaso en el proyecto. Puesto que uno de los principales motivos es la falta o inadecuada planificación y un punto crucial en las planificaciones es la estimación del tamaño del producto. 12

En Scrum se suele utilizar user stories como unidad de requerimiento (registrarlos) aunque el rol especifico lo tiene el product owner que es el encargado de transmitir oralmente los deseos, necesidades y expectativas, los user story son usados en la sesión de planning y en daily meeting para que el equipo pueda determinar la funcionalidad y conozca en que grado se encuentra. Las mismas se pueden estimar a través de una medida de tamaño relativa: story points. Con el fin de disponer de métricas para tener conocimiento del rendimiento del equipo y lograr mejorarlo, Sutherland et al [7] definieron e implementaron el siguiente conjunto de métricas: Velocity. Determina qué tamaño de software (que satisfaga al product owner) el equipo puede conseguir en un sprint. Es la suma de los story points originalmente estimados para cada story, pero considerando solamente las user stories que fueron aprobadas por el product owner. Work capacity. Determina el tamaño del trabajo que puede hacer un equipo en un sprint. El equipo puede haber dedicado esfuerzo a user stories que no fueron aceptadas por el product owner, y work capacity es la suma de todo el esfuerzo reportado durante el sprint, haya resultado en una user story aceptada o no. Focus factor. Determina qué porcentaje del esfuerzo invertido termina siendo aceptado por el cliente. Se define como velocity / work capacity. Adopted work. El equipo es el que determina qué user stories se compromete a realizar, por lo cual, esta medida se define como el cociente entre el esfuerzo realizado por encima de lo originalmente comprometido. Found work. Se define como la diferencia entre lo originalmente estimado y lo finalmente reportado, dividido lo originalmente comprometido. Accuracy of estimation. Mide la precisión con que se estimó el tamaño de cada una de las user stories. Se define como la suma de todos los deltas (tamaño final reportado menos el tamaño original estimado), dividiéndolo por la suma total de lo reportado, para finalmente restar a 1 este valor. Accuracy of commitment. Establece el margen de error sobre la porción de trabajo que compromete el equipo. Se define como el cociente entre la suma de todas las estimaciones iniciales por un lado, y por otro la suma de las estimaciones iniciales, adopted work y found work. Las lecciones aprendidas de la experiencia de implantación de las mediciones basadas en tamaño con el fin de utilizar las métricas descriptas son dos: 1. 2.

La importancia de la piedra angular para registrar el avance. Cómo registrar el avance cuando no hay avance.

Piedra angular: Es el punto de referencia a partir del cual y por comparación se realizan las estimaciones de tamaño relativo de los distintos productos a construir.

Ejemplos de mediciones reales 13

A continuación se exponen algunos indicadores de proyectos Scrum, los cuales en la vida real es lo que se entrega a líder. Bajo el enfoque predictivo tradicional, el énfasis está en medir el progreso del proyecto, en relación con la fecha y presupuesto comprometido originalmente, mientras que bajo el desarrollo ágil, se coloca énfasis en medir el desempeño del equipo en función de historias e items de retrasos, deuda técnica y velocidad, en iteraciones de tiempo y esfuerzo fijas.

1. Medidas para analizar y mejorar la productividad del equipo.

2. Comparación de Velocity y Work Capacity a lo largo del proyecto.

Conclusión

Vivimos en un mundo de datos e información. Algunas personas tienen una forma de pensar que los números diagnostican todos los problemas. Recordemos que solo muestran los datos". Sin embargo, muchos directivos sugieren ver de indicadores concretos de productividad y la eficiencia del equipo de Scrum. De otro modo tomaría mucho tiempo observar el desarrollo del proceso, pocos líderes están dispuestos a tomar este tiempo, delegan esta tarea síntesis información a los administradores a través de la solicitud típica informe.

14

El ciclo de vida definido por Scrum es incremental iterativo y se caracteriza por ser muy adaptable. Fomenta el surgimiento de equipos autodirigidos cooperativos y aplica inspecciones frecuentes como mecanismo de control. Sin embargo Scrum funciona bien sólo si las entradas están perfectamente definidas y el ruido, ambigüedad o cambio es muy pequeño. Por lo tanto, resulta ideal para proyectos con requerimientos inestables, ya que fomenta el surgimiento de los mismos. Desde este punto de vista, en todo proceso es importante las evaluación de proyectos, en el caso del desarrollo aplicando Agil Scrum no es la excepción. Por lo tanto, lo cierto es que aplicar desarrollo ágil no significa que las mediciones van a desaparecer, simplemente cambiaremos lo que se medirá y como. Nos guste o no, las métricas y los reportes a los niveles superiores en las organizaciones son parte de la vida profesional.

Bibliografía

Ingeniería del software, Un Enfoque Práctico, Séptima Edición, Roger S. Pressman. http://www.softeng.es/es-es/empresa/metodologias-de-trabajo/metodologiascrum.html

15

ingenieriadesoftware.mex.tl

Aplicación para la gestión de proyectos ágiles con Scrum, Jesús María Eraso Lerena, Universidad de la Rioja. Gestión de proyectos informáticos, metodología Scrum, Manuel Trigas Gallego. SCRUM Metodología de trabajo ágil, Jesús Cáceres Tello, Universidad de Alcalá. Métricas de scrum http://agilemanifesto.org/ Sutherland J, Downey S (2010) “Scrum metrics for hyper productive teams”. Agile 2010 Conference. Orlando, Florida. Disponible en: http://www.agile2010.org/ Video recomendado para el uso del método de desarrollo de Scrum. https://www.youtube.com/watch?v=PlLHc60egiQ

16