Procesos Agiles de Desarrollo de Software

Vista previa del material en texto

Estudiante: Diego Barrientos Jaldín 
 
Procesos Ágiles de Desarrollo de Software 
 
¿Por qué usar procesos ágiles? Los procesos ágiles surgen como una forma 
de superar las deficiencias de la ingeniería de software convencional que 
considera, al parecer, que el proceso lo es todo, que los grupos son 
homogéneos y que los desarrolladores carecen de los problemas de las 
personas comunes. También es un hecho que los requerimientos del 
software cambian constantemente y que es muy costoso hacer cambios en 
las fases más avanzadas de un proyecto. De igual manera, es demasiado 
común creer que se han entendido las necesidades del cliente y, sin 
embargo, hacer las cosas de un modo diferente a lo requerido por éste. Por 
último, y no menos importante, lo que de verdad le da confianza al cliente en 
el equipo de desarrollo es el producto; al cliente no le sirven los documentos 
que se generan en el proceso. Es por eso que se buscó un enfoque diferente 
para el desarrollo de software, el enfoque ágil. 
Lo que nos dice el enfoque ágil de desarrollo de software es lo siguiente: 
 Los desarrolladores son personas y como tales tienen limitaciones y 
problemas, por tanto el proceso debe adaptarse a las personas y no al 
revés. Se debe confiar en que harán su trabajo y se les debe brindar el 
apoyo necesario. Son ellos los que se organizarán así mismos para el 
trabajo. 
 La prioridad es dejar satisfecho al cliente por sobre todo. Esto se hace 
con la entrega pronta y continua de software que funciona y mediante 
la capacidad de adaptarse a los cambios en los requerimientos, sin 
incurrir en grandes gastos. 
 
 
 Se debe trabajar conjuntamente con el cliente. El Ilieﾐte deHe seヴ さuﾐo 
ﾏásざ del eケuipo de desaヴヴollo. Es la mejor forma de ver cómo 
realmente funciona el negocio, observar que es lo que de verdad se 
necesita y crear un mejor ambiente de trabajo. 
 La medida principal del trabajo es el software que funciona, es lo único 
que puede indicar que el trabajo está yendo por buen camino o que 
hay algo que está fallando y además es lo que al cliente realmente le 
interesa: el producto. 
Todo esto está condensado en el Manifiesto Ágil de la Alianza Ágil del año 
2001: 
さEstamos descubriendo mejores formas de desarrollar software, haciéndolo y 
dando ayuda a otros para que lo hagan. Este trabajo nos ha hecho valorar: 
Los individuos y sus interacciones, sobre los procesos y las herramientas. 
El software que funciona, más que la documentación exhaustiva. 
La colaboración con el cliente, y no tanto la negociación del contrato. 
Responder al cambio, mejor que apegarse a un plan. 
Es decir, si bien son valiosos los conceptos que aparecen en segundo lugar, 
valoramos más los que aparecen en el primer sitioざ. 
 
Ahora que vimos qué son los procesos ágiles, vamos a ver cómo son 
revisando uno de éstos: Scrum. 
Scrum (cuyo nombre proviene de una jugada de rugby en la que los 
jugadores trabajan juntos) es un proceso ágil de desarrollo de software 
basado en la auto-organización, creado a principios de los 90 por Jeff 
Sutherland y su equipo de desarrollo. 
 
 
Los pasos que en esencia deben seguirse son: 
 El equipo debe reunirse con el cliente, empaparse del negocio y en 
base a eso hacer las historias de usuario, que son en realidad una 
descripción de funcionalidad. El formato es el siguiente: 
Yo como __________ 
Requiero __________ 
Tal que __________ 
 A cada historia se le asigna un valor de complejidad. Esto puede ser 
hecho con Scrum Póker. El juego consiste en repartir cartas con valores 
de 0, 1, 2, 3, 5, 8, 13, 20, 40 y 100 (que representan la complejidad de 
la historia) a cada desarrollador. Luego se lee en voz alta la descripción 
del requerimiento, después cada participante debe escoger una carta y 
ponerla boca abajo. Una vez que todos hayan puesto las cartas, éstas 
se voltean y se muestran los valores. Si se diera el caso en que hay 
mucha diferencia entre dos cartas, se discute el porqué y se vuelven a 
escoger cartas. Y así sucesivamente hasta que se llegue a un valor 
parecido entre todos. 
 Se le asigna un valor que representa cuán importante para el cliente es 
esa historia (ROI). Normalmente es el Product Owner quien se encarga 
de ello. Ésta persona tiene que estar en contacto con el negocio, debe 
hacerse pasar como un cliente y actuar como actuaría uno. 
 Luego se procede a escoger las historias que entraran en el Sprint, que 
es una iteración de treinta días. Lo recomendable es escoger las 
historias que no sean tan complejas pero que sí sean valiosas para el 
cliente. En segundo lugar están las que son valiosas pero son 
complejas, a éstas hay que dividirlas para reducir la complejidad y 
puedan entrar al Sprint. Se deja de lado las historias sencillas pero de 
valor pobre y también las complejas de poco valor para un próximo 
Sprint. 
 Se definen las tareas de cada historia, los estándares y un contenedor 
para las tareas ya terminadas. Se elabora un cuadro con 3 columnas, 
para indicar el avance del equipo: さPor Hacerざ, さHaciendoざ y さHechoざ. 
Las tareas son escritas en unas notas y son pegadas en la parte さPor 
Hacerざ. Cada integrante del equipo escoge las tareas que vea 
conveniente, se compromete a terminarlas y las coloca en la columna 
さHaciendoざ. 
 Comienza el Sprint. Cada día debe haber una reunión diaria de unos 15 
minutos, donde cada miembro del equipo responde a las siguientes 
preguntas: ¿qué hiciste desde la última reunión? ¿qué harás hasta la 
próxima reunión? ¿tienes algún obstáculo? Esto ayuda a detectar 
problemas tan pronto como sea posible y a darles una solución. 
 Una vez terminado el Sprint se hace una retrospectiva. Se analizan los 
aciertos y desaciertos. Se hace una evaluación de qué tan bien 
divididas están las historias, cuán bien se ha planificado, los errores 
cometidos, etc. El próximo Sprint con seguridad saldrá mejor gracias a 
lo aprendido. 
 Software que funciona es mostrado al cliente, quien evalúa el 
resultado. 
Como se ha podido observar, lo que hacen los procesos ágiles es tomar las 
cosas como son. Lo importante son las personas, el software y no tanto el 
proceso o la documentación. El cliente es parte esencial del proceso de 
desarrollo y, aunque es bueno planificar, lo mejor es ser adaptable a los 
cambios ya que éstos siempre se dan.