domingo, 26 de febrero de 2017

Scrum vs XP

Scrum vs XP

Introducción

En este ensayo se hablará sobre las metodologías agiles Scrum y XP describiendo a cada una, se mencionará el proceso que estas emplean, además de señalar los distintos roles y las funciones estos realizan en dichas metodologías. También se expondrán los artefactos por medio de los cuales se organiza y planifica el proyecto, posteriormente se presentará una tabla en la cual se contrastarán las características de cada una de las metodologías.

Scrum

Esta es un tipo de metodología ágil para llevar a cabo el manejo del desarrollo del software, en este se practica como actividad principal el trabajo en equipo altamente eficiente con el fin de obtener el mejor resultado en el menor tiempo posible sin comprometer la calidad del proyecto. Se basa en la adaptación, auto gestión y se enfoca en construir las funciones más importantes para el cliente además de maximizar el retorno de la inversión. Esta metodología es la indicada cuando los proyectos que se realizan cambian sus requisitos constantemente.

Proceso

En esta metodología se lleva un proceso iterativo e incremental en donde se planifica en diversos bloques temporales, a través de cada iteración llamada Sprint el proyecto va evolucionando, esta se llevan a cabo en un periodo de tiempo de 2 a 4 semanas obteniendo de estas nuevas versiones del software, durante este se van haciendo ajustes, añadiendo o modificando la funcionalidad con el fin de darle mayor valor al negocio para que al final se entregue un producto de calidad cumpliendo con todas las especificaciones estipuladas con el cliente.

Roles

En esta metodología se desempeñan distintos roles con funciones específicas estos son:

  • Scrum Master: Esta persona es la que se encarga de supervisar que todos los integrantes se desempeñen correctamente y cumplan con los objetivos establecidos en los sprints respetando todas las normas establecidas y se alineen al proceso de esta metodología.


  • Product Owner:Esta persona representa al cliente o al grupo de accionistas a los cuales se está desarrollando el proyecto, este se encarga de revisar las funcionalidades del producto e indica los cambios o mejoras que se le debe de hacer además de Maximizar el valor para el negocio con respecto al Retorno de Inversión (ROI), abogando por los intereses de este.

  • Team:Son el conjunto de programadores, diseñadores, arquitectos, testers etc., que se encargan de desarrollar el proyecto llevando a cabo los objetivos que se comprometieron a cumplir en cada sprint. 

  • Stakeholders: Son los clientes, proveedores, accionistas etc. a los cuales se está desarrollando el proyecto y son los principales beneficiarios o afectados del resultado que da el producto.



Artefactos


Son las herramientas por medio de las cuales podemos tener una organización en nuestro proyecto ayudando a planificar mejor el proyecto.

  • Product Backlog
Es un documento en el cual se establece todos los requisitos del proyecto, es decir se menciona todo lo que se va a hacer, conteniendo la descripción de las funcionalidades que va a tener en donde se especifica el grado de prioridad, el esfuerzo que demanda y los criterios de aceptación.Este solo lo puede modificar el product owner y su contenido está disponible para todos los miembros del equipo.

  • Sprint (Ejecución de iteración)
Son las iteraciones que se llevan a cabo en un periodo de tiempo corto y este es fijo, en donde cada miembro del equipo fija los objetivos a completar comprometiéndose de que al final debe de entregar el resultado esperado, de forma que este proporcione un potencial avance en el proyecto.

  • Incremento
Es el resultado que el equipo entrega y debe de cumplir con lo definido en el Product Backlog este resultado debe ser funcional y se tiene que marcarse como terminado.

  • Sprint Backlog
 Esto son los elementos que se desarrollaran en el Sprint, en este se identifica el trabajo necesario para cumplir los objetivos establecidos,  se detalla todo lo que se va a realizar y tiene la característica de que puede ser modificado durante el transcurso del desarrollo si se encuentran nuevas tareas a realizar así como también se eliminan estas si ya no son necesarias además de que sólo el Equipo de Desarrollo puede realizar cambios en el Sprint Backlog.

  •  Burn down chart
