Presentación 4:
¿Qué
es la Programación Extrema?
La
programación extrema es una metodología de desarrollo ágil que tiene como
principal objetivo aumentar la productividad a la hora de desarrollar un
proyecto software. Da prioridad a los trabajos que dan un resultado directo y
en los cuales se reduce la burocracia que pueda existir en el entorno de
trabajo.
Esta
metodología tiene como base la simplicidad y como objetivo principal la
satisfacción del cliente
¿Cuáles
son los valores y principios de la
Programación Extrema?
Comunicación
Es
muy importante que haya una comunicación constante con el cliente y dentro de
todo el equipo de trabajo, de esto dependerá que el desarrollo se lleve a cabo
de una manera sencilla, entendible y que se entregue al cliente lo que
necesita.
Simplicidad
En
la XP se refiere que ante todo y sin importar qué funcionalidad requiera el
usuario en su sistema, éste debe ser fácil. El diseño debe ser sencillo y
amigable al usuario, el código debe ser simple y entendible, programando sólo
lo necesario y lo que se utilizará.
Retroalimentación
Es
la comunicación constante entre el desarrollador y el usuario.
Coraje
Se
refiere a la valentía que se debe tener al modificar o eliminar el código que
se realizó con tanto esfuerzo; el desarrollador debe saber cuando el código que
desarrolló no es útil en el sistema y, por lo mismo, debe ser eliminado.
También se refiere a tener la persistencia para resolver los errores en la
programación.
Dentro
de la programación extrema se tiene 12 principios que llevan o guían el
desarrollo con esta metodología:
1.
El principio de pruebas
2.
Proceso de planificación
3.
El cliente en el lugar
4.
Programación en parejas
5.
Integración continua
6.
Refactorización
7.
Entregas pequeñas
8.
Diseño simple
9.
Metáfora
10.
Propiedad colectiva del código
11.
Estándar de codificación
12.
La semana de 40 horas
¿Cuáles
son las actividades, recursos y prácticas de la Programación Extrema?
Las prácticas son las siguientes:
1. El juego de la
planificación (the planning game). Es un permanente diálogo entre las
partes empresarial (deseable) y técnica (posible).
2. Pequeñas entregas
(small releases). Cada versión debe de ser tan pequeña como fuera posible,
conteniendo los requisitos de negocios más importantes, las versiones tiene que
tener sentido como un todo, me explico no puedes implementar media
característica y lanzar la versión.
3. Metáfora
(metaphor). Una metáfora es una historia que todo el mundo puede contar a
cerca de cómo funciona el sistema. Algunas veces podremos encontrar metáforas
sencillas “Programa de gestión de compras, ventas, con gestión de cartera y
almacén”. Las metáforas ayudan a cualquier persona a entender el objeto del
programa.
4. Diseño sencillo
(simple design). Cuando implementamos nuevas características en nuestros programas
nos planteamos la manera de hacerlo lo mas simple posible, después de
implementar esta característica, nos preguntamos como hacer el programa mas
simple sin perder funcionalidad, este proceso se le denomina recodificar o
refactorizar (refactoring).
5. Pruebas (testing). No debe
existir ninguna característica en el programa que no haya sido probada, los
programadores escriben pruebas para chequear el correcto funcionamiento del
programa, los clientes realizan pruebas funcionales. El resultado un programa
mas seguro que conforme pasa el tiempo es capaz de aceptar nuevos cambios.
6. Refactorización
(refactoring). Cuando implementamos nuevas características en nuestros programas nos
planteamos la manera de hacerlo lo mas simple posible, después de implementar
esta característica, nos preguntamos como hacer el programa mas simple sin
perder funcionalidad, este proceso se le denomina recodificar o refactorizar
(refactoring). No debemos de recodificar ante especulaciones si no solo cuando
el sistema te lo pida.
7. Programación por
parejas (pair programming). Todo el código de producción lo escriben dos
personas frente al ordenador, con un sólo ratón y un sólo teclado. Cada miembro
de la pareja juega su papel: uno codifica en el ordenador y piensa la mejor
manera de hacerlo, el otro piensa mas estratégicamente. Cualquier miembro del
equipo se puede emparejar con cualquiera.
8. Propiedad colectiva
(collective ownership). Cualquiera que crea que puede aportar valor
al código en cualquier parcela puede hacerlo, ningún miembro del equipo es
propietario del código. Si alguien quiere hacer cambios en el código puede
hacerlo. XP propone un propiedad colectiva sobre el código nadie conoce cada
parte igual de bien pero todos conoce algo sobre cada parte, esto nos preparará
para la sustitución no traumática de cada miembro del equipo.
9. Integración
continua (continuos integration). El código se debe integrar como
mínimo una vez al día, y realizar las pruebas sobre la totalidad del sistema.
Una pareja de programadores se encargara de integrar todo el código en una
maquina y realizar todas las pruebas hasta que estas funcionen al 100%.
10. 40 horas semanales
(40-hour week). Si queremos estar frescos y motivados cada mañana y cansado y
satisfecho cada noche. El viernes quiero estar cansado y satisfecho para sentir
que tengo dos días para pensar en algo distinto y volver el lunes lleno de
pasión e ideas. Las horas extras son síntoma de serios problemas en el
proyecto, la regla de XP dice nunca 2 semanas seguidas realizando horas extras.
11. Cliente en casa
(on-site costumer). Un cliente real debe sentarse con el equipo de programadores, estar
disponible para responder a sus preguntas, resolver discusiones y fijar las
prioridades.
12. Estándares de
codificación (coding standards). Si los programadores van a
estar tocando partes distintas del sistema, intercambiando compañeros, haciendo
refactoring, debemos de establecer un estándar de codificación aceptado e
implantado por todo el equipo.
No es fácil aplicar una nueva
metodología en un equipo de desarrollo ya que obliga a aprender una nueva forma
de trabajar. También obliga a abandonar cómo se hacían las cosas antes, que
aunque no fuera la mejor forma posible ya se conocía. XP ha sido adoptado por
un gran número de equipos en los últimos años y de sus experiencias se ha
extraído una conclusión sencilla: es mejor empezar a hacer XP gradualmente.
¿Cuál
son las fases del proceso de desarrollo de XP?
El
proceso que recomiendan los autores de XP es el siguiente: Identifica el
principal problema del proceso de desarrollo actual. Escoge la práctica que
ayuda a resolver ese problema y aplicarla. Cuando ese haya dejado de ser un problema,
escoge el siguiente. En realidad se recomienda que se apliquen las prácticas de
dos en dos. El objetivo es que las prácticas de XP se apoyan unas a otras y por
tanto dos prácticas aportan más que la suma de ambas y por tanto es más fácil
comprobar los resultados.
El
objetivo final debe ser aplicar todas las prácticas, ya que representan un
conjunto completo, "si no las aplicas todas no estás haciendo eXtreme
Programming".
En
resumen sería Planificación del proyecto, diseño, codificación y pruebas.
¿Qué
es una historia de usuario?
Es una representación de un requisito
de software escrita por el cliente en 1 a 4 frases en su lenguaje común. Son
usadas para la especificación de requerimientos y para estimar tiempos de
desarrollo. El tiempo de desarrollo de cada una es entre 1 y 3 semanas.
Las historias de usuario son una
forma rápida de administrar los requisitos de los usuarios sin tener que
elaborar gran cantidad de documentos formales y sin requerir de mucho tiempo
para administrarlos. Las historias de usuario permiten responder rápidamente a
los requisitos cambiantes.
Bibliografia:
http://www.ecured.cu/Programaci%C3%B3n_Extrema_(XP)
--------------------------------------------------------------------------------------------------------------------------
Presentación 3:
¿Qué son las metodologías ágiles de desarrollo de software?
Las metodologías ágiles son una serie de técnicas
para la gestión de proyectos que han surgido como contraposición a los métodos
clásicos de gestión como CMMI. Aunque surgieron en el ámbito del desarrollo de
software, también han sido exportadas a otro tipo de proyectos.
¿Cuáles son las características en las que se basan las metodologías
ágiles?
Los individuos y su interacción, por encima de los
procesos y las herramientas.
El software que funciona, frente a la documentación
exhaustiva.
La colaboración con el cliente, por encima de la
negociación contractual.
La respuesta al cambio, por encima del seguimiento
de un plan.
¿Cuáles son las ventajas y desventajas del empleo de las
metodologías ágiles respecto a las
tradicionales?
Ventajas:
Rápida respuesta al cambio de los requisitos a lo
largo del desarrollo
El cliente es parte del equipo de desarrollo
Importancia
de la simplicidad al eliminar trabajo innecesario
Desventajas:
Falta de documentación del diseño. Al no haber
documentación es el código (junto con sus comentarios) lo que se toma como
documentación.
Problemas derivados de la comunicación oral. No
hace falta decir que algo que está escrito “no se puede borrar”, en cambio,
algo dicho es muy fácil crear ambigüedad.
Fuerte dependencia de las personas.
Falta de reusabilidad derivada de la falta de
documentación
Restricciones en cuanto a tamaño de los proyectos
¿Cuándo es recomendable utilizar metodologías ágiles en el desarrollo de software?
-Cuando se tiene un proyecto pequeño en tiempo o
con un equipo de desarrollo reducido de 3 a 8 personas
-Requerimientos dinámicos; cuando te encuentras
ante un ámbito de actuación los puntos de vista de análisis estan
constantemente cambaindo como podría ser un datamart de fuerza de ventas
-Si tu cliente tiene tiempo para dedicarlo al
proyecto
-Si se tiene un equipo de desarrollo con un nivel
mayor a junior, en general las
metodologías ágiles requieren de una gran madurez, experiencia y una dosis de
talento.
¿Cuáles son algunos tipos de metodologías ágiles?
Programación Extrema, es uno de los ejemplos más
exitosos de metodología ágil.
Scrum
Crystal
Evolutionary Project
Management (Evo)
Feature Driven Development
(FDD)
Adaptive Software
Developmen(ASD)
Lean Development (LD) y
Lean Software Development (LSD)
Proceso Unificado de Desarrollo Software
Bibliografía:
No hay comentarios:
Publicar un comentario