Professional Documents
Culture Documents
Introduccin al curso
Desglose de objetivos
Conocer las bases de las metodologas giles y su diferencia con las metodologas tradicionales. Conocer las prcticas giles propias de Scrum, sus particularidades e importancia actual de dicha metodologa gil en el sector. Conocer LEAN Y Kanban. Presentar cules son los mtodos de estimacin ms eficientes en el rea de las metodologas giles. Veremos cmo funciona el Planning Poker y los puntos historia otros aspectos relacionados, como la relacin de las metodologas giles, como Scrum, con modelos de procesos como CMMI o ISO/IEC 15504.
Dirigido a
Estudiantes de carreras tecnolgicas Profesionales de informtica en general Directivos, Jefes de proyecto, responsables de calidad Consultores Personal de gerencia media y tcnica del rea de TI.
Modalidad de evaluacin
El curso est compuesto de 5 lecciones de contenido audiovisual, textual y presentaciones. No est previsto restringir los horarios de acceso por lo que el estudiante podr acceder a las lecciones a partir del momento en que se habiliten y hasta la finalizacin del curso. Al finalizar cada leccin, el usuario obtendr una nota con su calificacin despus de realizar el test correspondiente, siendo todos estos obligatorios. Esa nota no tendr ningn valor sobre la calificacin final del curso. Solo se utilizar para que el estudiante conozca cmo ha realizado esa leccin. Cada test podr realizarse una nica vez, y es obligatoria su realizacin para pasar al siguiente mdulo. Las lecciones han de realizarse en orden secuencial, es decir, para acceder a una leccin es necesario haber completado la leccin anterior. Para obtener el certificado que indica que se ha superado el curso, es necesario obtener una calificacin del 50% en el examen final. Este examen estar disponible para su realizacin tras la publicacin de todas las lecciones del curso. Utiliza el "Foro" para cualquier tipo de duda que te surja sobre el curso o su contenido. En este foro sers respondido por otros alumnos o por los profesores del curso.
LECCIN 1
La gestin de proyectos predictiva es tpica en disciplinas como la arquitectura. Y desde sus orgenes, la ingeniera del software intent perseverantemente emular a las ingenieras clsicas. Tener una fase de diseo muy claramente separada de la programacin (hasta el punto de intentar tener una organizacin cliente que detalle los diseos y otra organizacin, normalmente llamada fbrica de software, que los implemente). Que la programacin no comenzase hasta que terminase el diseo. Que el diseo concluya con unos planos precisos que guen totalmente la construccin. Que una vez que se hace un diseo ste no se modifique; de hecho, notaciones como UML (UnifiedModelingLanguage es un lenguaje grfico para visualizar, especificar, construir y documentar un sistema) se concibieron para construir los planos detallados del software. Al anterior tipo de gestin de proyectos predictiva, en el mundo del software se le conoce como ciclo de vida en cascada (ver Figura 1).
@jgarzas
Por lo general, realizar un cambio en el producto final que construyen las ingenieras clsicas o la arquitectura es muy costoso. Cambiar, por ejemplo, la posicin de una columna en un edificio o realizar modificaciones a la estructura de un puente ya construido tiene un alto coste. Y de ah que la arquitectura o las ingenieras clsicas pretendan lograr a toda costa diseos o planos de un alto
1
En este caso se utiliza la palabra prototipo como sinnimo de un producto software con caractersticas que pueden ser utilizadas por el cliente
nivel de detalle, para que una vez que comience la fase de construccin no tengan que ser modificados. Adems, normalmente, en la arquitectura o en las ingenieras clsicas los costes de construir son muy elevados en comparacin con los de disear. El coste del equipo de diseadores es sustancialmente inferior al de la realizacin de la obra, del puente, edificio, etc. La anterior relacin de costes no se comporta igual en el caso del software. Por un lado, el software, por su naturaleza (y si se construye mnimamente bien), es ms fcil de modificar. Cambiar lneas de cdigo tiene menos impacto que cambiar los pilares de un edificio ya construido. De ah que existan numerosas propuestas que recomiendan construir rpido una versin software y modificarla evolutivamente (la tcnica de la refactorizacin trabaja sobre esta idea). En software no existe esa divisin tan clara entre los costes del diseo y los de la construccin. Tambin en las ingenieras clsicas o la arquitectura los roles y especializacin necesaria en cada fase son diferentes. Los planos o diseos los realizan arquitectos que no suelen participar en la fase de construccin. La construccin tiene poco componente intelectual y mucho manual, al contrario que el diseo. Y todo apoya a que existan dos actividades claramente diferenciadas: el diseo y la construccin. En nuestro caso, el producto final, el software, tiene diferencias muy sustanciales con estos productos fsicos. Estas diferencias hacen que el proceso de construccin sea diferente. Durante muchos aos, quizs por la juventud de la ingeniera del software, se han obviado estas diferencias, e incluso se han intentado encontrar metodologas que imitasen y replicasen los procesos de construccin tradicional al software. Ejemplo de ello son las primeras versiones y usos de lenguajes de diseo como UML, o metodologas como RUP 2 o Mtrica v3 3 . Sin embargo en muchas ocasiones, estos intentos de emular la construccin de software a productos fsicos han creado importantes problemas y algunos de los mayores errores a la hora de gestionar proyectos software. Diferenciar el cmo se construye software del cmo se construyen los productos fsicos es uno de los pilares de las metodologas giles (M. Fowler, 2005) 4. De hecho es un tema del que se ha escrito mucho .Y tambin se ha debatido bastante, desde hace muchos aos, con posturas a favor y en contra. Y es que en software, es frecuente que diseo y construccin muchas veces se solapen, y por ello se recomiende construir por iteraciones, por partes, y el uso de prototipos incrementales.
RUP, por sus siglas en ingls que significan RationalUnifiedProcess es un proceso de desarrollo de software utilizado junto con UML y que constituye una metodologa para el anlisis, diseo, implementacin y documentacin de proyectos software orientados a objetos. 3 Mtrica v3 es una metodologa de planificacin, desarrollo y mantenimiento de sistemas de informacin, mayormente promovida y utilizada en el mbito de las administraciones pblicas. 4 Fowler, M. (2005). The new methology.
2
Cascada
Las fases del ciclo de vida (requisitos, anlisis, diseo, etc.) se realizan (en teora) de manera lineal, una nica vez, y el inicio de una fase no comienza hasta que termina la fase anterior. Su naturaleza es lineal, tpica de la construccin de productos fsicos y su principal problema viene de que no deja claro cmo responder cundo el resultado de una fase no es el esperado. El ciclo de vida ms criticado en los ltimos aos. En muchos proyectos su implantacin ha sido un fracaso, mientras que hay otros proyectos que trabajan perfectamente de esta manera.
Iterativo e incremental
Incremental = aadir, iterativo = retrabajo Se va liberando partes del producto (prototipos) peridicamente, en cada iteracin, y cada nueva versin, normalmente, aumenta la funcionalidad y mejora en calidad respecto a la anterior. Aqu hay un post (p1.1) con ms informacin. Adems, el ciclo de vida iterativo e incremental es una de las bases de un proyecto gil, ms concretamente, con iteraciones cortas en tiempo, de pocas semanas, normalmente un mes y raramente ms de dos
P1.1 EL CICLO DE VIDA ITERATIVO E INCREMENTAL Y EL RIESGO DE OLVIDARSE DEL ITERATIVO Y QUEDARSE SOLO CON EL INCREMENTAL
Si en un ciclo de vida en cascada las fases del ciclo de vida (requisitos, anlisis, diseo, etc.) se realizan (en teora) una nica vez, y el inicio de una fase no comienza hasta que termina la fase que le precede, en un ciclo de vida iterativo e incremental se va liberando partes del producto (prototipos) peridicamente, en cada iteracin, y cada nueva versin, normalmente, aumenta la funcionalidad y mejora en calidad respecto a la anterior. El ciclo de vida iterativo e incremental es una de las buenas prcticas de ingeniera del software ms antiguas, su primer uso en el software se data en los 50 (pincha aqu, te dejo este post donde hablamos del tema) (P1.2). Adems, el ciclo de vida iterativo e incremental es una de las bases de un proyecto gil, ms concretamente, con iteraciones cortas en tiempo, de pocas semanas, normalmente un mes y raramente ms de dos. Normalmente se habla, se lee, etc., el ciclo de vida iterativo e incremental (o incluso por defecto slo el el ciclo de vida iterativo). Pero ello no quiere decir que iterativo e incremental sea lo mismo. De hecho, el desarrollo iterativo no implica, ni presupone el uso del incremental, y viceversa. El problema es que muchas veces se olvida la parte iterativa, del ciclo de vida iterativo e incremental. Pero veamos antes qu implica incremental y qu iterativo. El ciclo de vida incremental Desarrollar por partes el producto software, para despus integrarlas a medida que se completan. Un ejemplo de un desarrollo puramente incremental puede ser la agregacin de mdulos en diferentes fases. El agregar cada vez ms funcionalidad al sistema. El ciclo de vida iterativo En cada ciclo, iteracin, se revisa y mejora el producto. Un ejemplo de desarrollo iterativo es aquel basado en refactorizaciones (te dejo el post de introduccin a la refactorizacin), en el que cada ciclo mejora ms la calidad del producto. Es importante sealar que este ciclo no implica aadir funcionalidades en el producto, pero si revisin y mejora. No olvides la parte iterativa, del ciclo de vida iterativo e incremental De la unin del ciclo de vida iterativo y el incremental al final de cada iteracin se consigue una versin ms estable del software, de ms calidad, y aadiendo adems nuevas funcionalidades respecto a versiones anteriores. Pero en la prctica, muchas veces nos encontramos con que los equipos olvidan la parte iterativa, olvidan que cada prototipo debe mejorar en calidad al anterior, y se centran solo en aadir funcionalidad. El problema de esto es que pasadas unas cuantas iteraciones, el producto se hace inmantenible, por su baja calidad, y por ello es muy difcil aadir nueva funcionalidad, alargndose las iteraciones, los ciclos, y muriendo la esencia de todo esto.
Sobre estos dos ciclos de vida te dejo un artculo de Cockburn especialmente aclaratorio.
10
How you answer that question yields very different results on what happens next on your project. I have always kept them separate, with good results. What stunned me, back in around 1994, was that the pundits and authors at the time seem to have gotten so excited at the thought of repeating the cycle at all that they lumped the two together and never saw the difference in what happened on the project based on whether you were revising old stuff or getting onto new stuff! Indeed I did, and so did a lot of projects. I visited a 200-person project team, where, as one manager put it when he finally saw the difference, Were iterating when we should be incrementing!! You can imagine the feeling of helplessness on that project as the developers saw the same requirements coming at them over and over again in slightly different forms, and no plan for making progress through the requirements set. At that time, the lesson was: be sure to increment; yes you will iterate anyway. More recently, on XP/agile projects, we see them incrementing like wildfire, but never putting time into the schedule to iterate (see the article ). Now the quality suffers. Note Iterative development was a particularly bad choice of words, and remains a troublesome phrase. Any sponsor hearing, Were going to do iterative development immediately hears, Were going to do a lot of rework! (Ouch, my wallet!) At least with incremental development they get to think, Were going to do step-wise growth. Their funding reflexes twitch differently (much more scared ((and rightfully so)) with iterative). Remember, Incremental fundamentally means add onto. Incremental development helps you improve your process. Iterative fundamentally means re-do. Iterative development helps you improve your product. Both need improvement. Create your staging, integration and rework strategies accordingly.
11
Comentaba Ambler 5, que un proyecto gil se podra definir como una manera de enfocar el desarrollo software mediante un ciclo iterativo e incremental, con equipos que trabajan de manera altamente colaborativa y autoorganizados. Es decir, un proyecto gil es un desarrollo iterativo ms la segunda gran caracterstica implicada directamente por la iteracin extrema: equipos colaborativos y autoorganizados. A diferencia de ciclos de vida iterativos e incrementales ms relajados, en un proyecto gil cada iteracin no es un mini cascada. Esto no es as, porque el objetivo de acortar al mximo las iteraciones (normalmente entre 1 y 4 semanas) lo hace casi imposible. Cuanto menor es el tiempo de iteracin ms se solapan las tareas. Hasta el punto que implicar que de manera no secuencial, muchas veces solapada, y repetitivamente, durante una iteracin se est casi a la vez diseando, programando y probando. Lo que implicar mxima colaboracin e interaccin de los miembros del equipo. Implicar equipos multidisciplinares, es decir, que no hay roles que slo diseen o programen todos pueden disear y programar. E implica auto-organizacin, es decir, que en la mayora de los proyectos giles no hay, por ejemplo, un nico jefe de proyecto responsable de asignar tareas. Frente a un ciclo de vida en cascada, o frente a un ciclo iterativo de iteraciones largas compuestas por pequeas cascadas, en un ciclo de vida gil:
12
El diseo en el desarrollo y las pruebas se realizan de manera continua. En un ciclo de vida en cascada se realizan de manera secuencial. Las personas que integran un equipo de desarrollo realizarn diferentes tareas. No existen equipos o roles especializados, que sin embargo s existan en el ciclo de vida en cascada.
La duracin de una iteracin es fija, incluso si no se han podido desarrollar todas las actividades planificadas para la misma. En cambio en los ciclos de vida en cascada generalmente se supera el tiempo planificado.
Un proyecto gil lleva la iteracin al extremo: 1. Se busca dividir las tareas del proyecto software en incrementos con una planificacin mnima y de una corta duracin (segn la metodologa gil, tpicamente entre 1 y 4 semanas). 2. Cada iteracin suele concluir con un prototipo operativo. Al final de cada incremento se obtiene un producto entregable que es revisado junto con el cliente, posibilitando la aparicin de nuevos requisitos o la perfeccin de los existentes, reduciendo riesgos globales y permitiendo la adaptacin rpida a los cambios. Normalmente un proceso gil se basa en un ciclo de vida iterativo e incremental pero no todo proceso iterativo e incremental es un proceso gil. Adems, estn la colaboracin y los equipos auto organizados, entonces, qu caracteriza un proyecto gil? en el siguiente captulo veremos que derivado de todo lo anterior se debe cumplir adems otros valores y principios.
13
El trmino metodologa es utilizado de manera coloquial, siendo rigurosos las metodologas son ms bien marcos de trabajo o frameworks
14
LO QUE NO DICE
Ausencia total de documentacin. Ausencia total de planificacin: planificar y ser flexible es diferente a improvisar. El cliente debe hacer todo el trabajo y ser el Jefe de Proyecto. El equipo puede modificar la metodologa sin justificacin. De estos cuatro valores surgen los doce principios del manifiesto. Estos principios son caractersticas que diferencian un proceso gil de uno tradicional. Los principios son los siguientes: 1. La prioridad es satisfacer al cliente mediante entregas tempranas y continuas de software que le aporten valor. 2. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva. 3. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas. 4. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto. 5. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo. 6. El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar informacin dentro de un equipo de desarrollo. 7. El software que funciona es la medida fundamental de progreso. 8. Los procesos giles promueven un desarrollo sostenible. Los promotores,
desarrolladores y usuarios deberan ser capaces de mantener una paz constante. 9. La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad. 10. La simplicidad es esencial. 11. Las mejores arquitecturas, requisitos y diseos surgen de los equipos organizados por s mismos. 12. En intervalos regulares, el equipo reflexiona respecto a cmo llegar a ser ms efectivo, y segn esto ajusta su comportamiento.
15
A modo de resumen, esta son las principales diferencias entre las metodologas giles y tradicionales:
16
En ocasiones existe la percepcin de que es incompatible unir modelos como CMMI o ISO/IEC 15504 ISO/IEC 12207 con metodologas giles. Sin embargo, esta concepcin no es correcta, ya que los modelos y las metodologas se encuentran en distintos niveles de abstraccin. Los modelos de procesos establecen qu es lo que espera encontrarse en los procesos, pero son las metodologas las que indicarn cmo deben realizarse. Es por esto que el uso de modelos de procesos y metodologas giles no debe considerarse un aspecto contradictorio si no complementario.
17
2. 3. 4. 5. 6. 7. 8. 9.
Video muy interesante y dinmico de la reunin en el Dcimo Aniversario del Manifiesto gil Desarrollo gil o tradicional: existe el punto intermedio? Una metodologa por cada proyecto Ciclo de vida iterativo e incremental Manifiesto gil CMMI o Mtodos giles? Guia Prctica de Supervivencia en una Auditora CMMI Procesos software
18