Es un diagrama en el cual se representa el progreso del proyecto, cuando se cumple con los objetivos en el tiempo especificado la línea es descendente de tal forma que cuando llegue al eje horizontal el proyecto se concluyó.


Reuniones en Scrum

  • Daily Scrum

Son las reuniones que se hacen a diario en las que se habla sobre el progreso del proyecto, lo que se va a realizar en ese día y si se está teniendo alguna complicación.  Esta reunión debe de comenzar puntualmente al igual que todo el equipo debe de presentarse de la misma forma además de que todos los miembros pueden asistir, pero con la restricción de que solo los involucrados pueden hablar.
Esta reunión tiene una duración fija de 15 minutos, todos los asistentes deben de permanecer de pie y tanto la ubicación como la hora de este debe ser la misma siempre.

  • Scrum de Scrum

Se llevan a cabo después del Daily Scrum o máximo después de cada dos días, se realizan cuando en la organización hay varios equipos de Scrum, en este se discute lo mismo que en el Daily Scrum pero centrándose en el área de integración, además se habla sobre lo que se va a realizar antes de que se vuelva a llevar a cabo la reunión.

  • Sprint Planning Meeting

Se realiza al iniciarse el sprint, en esta se planteará lo que se va a realizar, en qué tiempo además de identificar el trabajo que será necesario para ese sprint y esta planificación deberá de duran 8 horas máximo.

  • Sprint Review Meeting

Se realiza después de cada Sprint con el fin de revisar el trabajo, en caso de que sea haya completado se debe de mostrar. El tiempo de duración será 4 hora máximo.


  • Sprint Retrospective

Se lleva a cabo al término de cada Sprint en donde entre todos los miembros analizan lo que se realizó con el fin de mejorar el proceso si así se requiere, el tiempo en el que se tiene que llevar a cabo esta reunión es de 4 horas.





XP (Extreme Programming)

Es uno de los muchos tipos que existe de metodología ágil, esta favorece la comunicación tanto entre el equipo como con el cliente, se caracteriza por fomentar el trabajo en equipo además de tener un buen entorno de trabajo, se caracteriza por la simplicidad de sus soluciones y la aceptación de cambios durante el desarrollo. Esta metodología es recomendada para proyecto con requisitos muy cambiantes.

Proceso

El ciclo que se lleva a cabo para esta metodología es:

1.- El cliente por medio de distintos artefactos como historias de usuario define el valor de negocio a implementar.
2. El programador estima el esfuerzo necesario para su implementación y realiza la planificación para realizar el proyecto.
3.- Según las prioridades del cliente y el tiempo en el que este desea el proyecto va a seleccionar lo que se va a desarrollar.
4. El programador construye ese valor de negocio bajo las normas de la programación extrema.
5.- Se realizan las respectivas pruebas al sistema en caso de que haya algún error este será arreglado y se volverá a aplicar la pruebas hasta que estas no arrojen errores.


Ciclo de vida:

El ciclo de vida ideal de XP consiste de seis fases:

Exploración:
Se realiza la toma de contacto con el proceso de negocio que se van a informatizar, así como con la arquitectura y tecnología de desarrollo además de que en esta etapa se realizan las historias de usuario y se analiza la posibilidad de realizar algún prototipo para determinar la viabilidad de proyecto.

Planificación de la Entrega: 
En esta etapa los programadores realizan la estimación del tiempo necesario para implementar cada historia de usuario y obtener es el plan o cronograma de entregas.

Iteraciones:
Se desarrollan las iteraciones que se van a realizar según las historias de usuario, cada una de estas será una actividad que realizará algún miembro del equipo y se llevan a cabo según el tiempo estipulado.

Producción:
Se llevan a cabo distintos tipos de pruebas y revisiones al proyecto antes de ser entregado, también se analiza sobre si se agregaran nuevas características debido a los cambios efectuados, posteriormente el cliente deberá de realizar la aceptación según su criterio o en caso de que no sea así se realizaran las correcciones correspondientes que este manifieste antes de ponerlo en funcionamiento.

