Metodología XP(Programación extrema)

 La metodología XP o programación extrema, sigue estrictamente una serie de reglas importantes para la elaboración del software,

Estas son las reglas que usa la Metodología XP.-

 Test Driven Design.- Consiste en probar el código generado hasta el momento, donde se da un visto de color verde si esta bien o de color rojo si no sigue las indicaciones del software.

Refactoring.- Consiste en volver a escribir el código, quitando código innecesario, mejorándolo sin modificar su funcionalidad principal.

 Propiedad colectiva.- La siguiente regla consiste en compartir el código entre todo el equipo, donde cualquier integrante podrá visualizar los códigos de los demás permitiendo opinar y corregirlo.

Integración continua.- Consiste en usar un repositorio o servidor de internet donde se pueda actualizar de manera continua, todas las modificaciones que se le haga al sofware, el repositorio de google es uno de los más usados.

Programación en pares.-

Consiste en que dos personas hagan un mismo codigo, donde el que este frente a la computadora sea el piloto y el otro sea el copiloto, en donde las dos personas acaben la programación en poco tiempo.

Una de las reglas es que las  personas que trabajan en pares deben estar constantemente cambiando de parejas para así obtener la opinión y ayuda de todo el equipo.

Roles de la Programación Extrema (XP).- Los roles del método de la programación extrema son los siguientes.

Programador.- Escribe el código del software

Cliente.- Es el dueño de software, escribe las historias de los usuario(Requerimientos del software).

Encargado de Pruebas (Tester).-Ayuda al cliente a realizar las pruebas del software.

 Encargado de Seguimiento (Tracker).- Es el que proporciona la realimentación al equipo.

 Entrenador (Coach).- Es el responsable del proceso global.

Consultor.- Es un miembro externo del equipo con un conocimiento especifico en algún tema que es necesario para el proyecto

Gestor (Big boss).- Es el vinculo entre clientes y programadores, se centraliza en la coordinación del cliente y el programador.

Donde cada uno de ellos aporta es responsable del éxito del software.





Conclusiones.-

• La programación extrema es un buena alternativa, si se quiere diseñar un software en corto tiempo.
• No solo la rapidez es una de sus ventajas, sino que también las habilidades sociales, el trabajo en equipo y la disciplina.

Metología Scrum

Scrum.-

Muchos principiantes en desarrollo de software al escuchar la palabra Scrum nos preguntamos que significado tiene dicha palabra. Lo primero que hice al tener mi computadora al frente fue traducir la palabra y me di una gran sorpresa al saber que significaba  “mele”, que es un término de rugby un deporte muy conocido donde todos los compañeros de equipo empujan en una sola dirección.

¿Qué es Scrum?.-

Es una metodología que nos orienta como desarrollar un software. Nos indica lo que debemos realizar paso a paso, sino nosotros tenemos que adaptarlo a nuestra situación, ayudándonos a afrontar retos como los cambios a los que estamos inmersos al desarrollar un proyecto, cambios requeridos por el cliente por ejemplo. Scrum maximiza la realimentación para poder corregir problemas en el software.

Características de Scrum.-

• Le da la prioridad al software funcional que a la documentación excesiva.
• Permite evaluar y detectar permanentemente los riesgos  realizando entregas parciales del producto final en determinados tiempos.
• Transparencia y visibilidad del proyecto con el cliente manteniéndole lo más informado posible.
• Este dispuesto al cambio por encima del plan, la opinión del cliente es muy importante.

Claves de Scrum.-

Los equipos pequeños consiguen mejores resultados al poderse organizar más rápido. Aunque según Henrik Kniberg autor del libro SCRUM Y XP DESDE LAS TRINCHERAS menciona lo siguiente “Mi experiencia me dicta que es mejor tener menos equipos que sean demasiado  grandes que tener muchos equipos pequeños que están todo el rato interfiriendo unos con otros. ¡Haz equipos pequeños sólo cuando no necesiten interferir unos con otros!”

Punto de vista del usuario.-

Los requisitos para realizar el software se realizan desde el punto de vista del cliente, mediante “historia de usuario” unas pequeñas tarjetas donde se escribe la lista de requisitos del producto y a cada tarjeta dándole una prioridad distinta.

El mercado exige ciclos de desarrollo cada vez más cortos. Para lograrlo se utiliza el sprint de requisitos o “sprint backlog”, una lista en la que se detalla CÓMO se van a construir los diferentes requisitosdel producto.

Los requisitos del product backlog se “trocean” para transformarlos en tareas de no más de 16 horas. Cada sprint suele realizarse en un plazo de entre 2 y 4 semanas. Al final, el objetivo es entregar algo que funcione, para el usuario pueda probarlo y se puedan introducir los cambios necesarios antes de que sea demasiado tarde. Esto es lo que nos permitirá ser flexibles.

El Sprint.- Es el período en el cual se lleva a cabo el trabajo en sí. Es recomendado que la duración de los sprints sea constante y definida por el equipo con base en su propia experiencia.

Se puede comenzar con una duración de sprint en particular (2 o 3 semanas) e ir ajustándolo con base en el ritmo del equipo, aunque sin relajarlo demasiado.

Al final de cada sprint, el equipo deberá presentar los avances logrados, y deberán entregar un producto con características de utilizable por el cliente. Asimismo, se recomienda no cambiar los objetivos del sprint o sprint backlog a menos que la falta de estos cambios amenace al éxito del proyecto. La constancia permite la concentración y mejora la productividad del equipo de trabajo.

Roles de la metodologías Scrum.-