Mantenimiento:
En esta fase el sistema ya está en funcionamiento se debe de mantener así por medio de soporte de software y caso de que sea necesario se deberá de aplicar mantenimiento correctivo a este, mientras tanto se siguen desarrollando nuevas iteraciones.   
        
Muerte del Proyecto:
Se presenta cuando ya no ay más historias de usuario a incluir en el sistema, el cliente está totalmente satisfecho con los resultados y por lo tanto no se realizarán más cambios al este, es esta fase se realizará la documentación final del proyecto.
También se puede dar debido a que ya no hay presupuesto para seguir en pie con el desarrollo o este no genera los beneficios que el cliente espera.



Roles

  • Programador:Se encarga de definir las tareas según las historias de usuario con esto estima el tiempo que será necesario para la realización de cada una y escribir las pruebas unitarias que se realizaran al sistema para finalmente llevar a cabo la codificación de este.


  • Cliente:Lleva acabo la tarea de escribir las historias de usuario asignando su prioridad y también redactara las pruebas funcionales que se aplicaran para validar si se implementara el sistema además de decidir cuál historia de usuario se implementara a cada iteración con el fin de aportar el mayor valor de negocio.

  
  • Encargado de Pruebas (tester):Se encarga de ejecutar las pruebas (las cuales ayudo previamente al usuario a hacer)  y difundir los resultados entre todos los miembros del equipo, además tiene la responsabilidad del manejo de las herramientas necesarias para llevar acabo el soporte para las pruebas.


  • Tracker(Encargado de seguimiento):Es la persona responsable de dar seguimiento constante al proyecto proporcionando la retroalimentación necesaria a los integrantes del equipo para que puedan desempeñar mejor sus actividades, también se encarga de constatar que el tiempo de estimación concuerde con el tiempo real dedicado según la planeación y difunde estos los resultados con el fin de mejorar las próximas estimaciones.


  • Entrenador (coach):Es la persona responsable general del proyecto, experto en dicha metodología, se encarga de corroborar que el proceso se lleve a cabo correctamente y si identifica desviaciones, reclama atención sobre las mismas, también guía al equipo para que este aplique las prácticas de esta metodología y en caso de que surja un problema debe de atajarlo rápidamente.    


  • Gestor (Big boss):Se encarga de darle lo necesario al equipo para que este sea eficiente, resuelve los problemas que surgen en el proyecto, dirige las reuniones y es el vínculo de comunicación con el cliente con el fin de alcanzar los objetivos planteados.


  • Consultor:Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto pudiendo así guiar al equipo para resolver un problema específico.


  • Doomsayer (Augur de desastres):Es el responsable de buscar y difundir los riesgos que pueden surgir en el proyecto con una posible solución además de comunicar las malas noticias de manera sutil.



Artefactos


  • Historias de Usuario

En estas se describe una funcionalidad del sistema y por lo tanto definen que es lo que se va a realizar, estas deben de ser cortas, negociables, independientes unas de otras y verificables.

  • Prueba de aceptación

Esta prueba se realiza al producto final siguiendo protocolos específicos con el fin corroborar su optimo y completo funcionamiento según lo establecido, esta no la deben de llevar acabo los desarrolladores, con estas pruebas se obtiene un conocimiento más profundo acerca de cómo funciona el equipo.

  • Tareas de Ingeniería

Estas especifican las actividades que se llevaran a cabo en cada una de las historias de usuario, se vinculan más al desarrollador debido a que permite tener un acercamiento con el código.

  • Plan de Entregas

En este se establece un cronograma donde basándose en las historias de usuario, todos los integrantes del equipo hacen una estimación del tiempo y se acuerdan las entregas que se van a realizar. Luego de algunas iteraciones se recomienda realizar una reunión en donde se vuelva a ajusta este plan si es necesario.

  • Tarjetas Crc (Clase – Responsabilidades –Colaboradores)

Por medio de estas se conoce de clases está conformado el sistema y entre ellas cuales tiene una interacción mutua. Estas se dividen en tres secciones: Nombre de la clase, responsabilidad y colaboradores.

  • Pruebas Unitarias

Son pruebas que se realizan a cada módulo del sistema con el fin de verificar su correcto funcionamiento.

  • Pruebas de Integración

Estas se realizan después de las pruebas unitarias, cuando los distintos módulos de los que se compone el sistema se juntan, y tienen la finalidad de verificar que todos estos funcionan correctamente juntos.


Tabla de Diferencias 



Scrum
XP
Dentro del equipo de Scrum no es posible realizar cambios entre iteraciones, en caso de que estos sean en verdad necesarios el sprint actual se finaliza y se comienza otro nuevo.
XP tiene flexibilidad a cambios entre iteraciones en caso de que estas ofrezcan una mejora y logren mayor eficiencia del producto.
Las iteraciones que se llevan a cabo tienen una duración de 2 a 4 semanas
Las iteraciones duran de 1a 2 semanas
Esta metodología se centra más en la correcta administración y productividad
Esta metodología se preocupa más por la ingeniería y la programación o creación del producto.
En Scrum, el cliente especifica la prioridad de desarrollo de las tareas, pero si el equipo nota que se pueden realizar mejoras estas se llevan a cabo.
En XP la prioridad del desarrollo de las tareas se lleva a cabo estrictamente según las prioridades del cliente.
Las validaciones que se realizan al software son siempre al final de cada Sprint, se realizan en el Sprint Review.
En esta metodología el software es validado durante todo el proceso de desarrollo debido a las pruebas que se redactan al principio de cada una de las actividades.
En está, la forma de trabajo en el equipo es individual.
En esta la forma de trabajo es en parejas.
Cuando se finaliza el Sprint y las tareas definidas en un principio en el Sprint Backlog son finalizadas y aceptadas por el Product Owner no se vuelven a modificar.
Las tareas  que se van terminando siguen siendo susceptibles a ser modificadas durante el transcurso de proyecto, incluso, después de que funcionen correctamente.
El Scrum Master es la única persona que puede autorizar cambios en el código.
Cualquier desarrollador puede modificar partes del código si así es necesario.




Conclusión

Se puede concluir que tanto la metodología SCRUM como la XP son muy parecidas pero cada una tiene diferentes particularidades por las cuales se caracterizan, son la forma en que se organizan y trabajan lo que hace que se note una diferencia entre estas como lo son las iteraciones que realizan y el tiempo que dedican a estas, así como los cambios y la facilidad que se tienen para implementarlos o la forma de codificación etc. es por esto que no se puede decir que una es mejor que la otra debió a que muchas personas se adaptan mejor a la organización de una metodología, por lo tanto las dos tienen la capacidad de ofrecer éxito y calidad como resultado al ser implementadas en los proyectos.   





Referencias


Bahit, E. (21 de Septiembre de 2011). www.desarrolloweb.com. Obtenido de https://www.desarrolloweb.com/articulos/artefactos-scrum.html

es.vaisala.com. (s.f.). Obtenido de http://es.vaisala.com/sp/services/projectservices/Pages/acceptancetesting.aspx

Jeffries, R. (23 de Mayo de 2011). jmbeas.es. Obtenido de http://jmbeas.es/guias/historias-de-usuario/
Valladarez, B. S. (2016). Metodología Ágil Programación Extrema XP.

Wells, J. D. (2001). oness.sourceforge.net. Obtenido de http://oness.sourceforge.net/proyecto/html/ch05s02.html

www.ecured.cu. (s.f.). Obtenido de https://www.ecured.cu/Programaci%C3%B3n_Extrema_o_XP

www.ids.com.mx. (2 de Diciembre de 2014). Obtenido de http://www.ids.com.mx/desarrollo-profesional/comunidad-ids/blog/scrum-4ta-parte-artefactos





No hay comentarios.:

Publicar un comentario