Tesis Final

DESARROLLO AGIL Y LEAN SOFTWARE DEVELOPMENT
TESIS
GERMAN E. SCHMIDT L.U: 41066
German E. Schmidt LU: 41066
NDICE
INTRODUCCIN........................................................................................................................................ 4 MANIFIESTO DE DESARROLLO GIL DE SOFTWARE.................................................................. 5 PRINCIPIOS GILES ................................................................................................................................ 6 CARACTERSTICAS DEL SOFTWARE................................................................................................. 8 EL DESARROLLO TRADICIONAL DEL SOFTWARE ..................................................................... 10 SEPARACIN DE DISEO Y CONSTRUCCIN ............................................................................... 11 LA IMPREVISIBILIDAD DE LOS REQUISITOS................................................................................ 13 COSTO DE LOS CAMBIOS EN LA CONSTRUCCIN DE SW........................................................................... 15 LOS PROBLEMAS Y ERRORES COMUNES DE LOS MTODOS NO GILES........................... 16 1. PERSONAS ............................................................................................................................................. 16 2. PROCESO ......................................................................................................................................... 19 CARACTERSTICAS DEL DESARROLLO GIL. ............................................................................. 21 BENEFICIOS DE USAR DESARROLLO GIL ................................................................................... 22 DESARROLLO GUIADO POR VALOR ........................................................................................................... 22 MEJOR MANEJO DE RIESGOS E INCERTIDUMBRE........................................................................................ 22 MEJORA DE LA PRODUCTIVIDAD ............................................................................................................... 23 APLICABILIDAD DEL DESARROLLO GIL ................................................................................................... 23 METODOLOGAS GILES DE DESARROLLO ............................................................................................... 24 X.P EXTREME PROGRAMMING ......................................................................................................... 25 LAS HISTORIAS DE USUARIO .................................................................................................................... 25 ROLES XP................................................................................................................................................. 26 Cliente................................................................................................................................................. 26 Encargado de pruebas ........................................................................................................................ 26 Encargado de seguimiento.................................................................................................................. 26 Entrenador:......................................................................................................................................... 26 Consultor ............................................................................................................................................ 26 Gestor: ................................................................................................................................................ 26 PROCESO XP ............................................................................................................................................ 26 1. Exploracin..................................................................................................................................... 27 2. Planificacin de la Entrega ............................................................................................................ 27 3. Iteraciones ...................................................................................................................................... 28 4. Produccin...................................................................................................................................... 28 5. Mantenimiento ................................................................................................................................ 28 6. Muerte del Proyecto........................................................................................................................ 29 EL JUEGO DE LA PLANIFICACIN ............................................................................................................... 29 Entregas pequeas.............................................................................................................................. 29 Metfora.............................................................................................................................................. 29 Pruebas ............................................................................................................................................... 30 Refactorizacin (Refactoring)............................................................................................................. 30 Programacin en parejas.................................................................................................................... 30 Propiedad colectiva del cdigo........................................................................................................... 31 Integracin contina........................................................................................................................... 31 40 horas por semana........................................................................................................................... 31 Cliente in-situ...................................................................................................................................... 31 Estndares de programacin .............................................................................................................. 32
ALGUNAS DE LAS CRTICAS DE XP ............................................................................................................ 32 SCRUM ....................................................................................................................................................... 33 ROLES EN SCRUM ..................................................................................................................................... 34 REUNIONES EN SCRUM ............................................................................................................................. 35 SCRUM DE SCRUM .................................................................................................................................... 35 DOCUMENTOS .......................................................................................................................................... 36 CRYSTAL................................................................................................................................................... 38 CARACTERSTICAS.................................................................................................................................... 39 EL CDIGO GENTICO .............................................................................................................................. 42 CONCLUSIN ............................................................................................................................................ 43 DYNAMIC SYSTEMS DEVELOPMENT METHOD (DSDM) ............................................................ 44 FASES EN LA CONSTRUCCIN DE UN SISTEMA ........................................................................................... 45 FEATURE DRIVEN DEVELOPMENT (F.D.D) .................................................................................... 48 ROLES ...................................................................................................................................................... 50 CONCLUSIN ............................................................................................................................................ 51 ADAPTIVE SOFTWARE DEVELOPMENT ......................................................................................... 52 CONCLUSION ............................................................................................................................................ 54 LEAN SOFTWARE DEVELOPMENT ................................................................................................... 55 OBJETIVOS ............................................................................................................................................ 55 LOS PRINCIPIOS LEAN ............................................................................................................................... 56 Nociones previas importantes............................................................................................................. 56 Buscar la fuente de los errores en el sistema...................................................................................... 56 LOS SIETE PRINCIPIOS ............................................................................................................................... 57 Eliminar los residuos .......................................................................................................................... 57 Ampliar el aprendizaje........................................................................................................................ 58 Decida lo ms tarde posible................................................................................................................ 59 Reaccionar tan rpido como sea posible ............................................................................................ 61 Potenciar el equipo ............................................................................................................................. 62 Crear la integridad ............................................................................................................................. 62 Respetar a las personas ...................................................................................................................... 63 UN POCO MAS DE LEAN........................................................................................................................... 64 Crear conocimiento ............................................................................................................................ 65 Entregar rpidamente......................................................................................................................... 66 CRITICAS AL L.S.D................................................................................................................................... 67 AGILIDAD, CAOS Y COMPLEJIDAD .................................................................................................. 68 CONCLUSIN........................................................................................................................................... 72 REFERENCIAS BIBLIOGRFICAS...................................................................................................... 72
INTRODUCCIN
El desarrollo de software no es una tarea fcil. Prueba de ello es que existen numerosas propuestas metodolgicas que inciden en distintas dimensiones del proceso de desarrollo. Por una parte tenemos aquellas propuestas ms tradicionales que se centran especialmente en el control del proceso, estableciendo rigurosamente las actividades involucradas, los artefactos que se deben producir, y las herramientas y notaciones que se usarn. Estas propuestas han demostrado ser efectivas y necesarias en un gran nmero de proyectos, pero tambin han presentado problemas en otros muchos. Una posible mejora es incluir en los procesos de desarrollo ms actividades, ms artefactos y ms restricciones, basndose en los puntos dbiles detectados. Sin embargo, el resultado final sera un proceso de desarrollo ms complejo que puede incluso limitar la propia habilidad del equipo para llevar a cabo el proyecto. Otra aproximacin es centrarse en otras dimensiones, como por ejemplo el factor humano o el producto software. Esta es la filosofa de las metodologas giles, las cuales dan mayor valor al individuo, a la colaboracin con el cliente y al desarrollo incremental del software con iteraciones muy cortas. Este enfoque est mostrando su efectividad en proyectos con requisitos muy cambiantes y cuando se exige reducir drsticamente los tiempos de desarrollo pero manteniendo una alta calidad. Las metodologas giles estn revolucionando la manera de producir software, y a la vez generando un amplio debate entre sus seguidores y quienes por escepticismo o convencimiento no las ven como alternativa para las metodologas tradicionales. El desarroll de software es una disciplina que se relaciona en forma directa con el progreso como las mejoras en la productividad, y muchos programadores trabajando duramente y generando ganancias para las empresas y toda la sociedad. Pero tambin se ve muy seguido que los proyectos sufren retrasos y no se obtienen los resultados esperados pese el talento y esfuerzo puesto en accin por parte de los analistas, programadores y usuarios para que "el nuevo sistema" funcione como corresponde en tiempo y forma. Cabe hacerse la siguiente pregunta, porque tantos proyectos de desarrollo software no tener tiempo, cuesta ms de lo presupuestado, tienen problemas de calidad serios y genera un menor valor que lo esperado? Estas preguntas se formularon los 17 profesionales expertos en desarrollo cuando se reunieron en febrero de 2001 para analizar el problema y decidieron redactar el manifiesto gil. Se trata de un compromiso pblico en buscar nuevas y mejores formas de desarrollar programas poniendo nfasis en las personas y sus interacciones, la colaboracin y la respuesta continua el cambio, explorando dos formas de hacer las cosas y compartiendo experiencias.
Manifiesto de desarrollo gil de software

Estamos descubriendo formas mejores desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A travs este trabajo hemos aprendido a valorar: individuos en interacciones sobre procesos y herramientas. La gente es el principal factor de xito de un proyecto software. Si se sigue un buen proceso de desarrollo, pero el equipo falla, el xito no est asegurado; sin embargo, si el equipo funciona, es ms fcil conseguir el objetivo final, aunque no se tenga un proceso bien definido. No se necesitan desarrolladores brillantes, sino desarrolladores que se adapten bien al trabajo en equipo. As mismo, las herramientas (compiladores, depuradores, control de versiones, etc.) son importantes para mejorar el rendimiento del equipo, pero el disponer ms recursos que los estrictamente necesarios tambin puede afectar negativamente. En resumen, es ms importante construir un buen equipo que construir el entorno. Muchas veces se comete el error de construir primero el entorno y esperar que el equipo se adapte automticamente. Es mejor crear el equipo y que ste configure su propio entorno de desarrollo en base a sus necesidades. software funcionando sobre documentacin extensiva. Aunque se parte de la base de que el software sin documentacin es un desastre, la regla a seguir es no producir documentos a menos que sean necesarios de forma inmediata para tomar un decisin importante. Estos documentos deben ser cortos y centrarse en lo fundamental. Si una vez iniciado el proyecto, un nuevo miembro se incorpora al equipo de desarrollo, se considera que los dos elementos que ms le van a servir para ponerse al da son: el propio cdigo y la interaccin con el equipo. Colaboracin con el cliente sobre de negociacin contractual. Las caractersticas particulares del desarrollo de software hace que muchos proyectos hayan fracasado por intentar cumplir unos plazos y unos costes preestablecidos al inicio del mismo, segn los requisitos que el cliente manifestaba en ese momento. Por ello, se propone que exista una interaccin constante entre el cliente y el equipo de desarrollo. Esta colaboracin entre ambos ser la que marque la marcha del proyecto y asegure su xito. Respuesta ante el cambio sobre seguir un plan. La habilidad de responder a los cambios que puedan surgir a los largo del proyecto (cambios en los requisitos, en la tecnologa, en el equipo, etc.) determina tambin el xito o fracaso del mismo. Por lo tanto, la planificacin no debe ser estricta puesto que hay muchas variables en juego, debe ser flexible para poder adaptarse a los cambios que puedan surgir. Una buena estrategia es hacer planificaciones detalladas para unas pocas semanas y planificaciones mucho ms abiertas para unos pocos meses.
Esto es aunque valoramos los elementos derecha valoramos ms los de la izquierda.
PRINCIPIOS GILES
Los valores anteriores inspiran los doce principios del manifiesto. Estos principios son las caractersticas que diferencian un proceso gil de uno tradicional. Los dos primeros son generales y resumen gran parte del espritu gil. Son: 1. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor. Un proceso es gil si a las pocas semanas de empezar ya entrega software que funcione aunque sea rudimentario. El cliente decide si pone en marcha dicho software con la funcionalidad que ahora le proporciona o simplemente lo revisa e informa de posibles cambios a realizar. 2. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva. Este principio es una actitud que deben adoptar los miembros del equipo de desarrollo. Los cambios en los requisitos deben verse como algo positivo. Les va a permitir aprender ms, a la vez que logran una mayor satisfaccin del cliente. Este principio implica adems que la estructura del software debe ser flexible para poder incorporar los cambios sin demasiado coste aadido. El paradigma orientado a objetos puede ayudar a conseguir esta flexibilidad. Luego existen una serie de principios que tienen que ver directamente con el proceso de desarrollo de software a seguir: 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. Las entregas al cliente se insisten en que sean software, no planificaciones, ni documentacin de anlisis o de diseo. 4. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto. El proceso de desarrollo necesita ser guiado por el cliente, por lo que la interaccin con el equipo es muy frecuente. 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. La gente es el principal factor de xito, todo los dems (proceso, entorno, gestin, etc.) queda en segundo plano. Si cualquiera de ellos tiene un efecto negativo sobre los individuos debe ser cambiado. 6. El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar informacin dentro de un equipo de desarrollo. Los miembros de equipo deben hablar entre ellos, ste es el principal modo de comunicacin. Se pueden crear documentos pero no todo estar en ellos, no es lo que el equipo espera. . 7. El software que funciona es la medida principal de progreso. El estado de un proyecto no viene dado por la documentacin generada o la fase en la que se encuentre, sino por el cdigo generado y en funcionamiento. Por ejemplo, un proyecto se encuentra al 50% si el 50% de los requisitos ya estn en funcionamiento.
8. Los procesos giles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberan ser capaces de mantener una paz constante. No se trata de desarrollar lo ms rpido posible, sino de mantener el ritmo de desarrollo durante toda la duracin del proyecto, asegurando en todo momento que la calidad de lo producido es mxima. Finalmente los ltimos principios estn ms directamente relacionados con el equipo de desarrollo, en cuanto metas a seguir y organizacin del mismo. 9. La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad. Producir cdigo claro y robusto es la clave para avanzar ms rpidamente en el proyecto. La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad. Producir cdigo claro y robusto es la clave para avanzar ms rpidamente en el proyecto. 10. La simplicidad es esencial. Tomar los caminos ms simples que sean consistentes con los objetivos perseguidos. Si el cdigo producido es simple y de alta calidad ser ms sencillo adaptarlo a los cambios que puedan surgir. 11. Las mejores arquitecturas, requisitos y diseos surgen de los equipos organizados por s mismos. Todo el equipo es informado de las responsabilidades y stas recaen sobre todos sus miembros. Es el propio equipo el que decide la mejor forma de organizarse, de acuerdo a los objetivos que se persigan. 12. En intervalos regulares, el equipo reflexiona respecto a cmo llegar a ser ms efectivo, y segn esto ajusta su comportamiento. Puesto que el entorno est cambiando continuamente, el equipo tambin debe ajustarse al nuevo escenario de forma continua. Puede cambiar su organizacin, sus reglas, sus convenciones, sus relaciones, etc., para seguir siendo gil.
Caractersticas del Software.

Es inmaterial e invisible El comprador lo puede evaluar cuando ya ha sido construido. El Software se desarrolla, no se fabrica. Es complejo. Los sistemas actuales estn formados por miles de funciones con interfaces complejas entre ellas. Es excesivamente maleable.
El Software se desarrolla, no se fabrica. En cualquier sistema de produccin podemos observar dos fases la de desarrollo y la de fabricacin. El desarrollo es lento y costoso. La fabricacin en serie y con costes estables. Con el Software ocurre lo mismo pero ... Muchas aplicaciones se desarrollan a medida, sin usar componentes existentes. La fabricacin no se considera tal. El software es excesivamente maleable. Todo el mundo exige que se realicen cambios sobre el Software como respuesta a pequeos cambios del entorno. Adems no es fcil comprender su comportamiento, segn Pressman: o La curva de fallos del Hardware. o La curva ideal de fallos del Software. o La curva real de fallos del Software. Clasificaciones del software desde diversos puntos de vista: La utilizacin que se hace de el. El tratamiento comercial que tiene. En relacin con la funcionalidad que aporta a la maquina. Exigencia en eficiencia y los factores crticos que se le exigen. Segn la utilizacin del software: De Gestin: Se trata del software que da soporte a los procesos comerciales y manejo de informacin que tienen por objetivo permitir a las gestiones una mejor gestin. Produccin y control de procesos: Es el software que da soporte a los procesos productivos y conducentes a desarrollar las actividades propias de cada negocio. Robtica: Software que se centra en controlar y automatizar el comportamiento de engendros mecnicos que colaboran con los seres humanos en diversos campos, desde la ortopedia hasta la exploracin de otros planetas. De ingeniera y Cientfico: Da soporte a los procesos creativos y de diseo de las personas, se caracteriza por clculos matemticos complejos. Ejemplo de ello son las herramientas CAD o el soporte a seguimiento de acontecimientos en el espacio. Ofimtico: Software que permite a las personas utilizar los ordenadores en las tareas que habitualmente se realizan en oficinas.
De Formacin y divulgacin: Software que tiene por objetivo el transferir conocimientos al ser humano. Domtico: Software que se utiliza para controlar el hbitat del ser humano, a pequea escala. Va desde las alarmas hasta el control de temperaturas de un hogar. Ocio y Juegos: En esta categora entran un gran conjunto de aplicaciones que tienen por objetivo el que el ser humano pase algo de tiempo disfrutando con los ordenadores.
El desarrollo tradicional del software

El desarrollo de software es una actividad problematica, frecuentemente caracterizada por la frase "codifica y compilar". El software se escribe con un plan subyacente mnimo, y el diseo del sistema se hace con muchas decisiones a corto plazo. Esto realmente funciona muy bien si el sistema es pequeo, pero conforme el sistema crece llega a ser cada vez ms difcil agregar nuevos aspectos al mismo. Adems los errores llegan a ser cada vez ms frecuentes y ms difciles de encontrar. La sea tpica de tal sistema es una larga fase de pruebas despus de que el sistema ha sido terminado. Tal fase larga de pruebas hace estragos con los planes de pruebas y depurado llegando a ser imposible de incluir en el programa de trabajo. Las metodologas imponen un proceso disciplinado sobre el desarrollo de software con el fin de hacerlo ms predecible y eficiente. Lo hacen desarrollando un proceso detallado con un fuerte nfasis en planificar inspirado por otras disciplinas de la ingeniera. Las metodologas ingenieriles han estado presentes durante mucho tiempo. No se han distinguido precisamente por ser muy exitosas. An menos por su popularidad. La crtica ms frecuente a estas metodologas es que son burocrticas. Hay tanto que hacer para seguir la metodologa que el ritmo entero del desarrollo se retarda. La forma tradicional de desarrollar programas se basa en procesos redefinidos con una documentacin muy precisa y extensa, una planificacin inicial sper detallada que debe seguirse estrictamente. Esta forma de trabajar surgi naturalmente hace unos 50 aos como una adaptacin manejo de proyectos de ingeniera, que no lo ms parecido a desarrollar programas que se conoca en ese momento, y funcion razonablemente bien en el comienzo. Tambin hay que tener en cuenta que en esa poca las computadoras eran grandes y extremadamente caras, la mayor parte la inversin informtica se hallaba en los equipos y por este motivo los programas se hacan a medida para que las mquinas adquiridas puedan realizar unas tareas muy concretas. Los proyectos de desarrollo actuales incluyen desafos muy diferentes a los que presentan a construir puentes y casas por lo sorprende que los mtodos tradicionales (de tipo ingenieril) esta en crisis. Tradicionalmente los proyectos se dividen en etapas bien definidas: Anlisis de factibilidad. Anlisis de requerimientos. Diseo Programacin. Testeo. Generalmente se trata de que haya retroalimentacin entre las etapas contiguas, de tal forma, por ejemplo que existe un momento en el que se mejoren los requerimientos en base a comentarios, sugerencias y necesidades de los responsables del diseo. Sin embargo, esta forma de generar programas genera serios inconvenientes, debido a que el comienzo del proyecto, es cuando menos se conocen las caractersticas del problema a resolver, se toman las decisiones mayor relevancia, impacto e importancia para el resto del proyecto. En otras palabras en el momento que menos se sabe sobre lo que se va realizar se deciden lineamientos que van a afectar el desarrollo del proyecto durante toda la duracin del mismo. Se argumenta a favor de esto, que cuenta con profesionales que conozcan el rea de aplicacin del problema, solucin esta dificultad.
10
La informacin recogida a lo largo del tiempo demuestra que contar con expertos es importante, pero no soluciona la crisis. Como es muy probable tomar decisiones equivocadas al comienzo del proyecto suele ocurrir que el software obtenido siguiendo el mtodo tradicional no cumple los objetivos, no se termina tiempo, y resulta mucho ms caro que lo presupuestado. En particular, esto ocurre con mayor frecuencia en casos en que el grupo de desarrollo debiera crear algo totalmente nuevo, o de caractersticas especficas que nadie creado an, lo cual es muy cierto para la mayora los proyectos de software. Porque en caso contrario, la organizacin compr directamente un producto sistema ya hecho en lugar de desarrollarlo por ellos mismos. Como propuesta para solucionar estos problemas han surgido una serie de "mtodos giles" de desarrollar programas y manejo de proyectos en general, cuyas caractersticas sern enunciadas a continuacin.
Separacin de Diseo y Construccin

La inspiracin usual para las metodologas han sido disciplinas como las ingenieras civil o mecnica. Tales disciplinas enfatizan que hay que planear antes de construir. Los ingenieros trabajan sobre una serie de esquemas que indican precisamente qu hay que construir y como deben juntarse estas cosas. Muchas decisiones de diseo, como la manera de controlar la carga sobre un puente, se toman conforme los dibujos se producen. Los dibujos se entregan entonces a un grupo diferente, a menudo una compaa diferente, para ser construidos. Se supone que el proceso de la construccin seguir los dibujos. En la prctica los constructores se encuentran con algunos problemas, pero stos son normalmente poco importantes.Como los dibujos especifican las piezas y cmo deben unirse, actan como los fundamentos de un plan de construccin detallado. Dicho plan define las tareas que necesitan hacerse y las dependencias que existen entre estas tareas. Esto permite un plan de trabajo y un presupuesto de construccin razonablemente predecibles. Tambin dice en detalle cmo deben hacer su trabajo las personas que participan en la construccin. Esto permite que la construccin requiera menos pericia intelectual, aunque se necesita a menudo mucha habilidad manual. As que lo que vemos aqu son dos actividades fundamentalmente diferentes. El diseo, qu es difcil de predecir y requiere personal caro y creativo, y la construccin que es ms fcil de predecir. Una vez que tenemos el diseo, podemos planear la construccin. Una vez que tenemos el plan de construccin, podemos ocuparnos de la construccin de una manera ms predecible. En ingeniera civil la construccin es mucho ms costosa y tardada que el diseo y la planeacin. As el acercamiento de muchas metodologas es: queremos un plan de trabajo predecible que pueda usar gente del ms bajo nivel. Para hacerlo debemos separar el plan de la construccin. Por consiguiente necesitamos entender cmo hacer el diseo de software de modo que la construccin pueda ser sencilla una vez que el plan est hecho. Qu forma toma este plan? Para muchos, ste es el papel de notaciones de diseo como el UML. Si podemos hacer todas las decisiones significativas usando UML, podemos armar un plan de construccin y entonces podemos dar planes a los programadores como una actividad de construccin.
11
Pero aqu surgen preguntas cruciales. Es posible armar un plan que sea capaz de convertir el cdigo en una actividad de construccin predecible? Y en tal caso, es la construccin suficientemente grande en costo y tiempo para hacer valer la pena este enfoque? Todo esto trae a la mente ms preguntas. La primera es la cuestin de cun difcil es conseguir un diseo UML en un estado que pueda entregarse a los programadores. El problema con un diseo tipo UML es que puede parecer muy bueno en el papel, pero resultar seriamente fallido a la hora de la programacin. Los modelos que los ingenieros civiles usan est basado en muchos aos de prctica guardados en cdigos ingenieriles. Adems los problemas importantes, como el modo en que juegan las fuerzas, son dciles al anlisis matemtico. La nica verificacin que podemos hacer con los diagramas UML es la revisin cuidadosa. Mientras esto es til trae errores al diseo que slo se descubren durante la codificacin y pruebas. Incluso los diseadores experimentados, se sorprenden a menudo cuando convierten dichos diseos en software. Otro problema es el costo comparativo. Cuando se construye un puente, el costo del esfuerzo en el plan es aproximadamente un 10% del total, siendo el resto la construccin. En software la cantidad de tiempo gastada codificando es mucho, mucho menor. Steve McConnell sugiere que para un proyecto grande, slo 15% del proyecto son cdigo y pruebas unitarias, una inversin casi perfecta de las proporciones de la construccin del puente. Aun cuando se consideren las pruebas parte de la construccin, el plan es todava 50% del total. Esto genera una pregunta importante sobre la naturaleza del diseo en software comparado con su papel en otras ramas de la ingeniera. Esta clase de preguntas llevaron a Jack Reeves a sugerir que de hecho el cdigo fuente es un documento de diseo y que la fase de construccin est en realidad en la compilacin y el ligado. De hecho cualquier cosa que pueda tratarse como construccin puede y debe automatizarse. Estas ideas llevan a algunas conclusiones importantes: En software la construccin es tan barata que es casi gratis. En software todo el esfuerzo est en el diseo, de modo que requiere de personas creativas y talentosas. Los procesos creativos no se planean fcilmente, de modo que la previsibilidad bien puede ser una meta imposible.
Debemos ser muy cautos al usar la metfora de la ingeniera tradicional para construir software. Es un tipo diferente de actividad y por ende requiere un proceso diferente.
12
La imprevisibilidad de los Requisitos

Hay un dicho que se oye en cada proyecto problemtico. Los desarrolladores vienen y me dicen "el problema con este proyecto es que los requisitos cambian todo el tiempo". Lo sorprendente de esta situacin es que sorprenda a cualquiera. En el negocio de construccin de software los cambios en los requisitos son la norma, la pregunta es qu hacemos al respecto. Una forma es tratar los requisitos cambiantes como el resultado de una pobre ingeniera de requisitos. La idea detrs de la ingeniera de requisitos es conseguir un cuadro totalmente entendido de los requisitos antes de empezar a construir el software, conseguir la firma del cliente sobre estos requisitos, y entonces preparar procedimientos que limiten los cambios de requisitos despus de la firma. Un problema con esto es que simplemente tratar de entender las opciones para los requisitos es duro. Es aun ms duro porque la organizacin del desarrollo normalmente no proporciona la informacin del costo en los requisitos. El cliente termina solicitando algo que el vendedor no puede cotizar con exactitud. Sin una buena idea del costo, cmo puede el cliente decidir si quiere pagar por ese pedido? La estimacin es difcil por muchas razones. En parte porque el desarrollo de software es una actividad de diseo, difcil de planear y costear. En parte porque los materiales bsicos cambian rpidamente. En parte por lo mucho que depende de los individuos involucrados, y los individuos son difciles de predecir y cuantificar. La naturaleza intangible del software tambin afecta. Es muy difcil saber qu valor aporta un rasgo de software hasta que se usa en realidad. Slo cuando se usa realmente una versin temprana de algn software se empieza a entender cules rasgos son valiosos y cules no. Esto lleva al punto irnico de que es de esperarse que los requisitos sean cambiables. Despus de todo se supone que el software es "suave". As no slo son cambiables los requisitos, sino que deben de serlo. Toma mucha energa conseguir que los clientes de software corrijan los requisitos. Es aun peor si ellos han estado alguna vez en desarrollo de software, porque entonces "saben" que el software es fcil de cambiar. Pero aun cuando se pudiera controlar todo esto y realmente se pudiera conseguir un conjunto exacto y estable de requisitos, probablemente an no estamos a salvo. En la economa de hoy las fuerzas de negocios fundamentales cambian el valor de los rasgos de software demasiado rpidamente. El que podra ser un buen conjunto de requisitos ahora, no ser tan bueno en seis meses. An cuando el cliente pueda corregir sus requisitos, el mundo de negocios no va a detenerse por l. Y muchos cambios en el mundo de negocios son completamente imprevisibles: cualquiera que diga otra cosa est mintiendo, o ya ha hecho mil millones en la bolsa de valores. Casi todo en el desarrollo de software depende de los requisitos. Si no se pueden obtener requisitos estables no se puede obtener un plan predecible.
13
Es Imposible la Previsibilidad?
En general, no. Hay algunos desarrollos de software dnde la previsibilidad es posible, sin embargo no se cree que el software comercial encaje en esa categora. Para ste se necesita un tipo diferente de proceso. Uno de los grandes peligros es pretender que se puede seguir un proceso predecible cuando no se puede. La gente que trabaja en metodologas no es buena en identificar condiciones lmite: los lugares donde la metodologa pasa de apropiada en inapropiada. La mayora de los metodologistas quieren que sus metodologas sean usadas por todos, de modo que no entienden ni publican sus condiciones lmite. Esto lleva a la gente a usar una metodologa en malas circunstancias, como usar una metodologa predictiva en una situacin imprevisible. Hay una tentacin fuerte para hacer eso. La previsibilidad es una propiedad muy deseable. No obstante creer que se puede ser predecible cuando no se puede, lleva a situaciones en donde las personas construyen un plan temprano, y entonces no pueden manejar la situacin cuando el plan se cae en pedazos. Usted acaba viendo el plan y la realidad flotando aparte. Durante algn tiempo usted podr pretender que el plan es vlido. Pero en algn punto la deriva es demasiada y el plan se cae en pedazos. Normalmente la cada es dolorosa. As si usted est en una situacin impredecible no puede usar una metodologa predictiva. se es un golpe duro. Significa que tantos modelos para controlar proyectos, y muchos de los modelos para llevar la relacin con el cliente, ya no son ciertos. Los beneficios de la previsibilidad son tan grandes, que es difcil dejarlos ir. Como en tantos problemas la parte ms difcil est simplemente en comprender que el problema existe. De cualquier modo dejar ir la previsibilidad no significa que hay que volver al caos ingobernable. Ms bien hace falta un proceso que pueda dar control sobre la imprevisibilidad. De eso se trata la adaptabilidad.
14
Estadstica realizada sobre 8 proyectos de Software Estadounidenses.
rea: Sistemas de Defensa en Tiempo Real

Pagado pero no entregado Entregado pero no utilizado abandonado o rechazado Utilizado despus de cambios Utilizado como se entrego
0.5
1.5
2.5
3.5
Millones de dolares
Costo de los Cambios en la Construccin de SW

En la siguiente figura se muestra el costo de producir cambios en el software que se desarrolla mediante una metodologa tradicional versus el costo de producir cambios en el software que se desarrolla mediante alguna de las metodologas giles. Como se puede apreciar, a medida que avanza el tiempo, el costo es exponencial en el caso de la construccin mediante una metodologa tradicional.
costo del cambio
metodologa tradicional
suposicin metodologa gil tiempo
15
Los problemas y errores comunes de los mtodos no giles

Los desarrolladores, directivos y clientes normalmente tienen buenas razones para tomar las decisiones que toman, y la apariencia seductora de los errores clsicos es una de las razones de que esos errores se cometan tan a menudo. Pero debido a que se han cometido muchas veces, sus consecuencias se han hecho fciles de predecir. Y los errores rara vez producen los resultados que la gente espera.
1. Personas
A continuacin aparecen algunos de los errores clsicos relacionados con las personas. 1.1. Motivacin dbil. Estudio tras estudio ha mostrado que la motivacin probablemente tiene mayor efecto sobre la productividad y la calidad que ningn otro factor. Ejemplo: directivos que a lo largo de todo el proyecto toman medidas que minan la moral: como dar nimos a diario al principio para pedir horas extras en la mitad, y como irse de vacaciones mientras el equipo esta trabajando incluso los das de fiesta, para dar recompensas al final del proyecto que resultan ser de menos de un dlar por cada hora extra. 1.2. Empleados problemticos incontrolados. Un fallo al tratar con personal problemtico tambin amenaza la velocidad de desarrollo. Un fallo al tomar una decisin cuando se trata con un empleado problemtico es una de las quejas ms comunes que tienen los miembros del equipo respecto de sus responsabilidades, el equipo sabe que uno de ellos es una manzana podrida, pero el jefe del equipo no hace nada. El resultado es predecible: rehacer el trabajo de la manzana podrida. 1.3. Hazaas. Algunos desarrolladores de software ponen un gran nfasis en la realizacin de hazaas en los proyectos. Pero lo que hacen tiene ms de malo que de bueno. Ejemplo, los directivos de nivel medio dan mayores aplausos a actitudes del tipo ser capaz de que a los progresos firmes y consistentes y a los informes significativos de progreso. El resultado es un modelo de planificacin al lmite en el que las amenazas de desajuste del plan no se detectan, no se conocen o ni se informan a la cadena de directivos hasta el ltimo minuto. Un pequeo equipo de desarrollo y sus jefes inmediatos toman como rehenes a una compaa entera por no admitir que tiene problemas para cumplir su plan. El nfasis en los comportamientos heroicos fomenta correr un riesgo extremo, e impide la cooperacin entre los mltiples elementos que contribuyen al proceso de desarrollo del software. Algunos directivos fomentan el comportamiento heroico cuando se concentran con demasiada firmeza en actitudes del tipo "ser capaz de". Elevando estas actitudes por encima de informes del estado exacto y a veces pesimista, los directivos de estos proyectos coartan su capacidad de tomar medidas correctivas. Ni siquiera saben que tienen que emprender acciones correctoras hasta que el dao ya est hecho. Como dijo Tom DeMarco, las actitudes <<ser capaz de>> convierten pequeos contratiempos en autnticos desastres.
16
1.4. Aadir ms personal a un proyecto retrasado. Este es quizs el ms clsico de los errores clsicos. Cuando un proyecto se alarga, aadir ms gente puede quitar ms productividad a los miembros del equipo existente de la que aaden los nuevos miembros. Aadir gente a un proyecto retrasado con echar nafta al fuego. 1.5. Oficinas repletas y ruidosas. La mayora de los desarrolladores consideran sus condiciones de trabajo como insatisfactorias. Alrededor del 60 por 100 indican que no tienen suficiente silencio ni privacidad. Los trabajadores que estn en oficinas silenciosas y privadas tienden a funcionar significativamente mejor que aquellos que ocupan cubculos en salas ruidosas y repletas. Los entornos repletos y ruidosos alargan los planes de desarrollo. 1.6. Fricciones entre los clientes y los desarrolladores. Las fricciones entre los clientes y los desarrolladores pueden presentarse de distintas formas. A los clientes pueden parecerles que los desarrolladores no cooperan cuando rehusan comprometerse con el plan de desarrollo que desean los clientes o cuando fallan al entregar lo prometido. A los desarrolladores puede parecerles que los clientes no son razonables porque insisten en planes irreales o cambios en los requerimientos despus de que stos hayan sido fijados. Pueden ser simplemente conflictos de personalidad entre dos grupos. El principal efecto de esta friccin es la mala comunicacin, y los efectos secundarios de la mala comunicacin incluyen el pobre entendimiento de los requerimientos, pobre diseo de la interfaz de usuario y, en el peor caso, el rechazo del cliente a aceptar el producto acabado. En el caso medio, las fricciones entre clientes y desarrolladores de software llegan a ser tan severas que ambas partes consideran la cancelacin del proyecto (Jones, 1994). Para remediar estas fricciones se consume tiempo, y distraen tanto a desarrolladores como a clientes del trabajo real en el proyecto. 1.7. Expectativas pocos realistas. Una de las causas ms comunes de fricciones entre los desarrolladores y sus clientes o los directivos son las expectativas poco realistas. Ejemplo, no tener razones tcnicas para pensar que un software se podr desarrollar en 6 meses, pero se es el plazo en que lo quiere el comit ejecutivo de la compaa. La incapacidad del jefe de proyecto para corregir esta expectativa irreal ser la principal fuente de problemas. En otros casos, los directivos o los desarrolladores de un proyecto se buscan problemas al pedir fondos basndose en estimaciones de planificacin demasiado optimistas. Aunque por s mismas las expectativas irreales no alargan el plan, contribuyen a la percepcin de que el plan de desarrollo es demasiado largo, y de que puede ser malo. 1.8. Falta de un promotor efectivo del proyecto. Para soportar muchos de los aspectos del desarrollo rpido es necesario un promotor del proyecto de alto nivel, incluyendo una planificacin realista, el control de cambios y la introduccin de nuevos mtodos de desarrollo. Sin un promotor ejecutivo efectivo, el resto del personal de alto nivel de la empresa puede forzar a que se acepten fechas de entrega irreales o hacer cambios que debiliten el proyecto. 1.9. Falta de participacin de los implicados. Todos los principales participantes del esfuerzo de desarrollo de software deben implicarse en el proyecto.
17
Incluyendo a los promotores, ejecutivos, responsables del equipo, miembros del equipo, personal de ventas, usuarios finales, clientes y cualquiera que se juegue algo con el proyecto. La cooperacin estrecha slo se produce si se han implicado todos los participantes, permitiendo una coordinacin precisa del esfuerzo para el desarrollo rpido, que es imposible conseguir sin una buena participacin. 1.10. Falta de participacin del usuario. La razn nmero uno de que los proyectos de Sistemas de Informacin tuviesen xito es la implicacin del usuario. Los proyectos que no implican al usuario desde el principio corren el riesgo de que no se comprendan los requerimientos del proyecto y son vulnerables a que se consuma tiempo en prestaciones que ms tarde retrasarn el proyecto. 1.11. Poltica antes que desarrollo. Hay cuatro tipos diferentes de orientaciones polticas. Los "polticos" estn especializados en la "gestin", centrndose en las relaciones con sus directivos. Los "investigadores" se centran en explorar y reunir la informacin. Los "aislacionistas" estn solos, creando fronteras para el proyecto que mantienen cerradas a los que no son miembros del equipo. Primar la poltica en vez de los resultados es fatal para el desarrollo orientado a la velocidad. 1.12. Ilusiones. Muchos problemas del desarrollo del software se deben a la ilusin. Cuntas veces hemos escuchado cosas como stas a distintas personas: "Ninguno de los miembros del proyecto cree realmente que pueda completarse el proyecto de acuerdo con el plan que tienen, pero piensan que quizs si trabajan duro, y nada va mal, y tienen un poco de suerte, sern capaces de concluir con xito". "Nuestro equipo no hace mucho trabajo para la coordinacin de las interfaces entre las distintas partes del producto, pero tenemos una buena comunicacin para otras cosas, y las interfaces son relativamente simples, as que probablemente slo necesitaremos un da o dos para eliminar los errores" Las ilusiones no son slo optimismo. Realmente consisten en cerrar los ojos y esperar que todo funcione cuando no se tienen las bases razonables para pensar que ser as. Las ilusiones al comienzo del proyecto llevan a grandes explosiones al final. Impiden llevar a cabo una planificacin coherente y pueden ser la raz de ms problemas en el software que todaslas otras causas combinadas.
18
2. Proceso Los errores relacionados con el proceso malgastan el talento y el esfuerzo del personal. A continuacin se muestran algunos de los peores errores relacionados con el proceso. 2.1. Planificacin excesivamente optimista. Los retos a los que se enfrenta alguien que desarrolla una aplicacin en tres meses son muy diferentes de aquellos a los que se enfrenta alguien que desarrolla una aplicacin que necesita un ao. Fijar un plan excesivamente optimista predispone a que el proyecto falle por infravalorar el alcance del proyecto, minando la planificacin efectiva, y reduciendo las actividades crticas para el desarrollo, como el anlisis de requerimientos o el diseo. Tambin supone una excesiva presin para los desarrolladores, quienes a largo plazo se ven afectados en su moral y su productividad. 2.2. Gestin de riesgos insuficiente. Algunos errores no son lo suficientemente habituales como para considerarlos clsicos. Son los llamados "riesgos". Como con los errores clsicos, si no ejercemos una gestin activa de los riesgos, con qu slo vaya mal una cosa se pasar de tener un proyecto con un desarrollo rpido a uno con un desarrollo lento. El fallo de no gestionar uno solo de estos riesgos es un error clsico. 2.3. Planificacin insuficiente. Si no planificamos para conseguir un desarrollo rpido, no podemos esperar obtenerlo. 2.4. Abandono de planificacin bajo presin. Los equipos de desarrollo hacen planes y rutinariamente los abandonan cuando se tropiezan con un problema en la planificacin. El problema no est en el abandono del plan, sino ms bien en fallar al no crear un plan alternativo, y caer entonces en el modo de trabajo de codificar y corregir. Ejemplo, un equipo abandona su plan despus de fallar en la primera entrega, y esto es lo habitual. A partir de este punto, el trabajo no tiene coordinacin ni elegancia. 2.5. Prdida de tiempo en el inicio difuso. El "inicio difuso" es el tiempo que transcurre antes de que comience el proyecto; este tiempo normalmente se pierde en el proceso de aprobar y hacer el presupuesto. No es poco comn que un proyecto desperdicie meses o aos en un inicio difuso, y entonces se est a las puertas de un plan agresivo. Es mucho ms fcil y barato y menos arriesgado suprimir unas pocas semanas o meses del inicio difuso en vez de comprimir el plan de desarrollo en ese mismo tiempo. 2.6. Escatimar en las actividades iniciales. Los proyectos se aceleran intentando acortar las actividades "no esenciales", y puesto que el anlisis de requerimientos, la arquitectura y el diseo no producen cdigo directamente, son los candidatos fciles. Los resultados de este error, tambin conocido como "saltar a la codificacin", son todos demasiado predecibles. Los proyectos que normalmente escatiman en sus actividades iniciales tendrn que hacer ese trabajo en otro momento, con un costo de 10 a 100 veces superior a haberlo hecho bien inicialmente. Si no podemos encontrar cinco horas para hacer el trabajo correctamente la primera vez, cmo vamos a encontrar 50 para hacerlo correctamente ms tarde?
19
2.7. Diseo inadecuado. Un caso especial de escatimar en las actividades iniciales es el diseo inadecuado. Proyectos acelerados generan un diseo indeterminado, no asignado suficiente tiempo para l y originado un entorno de alta presin que hace difcil la posibilidad de considerar alternativas en el diseo. El nfasis en el diseo est ms orientado a la conveniencia que a la calidad, por lo que necesitar varios ciclos de diseo de poder finalizar completamente el sistema. 2.8. Escatimar en el control de calidad. En los proyectos que se hacen con prisa se suele cortar por lo sano, eliminando las revisiones del diseo y del cdigo, eliminando la planificacin de las pruebas y realizando slo pruebas superficiales. Acortar en un da las actividades de control de calidad al comienzo del proyecto probablemente supondr de 3 a 10 das de actividades finales. 2.9. Control insuficiente de la directiva. Poco control de la directiva para detectar a tiempo los signos de posibles retrasos en el plan, y los pocos controles definidos al comienzo se abandonan cuando el proyecto comienza a tener problemas. Antes de encarrilar un proyecto,en primer lugar debemos ser capaces de decir si va por buen camino. 2.10. Convergencia prematura o excesivamente frecuente. Bastante antes de que se haya programado entregar un producto, hay un impulso para preparar el producto para la entrega, mejorar el rendimiento del producto, imprimir la documentacin final, incorporar entradas en el sistema final de ayuda, pulir el programa de instalacin, eliminar las funciones que no van a estar listas a tiempo y dems. En proyectos hechos con prisa, hay una tendencia a forzar prematuramente la convergencia. Puesto que no es posible forzar la convergencia del producto cuando se desea, algunos proyectos de desarrollo rpido intentan forzar la convergencia media docena de veces o ms antes de que finalmente se produzca. Los intentos adicionales de convergencia no benefician al producto, Slo son una prdida de tiempo y prolongan el plan. 2.11. Omitir tareas necesarias en la estimacin. Si la gente no guarda cuidadosamente datos de proyectos anteriores, olvida las tareas menos visibles, pero son tareas que se han de aadir. El esfuerzo omitido suele aumentar el plan de desarrollo en un 20 o 30 por 100. 2.12. Planificar ponerse al da ms adelante. Un tipo de reestimacin es responder inapropiadamente el retraso del plan. Si hemos trabajado en un proyecto durante 6 meses, y hemos empleado tres meses en llegar al hito correspondiente a los dos meses qu hacer? En muchos proyectos simplemente se plantea recuperar el retraso ms tarde, pero nunca se hace. Aprenderemos ms del producto conforme lo estamos construyendo, incluyendo ms sobre lo que nos llevar construirlo. Estos conocimientos necesitan reflejarse en la reestimacin del plan. Otro tipo de error es la reestimacin que se debe a cambios en el producto. Si el producto que estamos construyendo cambia, la cantidad de tiempo necesaria para construirlo cambiar tambin. El crecimiento de las nuevas prestaciones sin ajustar el plan garantiza que no se alcanzar la fecha de entrega.
20
Caractersticas del desarrollo gil.

En los proyectos con desarrollo gil se busca que todos los esfuerzos se usen en la creacin de un mejor programa que satisfaga las necesidades del cliente. Esto significa que todos los que forman parte del equipo de trabajo se concentran nicamente en tareas y procesos que agregan valor al cliente del producto que se est realizando, mejorando o implementando. Adems los usuarios o clientes reciben peridicamente prototipos a medida que el producto se va construyendo, lo cual les permite: evaluar el trabajo realizado. Advertir sobre problemas que se detecten. Sugerir mejoras o funcionaria valiosa que no se haba considerado. Distinguir entre tareas relevantes y las que no agregan valor se consigue a travs de la creacin de contextos con alto nivel de empowerment y feedback. empowerment: consiste en otorgar autonoma para tomar decisiones al equipo de desarrollo, y genera un clima de sinergia grupal que permite el grupo avanzar a pesar de las complicaciones y dificultades que ocurren habitualmente en los proyectos. Feedback: constante presente en varios niveles permite el desarrollo incremental y el crecimiento adaptativo de la programacin, as tambin como una mejora constante en la forma de trabajo de los equipos, lo que permite detectar problemas y resolverlos antes que se desaten las crisis que afecta la calidad el tiempo o del costo desarrollo. Los principales tipos de feedback ocurren a nivel producto, procesos y cdigo. Peridicamente el cliente evala el estado del programa que se est creando, lo que asegura que el entregado al final del proyecto coincida con lo esperado. Esto se consigue a travs del desarrollo incremental: el producto puede probarse desde las primeras semanas y meses del proyecto al menos en cuanto su funcionalidad bsica, que luego se va incrementando y mejorando. A nivel procesos se realizan frecuentes reuniones retrospectivas donde los integrantes de los equipos comentan y discuten en profundidad sus aciertos, para poder repetirlos y convertirlos en hbitos y as tambin como el trabajo no se realiz en forma correcta, o no llev al equipo obtener los resultados esperados, compartir los errores es bueno para el equipo de desarrollo porque puede advertir a los miembros de situaciones en las que no se puesto atencin. Adicionalmente los desarrolladores suelen trabajar mucho en equipo y tambin en parejas, revisando juntos el cdigo resolviendo problemas en lugar de tratar de cubrirlos, lo que repercute en un producto de mejor calidad, mejor documentado y simple de mantener. Cuando es conveniente usar desarrollo gil? En tareas incrementales: producto del proyecto Vamos a comparar la forma en que se planifica los proyectos con la forma en que se planifica los productos, intentando extraer algunas conclusiones tiles. Cono de incertidumbre Boehm y Steve McConnell indican que cualquier variable x del proyecto, por ejemplo cost esfuerzo, estimada el principio de un proyecto variara entre 4x y 0.25x. A medida que se avanza en el proyecto se conoce ms y se reduce el error hasta llegar a la certeza, desgraciadamente esta ocurre slo cuando se finaliza el proyecto.
21
Beneficios de usar desarrollo gil

las mejoras obtenidas por usar el mtodo de desarrollo gil dependen de la situacin. Por ejemplo, el mtodo Srum no define prcticas tcnicas (como hacer las cosas), en cambio los beneficios obtenidos urgentes de brindar visibilidad, lo que facilita encontrar las reas de mejora, y un marco de trabajo de mejora continua, en el que se priorizan las mejoras segn la necesidad del negocio. Pero hay algunas mejoras que tpicamente se tienen con el desarrollo gil: desarrollo guiado por valor. Mejor manejo de riesgos e incertidumbre. Mejora de la productividad.
Desarrollo guiado por valor

en muchas situaciones con los sistemas se presente una relacin de parapeto, en el cual un 20% de la funcionalidad provee un 80% del valor. Si organizamos el proyecto de manera que cliente reciba ese 20% de funcionalidad lo antes posible, empezar a recibir el valor del resultado del proyecto antes. Esto puede ser que incluso se replantee la necesidad o que cambie la definicin del resto del proyecto. Con esta idea en la cabeza, se realiza el proyecto de manera de entregar el producto funcionando en intervalos cortos, y modificar la direccin del proyecto basado en lo que hemos aprendido hasta el momento. Esta es una de las aplicaciones del concepto de inspeccionar y adaptar, que se utiliza tambin en otras reas de Scrum. Para lograr estas ventajas se requiere tanto de cambios internos en el equipo, como en el cliente, es decir, la funcionalidad es menos prioritarias se les dedica muy poco ningn esfuerzo y por otro lado el cliente acepta y promueve una forma contractual que posibilite ajustar el contenido del producto, sin grandes costos para ninguna de las partes. Esta situacin es particularmente notoria en caso proyectos complejos, segn la definicin de complejo que ser continuacin.
Mejor manejo de riesgos e incertidumbre

Cuando se analizan proyectos, intentamos planificar la ejecucin para lograr minimizar los riesgos y utiliza los recursos de manera ms eficiente posible. Por ejemplo: Si estamos arrollando un producto que ser puesto en produccin con servidores que deben adquirirse, es necesario que mencionemos el equipo necesario con 12 meses de anticipacin, para poder asegurar que estar disponible, es decir comprado entregado instalado y configurado para el momento en que se necesite. Esto puede modificar como organicemos el trabajo, ya sea sin esa restriccin, probablemente lo ideal sera esperar hasta tener una prueba de performance con el producto completamente desarrollado. Sus es Proyecto complejo: sus la planificacin requiere que se pueda identificar una lista completa de las tareas que debemos realizar, a un nivel suficiente como para ser destinadas con una confianza suficiente. Esto es difcil en algunos contextos, en los que los requerimientos son poco conocidos, o el ambiente de negocios nuevo, o en el caso de tecnologas no conocidas por el equipo. En estos casos, estamos en el rea marcada como proyectos complicados o complejos, y en este caso el balance entre planificar y no planificar se corre hacia la menos planificacin.
22
El desarrollo gil Scrum permite planificar con dos niveles de detalle: Alto nivel: planteamos necesidades de negocio, pero no o debemos prometer alcance detallado. Bajo nivel: comprometemos alcance, pero fijamos algunas condiciones de contexto. Adicionalmente el concepto de inspeccionar y adaptar, presente en el punto anterior, tambin aporta para manejar mejor los riesgos existentes en los proyectos complejos.
Mejora de la productividad
desde hace un tiempo se sabe que distintos equipo puede tener diferencias de productividad de 10 a 1 o incluso ms. Entre las empresas de menor productividad y el promedio de la industria hay un orden de magnitud de diferencias, mientras que entre el promedio y los ms productivos hay dos rdenes de magnitud de diferencias. Analizando las razones de esta diferencias, se han encontrado que la forma de trabajo, esto es, cultura, entorno fsico, forma de liderazgo y toma de decisiones, tiene un papel preponderante. En el desarrollo gil se incorpora la autoorganizacin, el liderazgo facilitador, el trabajo en equipo, la transparencia, los grupos pequeos y otras condiciones.
Aplicabilidad del desarrollo gil

Una duda que surge cuando se evalu utilizar Scrum es si se aplica al contexto particular del interesado. Con las conciliaciones indicadas sobre los contextos ms o menos favorables para su implementacin, se puede afirmar que el desarrollo gil que ha sido aplicado con xito tanto en empresas as tanto como en equipos pequeos. Con respecto a los tipos de aplicaciones, ha sido aplicado en equipos mdicos con riesgo de vida que requiere aprobacin de la FDA, como en el manejo de pagos electrnicos, sistemas de alta disponibilidad, de alto volumen, etc. la lnea lo ms recomendado es que se utilicen equipo que trabaja en un nico lugar fsico pero an as, ha sido usado por equipo distribuidos y con subcontrataciones. Comparacin entre la vista del producto y la vista del proyecto muchas compaas han tomado el modelo de procesos como la forma que se comunican los sectores internos, cada uno de ellos tomando el rol de cliente o proveedor, con una comunicacin entre ellos ms asociada al modelo contractual de proyectos que la forma evolutiva y focalizada en el cliente de las empresas de desarrollo de producto. Es muy frecuente que estas empresas tengan reas que son optimizadas localmente,, y que se relacionen con otras reas a travs de contratos llave en mano. Una forma alternativa de trabajar para desarrollo interno usando el modelo de desarrollo de productos, considerando que el mismo equipo se mantiene a lo largo de varias versiones, teniendo que dar soporte al usuario actual. Esto podra ayudar a que el equipo obtenga retroalimentacin de cliente y que incorpore esa informacin a prximas entregas. Antes de resumir algunas metodologas giles, vamos a enumerar las principales diferencias respecto de las metodologas tradicionales (no giles). La siguiente tabla muestra esquemticamente estas diferencias que no se refieren slo al proceso en s, sino tambin al contexto de equipo y organizacin que es ms favorable a cada uno de estas filosofas de procesos de desarrollo de software.
23
Metodologas giles Metodologas Tradicionales Basadas en heursticas provenientes de Basadas en normas provenientes de prcticas de produccin de cdigo estndares seguidos por el entorno de desarrollo Especialmente preparados para cambios Cierta resistencia a los cambios durante el proyecto Impuestas internamente (por el equipo de Impuestas externamente desarrollo) Proceso menos controlado, con pocos Proceso mucho ms controlado, con principios numerosas polticas/normas No existe contrato tradicional o al menos Existe un contrato prefijado es bastante flexible El cliente es parte del equipo de desarrollo El cliente interacta con el equipo de desarrollo mediante reuniones Grupos pequeos (<10 integrantes) y Grupos grandes y posiblemente trabajando en el mismo sitio distribuidos Pocos artefactos Ms artefactos Pocos roles Ms roles Menos nfasis en la arquitectura del La arquitectura del software es esencial y software se expresa mediante modelos
Metodologas giles de Desarrollo

A principios de la dcada del 90, surgi un enfoque que fue bastante revolucionario para su momento ya que iba en contra de la creencia de que mediante procesos altamente definidos se iba a lograr obtener software en tiempo, costo y con la requerida calidad. El enfoque fue planteado por primera vez por y se dio a conocer en la comunidad de ingeniera de software con el nombre de Rapid Application Development. RAD consista en un entorno de desarrollo altamente productivo, en el que participaban grupos pequeos de programadores utilizando herramientas que generaban cdigo en forma automtica tomando como entradas sintaxis de alto nivel. En general, se considera que este fue uno de los primeros hitos en pos de la agilidad en los procesos de desarrollo como mencionaremos. Cabe mencionar que las metodologas giles no inventaron la nocin de los procesos iterativos e incrementales, los cuales eran usados desde dcadas pasadas inclusive en momentos en que el modelo en cascada era el estndar. Entre las metodologas giles ms destacadas hasta el momento podemos nombrar:
XP Extreme Programming Scrum Crystal. DSDM Dynamic Systems Developmemt Method FDD Feature Driven Development ASD Adaptive Software Development Lean software development
24
X.P Extreme Programming

XP es una metodologa gil centrada en potenciar las relaciones interpersonales como clave para el xito en desarrollo de software, promoviendo el trabajo en equipo, preocupndose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentacin continua entre el cliente y el equipo de desarrollo, comunicacin fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo tcnico. Los principios y prcticas son de sentido comn pero llevadas al extremo, de ah proviene su nombre. A continuacin presentaremos las caractersticas esenciales de XP organizadas en los tres apartados siguientes: historias de usuario, roles, proceso y prcticas.
Las Historias de Usuario

Las historias de usuario son la tcnica utilizada en XP para especificar los requisitos del software. Se trata de tarjetas de papel en las cuales el cliente describe brevemente las caractersticas que el sistema debe poseer, sean requisitos funcionales o no funcionales. El tratamiento de las historias de usuario es muy dinmico y flexible, en cualquier momento historias de usuario pueden romperse, reemplazarse por otras ms especficas o generales, aadirse nuevas o ser modificadas. Cada historia de usuario es lo suficientemente comprensible y delimitada para que los programadores puedan implementarla en unas semanas. Respecto de la informacin contenida en la historia de usuario, existen varias plantillas sugeridas pero no existe un consenso al respecto. En muchos casos slo se propone utilizar un nombre y una descripcin o slo una descripcin, ms quizs una estimacin de esfuerzo en das. Ejemplo de ficha en la cual pueden reconocerse los siguientes contenidos: Fecha tipo de actividad (nueva, correccin, mejora) prueba funcional nmero de historia prioridad tcnica y del cliente referencia a otra historia previa riesgo estimacin tcnica descripcin notas y una lista de seguimiento con la fecha estado cosas por terminar y comentarios. Las historias de usuario son descompuestas en tareas de programacin y asignadas a los programadores para ser implementadas durante una iteracin.
25
Roles XP
Programador: escribe las pruebas unitarias y produce el cdigo del sistema. Debe existir una comunicacin y coordinacin adecuada entre los programadores y otros miembros del equipo.
Cliente: escribe las historias de usuario y las pruebas funcionales para validar su Implementacin. Adems, asigna la prioridad a las historias de usuario y decide cules se implementan en cada iteracin centrndose en aportar mayor valor al negocio. El cliente es slo uno dentro del proyecto pero puede corresponder a un interlocutor que est representando a varias personas que se vern afectadas por el sistema. Encargado de pruebas: ayuda al cliente a escribir las pruebas funcionales.
Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas.
Encargado de seguimiento: proporciona realimentacin al equipo en el proceso XP. Su responsabilidad es verificar el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para mejorar futuras estimaciones. Tambin realiza el seguimiento del progreso de cada iteracin y evala si los objetivos son alcanzables con las restricciones de tiempo y recursos presentes. Determina cundo es necesario realizar algn cambio para lograr los objetivos de cada iteracin. Entrenador: es responsable del proceso global. Es necesario que conozca a fondo el proceso XP para proveer guas a los miembros del equipo de forma que se apliquen las prcticas XP y se siga el proceso correctamente. Consultor: es un miembro externo del equipo con un conocimiento especfico en
algn tema necesario para el proyecto. Gua al equipo para resolver un problema especfico.
Gestor: Es el vnculo entre clientes y programadores, ayuda a que el equipo trabaje

efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinacin.
Proceso XP
Un proyecto XP tiene xito cuando el cliente selecciona el valor de negocio a implementar basado en la habilidad del equipo para medir la funcionalidad que puede entregar a travs del tiempo. El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos: 1. El cliente define el valor de negocio a implementar. 2. El programador estima el esfuerzo necesario para su implementacin. 3. El cliente selecciona qu construir, de acuerdo con sus prioridades y las restricciones de tiempo. 4. El programador construye ese valor de negocio. 5. Vuelve al paso 1. En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No se debe presionar al programador a realizar ms trabajo que el estimado, ya que se perder calidad en el software o no se cumplirn los plazos. De la misma forma el
26
cliente tiene la obligacin de manejar el mbito de entrega del producto, para asegurarse que el sistema tenga el mayor valor de negocio posible con cada iteracin. El ciclo de vida ideal de XP consiste de seis fases: 1. Exploracin. 2. Planificacin de la entrega (Release). 3. Iteraciones. 4. Produccin. 5. Mantenimiento. 6. Muerte del Proyecto.
1. Exploracin
En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son de inters para la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas, tecnologas y prcticas que se utilizarn en el proyecto. Se prueba la tecnologa y se exploran las posibilidades de la arquitectura del sistema construyendo un prototipo. La fase de exploracin toma de pocas semanas a pocos meses, dependiendo del tamao y familiaridad que tengan los programadores con la tecnologa.
2. Planificacin de la Entrega
En esta fase el cliente establece la prioridad de cada historia de usuario, y correspondientemente, los programadores realizan una estimacin del esfuerzo necesario de cada una de ellas. Se toman acuerdos sobre el contenido de la primera entrega y se determina un cronograma en conjunto con el cliente. Una entrega debera obtenerse en no ms de tres meses. Esta fase dura unos pocos das. Las estimaciones de esfuerzo asociado a la implementacin de las historias la establecen los programadores utilizando como medida el punto. Un punto, equivale a una semana ideal de programacin. Las historias generalmente valen de 1 a 3 puntos. Por otra parte, el equipo de desarrollo mantiene un registro de la velocidad de desarrollo, establecida en puntos por iteracin, basndose principalmente en la suma de puntos correspondientes a las historias de usuario que fueron terminadas en la ltima iteracin. La planificacin se puede realizar basndose en el tiempo o el alcance. La
27
velocidad del proyecto es utilizada para establecer cuntas historias se pueden implementar antes de una fecha determinada o cunto tiempo tomar implementar un conjunto de historias. Al planificar por tiempo, se multiplica el nmero de iteraciones por la velocidad del proyecto, determinndose cuntos puntos se pueden completar. Al planificar segn alcance del sistema, se divide la suma de puntos de las historias de usuario seleccionadas entre la velocidad del proyecto, obteniendo el nmero de iteraciones necesarias para su implementacin.
3. Iteraciones
Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan de entrega est compuesto por iteraciones de no ms de tres semanas. En la primera iteracin se puede intentar establecer una arquitectura del sistema que pueda ser utilizada durante el resto del proyecto. Esto se logra escogiendo las historias que fuercen la creacin de esta arquitectura, sin embargo, esto no siempre es posible ya que es el cliente quien decide qu historias se implementarn en cada iteracin. Al final de la ltima iteracin el sistema estar listo para entrar en produccin. Los elementos que deben tomarse en cuenta durante la elaboracin del Plan de la Iteracin son: historias de usuario no abordadas. velocidad del proyecto. pruebas de aceptacin no superadas en la iteracin anterior tareas no terminadas en la iteracin anterior. Todo el trabajo de la iteracin es expresado en tareas de programacin, cada una de ellas es asignada a un programador como responsable, pero llevadas a cabo por parejas de programadores.
4. Produccin
La fase de produccin requiere de pruebas adicionales y revisiones de rendimiento antes de que el sistema sea trasladado al entorno del cliente. Al mismo tiempo, se deben tomar decisiones sobre la inclusin de nuevas caractersticas a la versin actual, debido a cambios durante esta fase. Es posible que se rebaje el tiempo que toma cada iteracin, de tres a una semana. Las ideas que han sido propuestas y las sugerencias son documentadas para su posterior implementacin.
5. Mantenimiento
Mientras la primera versin se encuentra en produccin, el proyecto XP debe mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas iteraciones. Para realizar esto se requiere de tareas de soporte para el cliente. De esta forma, la velocidad de desarrollo puede bajar despus de la puesta del sistema en produccin. La fase de mantenimiento puede requerir nuevo personal dentro del equipo y cambios en su estructura.
28
6. Muerte del Proyecto

Es cuando el cliente no tiene ms historias para ser incluidas en el sistema. Esto requiere que se satisfagan las necesidades del cliente en otros aspectos como rendimiento y confiabilidad del sistema. Se genera la documentacin final del sistema y no se realizan ms cambios en la arquitectura. La muerte del proyecto tambin ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando no hay presupuesto para mantenerlo. Prcticas XP La principal suposicin que se realiza en XP es la posibilidad de disminuir la curva exponencial del costo del cambio a lo largo del proyecto, lo suficiente para que el diseo evolutivo funcione. XP apuesta por un crecimiento lento del costo del cambio y con un comportamiento asinttico. Esto se consigue gracias a las tecnologas disponibles para ayudar en el desarrollo de software y a la aplicacin disciplinada de las prcticas.
El juego de la planificacin
Es un espacio frecuente de comunicacin entre el cliente y los programadores. El equipo tcnico realiza una estimacin del esfuerzo requerido para la implementacin de las historias de usuario y los clientes deciden sobre el mbito y tiempo de las entregas y de cada iteracin. Esta prctica se puede ilustrar como un juego, donde existen dos tipos de jugadores: Cliente y Programador. El cliente establece la prioridad de cada historia de usuario, de acuerdo con el valor que aporta para el negocio. Los programadores estiman el esfuerzo asociado a cada historia de usuario. Se ordenan las historias de usuario segn prioridad y esfuerzo, y se define el contenido de la entrega y/o iteracin, apostando por enfrentar lo de ms valor y riesgo cuanto antes. Este juego se realiza durante la planificacin de la entrega, en la planificacin de cada iteracin y cuando sea necesario reconducir el proyecto.
Entregas pequeas
La idea es producir rpidamente versiones del sistema que sean operativas, aunque obviamente no cuenten con toda la funcionalidad pretendida para el sistema pero si que constituyan un resultado de valor para el negocio. Una entrega no debera tardar ms 3 meses.
Metfora
En XP no se enfatiza la definicin temprana de una arquitectura estable para el sistema. Dicha arquitectura se asume evolutiva y los posibles inconvenientes que se generaran por no contar con ella explcitamente en el comienzo del proyecto se solventan con la existencia de una metfora. El sistema es definido mediante una metfora o un conjunto de metforas compartidas por el cliente y el equipo de desarrollo. Una metfora es una historia compartida que describe cmo debera funcionar el sistema. La prctica de la metfora consiste en formar un conjunto de nombres que acten como vocabulario para hablar sobre el dominio del problema. Este conjunto de nombres ayuda a la nomenclatura de clases y mtodos del sistema. Diseo simple
29
Se debe disear la solucin ms simple que pueda funcionar y ser implementada en un momento determinado del proyecto. La complejidad innecesaria y el cdigo extra debe ser removido inmediatamente. Kent Beck dice que en cualquier momento el diseo adecuado para el software es aquel que: supera con xito todas las pruebas, no tiene lgica duplicada, refleja claramente la intencin de implementacin de los programadores y tiene el menor nmero posible de clases y mtodos.
Pruebas
La produccin de cdigo est dirigida por las pruebas unitarias. Las pruebas unitarias son establecidas antes de escribir el cdigo y son ejecutadas constantemente ante cada modificacin del sistema. Los clientes escriben las pruebas funcionales para cada historia de usuario que deba validarse. En este contexto de desarrollo evolutivo y de nfasis en pruebas constantes, la automatizacin para apoyar esta actividad es crucial.
Refactorizacin (Refactoring)
La refactorizacin es una actividad constante de reestructuracin del cdigo con el objetivo de remover duplicacin de cdigo, mejorar su legibilidad, simplificarlo y hacerlo ms flexible para facilitar los posteriores cambios. La refactorizacin mejora la estructura interna del cdigo sin alterar su comportamiento externo. El sistema de software es una cosa viviente, no se le puede imponer todo en un inicio, pero en el transcurso del tiempo este diseo evoluciona conforme cambia la funcionalidad del sistema. Para mantener un diseo apropiado, es necesario realizar actividades de cuidado continuo durante el ciclo de vida del proyecto. De hecho, este cuidado continuo sobre el diseo es incluso ms importante que el diseo inicial. Un concepto pobre al inicio puede ser corregido con esta actividad continua, pero sin ella, un buen diseo inicial se degradar.
Programacin en parejas
Toda la produccin de cdigo debe realizarse con trabajo en parejas de programadores. Segn Cockburn y Williams en un estudio realizado para identificar los costos y beneficios de la programacin en parejas, las principales ventajas de introducir este estilo de programacin son: muchos errores son detectados conforme son introducidos en el cdigo (inspecciones de cdigo continuas), por consiguiente la tasa de errores del producto final es ms baja, los diseos son mejores y el tamao del cdigo menor (continua discusin de ideas de los programadores), los problemas de programacin se resuelven ms rpido, se posibilita la transferencia de conocimientos de programacin entre los miembros del equipo, varias personas entienden las diferentes partes sistema, los programadores conversan mejorando as el flujo de informacin y la dinmica del equipo, y finalmente, los programadores disfrutan ms su trabajo. Dichos beneficios se consiguen despus de varios meses de practicar la programacin en parejas. En los estudios realizados por Cockburn y Williams este lapso de tiempo vara de 3 a 4 meses.
30
Propiedad colectiva del cdigo

Cualquier programador puede cambiar cualquier parte del cdigo en cualquier momento. Esta prctica motiva a todos a contribuir con nuevas ideas en todos los segmentos del sistema, evitando a la vez que algn programador sea imprescindible para realizar cambios en alguna porcin de cdigo.
Integracin contina
Cada pieza de cdigo es integrada en el sistema una vez que est lista. As, el sistema puede llegar a ser integrado y construido varias veces en un mismo da. Todas las pruebas son ejecutadas y tienen que ser aprobadas para que el nuevo cdigo sea incorporado definitivamente. La integracin continua a menudo reduce la fragmentacin de los esfuerzos de los desarrolladores por falta de comunicacin sobre lo que puede ser reutilizado o compartido. Martin Fowler en [7] afirma que el desarrollo de un proceso disciplinado y automatizado es esencial para un proyecto controlado, el equipo de desarrollo est ms preparado para modificar el cdigo cuando sea necesario, debido a la confianza en la identificacin y correccin de los errores de integracin.
40 horas por semana

Se debe trabajar un mximo de 40 horas por semana. No se trabajan horas extras en dos semanas seguidas. Si esto ocurre, probablemente est ocurriendo un problema que debe corregirse. El trabajo extra desmotiva al equipo. Los proyectos que requieren trabajo extra para intentar cumplir con los plazos suelen al final ser entregados con retraso. En lugar de esto se puede realizar el juego de la planificacin para cambiar el mbito del proyecto o la fecha de entrega.
Cliente in-situ
El cliente tiene que estar presente y disponible todo el tiempo para el equipo. Gran parte del xito del proyecto XP se debe a que es el cliente quien conduce constantemente el trabajo hacia lo que aportar mayor valor de negocio y los programadores pueden resolver de manera inmediata cualquier duda asociada. La comunicacin oral es ms efectiva que la escrita, ya que esta ltima toma mucho tiempo en generarse y puede tener ms riesgo de ser mal interpretada. En [12] Jeffries indica que se debe pagar un precio por perder la oportunidad de un cliente con alta disponibilidad. Algunas recomendaciones propuestas para dicha situacin son las siguientes: intentar conseguir un representante que pueda estar siempre disponible y que acte como interlocutor del cliente, contar con el cliente al menos en las reuniones de planificacin, establecer visitas frecuentes de los programadores al cliente para validar el sistema, anticiparse a los problemas asociados estableciendo llamadas telefnicas frecuentes y conferencias, reforzando el compromiso de trabajo en equipo.
31
Estndares de programacin
XP enfatiza la comunicacin de los programadores a travs del cdigo, con lo cual es indispensable que se sigan ciertos estndares de programacin (del equipo, de la organizacin u otros estndares reconocidos para los lenguajes de programacin utilizados). Los estndares de programacin mantienen el cdigo legible para los miembros del equipo, facilitando los cambios. Crticas a eXtreme Programming
Algunas de las crticas de Xp

Xp tiene muchas crticas especialmente contra la programacin por parejas por parte de muchos programadores con gran sentimiento de posesin del cdigo, piensan que ellos son los mejores conocedores de las herramientas y lenguajes que utilizan y que si alguien no lo entiende es por que no sabe lo suficiente. Tambin se critica el mito de las 40 horas semanales ya que es un lujo para las exigencias del mercado. Tambin hay crticas hacia Xp que dicen que solo puede funcionar con programadores muy buenos. Xp es mas una filosofa de trabajo que una metodologa. Por otro lado ninguna de las practicas defendidas por Xp son invencin de este mtodo, Xp lo que hace es ponerlas todas juntas. Xp esta diseado para grupos de pequeos programadores, ms de 10 ya seria muy complicado, y mas aun para que estn en el mismo centro de trabajo.
32
SCRUM
SCRUM es un trmino de Rugby, es la agrupacin de los miembros del equipo. De esta manera el equipo trata de recorrer la distancia hacia la meta como una unidad, pasndose la pelota entre ellos. Define un marco para la gestin de proyectos, que se ha utilizado con xito durante los ltimos 10 aos. Est especialmente indicada para proyectos con un rpido cambio de requisitos. Sus principales caractersticas se pueden resumir en dos. El desarrollo de software se realiza mediante iteraciones, denominadas sprints, con una duracin de 30 das. El resultado de cada sprint es un incremento ejecutable que se muestra al cliente. La segunda caracterstica importante son las reuniones a lo largo proyecto. stas son las verdaderas protagonistas, especialmente la reunin diaria de 15 minutos del equipo de desarrollo para coordinacin e integracin. Scrum es un marco de trabajo para la gestin y desarrollo de software basada en un proceso iterativo e incremental utilizado comnmente en entornos basados en el desarrollo gil de software. Aunque Scrum estaba enfocado a la gestin de procesos de desarrollo de software, puede ser utilizado en equipos de mantenimiento de software, o en una aproximacin de gestin de programas. Caractersticas de Scrum Scrum es un modelo de referencia que define un conjunto de prcticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutar durante un proyecto. Los roles principales en Scrum son: ScrumMaster: que mantiene los procesos y trabaja de forma similar al director de proyecto. ProductOwner: que representa a los interesados externos o internos. Team: que incluye a los desarrolladores. Durante cada sprint, un periodo entre 15 y 30 das (la magnitud es definida por el equipo), el equipo crea un incremento de software potencialmente entregable (utilizable). El conjunto de caractersticas que forma parte de cada sprint viene del Product Backlog, que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar. Los elementos del Product Backlog que forman parte del sprint se determinan durante la reunin de Sprint Planning. Durante esta reunin, el Product Owner identifica los elementos del Product Backlog que quiere ver completados y los hace del conocimiento del equipo. Entonces, el equipo determina la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente sprint. Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos estn congelados durante el sprint. Scrum permite la creacin de equipos autoorganizados impulsando la co-localizacin de todos los miembros del equipo, y la comunicacin verbal entre todos los miembros y disciplinas involucrados en el proyecto.
33
Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los desafos impredecibles no pueden ser fcilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una aproximacin pragmtica, aceptando que el problema no puede ser completamente entendido o definido, y centrndose en maximizar la capacidad del equipo de entregar rpidamente y responder a requisitos emergentes. Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas amarillas "post-it" y pizarras hasta paquetes de software. Una de las mayores ventajas de Scrum es que es muy fcil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar.
Roles en Scrum
En Scrum se definen varios roles, estos estn divididos en dos grupos: cerdos y gallinas. De esta forma: Los cerdos: estn comprometidos a desarrollar el software de forma regular y frecuente. Estn comprometidos con el proyecto y el proceso Scrum. Las Gallinas: slo interesados en el proyecto. Las necesidades, deseos, ideas e influencias de los roles 'gallina' se tienen en cuenta, pero no de forma que pueda afectar, distorsionar o entorpecer el proyecto Scrum. Los roles gallina en realidad no son parte del proceso Scrum, pero deben tenerse en cuenta. Un aspecto importante de una aproximacin gil es la prctica de involucrar en el proceso a los usuarios, expertos del negocio y otros interesados (stakeholders). Es importante que esa gente participe y entregue retroalimentacin con respecto a la salida del proceso a fin de revisar y planear cada sprint. La gallina alimenta al proyecto "poniendo huevos", no se ve comprometida como el cerdo que va al matadero.
El Product Owner: representa la voz del cliente. Se asegura de que el equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuario, las prioriza, y las coloca en el Product Backlog.
34
ScrumMaster (o Facilitador): El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obstculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el lder del equipo (porque ellos se auto-organizan), sino que acta como una proteccin entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan. ScrumTeam o Equipo: El equipo tiene la responsabilidad de entregar el producto. Un pequeo equipo de 5 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (diseador, desarrollador, etc). Usuarios: Es el destinatario final del producto. Como bien lo dice la paradoja, El rbol cae en el bosque cuando no hay nadie Hace ruido? Aqu la definicin sera Si el software no es usado fue alguna vez escrito? Stakeholders (Clientes, Proveedores, Inversores): Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producir el beneficio acordado que lo justifica. Slo participan directamente durante las revisiones del sprint. Managers: Es la gente que establece el ambiente para el desarrollo del producto.
Reuniones en Scrum
Daily Scrum: Cada da de un sprint, se realiza la reunin sobre el estado de un proyecto. Esto se llama "daily standup". El scrum tiene unas guas especficas: La reunin comienza puntualmente a su hora. A menudo hay castigos acordados por el equipo- para quien llegue tarde (por ejemplo: dinero, flexiones, llevar colgando una gallina de plstico del cuello, etc.). Todos son bienvenidos, pero slo los "cerdos" pueden hablar. La reunin tiene una duracin fija de 15 minutos, de forma independiente del tamao del equipo. Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunin corta). La reunin debe ocurrir en la misma ubicacin y a la misma hora todos los das. Durante la reunin, cada miembro del equipo contesta a tres preguntas: 1. Qu has hecho desde ayer? 2. Qu es lo que ests planeando hacer hoy? 3. Has tenido algn problema que te haya impedido alcanzar tu objetivo? (Es el papel del ScrumMaster recordar estos impedimentos).
Scrum de Scrum
Cada da normalmente despus del Daily Scrum Estas reuniones permiten a los grupos de equipos discutir su trabajo, enfocndose especialmente en reas de solapamiento e integracin. Asiste una persona asignada por cada equipo.
35
La agenda ser la misma que la del Daily Scrum, aadiendo adems las siguientes cuatro preguntas: 1. Qu ha hecho tu equipo desde nuestra ltima reunin? 2. Qu har tu equipo antes que nos volvamos a reunir? 3. Hay algo que demora o estorba a tu equipo? 4. Ests a punto de poner algo en el camino del otro equipo? Reunin de Planificacin del Sprint Al inicio del ciclo Sprint (cada 15 o 30 das), una Reunin de Planificacin del Sprint se lleva a cabo. Seleccionar qu trabajo se har Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que tomar hacer el trabajo. Identificar y comunicar cunto del trabajo es probable que se realice durante el actual Sprint Ocho horas como lmite Al final del ciclo Sprint, dos reuniones se llevaran a cabo: la Reunin de Revisin del Sprint y la Retrospectiva del Sprint Reunin de Revisin del Sprint Revisar el trabajo que fue completado y no completado Presentar el trabajo completado a los interesados (alias demo) El trabajo incompleto no puede ser demostrado Cuatro horas como lmite Retrospectiva del Sprint (Sprint Retrospective) Despus de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los miembros del equipo dejan sus impresiones sobre el sprint recin superado. El propsito de la retrospectiva es realizar una mejora continua del proceso. Esta reunin tiene un tiempo fijo de cuatro horas. Sprint El Sprint es el perodo en el cual se lleva a cabo el trabajo en s. Es recomendado que la duracin de los sprints sea constante y definida por el equipo en base a su propia experiencia. Se puede comenzar con una duracin de sprint en particular (2 o 3 semanas) e ir ajustndolo en base al ritmo del equipo, aunque sin relajarlo demasiado. Al final de cada sprint, el equipo deber presentar los avances logrados, y deberan entregar un producto con caractersticas 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 amenacen al xito del proyecto. La constancia hace a la concentracin y la mejor productividad del equipo de trabajo.
Documentos
Product backlog El product backlog es un documento de alto nivel para todo el proyecto. Contiene descripciones genricas de todos los requerimientos, funcionalidades deseables, etc. priorizadas segn su retorno sobre la inversin (ROI) . Es el qu va a ser construido. Es abierto y cualquiera puede modificarlo. Contiene estimaciones grosso modo, tanto del valor para el negocio, como del esfuerzo de desarrollo requerido. Esta estimacin ayuda al product owner a ajustar la lnea temporal y, de manera limitada, la prioridad de las
36
diferentes tareas. Por ejemplo, si dos caractersticas tienen el mismo valor de negocio la que requiera menos tiempo de desarrollo tendr probablemente ms prioridad, debido a que su ROI ser ms alto. Sprint backlog El sprint backlog es un documento detallado donde se describe el cmo el equipo va a implementar los requisitos durante el siguiente sprint. Las tareas se dividen en horas con ninguna tarea de duracin superior a 16 horas. Si una tarea es mayor de 16 horas, deber ser rota en mayor detalle. Las tareas en el sprint backlog nunca son asignadas, son tomadas por los miembros del equipo del modo que les parezca oportuno. Burn down La burn down chart es una grfica mostrada pblicamente que mide la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una lnea que conecte los puntos de todos los Sprints completados, podremos ver el progreso del proyecto. Lo normal es que esta lnea sea descendente (en casos en que todo va bien en el sentido de que los requisitos estn bien definidos desde el principio y no varan nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay ms requisitos pendientes de ser completados en el Backlog). Si durante el proceso se aaden nuevos requisitos la recta tendr pendiente ascendente en determinados segmentos, y si se modifican algunos requisitos la pendiente variar o incluso valdr cero en algunos tramos. Algunas de las crticas de Scrum No todo en Scrum es un mundo maravilloso, existen crticos y personas que lo han descartado. Bsicamente sus quejas se centraban en los siguientes tres puntos: 1- Muchas Reuniones y algunas muy largas, como la de estimacin: Curiosamente este punto es uno de los pilares fundamentales de Scrum, al realizar reuniones para que fluya la comunicacin entre todos los agentes implicados. Pero existen personan que critican el hecho de tener que reunirse todos los das, aunque sean reuniones de cinco minutos, dado que creen que es innecesario muchas veces durante el desarrollo del sprint. Existe tambin una crtica hacia las reuniones de estimacin, que se suelen alargar a 3/4 horas y la verdad es que puede resultar agotador, sobre todo si no se preparan bien y se dejan las historias abiertas, creando debates ms largos de lo necesario. 2- Tener que medir con mtricas todos los procesos: En este punto los crticos responden que la obligacin de medir todos los procesos, que les lleva a crear unas grficas muy bonitas de cara a los clientes, disminuye la creatividad, supeditando la misma a valores medibles. 3- El equipo elimina cualidades del individuo: Los equipos ejercen una presin a sus miembros que les hace anular ciertas cualidades como la inspiracin, la espontaneidad, las genialidades absurdas, etc. Justifican que en todos los proyectos se necesitan dosis de estas caractersticas para que se consiga un producto completo.
37
Crystal
Se trata de un conjunto de metodologas para el desarrollo de software caracterizadas por estar centradas en las personas que componen el equipo (de ellas depende el xito del proyecto) y la reduccin al mximo del nmero de artefactos producidos. El desarrollo de software se considera un juego cooperativo de invencin y comunicacin, limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas, as como tener polticas de trabajo en equipo definidas. Estas polticas dependern del tamao del equipo por ejemplo: Cristal Clear (C.C)es para equipos de hasta 8 personas o menos. Amarillo para equipos entre 10 a 20 personas. Naranja para equipos entre 20 a 50 persona. Roja para equipos entre 50 a 100 personas. Azul para equipos entre 100 a 200 personas.
Crystal sugiere que escojas el color de la metodologa para un proyecto en funcin de su criticidad y tamao. Los proyectos ms grandes suelen necesitar una mayor coordinacin y metodologas ms complejas que no los proyectos ms pequeos. Cuanto ms crtico sea el sistema que queremos desarrollar, ms rigurosidad necesitamos disponer en el desarrollo del proyecto. En la figura anterior aparecen unos caracteres (C,D,E y L) e indican las perdidas potenciales por fallos del sistema, y lo hacen de la siguiente manera: C, indica prdida de confort debido a un fallo del sistema. D, indica prdida de dinero discrecional, es decir del que podemos disponer, generalmente nuestro. E, indica prdida de dinero esencial, es decir dinero que probablemente no es nuestro y no podemos disponer de el libremente. L, de Life en ingles, vida. Indica la prdida de vidas por el fallo del sistema. C.C puede ser usado en proyectos pequeos y como casi todos los otros mtodos, CC consiste en valores, tcnicas y procesos.
38
Menos nfasis en la documentacin exhaustiva y ms en versiones que corran y puedan ser probadas. Lo primero son promesas, lo segundo hechos. Cada proyecto necesita sus propios mtodos. Se trata de un conjunto de metodologas para el desarrollo de software caracterizadas por estar centradas en las personas que componen el equipo y la reduccin al mximo del nmero de artefactos producidos. El desarrollo de software se considera un juego cooperativo de invencin y comunicacin, limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas, as como tener polticas de trabajo en equipo definidas.
Caractersticas
Las personas, como dispositivos activos, tienen modos de xito y modos de fallo. Los siguientes son los principales: Cuando el nmero de personas aumenta, tambin aumenta la necesidad de coordinar. Cuando el potencial de daos se incrementa, la tolerancia a variaciones se ve afectada. La sensibilidad del tiempo en que se debe estar en el mercado vara: a veces este tiempo debe acortarse al mximo y se toleran defectos, otras se enfatiza la auditoria, confiabilidad, proteccin legal, entre otros. Las personas se comunican mejor cara a cara, con la pregunta y la respuesta en el mismo espacio de tiempo. El factor ms significativo es comunicacin. La ms exhaustivamente documentada es Crystal Clear, y es la que se ha de describir a continuacin. CC puede ser usado en proyectos pequeos. El otro mtodo elaborado en profundidad es el Naranja, apto para proyectos de duracin estimada en 2 aos. Los otros dos an se estn desarrollando. Como casi todos los otros mtodos, CC consiste en valores, tcnicas y procesos. Los siete valores o propiedades de CC son: 1. Entrega frecuente. Consiste en entregar software a los clientes con frecuencia, no solamente en compilar el cdigo. La frecuencia depender del proyecto, pero puede ser diaria, semanal o mensual. 2. Comunicacin osmtica. Todos juntos en el mismo cuarto. Una variante especial es disponer en la sala de un experto diseador senior y discutir respecto del tema que se trate. 3. Mejora reflexiva. Tomarse un pequeo tiempo (unas pocas horas cada o una vez al mes) para pensar bien qu se est haciendo, cotejar notas, reflexionar, discutir. 4. Seguridad personal. Hablar con los compaeros cuando algo molesta dentro del grupo. 5. Foco. Saber lo que se est haciendo y tener la tranquilidad y el tiempo para hacerlo. 6. Fcil acceso a usuarios expertos. Tener alguna comunicacin con expertos desarrolladores. Crystal Clear no requiere ninguna estrategia o tcnica, pero siempre es til tener unas cuantas a mano para empezar. Las estrategias comunes a otras Metodologas giles, son:
39
Exploracin de 360 Verificar o tomar una muestra del valor de negocios del . proyecto, los requerimientos, el modelo de dominio, la tecnologa, el plan del proyecto y el proceso. Victoria temprana. Es mejor buscar pequeos triunfos iniciales que aspirar a una gran victoria tarda Esqueleto ambulante. Es una transaccin que debe ser simple pero completa. Re-arquitectura incremental. Se ha demostrado que no es conveniente interrumpir el desarrollo para corregir la arquitectura. Ms bien la arquitectura debe evolucionar en etapas, manteniendo el sistema en ejecucin mientras ella se modifica. Radiadores de informacin. Es una lmina pegada en algn lugar que el equipo pueda observar mientras trabaja o camina. Tiene que ser comprensible para el observador casual, entendida de un vistazo y renovada peridicamente para que valga la pena visitarla.
En cuanto a las tcnicas, se favorecen: Entrevistas de proyectos. Se suele entrevistar a ms de un responsable para tener visiones ms ricas. Talleres de reflexin. El equipo debe detenerse treinta minutos o una hora para reflexionar sobre sus convenciones de trabajo, discutir inconvenientes y mejoras y planear para el perodo siguiente. Planeamiento Blitz. Una tcnica puede ser el Juego de Planeamiento de XP. En este juego, se ponen tarjetas indexadas en una mesa, con una historia de usuario o funcin visible en cada una. El grupo finge que no hay dependencias entre tarjetas, y las alinea en secuencias de desarrollo preferidas. Los programadores escriben en cada tarjeta el tiempo estimado para desarrollar cada funcin. El patrocinador del usuario escribe la secuencia de prioridades, teniendo en cuenta los tiempos referidos y el valor de negocio de cada funcin. Las tarjetas se agrupan en perodos de tres semanas llamados iteraciones que se agrupan en entregas, usualmente no ms largas de tres meses. Estimacin Delphi con estimaciones de pericia. En el proceso Delphi se renen los expertos responsables y proceden como en un remate para proponer el tamao del sistema, su tiempo de ejecucin, la fecha de las entregas segn dependencias tcnicas y de negocios y para equilibrar las entregas en paquetes de igual tamao. Encuentros diarios de pie. La palabra clave es brevedad, cinco a diez minutos como mximo. No se trata de discutir problemas, sino de identificarlos. Miniatura de procesos. Una forma de presentar Crystal Clear puede consumir entre 90 minutos y un da. La idea es que la gente pueda degustar la nueva metodologa. Grcos de quemado. Su nombre viene de los grficos de quemado de caloras de los regmenes dietticos; se usan tambin en Scrum. Se trata de una tcnica de gracacin para descubrir demoras y problemas tempranamente en el proceso, evitando que se descubra demasiado tarde que todava no se sabe cunto falta. Para ello se hace una estimacin del tiempo faltante para programar lo que resta al ritmo actual, lo cual sirve para tener dominio de proyectos en los cuales las prioridades cambian bruscamente y con frecuencia. Esta tcnica se asocia con algunos recursos ingeniosos, como la Lista Temprana, llamada as porque se refiere al agregado de tems con alta prioridad en el tope de las listas de trabajos pendientes, esperando que los dems
40
elementos se hundan bajo la lnea de flotacin; los elementos que estn sobre la lnea se entregarn en la iteracin siguiente, los que estn por debajo en las restantes. En otras Metodologas giles la Lista temprana no es otra cosa que un grafico de retraso. Los grficos de quemado ilustran la velocidad del proceso, analizando la diferencia entre las lneas proyectadas y efectivas de cada entrega. Programacin lado a lado. Mucha gente siente que la programacin en pares de XP involucra una presin excesiva; la versin de Crystal Clear establece proximidad, pero cada quien se enfoca a su trabajo asignado, prestando un ojo a lo que hace su compaero, quien tiene su propia mquina. Esta es una ampliacin de la Comunicacin Osmtica al contexto de la programacin.
Hay ocho roles nominados en CC: Patrocinador, Usuario Experto, Diseador Principal, Diseador Programador, Experto en Negocios, Coordinador, Vericador, Escritor. En Crystal Naranja se agregan aun ms roles: Diseador de IU (Interfaz de Usuario), Diseador de Base de Datos, Experto en Uso, Facilitador Tcnico, Analista/Diseador de Negocios, Arquitecto, Mentor de Diseo, Punto de Reutilizacin. A continuacin se describen los artefactos de los que son responsables los roles de CC: 1. Patrocinador. Produce la Declaracin de Misin con Prioridades de Compromiso (Tradeoff). Consigue los recursos y dene la totalidad del proyecto. 2. Usuario Experto. Junto con el Experto en Negocios produce la Lista de Actores-Objetivos y el Archivo de Casos de Uso y Requerimientos. Debe familiarizarse con el uso del sistema, sugerir atajos de teclado, modos de operacin, informacin a visualizar simultneamente, navegacin. 3. Diseador Principal. Produce la Descripcin Arquitectnica. Se supone que debe ser al menos un profesional de Nivel 3. En Metodologas giles se denen tres niveles de experiencia: Nivel 1 es capaz de seguir los procedimientos. Nivel 2 es capaz de apartarse de los procedimientos especcos y encontrar otros distintos Nivel 3 es capaz de manejar con uidez, mezclar e inventar procedimientos. El Diseador Principal tiene roles de coordinador, arquitecto, mentor y programador ms experto. 4. Diseador-Programador. Produce, junto con el Diseador Principal, los Borradores de Pantallas, el Modelo Comn de Dominio, las Notas y Diagramas de Diseo, el Cdigo Fuente, el Cdigo de Migracin, las Pruebas y el Sistema Empaquetado. Un programa en CC es diseo y programa; sus programadores son diseadores-programadores. En CC un diseador que no programe no tiene cabida. 5. Experto en Negocios. Junto con el Usuario Experto produce la Lista de Actores-Objetivos y el Archivo de Casos de Uso y Requerimientos. Debe conocer las reglas y polticas del negocio. 6. Coordinador. Con la ayuda del equipo, produce el Mapa de Proyecto, el Plan de Entrega, el Estado del Proyecto, la Lista de Riesgos, el Plan y Estado de Iteracin y la Agenda de Visualizacin. 7. Verificador. Produce el Reporte de Bugs. Puede ser un programador en tiempo parcial, o un equipo de varias personas.
41
8. Escritor. Produce el Manual de Usuario. El Equipo como Grupo es responsable de producir la Estructura y Convenciones del Equipo y los Resultados del Taller de Reexin.
El Cdigo Gentico
Consiste en: 1. Un modelo de juegos cooperativos Este modelo ve al desarrollo de software como una serie de partidos que consisten en inventar y comunicar. Cada partido es diferente y tiene como objetivo entregar software y prepararse para el siguiente juego. Esto permite al equipo trabajar concentrado y en forma efectiva con un objetivo claro cada vez. 2. Prioridades Crystal Clear establece un conjunto de prioridades y principios que sirven de gua para la toma de decisiones, estas son: Eficiencia en el desarrollo: para hacer que los proyectos sean econmicamente rentables Seguridad en lo que se entrega Habitabilidad: hacer que todos los miembros del equipo adopten y sigan las convenciones de trabajo establecidas por el equipo mismo. 3. Propiedades Frecuencia en las entregas: entregar al usuario funcionalidad "usable" con una frecuencia de entre 2 semanas y no ms de un mes. Comunicacin: Crystal Clear toma como uno de sus pilares a la comunicacin. Promueve prcticas como el uso de pizarrones, pizarras y espacios destinados a que todos (miembros del equipo y visitas) puedan ver claramente el progreso del trabajo. Crecimiento reflexivo: es necesario que el equipo lleve a cabo reuniones peridicas de reflexin que permitan crecer y hacernos ms eficientes. Estas tres propiedades son "obligatorias" para Crystal Clear, las siguientes pueden agregarse en la medida de las necesidades de cada grupo y proyecto. Seguridad personal: lograr que cada miembro del team pueda sentirse cmodo con el trabajo y el entorno. Concentracin: las entregas frecuentes permiten que cada desarrollador puede enfocar de a un problema evitando dispersiones. Fcil acceso a usuarios clave: tratar de hacer que el usuario sea una parte ms del equipo es fundamental para ir depurando errores de manera temprana. Entorno tcnico con: o Testing automatizado (incorporacin, por ejemplo, de UnitTest). o Integracin frecuente (uso de herramientas especficas como Cruise Control).
4. Principios El grado de detalle necesario en documentar requerimientos, diseo, planeamiento, etc, vara segn el proyecto.
42
Es imposible eliminar toda documentacin pero puede ser reducida logrando un modo de comunicacin ms accesible, informal y preciso que pueda ser accedido por todos los miembros del equipo. El equipo ajusta constantemente su forma de trabajo para lograr que cada personalidad encaje con los otros miembros, con el entorno y las particularidades de cada asignacin.
5. Estrategias Ni las estrategias ni las tcnicas son mandatorias para Crystal Clear. Pero es bueno tener en cuenta alguna de ellas al momento de empezar a trabajar. Tres de las estrategias que estn ms relacionadas son las de apuntar a tener "Victorias Tempranas", arrancar el desarrollo de lo que se denomina un "Esqueleto que Camine" y pensar siempre en hacer "Re-arquitectura Incremental" van de la mano. El poder arrancar el proceso a partir de un esqueleto sobre el cual se ir agregando funcionalidad en cada una de las entregas ayuda a que se vean los avances desde el comienzo (aunque sea una simple pantalla de ABM que se conecta con la base de datos y muestra un solo dato). A medida que se avanza en el proceso, la re-arquitectura permitir ir agregando ms "cuerpo" al esqueleto inicial. Todas describen una forma de tomar ventaja del desarrollo incremental para establecer valor desde el principio. 6. Tcnicas Igual que con las estrategias, hay una lista de tcnicas propuestas por Crystal Clear, de las cuales se pueden ir tomando las ms convenientes segn el momento en que se encuentra el proceso de desarrollo del proyecto. Las reuniones diarias (introducidas por la metodologa Scrum) acompaan el seguimiento y mantienen el foco en el prximo paso a seguir, y tambin permiten la discusin productiva de lneas a seguir. Las reuniones de reflexin peridicas son fundamentales para que los miembros del equipo se expresen abiertamente, para revisar el trabajo hecho y evaluar qu cosas dan resultado y cules no o de empezar a trabajar. Todo esto permite ir armando una metodologa de trabajo que se adecue al equipo, el proyecto y los tiempos que se manejen.
Conclusin
La gua de trabajo que presenta Crystal Clear es altamente recomendable para equipos pequeos. Da flexibilidad y prioriza la parte humana, apuntando a lograr eficiencia, habitabilidad y confianza en los miembros del equipo. Presta especial importancia a la ubicacin fsica del grupo, donde la comunicacin cumple el principal rol. La entrega frecuente de cdigo confiable y "funcionando" mantiene el foco y evita distracciones. Todo esto permite ir armando una metodologa de trabajo que se adecue al equipo, el proyecto y los tiempos que se manejen. El riesgo en el mtodo gil son los Cambios de arquitectura son como ejercicios de trapecio
43
Dynamic Systems Development Method (DSDM)

DSDM es la nica de las metodologas aqu planteadas surgida de un Consorcio, formado originalmente por 17 miembros fundadores en Enero de 1994. El objetivo del Consorcio era producir una metodologa de dominio pblico que fuera independiente de las herramientas y que pudiera ser utilizado en proyectos de tipo RAD (Rapid Application Development). El Consorcio, tomando las mejores practicas que se conocan en la industria y la experiencia trada por sus fundadores, liber la primera versin de DSDM a principios de 1995. A partir de ese momento el mtodo fue bien acogido por la industria, que empez a utilizarlo y a capacitar a su personal en las prcticas y valores de DSDM. Debido a este xito, el Consorcio comision al Presidente del Comit Tcnico, Jennifer Stapleton, la creacin de un libro que explorara la realidad de implementar el mtodo. Dado el enfoque hacia proyectos de caractersticas RAD esta metodologa encuadra perfectamente en el movimiento de metodologas giles. La estructura del mtodo fue guiada por estos nueve principios: 1. El involucramiento del usuario es imperativo. 2. Los equipos de DSDM deben tener el poder de tomar decisiones. 3. El foco est puesto en la entrega frecuente de productos. 4. La conformidad con los propsitos del negocio es el criterio esencial para la aceptacin de los entregables. 5. El desarrollo iterativo e incremental es necesario para converger hacia una correcta solucin del negocio. 6. Todos los cambios durante el desarrollo son reversibles. 7. Los requerimientos estn especificados a un alto nivel. 8. El testing es integrado a travs del ciclo de vida. 9. Un enfoque colaborativo y cooperativo entre todos los interesados es esencial. DSDM define cinco fases en la construccin de un sistema. Las mismas son: 1. Estudio de factibilidad. 2. Estudio del negocio. 3. Iteracin del modelo funcional. 4. Iteracin del diseo y construccin. 5. Implantacin. El estudio de factibilidad es una pequea fase que propone DSDM para determinar si la metodologa se ajusta al proyecto en cuestin. Durante el estudio del negocio se involucra al cliente de forma temprana, para tratar de entender la operatoria que el sistema deber automatizar. Este estudio sienta las bases para iniciar el desarrollo, definiendo las features de alto nivel que deber contener el software. Posteriormente, se inician las iteraciones durante las cuales: se bajar a detalle los features identificados anteriormente, se realizar el diseo de los mismos, se construirn los componentes de software, y se implantar el sistema en produccin previa aceptacin del cliente.
44
Fases en la construccin de un sistema

Descontando la primera fase que es realizada una nica vez al principio del proyecto para analizar la factibilidad desde el punto de vista del negocio del desarrollo, las dems fases presentan las caractersticas del modelo iterativo e incremental ya tratado. Sin embargo, lo que diferencia a DSDM de dicho modelo son los principios alrededor de los cuales se estructura y que hacen nfasis en los equipos de desarrollo, en el feedback con el cliente, en las entregas frecuentes de productos. Para resolver la cuestin de la aplicabilidad de DSDM a un proyecto convendr responder las siguientes preguntas: Ser la funcionalidad razonablemente visible en la interfase del usuario? Se pueden identificar todas las clases de usuarios finales? Es la aplicacin computacionalmente compleja? Es la aplicacin potencialmente grande? Si lo es, puede ser particionada en componentes funcionales ms pequeos? Est el proyecto realmente acotado en el tiempo? Son los requerimientos flexibles y slo especificados a un alto nivel?
45
Las mismas refieren a las caractersticas que se deben cumplir en los proyectos para poder utilizar el enfoque RAD de construccin. Se observa que aquellos proyectos que califiquen afirmativamente de acuerdo a dichas preguntas tendrn las siguientes caractersticas que refieren a la aplicabilidad de DSDM: Son proyectos interactivos con la funcionalidad visible en la interfase de usuario. De baja o media complejidad computacional. Particionables en componentes de funcionalidad ms pequeos si la aplicacin es de gran tamao. Acotados en el tiempo. Con flexibilidad en los requerimientos. Con un grupo de usuarios bien definidos y comprometidos al proyecto. De esta forma observamos que DSDM deja las bases sentadas para el anlisis sobre su aplicabilidad a un espectro bien definido de proyectos de software. Sin embargo, la metodologa no tiene ninguna prescripcin respecto a las tcnicas a ser usadas en el proyecto, ni siquiera impone el desarrollo bajo un paradigma especfico, funciona tanto para el modelo de orientacin a objetos como para el modelo estructurado. Algo que s sugiere el mtodo es la generacin de un conjunto mnimo de modelos necesarios para la sana progresin de la entrega del software y facilidad en el mantenimiento. Estos modelos esenciales debern ser definidos antes que comience el desarrollo, y debern ser revisados en las sucesivas iteraciones para validad su contenido. El concepto de timebox es algo que est embebido en DSDM y en todas las metodologas giles, en las cuales tambin se conocen como iteracin, ciclo, intervalo. La consecuencia de utilizarlos es el feedback frecuente que brinda visibilidad a los stakeholders para que verifiquen el progreso y puedan tomar acciones correctivas a tiempo. Tambin permiten controlar la calidad de los productos intermedios que se van generando, y realizar estimaciones de esfuerzo ms precisas. Asimismo, cada timebox esta compuesta por actividades definidas en relacin a entregables en vez de tareas. Cada entregable generado durante el mismo es testeado/revisado dentro del mismo timebox. En DSDM, un timebox consta de tres fases que son: Investigacin, Refinamiento y Consolidacin. Durante la Investigacin se chequean que las actividades que componen el timebox se condicen con la arquitectura del sistema. Esta es una fase de carcter exploratorio, en la que se fijan los objetivos de la iteracin, los entregables a ser producidos, efectundose revisiones sobre las iteraciones anteriores a la actual. La siguiente fase, Refinamiento, consiste en la produccin propiamente dicha de los artefactos planificados. DSDM destaca la necesidad de colocar componentes de distinta prioridad en un mismo timebox, de manera de poder posponer a futuras iteraciones aquellos con menor prioridad, en caso que surjan imprevistos o se materialicen riesgos. Finalmente, la fase de Consolidacin consiste en completar los entregables, verificando la calidad de los mismos. En esta fase que posee el hito de finalizacin del timebox se demostrar que se satisficieron los requerimientos de calidad definidos durante la Investigacin.DSDM incluye roles claves en relacin al management del proyecto. Identifica al visionario como el encargado de asegurar que se satisfacen las necesidades del negocio; el usuario embajador que equivaldra al on-site customer de XP, que brinda el conocimiento del negocio y define los requerimientos del software; el coordinador tcnico que es la persona encargada de mantener la arquitectura y verificar
46
la consistencia de los componentes construidos respecto a esta y al cumplimiento de los estndares tcnicos. Algunas tcnicas sugeridas en DSDM son las sesiones JAD para capturar los requerimientos del software y la realizacin de prototipos para descifrar aquellas ambigedades que se presentan en el relevamiento y tambin para derribar las barreras comunicacionales entre analistas y usuarios. El enfoque propuesto consiste en la utilizacin de un prototipo evolutivo, el cual se va refinando hasta tenerse la aplicacin deseada. El nfasis queda en manifiesto en los prototipos que se sugieren para cada etapa: negocio, usabilidad, performance y capacidad, y diseo. En resumen, encontramos en DSDM una metodologa gil creada en el Reino Unido a partir de un consorcio con participacin de empresas de primera lnea. El mismo contiene las caractersticas principales de las metodologas giles y contiene prcticas tendientes al enfoque RAD. Algo que es importante de DSDM ha sido su aceptacin en la industria y su refinamiento continuo lo que indica que las metodologas giles no son solo dominio de pequeos grupos de desarrollo sino que estn siendo adoptadas por pesos pesados en las industrias.
47
Feature Driven Development (F.D.D)

Peter Coad es considerado uno de los referentes ms importantes dentro de la ingeniera de software. Coad ha sido uno de los principales pioneros detrs del movimiento de la orientacin a objetos y empez a trabajar con Ed Yourdon (uno de los creadores del Anlisis Estructurado) a principios de los noventa, cuando este ltimo pidi ayuda a alguien de la comunidad de objetos para desarrollar una nueva metodologa, basada en el paradigma de OO. Posteriormente, Coad junto con Jeff De Luca y otros, participara en la creacin de FDD, una metodologa desarrollada alrededor del ao 1998 que presenta las caractersticas de un proceso gil. La misma deriv del trabajo de Coad sobre las Feature Lists (Listas de Funcionalidades). FDD se estructura alrededor de la definicin de features que representan la funcionalidad que debe contener el sistema, y tienen un alcance lo suficientemente corto como para ser implementadas en un par de semanas. FDD posee tambin una jerarqua de features, siendo el eslabn superior el de feature set que agrupa un conjunto de features relacionadas con aspectos en comn del negocio. Por ltimo, establece el major feature set como el ms alto nivel de agrupacin de funcionalidad que abarca diferentes feature sets que contribuyen a proveer valor al cliente en relacin a un subdominio dentro del dominio completo de la aplicacin. Una de las ventajas de centrarse en las features del software es el poder formar un vocabulario comn que fomente que los desarrolladores tengan un dilogo fluido con los clientes, desarrollando entre ambos un modelo comn del negocio. Este tema ser tratado ms adelante en relacin al enfoque de las metodologas giles en los productos entregados. La jerarqua de los features utiliza los siguientes formatos: Para features: <accin> el <resultado> <de | para | sobre | por> un <objeto> Para feature sets: <accin><-endo> un <objeto> Para major feature sets: administracin de <accin> Ejemplos: Calcular el total de la facturacin de Noviembre (feature) Modificar el estado de las facturas de produccin (feature) Haciendo una venta a un cliente (feature set) Cargando la facturacin de los proveedores (feature set) Administracin de Bancos (mayor feature set) El ciclo de vida propuesto por FDD se puede observar en la siguiente figura y est compuesto por cinco procesos, dos de las cuales se realizan tantas veces como iteraciones se planifiquen en el desarrollo.
48
La primera actividad: consiste en Desarrollar un Modelo Global, que sugiere un cierto paralelismo con la construccin de la arquitectura del software. En la creacin de este modelo participan tanto los expertos en el dominio como los desarrolladores. Mediante el esfuerzo de ambas partes se intenta lograr lo que el modelo en espiral propona con sus primeras iteraciones: un conocimiento global de la aplicacin a construir, el entendimiento del negocio en que esta embebida, un primer bosquejo de las features del software, y la definicin de restricciones y cuestiones no funcionales. Para esto, se desarrollarn: diagramas de los paquetes, con las clases esenciales y las responsabilidades de las mismas; un documento similar al de Visin en donde se plasmen los objetivos del proyecto y como el mismo ayuda al negocio; un documento con los requerimientos no funcionales detectados; por ltimo, el documento que podramos llamar arquitectura y en el que figuran las opciones de modelado surgidas durante esta actividad. La segunda actividad: Construir una Lista de Features, comienza tomando el bosquejo de features formulado durante la actividad anterior para refinar las funcionalidades incluidas. Una vez que se han identificado las mismas se las agrupa jerrquicamente para poder estructurar el trabajo de desarrollo; se realiza la priorizacin de las mismas basndose en la satisfaccin al cliente las prioridades sugeridas para las features por FDD son: A (debe tener), B (sera til tener), C (agregar si es posible), o D (futuro); finalmente, se pondera la importancia de cada una para su posterior implementacin en caso que existan features que requieran ms de dos semanas de desarrollo en esta actividad se particionarn para lograr ubicarlos en iteraciones. La tercera actividad: Planificar por Feature, toma como input la lista priorizada de la fase anterior y establece los tiempos las futuras iteraciones. En esta actividad participan el lder de proyecto, el lder de desarrollo y el programador jefe. A medida que se realiza la planificacin se delinean los hitos de finalizacin de las iteraciones, dejando asentado cuales son los features y features sets que estarn construidos en dichos hitos. Parte de tambin incluye la delegacin de responsabilidades a los programadores jefe que sern dueos de los features, estos a su vez asignarn las clases a dueos de clases seleccionados del equipo. Las ltimas dos actividades: Disear por Feature y Construir por Feature, estn relacionadas con la parte productiva del proceso en que se construye la aplicacin de manera incremental. Empezando por el diseo que toma los features correspondientes a la iteracin, el equipo de programadores liderado por el programador jefe identifica las clases, atributos y mtodos que realizan la funcionalidad requerida. Mediante la
49
utilizacin de diagramas de secuencia de UML, se verifica que el diseo pueda ser implementado. Se realizar tambin una inspeccin del diseo en los casos en que la complejidad de la funcionalidad lo requiera. Posteriormente, en la fase de Construir por Feature, se procede a desarrollar las clases definidas en la actividad anterior. Cada programador implementar los mtodos de las clases por las que este es responsable, extendiendo las clases base de prueba para construir las pruebas unitarias. Una vez que la clase pasa todas las pruebas, se inspecciona el cdigo. Esta actividad ser realizada por el equipo asignado al feature en cuestin, y una vez que finaliza se promueve el cdigo al Build correspondiente, siendo entregado a Administracin de la Configuracin.
Roles
Roles claves: Gerente del proyecto: es quien tiene la ltima palabra en materia de visin, cronograma y asignacin del personal. Arquitecto jefe: este rol puede dividirse en arquitecto de dominio y arquitecto tcnico. Gerente de desarrollo: puede combinarse con arquitecto jefe o gerente de proyecto, se encarga de resolver conflictos dentro del equipo de desarrollo. Programador jefe: es la persona que participa en el anlisis de requerimientos y selecciona rasgos del conjunto a desarrollar en la siguiente iteracin. Propietarios de clases: trabajan bajo la gua del programador jefe en diseo, codificacin, prueba y documentacin, repartidos por rasgos. Experto de dominio: que puede ser un cliente, patrocinador, analista de negocios o una mezcla de todo esto. Roles de soporte: Administrador de entrega: controla el progreso del proceso revisando los reportes del programador jefe y manteniendo reuniones breves con l, reporta al gerente de proyecto. Guru de lenguaje: conoce a la perfeccin el lenguaje y la tecnologa. Herramientista (toolsmith): construye pequeas herramientas de desarrollo o mantiene bases de datos y sitios web. Administrador del sistema: controla el ambiente de trabajo, servidores, redetc. Roles Adicionales: Tester: verificador del sistema producido. Escritores de documentos tcnicos: Un miembro del equipo puede tener otros roles a cargo, y un solo rol puede ser compartido por varias personas. FDD consiste en cinco procesos secuenciales durante los cuales se disea y construye el sistema. En relacin a las actividades de management en FDD se recomienda una reunin semanal entre el Lder de proyecto y los programadores jefe; la misma debe ser breve, de no ms de 30 minutos, y en la cual se reporta el status de los features que estn siendo construidos por cada grupo. Por cada feature set que es implementado se tendr
50
la informacin como indica la Figura 006 para medir el avance del proyecto, dndole visibilidad al management superior y al cliente.
Conclusin
Encontramos en FDD un proceso gil orientado a la funcionalidad del software por sobre las tareas, sobre las cuales da guas mnimas. El proceso sugiere organizar bloques de features a ser construidos en forma incremental mediante iteraciones de dos semanas; provee estrategias de planeamiento para el lder de proyecto; fomenta la colaboracin mediante la creacin de equipos dirigidos por un programador jefe Algunos agilistas sienten que FDD es demasiado jerrquico para ser un mtodo gil, porque demanda un programador jefe, quien dirige a los propietarios de clases, quienes dirigen equipos de rasgos. Otros sienten que la ausencia de procedimientos detallados de prueba en FDD es llamativa e impropia. FDD se utiliz por primera vez en grandes aplicaciones bancarias a fines de la dcada de 1990. Un rasgo llamativo de FDD es que no exige la presencia del cliente.
51
Adaptive Software Development

Jim Highsmith en su libro es la mente detrs de este proceso gil. ASD consiste en un cambio de filosofa en las organizaciones pasando de la transicin del modelo Comando-Control al modelo Liderazgo-Colaboracin. Basado en los conceptos de los Sistemas Adaptativos Complejos relacionada con la Inteligencia Artificial, Highsmith lleva los mismos al campo de la Ingeniera de Software en particular. Dada la complejidad inherente al software concluye que la aplicacin de esta teora es esencial para el nuevo escenario que plantea la economa global. Comenzando por un cambio en el modelo de desarrollo determinista, tomado del ciclo de Deming, en que se aplica la secuencia Planificar-Ejecutar-Evaluar. Dicho esquema es llevado a la prctica con el modelo en cascada, en que se realiza una precisa planificacin inicial mediante el WBS, el Gantt, y el Pert definiendo las tareas a realizar en detalle, luego se tiene las fases de construccin, y finalmente, se tiene el testing que brinda el feedback en relacin al producto construido. ASD propone utilizar en cambio el ciclo de vida de la Figura 007, Especular-ColaborarAprender. El proyecto comienza con una fase de especulacin en que en que se lleva a cabo la planificacin tentativa del proyecto en funcin de las entregas que se irn realizando. La utilizacin del verbo Especular demuestra el inters de Highsmith en demostrar la naturaleza impredecible de los sistemas complejos. En esta etapa se fija un rumbo determinado a ser seguido en el desarrollo, sabiendo a partir de ese momento que no ser el lugar en que finalizar el proyecto. En cada iteracin, se aprendern nuevas funcionalidades, se entendern viejas cuestiones, y cambiarn los requerimientos. Gracias a centrarse en la especulacin, ASD permite administrar estos proyectos de alto cambio y rpido desarrollo que se encuentran en el borde del caos. Respecto a la especulacin, se recomienda realizar un component breakdown structure en vez del muy conocido y tradicional work breakdown structure (WBS) en el cual mediante una grilla u hoja de clculo se pueda conocer la funcionalidad a ser liberada en cada ciclo.Sin embargo, no es ms que una especulacin ya que el carcter adaptativo del proceso permite pequeas desviaciones en un sentido por lo que Highsmith sugiere que cada ciclo se componga de un mix entre funcionalidades crticas, tiles, y opcionales, previendo los posibles retrasos que puedan existir mediante el movimiento de las funcionalidades de menor prioridad a futuros ciclos y grandes desviaciones en otro, las cuales son utilizadas para la exploracin del dominio y de la aplicacin, que puede llevar a cambiar el rumbo del proyecto estos desvos est representado por las flechas de divergencia en la siguiente figura:
52
La siguiente fase del ciclo de vida, Colaborar, es aquella en la que se construye la funcionalidad definida durante la especulacin. ASD define un Componente como un grupo de funcionalidades o entregables a ser desarrollados durante un ciclo iterativo. Durante cada iteracin el equipo colabora intensamente para liberar la funcionalidad planificada. Tambin, existe la posibilidad de explorar nuevas alternativas, realizar pruebas de concepto, pudiendo eventualmente alterar el rumbo del proyecto profundamente. ASD no propone tcnicas ni prescribe tareas al momento de llevar a cabo la construccin simplemente mencionando que todas las prcticas que sirvan para reforzar la colaboracin sern preferidas, siguiendo de esta forma la lnea de las metodologas giles respecto a la orientacin a componentes. El nfasis se ubica en la relaciones entre las personas que deben estar lo suficientemente lubricadas para generar una propiedad imprescindible de los organismos complejos: emergencia. La emergencia es una propiedad de los sistemas adaptativos complejos que crea alguna propiedad ms grande del todo (comportamiento del sistema) a partir de la interaccin entre las partes (comportamiento auto-organizativo de los agentes). Gracias a esta propiedad los grupos de desarrollo logran sacar lo mejor de si en la el borde del caos. La fase final de ASD, Aprender, consiste en la revisin de calidad que se realiza al final de cada ciclo. En la misma se analizan cuatro categoras de cosas para aprender: Calidad del resultado de la desde la perspectiva del cliente. Calidad del resultado de la desde la perspectiva tcnica. El funcionamiento del equipo de desarrollo y las prcticas que este utiliza. El status del proyecto.
Para evaluar la calidad desde el punto de vista del cliente se sugieren utilizar grupos de enfoque en el cliente, mediante los cuales se explora un modelo de la aplicacin y se anotan los requerimientos de cambio del cliente. Las revisiones al diseo, al cdigo o a las pruebas permitirn aprender sobre la calidad de los mismos. En este caso, el nfasis estar puesto en aprender cuales han sido los errores o desvos y poder resolverlos, y no en encontrar culpables. Asimismo, est es la etapa en que se evaluarn las exploraciones que se hayan realizado dando la capacidad de poder modificar la arquitectura del sistema si se ha encontrado algn camino que se ajusta mejor a lo que necesita el usuario o si han cambiado los requerimientos. El tercer proceso de feedback est relacionado con la interaccin entre las partes, la dinmica de grupo, y las tcnicas empleadas. Para medir la performance y el grado de cohesin del mismo, se podrn realizar al final de cada ciclo pequeas reuniones de postmortem. En las mismas se discuten los aspectos del proceso que contribuyen al desarrollo y aquellos que deben ser descartados por su influencia negativa. En relacin al status del proyecto, se realizarn revisiones para determinar el estado del mismo en relacin a lo planificado. En este momento, se detectarn posibles diferencias que pueden surgir de la exploracin y que cambiarn el rumbo a que apuntaba el proyecto.
53
En la siguiente Figura se puede ver el detalle interno de cada fase como ya fue explicado, mostrndose con una flecha que trasciende las tres fases en sentido inverso, el bucle de aprendizaje. Este bucle es algo crtico para ASD ya que denota un cambio en el esquema tradicional de la vista de un sistema en que se tena un bucle de control para detectar diferencias y corregirlas. Es decir, en las metodologas tradicionales las diferencias respecto a lo planificado eran vistas como errores que deban ser enmendados para que cumplieran lo pautado. ASD y las metodologas giles plantean la necesidad de que el feedback necesario sea para aprender, nos da la posibilidad de entender ms respecto al dominio y construir la aplicacin que mejor satisfaga las necesidades del cliente. Highsmith lo expone claramente en la siguiente frase: En ambientes complejos, el seguir un plan al pie de la letra produce el producto que retendamos, pero no el producto que necesitamos.
Conclusion
En conclusin, tenemos en ASD un marco filosfico basado en la teora de Sistemas Adaptativos Complejos que nos permite encarar la construccin de software en forma gil utilizando las prcticas que nos resulten convenientes en cada caso. En este sentido resulta similar a Scrum.
54
LEAN SOFTWARE DEVELOPMENT

Lean es el nombre del mtodo que usa Toyota para producir y desarrollar automviles. Como desarrolladores de software no hacemos ninguna de esas dos cosas, as que por qu nos debera interesar? La razn es simple: los principios bsicos del mtodo de Toyota son principios que en la realidad aplican en cualquier lugar. No son panaceas: los principios son universales, aunque puedan variar las prcticas especficas. El trmino de desarrollo de software Lean tiene origen en un libro del mismo nombre, escrito por Mary Poppendieck y Tom Poppendieck. El libro presenta los tradicionales principios Lean en forma modificada, as como un conjunto de 22 instrumentos y herramientas para comparar las prcticas giles. La participacin de Mary y Tom en la comunidad del desarrollo gil de software, incluyendo charlas en varias conferencias, ha dado lugar a dichos conceptos, que son ms ampliamente aceptados en la comunidad de desarrollo gil. Ejemplos de ello sera la utilizacin del trmino "Lean-Agile" por empresas de consultora como NetObjectives Pace y CC, as como la inclusin de algunos de estos conceptos.
OBJETIVOS
1. Construir un mapa de la cadena de valor para su organizacin de desarrollo de software actual y luego crear un nuevo mapa para el futuro. 2. Reorganizar el proceso de desarrollo de software alrededor de ciclos cortos de desarrollo que permitan acelerar la generacin de valor. 3. Entender como administrar la calidad del software moviendo las actividades de testing hacia el comienzo y el centro del proceso de desarrollo. 4. Establecer el estado actual de sus disciplinas bsicas, las cuales determinan las capacidades de su proceso de desarrollo de software. 5. Cuantificar la capacidad de su organizacin de desarrollo de software y limitar el trabajo a esa capacidad. 6. Lograr el compromiso de la gente moviendo la responsabilidad y la toma de decisiones a los equipos de desarrollo. 7. Aplicar mtodos clsicos de mejora de procesos a problemas reales en su ambiente. 8. Crear mtricas que guen la optimizacin de resultados para la organizacin en su totalidad.
55
Los principios Lean

El desarrollo Lean puede resumirse en siete principios, muy cerca en concepto de los principios fabricacin Lean. Los principios que guian a Lean pueden aplicarse al software. Esto brinda una gua para aquellos que intentan desarrollar software de manera ms efectiva. En esta serie de artculos, en vez de describir a Lean por si slo, vamos a describir a Lean en trminos de las prcticas giles que sugiere. Hay mucho poder en este conocimiento: cuando un coach gil se encuentra en una situacin donde no se puede seguir una prctica gil estndar, los principios Lean lo van a guiar hacia un mejor camino. Los principios de Lean tambin nos muestran cosas diferentes para mirar adems de las prcticas giles. Al volver algunas cosas explcitas se logra que los coach giles tengan ms variedad a su alcance para mejorar los mtodos.
Nociones previas importantes

Antes, vamos a ver algunos principios fundamentales sobre los que se basa Lean, y que es bueno tener en claro desde el principio. Los ms importantes son: La mayora de los errores son de naturaleza sistmica y por lo tanto se debe mejorar el sistema de desarrollo. Por esto: Se debe respetar a las personas para poder mejorar el sistema. Se van a tomar mejores decisiones si se atiende la secuencia de tiempo del desarrollo, en vez de intentar maximizar la utilizacin de los recursos. Los dos primeros puntos son las bases del trabajo de Edwards Deming. Deming es el hombre al cual los Japoneses les suelen atribuir la forma en la que producen bienes de alta calidad. El ltimo punto, muchas veces descripto como "Justo-A-Tiempo" (Just-InTime) fue agregado por Toyota y constituye un componente esencial de Lean.
Buscar la fuente de los errores en el sistema

Cuando algo sale mal, nuestra tendencia normal es buscar a quien culpar. No nos cuestionamos este enfoque; sabemos que alguien tiene que tener la culpa del accidente. Pero quizs es la situacin en la cual se encontraba algunas de las personas que estamos culpando la que ocasion el problema. Veamos un ejemplo tpico del desarrollo de software. Supongamos que se te asigna como responsable de escribir una caracterstica para un sistema existente. Te dan la documentacin de un analista del equipo que describe la funcionalidad que se tiene que escribir. Nunca se te da la oportunidad de hablar con alguien que realmente vaya a utilizar el software, sino que simplemente tens que confiar en el documento. Escribis el cdigo, se prueba, se le muestra la nueva caracterstica al cliente, que dice q eso no fue lo que pidio. A quin culparas? Al cliente por no ser claro? Al analista por escribir algo pobremente? A vos mismo, por no poder seguir la especificacin? Al tester por no probarlo adecuadamente? Si reflexionamos un poquito vamos a descubrir que no hay ninguna persona a la quien culpar; en cambio, el problema tiene que ver con la forma en la que las personas estn trabajando juntas. En otras palabras, el "sistema" actual hace que cada persona trabaje de manera separada en roles especficos. No existen
56
mecanismos de feedback, y se propagan los errores. Un "sistema" gil hara que las personas trabajen como equipo. El cliente, analista, desarrollador y testear hablaran entre ellos y decidiran juntos sobre las necesidades del cliente y la mejor forma de satisfacerla. Este sistema es mejor. Aunque todava es posible que surjan errores, la mayora se elimina porque la comunicacin es mejor. Mejorar la comunicacin es uno de los objetivos principales de gil; desafortunadamente, las prcticas giles tienden a enfatizar la comunicacin a un nivel local: entre el equipo, y entre el equipo y el cliente. gil ofrece un soporte pobre para mejorar la comunicacin entre los equipos, arriba y abajo del flujo de valor, o a travs de la compaa. Las prcticas Lean ayudan con la comunicacin en estos contextos ms grandes, haciendo nfasis en la mejora continua del proceso, la optimizacin del total, y la entrega rpida. En Lean, las demoras de la comunicacin causan demoras y desperdicios, en la forma de errores, y por lo tanto deben ser eliminados. En los artculos siguientes de esta serie vamos a describir a Lean en trminos de prcticas giles, viendo como las diferentes prcticas apuntan a alguno de estos principios.
Los siete principios

Eliminar los residuos
El principio de eliminar los residuos (o muda, que es un tipo especfico de residuos en el lxico Toyota) ha sido tomado de las ideas de Taiichi Ohno - el padre del Sistema de Produccin Toyota. Se ha distinguido las actividades siguientes como residuos: Una parte de un automvil almacenada a la espera de ser usada. Producir todo lo que no necesita de inmediato. Movimiento innecesario de componentes. Partes que necesitan esperar a que otras que se produzcan. Pasos extra de procesamiento en la produccin. Defectos (menos calidad)
En otras palabras, aplicado al pensamiento Lean, todo lo que no aade valor al cliente se considera un residuo. Esto incluye: Cdigo y funcionalidad innecesaria Retraso en el proceso de desarrollo de software Requisitos poco claros Burocracia Comunicacin interna lenta
Con el fin de poder eliminar los residuos, uno debera ser capaz de reconocer y ver. Si alguna actividad podra ser superada o el resultado podra ser logrado sin ella, esta es un residuo. La codificacin parcial eventualmente abandonada durante el proceso de desarrollo es un residuo. Los procesos extra y funcionalidades que no utilizan con frecuencia por los clientes son residuos. Las esperas ocasionadas por otras actividades,
57
equipos o procesos son residuo. Defectos y menor calidad son los residuos. Gastos generales de gestin que no producen valor real son residuos. Se utiliza una tcnica llamada value stream mapping de para distinguir y reconocer los residuos. El segundo paso consiste en sealar las fuentes de los residuos y eliminarlos. Lo mismo debe hacerse iterativamente hasta incluso los procesos y procedimientos que parecen esenciales son eliminados.
Brindar un liderazgo tcnico y de mercado - la organizacin puede ser exitosa si produce productos innovadores y tecnolgicamente avanzados, pero es importante comprender lo que valoran nuestros clientes y conocer la tecnologa que se est usando. Crear slamente cosas de valor - debemos ser cuidados con todos los procesos que sigamos. Por ejemplo, debemos asegurarnos que todos estos procesos son tiles y estn enfocados en crear valor. Escribir menos cdigo - mientras ms cdigo se tenga, ms pruebas se van a necesitar, por lo que se necesitar ms trabajo. Si escribiemos pruebas para funcionalidad que no se necesita estamos perdiendo el tiempo.
Eliminar el desperdicio es la gua principal de un practicante Lean. Existe desperdicio en el esfuerzo que se requiere para construir un producto: cualquier trabajo que no agrega valor. El desperdicio es evidente en el cdigo que es ms complejo de lo necesario. El desperdicio surge cuando se crean defectos. En donde haya desperdicio, el practicante Lean observa al sistema para ver cmo eliminarlo porque es probable que cuando encontramos un error, va a continuar repitindose (de una manera u otra), hasta que arreglamos al sistema que lo provoca.
Ampliar el aprendizaje
El desarrollo de software es un proceso de aprendizaje continuo con el reto adicional de equipos de desarrollo y tamao de producto final. El mejor enfoque para la mejora de un entorno de desarrollo de software es ampliar el aprendizaje. La acumulacin de defectos debe evitarse ejecutando las pruebas tan pronto como el cdigo est escrito. En lugar de aadir ms documentacin o planificacin detallada, las distintas ideas podran ser juzgados escribiendo cdigo y construyendo. El proceso de recopilacin de requisitos de usuarios podra simplificarse mediante la presentacin de las pantallas de los usuarios finales y para que estos puedan hacer sus aportes. El proceso de aprendizaje es acelerado por el uso de ciclos de iteracin cortos - cada uno de ellos junto con refactorizacin y pruebas de integracin. Incrementando el feedback a travs de cortas sesiones con los clientes, ayuda a determinar la fase actual de desarrollo y ajusta los esfuerzos para introducir mejoras en el futuro. Durante los breves perodos de sesiones, tanto los clientes como el equipo de desarrollo, logran aprender sobre el dominio del problema y buscar posibles soluciones para un mejor desarrollo. Por lo tanto, los clientes comprenden mejor sus necesidades, basndose en el resultado de los esfuerzos del desarrollo, y los desarrolladores aprendan a satisfacer mejor estas necesidades. Otra idea en el proceso de aprendizaje y de comunicacin con los clientes basado en el desarrollo, se concentra en la comunicacin de las limitaciones de soluciones futuras y no las posibles soluciones, promoviendo as el nacimiento de la solucin a travs del dilogo con el cliente.
58
Crear equipos de diseo y construccin - el lder del equipo de desarrollo tiene que escuchar a los miembros y hacerles preguntas inteligentes que los insite a buscar respuestas y volver lo ms pronto posible con los problemas que surgen, o con las soluciones inventadas. Mantaner una cultura de mejora continua - crear un ambiente en donde las personas estn mejorando continuamente en lo que trabajan - deben saber que no son y no deben ser perfectas - y que siempre tienen algn rea que pueden mejorar. Ensear mtodos de resolucin de problemas - los equipos de desarrollo deberan comportarse como pequeos centros de investigacin, estableciendo hiptesis y realizando varios experimentos rpidos para verificar su validez.
Crear equipos de diseo y construccin - el lder del equipo de desarrollo tiene que escuchar a los miembros y hacerles preguntas inteligentes que los incite a buscar respuestas y volver lo ms pronto posible con los problemas que surgen, o con las soluciones inventadas. Mantener una cultura de mejora continua - crear un ambiente en donde las personas estn mejorando continuamente en lo que trabajan - deben saber que no son y no deben ser perfectas - y que siempre tienen algn rea que pueden mejorar. Ensear mtodos de resolucin de problemas - los equipos de desarrollo deberan comportarse como pequeos centros de investigacin, estableciendo hiptesis y realizando varios experimentos rpidos para verificar su validez.
Decida lo ms tarde posible

Como el desarrollo de software est siempre asociado con cierto grado de incertidumbre, los mejores resultados se alcanzan con un enfoque basado en opciones, lo que retrasa las decisiones tanto como sea posible, hasta que estas se basen en hechos y no en suposiciones y pronsticos inciertos. Cuanto ms complejo es un proyecto, ms capacidad para el cambio debe incluirse en este, as que debe permitirse el retraso los compromisos importantes y cruciales. El enfoque iterativo promueve este principio, la capacidad de adaptarse a los cambios y corregir los errores, lo que podra ser muy costoso si se descubre despus de la liberacin del sistema. Un enfoque de desarrollo de software gil puede llevarles opciones antes a los clientes, por lo tanto, retrasar algunas decisiones cruciales hasta que los clientes se hayan reconocido mejor sus necesidades. Esto tambin permite la adaptacin tarda a los cambios y previene de las costosas decisiones delimitadas por la tecnologa. Esto no significa que no haya planificacin involucrada en el proceso - por el contrario, las actividades de planificacin deben centrarse en las diferentes opciones y se las adapta a la situacin actual, as como se deben clarificar las situaciones confusas, estableciendo las pautas para una accin rpida. Evaluar las diferentes opciones es eficaz tan pronto como queda claro que ellos no son libres, pero proporcionando la flexibilidad necesaria para una tarda toma de decisiones.
Agendar las decisiones irreversibles hasta el ltimo momento responsable - debemos saber hacia donde queremos ir pero no conocemos el camino del todo, lo vamos descubriendo da a da - lo ms importante es mantener la direccin correcta.
59
Romper con las dependencias - los componentes deben estar lo ms desacoplados posible para que puedan implementarse en cualquier orden. Mantener opciones - desarrollar mltiples soluciones para todas las decisiones crticas y ver cuales funcionan mejor.
Posponer el compromiso significa posponer comprometerse a tomar una accin hasta que tener toda la informacin necesaria para tomar la decisin a la que nos comprometemos, o hasta que no podamos esperar ms a tomar esa decisin sobre qu hacer. Este principio puede usarse para guiar a los requerimientos, al anlisis y al diseo de un sistema. Posponer el compromiso en los requerimientos y el anlisis. Muy a menudo pensamos en los compromisos como en una accin o decisin que hicimos. Para tambin puede ser un compromiso a usar tiempo. Una vez que hayamos usado cierto tiempo en hacer algo, no puede deshacerse - es decir, no podemos volver atrs el tiempo. Al tomar requerimientos debemos preguntarnos - en dnde debera usar mi tiempo? Necesito discutir todos los requerimientos con el cliente? Claramente no. Algunos requerimientos son ms importantes que otros. Debera empezar con los requerimientos que invlucran funcionalidad que es la ms importante para el negocio, y por los requerimientos que crearn un riesgo tcnico si no se los ataca tempranamente. Estos requerimientos que son los ms importantes para el negocio son los que usualmente le dan ms valor al cliente. Los mtodos giles se encargan de esto al hacernos enfocar en aquellos requerimientos que el cliente siente que son los ms importantes. Esta es una de las principales justificaciones del desarrollo por iteraciones. Pero como gua sobre qu trabajo hacer no es suficiente mirar a la importancia de las caractersticas segn el cliente. Tambin hay que prestar atencin a los riesgos arquitectnicos. Cules requerimientos puede provocar problemas si se los ignora? Estos requerimientos tambin tienen que atenderse. Posponer el compromiso en el diseo. Los desarrolladores tienden a tomar uno o dos enfoques distintos cuando se los fuerza a disear algo que no tienen muy claro. Un enfoque es hacer las cosas lo ms simple posible sin hacer nada para atajar a los requerimientos futuros (no confundir con la regla de Extreme Programming, que es hacer algo lo ms simple posible - esta regla es dentro del contexto de otras acciones). El otro enfoque es anticiparse a lo que pueda ocurrir y construir hooks dentro del sistema. Ambos de estos enfoques tienen desafios distintos. El primero genera un cdigo que va a ser dificil de cambiar. Esto ocurre porque no se considera la naturaleza cambiante del cdigo cuando se lo escribe. El segundo enfoque genera cdigo que es ms complejo del necesario. Esto ocurre porque la mayora de los desarrolladores tienen una discapacidad para ver el futuro, igual que yo (una forma de decir de que no pueden adivinar el futuro - hasta donde yo s, todos somos discapacitados en este sentido!). Luego, cuando nos anticipamos a resolver temas futuros, a menudo terminamos con hooks (clases, mtodos, etc.) que en realidad no se necesitan y agregan complejidad.
60
Reaccionar tan rpido como sea posible

En la era de la rpida evolucin de tecnolgica, no es el ms grande quien sobrevive, sino el ms rpido. Cuanto antes el producto final se entrega sin defectos considerables, ms pronto se pueden recibir comentarios, y se incorporan en la siguiente iteracin. Cuanto ms cortas sean las iteraciones, mejor es el aprendizaje y la comunicacin dentro del equipo. Sin velocidad, las decisiones no pueden ser postergadas. La velocidad asegura el cumplimiento de las necesidades actuales del cliente y no lo que este requera para ayer. Esto les da la oportunidad de demorarse pensando lo que realmente necesitan, hasta que adquieran un mejor conocimiento. Los clientes valoran la entrega rpida de un producto de calidad. La ideologa de produccin Just In Time podra aplicarse a programas de desarrollo, reconociendo sus necesidades especficas y el ambiente. Esto se logra mediante la presentacin de resultados y la necesidad de dejar que el equipo organizarse y dividiendo las tareas para lograr el resultado necesario para una iteracin especfica . Al principio, el cliente dispone los requisitos necesarios. Esto podra ser simplemente presentan en pequeas fichas o historias y los desarrolladores estimarn el tiempo necesario para la aplicacin de cada tarjeta. As, la organizacin del trabajo cambia en sistema autopropulsado: cada maana durante una reunin inicial, cada miembro del equipo evala lo que se ha hecho ayer, y lo que hay que hacer hoy y maana, y pregunta por cualquier nueva entrada necesaria de parte de sus colegas o del cliente. Esto requiere la transparencia del proceso, que es tambin beneficioso para la comunicacin del equipo.Otra idea clave del Sistema de Desarrollo de Producto de la Toyota se establece a base de diseo. Si un nuevo sistema de frenos es necesario para un coche, por ejemplo, tres equipos pueden disear soluciones al mismo problema. Cada equipo aprende sobre el problema de espacio y diseos de una posible solucin. Cuando una solucin se considera irrazonable, se desecha. Al final de un periodo, los diseos sobrevivientes se comparan y se elige uno, quiz con algunas modificaciones basadas en el aprendizaje de los dems, un gran ejemplo de compromiso aplazado hasta el ltimo momento posible. Las decisiones en el software tambin podran beneficiarse de esta prctica para minimizar el riesgo provocado por un solo gran diseo realizado por adelantado.

Trabajar en bloques pequeos - reducir el tamao del proyecto, acortar los ciclos de entrega, estabilizar el ambiente de trabajo (escuch lo que te dice la velocidad), repetir lo bueno y erradicar las prcticas que crean obstculos. Limitar el trabajo a la capacidad - limitar la cola de tareas al mnimo (una o dos iteraciones por delante es suficiente), no hay que tener miedo al quitar elementos de la cola - rechazar cualquier trabajo hasta que se haya vaciado un lugar en la cola. Enfocarse en el tiempo del ciclo, no en la utilizacin - agregar tareas pequeas a la cola que no puedan atascar al proceso por un tiempo largo reducir el tiempo del ciclo y tener pocas cosas para procesar en la cola
61
Potenciar el equipo
Ha habido una creencia tradicional en la mayora de las empresas acerca de la toma de decisiones en la organizacin - los administradores de decirle a los trabajadores de cmo hacer su propio trabajo. En una tcnica Work-Out, los roles cambian: a los directivos se les ensea a escuchar a los desarrolladores, de manera que estos puedan explicar mejor qu acciones podran tomarse, as como ofrecer sugerencias para mejoras. Los directores de proyecto ms experimentados simplemente han declarado la clave de xito de los proyectos: "Buscar la buena gente y dejarles hacer su propio trabajo". Otra creencia errnea ha sido considerar a las personas como recursos. Las personas podran ser los recursos desde el punto de vista de una hoja de datos estadsticos, pero en el desarrollo de software, as como cualquier organizacin de negocios, las personas necesitan algo ms que la lista de tareas y la seguridad de que no ser alterada durante la realizacin de las tareas. Las personas necesitan motivacin y un propsito superior para el cual trabajar un objetivo alcanzable dentro de la realidad, con la garanta de que el equipo puede elegir sus propios compromisos. Los desarrolladores deberan tener acceso a los clientes, el jefe de equipo debe proporcionar apoyo y ayuda en situaciones difciles, as como asegurarse de que el escepticismo no arruine el espritu de equipo.
Crear la integridad
El siempre exigente cliente debe tener una experiencia general del sistema a esto se llama percepcin de integridad: cmo es publicitado, entregar, implementado y accedido? cuan intuitivo es su uso? precio? cuan bien resuelve los problemas? Integridad Conceptual significa que los componentes separados del sistema funcin bien juntos, como en un todo, logrando equilibrio entre la flexibilidad, mantenibilidad, eficiencia y capacidad de respuesta. Esto podra lograrse mediante la comprensin del dominio del problema y resolvindolo al mismo tiempo, no secuencialmente. La informacin necesaria es recibida por los pequeos lotes - no en una vasta cantidad y con una preferible comunicacin cara a cara, sin ninguna documentacin por escrito. El flujo de informacin debe ser constante en ambas direcciones - a partir del cliente a los desarrolladores y viceversa, evitando as la gran y estresante cantidad de informacin despus de un largo periodo de desarrollo en el aislamiento. Sinronizar: para lograr una alta calidad en el software nos debemos empezar a ocupar de l antes de empezar a escribir una sola lnea de cdigo. Automatizar: automatizar las pruebas, la construccin, las instalaciones, y cualquier cosa que sea rutinaria. Hay que automatizar de una manera inteligente, de forma que las personas puedan mejorar el proceso y cambiar cualqueir cosa que quieran sin preocuparse por si el cambio hace que las cosas dejen de funcionar. Refactor: eliminar la duplicacin de cdigo a CERO - cada vez que aparezca la oportunidad, realizar el refactor del cdigo, de las pruebas y de la documentacin para minimizar la complejidad. Una de las maneras ms saludables hacia una arquitectura integrante es la refactorizacin.
62
Cuanto ms funcionalidades se aaden a las del sistema, mas se pierde del cdigo base para futuras mejoras. As como en la metodologa gil XP, la refactorizacin es mantener la sencillez, la claridad, la cantidad mnima de funcionalidades en el cdigo. . Las repeticiones en el cdigo son signo un mal diseos de cdigo y deben evitarse. El completo y automatizado proceso de construccin debe ir acompaada de una suite completa y automatizada de pruebas, tanto para desarrolladores y clientes, que tengan la misma versin, sincronizacin y semntica que el sistema actual. Al final, la integridad debe ser verificada con una prueba global, garantizando que el sistema hace lo que el cliente espera haga. Las pruebas automatizadas tambin son consideradas como parte del proceso de produccin y, por tanto, si no agregan valor deben considerarse residuos. Las pruebas automatizadas no deberan ser un objetivo, sino ms bien un medio para un fin, especficamente para la reduccin de defectos.
Respetar a las personas
Capacitar a los lderes de equipo - darles a los lderes de equipo entrenamiento, guas y espacio libre para implmenetar el pensamiento Lean en su ambiente. Mover la responsabilidad y la toma de decisiones al nivel ms bajo posible - dejar que las personas piensen y decidan por su cuenta - ellos saben mejor que nadie cmo implementar algoritmos dificiles y aplicar tecnologas de ltima generacin. Fomentar orgullo por el trabajo - fomentar la pasin y la participacin del equipo hacia lo que hacen y cmo lo hacen.
Quin debera estar involucrado en la mejora de los sistemas? Es el trabajo principal de la gerencia? O de la gente que hace el trabajo mismo? Para Henry Ford la respuesta era la gerencia: para l, la gerencia era mucho ms inteligente que los trabajadores y slo se poda confiar en ellos para decidir cmo mejorar la produccin de automviles. Ford tena muy poco respeto por el conocimiento de sus trabajadores. Hay tres problemas con este pensamiento. Primero, si bien permiti construir un proceso esttico muy bueno para construir un tipo de auto, el proceso no ofreca ninguna flexibilidad. Recordemos la frase famosa de Ford que deca que las personas podan tener un auto "de cualquier color siempre y cuando ese color fuera el negro". Segundo, la mayora de los procesos no son estticos; siempre estn cambiando. Los trabajadores de todas las lneas siempre van a comprender las condiciones locales de un entorno que cambia mucho mejor que la gerencia porque ellos tienen mejor conocimiento de lo que ocurre. Y es as cmo se cambian los procesos en la lnea de produccin. Por ltimo, Ford poda exigirle a sus trabajadores en una poca donde el valor principal de los trabajos era poder ser de sostn para la familia; hoy en da la compensacin monetaria est relativamente baja en la lista de razones por las que uno selecciona un empleo. Hoy en da esta falta de respeto se traducira en no poder retener empleados de calidad. Respetar a las personas - tanto a la gerencia como a los trabajadores - es clave para permitir flexiblidad en el proceso, mejora continua del proceso, y atraer y retener personas disponibles para trabajar. En el desarrollo de software, respetar a las personas incluye la nocin de que el equipo que hace el trabajo es responsable por el proceso que siguen. El proceso se convierte
63
en su comprensin de cmo desarrollar software mejor. Cuando esto cambia, el proceso cambia. Luego, el proceso es la base del equipo para construir software de la mejor manera que conocen, dentro de las restricciones que tienen.
Un poco mas de LEAN

La manera de pensar ofrecida Lean tiene que ser bien entendida por todos los miembros de un proyecto, antes de aplicarlo de manera concreta en una situacin de la vida real. "Pensar en grande, actos pequeos, no rpido; aprender con rapidez" - estas consignas resumir la importancia de comprender el terreno y la idoneidad de implementar los principios Lean lo largo del proceso de desarrollo de software. Slo cuando todos los principios de Lean se aplican al mismo tiempo, combinado con un fuerte "sentido comn" en relacin con el ambiente de trabajo, hay una base para el xito en el desarrollo de software. Levante la mano por favor, aquella persona que: A la cual una grfica de Gantt le haya ayudado a sacar un proyecto adelante? Aquel al cual la documentacin le haya sido de ayuda vital en darle mantenimiento al software de alguien ms? Si a un lder de proyecto al cual el asignar y el controlar el avance de microtareas a cada miembro del equipo le haya funcionado para que la gente se comprometa ms con una fecha de entrega? Proyectos, para las cules invertimos miles y miles de pesos en herramientas y cursos de CMM, PMI, MoProSoft y cuntos acrnimos ms, cual oro de tontos nos estn vendiendo; no funcionan. Me pregunto entonces Por qu lo seguimos haciendo?. Al parecer nuestras organizaciones y nosotros mismos pensamos que cuando algo no sale bien en nuestros equipos, lo que necesitamos es una capa ms de control; un proceso ms definido y detallado que obligue a los programadores, rebeldes, negligentes o apticos, a tener conformidad con el proceso mgico que resolver todos nuestros problemas. Anhelamos recetas secretas, en realidad, lo que necesitamos es tan solo un slido conjunto de principios y sentido comun. Como liberar a nuestros proyectos de balas de plata que no funcionan? Afortunados somos de tener Lean Software Development (LSD) a nuestro alcance; es libre, es gratis y simplemente funciona. Desarrollado con mucho xito por los Poppiendick a partir de las slidas experiencias de 3M y Toyota, LSD se basa en aplicar al desarrollo de software, los principios Lean que han hecho tan exitoso a Toyota y otras empresas. Se le considera parte de los Mtodos giles, pero desde mi punto de vista estn por encima de ellos, LSD nos obliga a pensar, a cuestionarnos y a encontrar nuestras propias respuestas. En enfoque alternativo a estos dos es el Diseo Emergente. El Diseo Emergente en el software es una combinacin de tres disciplinas: 1. Usar patrones de diseo para crear arquitectura de aplicaciones que son robustas y flexibles. 2. Limitar la implementacin de estos patrones a aquellas caractersticas que sean relevantes.
64
3. Escribir pruebas unitarias y de aceptacinautomatizadas antes de escribir el cdigo para mejorar el proceso de pensamiento y para crear una "red de seguridad" de pruebas. Los patrones de diseo hacen que el cdigo sea facil de cambiar, limitarse a escribir cdigo para lo que se necesita hace que el sistema se mantenga pequeo (y menos complejo), y las pruebas mejoran al diseo y hacen que el cambio sea seguro. El Diseo Emergente en su conjunto permite que se pueda posponer el compromiso para una implementacin en particular hasta que comprendamos lo que realmente se necesita. Uso del desarrollo iterativo para minimizar complejidad y retrabajo Los principales motivos de la complejidad son: Escribir cdigo que no se necesita. Tener cdigo altamente acoplado entre si. Al hacer un desarrollo iterativo evitamos escribir cdigo que no se necesita. Es decir, el desarrollo iterativo nos ayuda a descubrir lo que el cliente realmente necesita y nos ayuda a evitar construir algo que no sea de valor. El Diseo Emergente nos asiste en el desacoplamiento al permitirnos usar cdigo sin agregar complejidad innecesaria al hacerlo.
Crear conocimiento
La creacin de conomiento es una parte integrar del proceso gil. Construimos por etapas para descubrir lo que el cliente necesita. Al hacerlo de esta manera entregamos valor rpidamente y evitamos construir cosas de menos valor. Creo que el desarrollo de software es ms un proceso de descubrimiento que de construccin. En este aspecto es muy parecido al desarrollo de productos. Una definicin til del Desarrollo de Productos es que son las actividades colectivas, o sistemas, que una empresa utiliza pra convertir su tecnologa e ideas en un flujo de productos que satisfacen las necesidades de los clientes y los objetivos estratgicos de la empresa (Kennedy 2003). Ms an: Es el producto, la actividad, el proceso en el cual se embebe el software el cual es el producto real en desarrollo. El desarrollo de software es slo un subconjunto del proceso de desarrollo del producto. Entonces en un sentido muy real, podemos llamar al desarrollo de software como un subconjunto del desarrollo de productos. Y as, si queremos comprender el desarrollo de software Lean, haramos bien en descubrir lo que constituye un desarrollo de producto de excelencia (Poppendieck y Poppendieck 2006). Podemos mirar al desarrollo de producto en tres partes: 1. Descubrir lo que necesita el cliente. 2. Entender como construirlo. 3. Constuirlo.
65
En el desarrollo de software parece que gastamos la mayor parte del tiempo hablando del Paso 3; sin embargo son los dos primeros pasos los que nos terminan llevando ms tiempo. Imaginemos haber terminado un proyecto de desarrollo de software y luego, al final, perdemos todo el cdigo fuente. Si quisieramos re-crear el sistema, cunto tiempo nos llevara? Y por "re-crear" quiero decir reconstruirlo esencialmente de la misma manera, sin intentar mejorarlo... lo nico, podemos dejar afuera cosas que no son necesarias. La mayora de los desarrolladores dira que esto les tomara entre un 20%-50% del tiempo que les llev escribirlo la primera vez. Entonces, qu se estuvo haciendo el otro 50%-80% del tiempo? Estuvimos "descubriendo lo que el cliente necesita" y "entendiendo cmo construir eso".
Entregar rpidamente
Otra razn para hacer desarrollo iterativo es poder entregar valor de manera rpida al cliente. Esto permite lograr una mayor penetracin en el mercado, mayor credibilidad del negocio con el cliente, ms lealdad y otros intangibles. Sin embargo, tambin genera ganancias de manera ms temprana, permitienendo que las entregas iniciales paguen al desarrollo subsiguiente. Si bien los beneficios de entregar rpidamente son claros, es esencial que esto se haga de una manera sustentable. Construir la calidad desde adentro Para poder sostener la velocidad del desarrollo, los equipos tienen que construir la calidad tanto en el proceso como en su cdigo. Construir calidad en el proceso les permite mejorarlo al eliminar los desperdicios que crea o necesita. Una mejora sugerida es juntar al cliente, a los desarrolladores y testers y definir pruebas de aceptacin antes de escribir el cdigo. Esto mejora la conversacin alrededor de los requerimientos y tambin asiste a los desarrolladores en comprender qu funcionalidad se necesita escribir. Construir calidad en el cdigo se logra por los mtodos mencionados anteriormente para eliminar el desperdicio. La mayora de los desarrolladores gastan mucho tiempo descubriendo cmo arreglar errores que fueron reportados. Esto es por falta de pruebas automatizadas y por una pobre calidad de cdigo que lo hace dificil de entender. Optimizar el total Uno de los cambios ms grandes generados por el pensamiento Lean fue cambiar la creencia de la produccin en masa de que se necesita optimizar cada paso paso, y llegar a comprender que para incrementar la eficiencia del proceso de produccin se necesita mirar al flujo de valor desde el principio del ciclo de produccin hasta su final. En otras palabras, hacer que cada mquina funcione lo ms eficientemente posible no va a funcionar tan bien como si mirramos al flujo productivo en su totalidad. Debemos enfocarnos en el proceso completo. El problema con optimizar cada paso es que genera inventarios grandes entre los pasos. En el mundo del software, estos "inventarios" representan al trabajo parcialmente terminado (por ejemplo, requerimientos completos, pero sin disear, codificar o probar). Lean demostr que un flujo de "una pieza" (por ejemplo, enfocarse
66
en construir un tem de manera completa) es un proceso mucho ms eficiente que concentrarse en construir todas las partes ms rpido.
Criticas al L.S.D
1. Eliminar el derroche Eliminar el derroche parece simple, como no existe una mtrica considerar que es imprescindible para el desarrollo de una aplicacin a veces puede causar conflicto entre los diseadores. La burocracia y la comunicacin lenta dentro de las organizaciones grandes es un atributo intrnsico de las mismas esto quizs no se pueda lograr. 2. Ampliar el Aprendizaje No siempre se trabaja sobre el mismo dominio de problemas, idealmente seria lo optimo tener un grupo de desarrollo q se encargue de un tipo de dominio especifico pero esto casi nunca es as. Pero es probable que uno pueda obtener ciertos conocimientos generales sobre como trabajar con un mtodo. 3. Retrasar los compromisos En este punto estoy de acuerdo, en actividades como el desarrollo de S.W generar cronogramas donde se especifica que se hace de ac a seis meces es irreal. Pueden ocurrir cosas inesperadas. Las herramientas no son adecuadas, La nueva tecnologa no trabaja bien, ETC. 4. Liberar Rpido De acuerdo, generar cosas que funcionen rpidamente es mucho mejor que el desarrollo de todo el sistema en paralelo. 5. Facultar al equipo La organizacin del grupo de personas es todo un tema en si mismo. El dominio del problema debe de ser quien determina el tipo de organizacin adecuada. 6. Construir Integridad Intriseca Nunca se prueba o inspecciones estn de ms. Cuando un producto mas se prueba este se va haciendo mas estable y mas adecuado a lo que el usuario quiere. Un ejemplo: El Warcraft III, lanzado en el julio del 2002 sigue siendo mantenido y pacheado hasta la fecha por la empresa Blizzar. 7. Pensar en el todo Estoy de acuerdo no se puede tener alguien indispensable. Lo indispensable debe ser el mtodo de trabajo no los componentes humanos. Por q si uno de resfria estamos en problemas. Finalmente creo q este mtodo de trabajo nos da un enfoque realista de cmo se debe de trabajar, en lugar de desgastarse produciendo documentos y modelos que la verdad segn mi experiencia solo son un derroche de energa. Por que por mas detallados y lindos q sean los documentos, si el programa no es lo que el cliente espera, nos lo hara saber rpidamente recurriendo a otra empresa.
67
Agilidad, Caos y Complejidad

Teora del caos es la denominacin popular de la rama de las matemticas, la fsica y otras ciencias que trata ciertos tipos de sistemas dinmicos muy sensibles a las variaciones en las condiciones iniciales. Pequeas variaciones en dichas condiciones iniciales, pueden implicar grandes diferencias en el comportamiento futuro; complicando la prediccin a largo plazo. Esto sucede aunque estos sistemas son deterministas, es decir; su comportamiento est completamente determinado por sus condiciones iniciales. Los sistemas dinmicos se pueden clasificar bsicamente en: Estables. Un sistema estable tiende a lo largo del tiempo a un punto, u rbita, segn su dimensin (atractor o sumidero). Inestables. Un sistema inestable se escapa de los atractores Caticos. Y un sistema catico manifiesta los dos comportamientos.Por un lado, existe un atractor por el que el sistema se ve atrado, pero a la vez, hay "fuerzas" que lo alejan de ste. De esa manera, el sistema permanece confinado en una zona de su espacio de estados, pero sin tender a un atractor fijo
Las teoras de la complejidad tratan de con diversas clases de procesos, fenmenos y sistemas: autmatas celulares, redes booleanas aleatorias, redes neuronales, programacin evolutiva, memtica, dinmica no lineal, criticalidad auto-organizada, modelos basados en agentes autnomos, metaheursticas, atractores extraos, gramticas recursivas, series de Fibonacci, orden emergente, fractales. La cuestin merece tratarse en un estudio especfico; aqu slo brindaremos un puado de indicios sobre esta peculiar convergencia. Algunos de los idelogos de Scrum se inspiran en conceptos tales como filo del caos y control de procesos caticos, tal como se los describe en el conocido libro Chaos de James Gleick. Tambin afirman que Microsoft implementa en sus prcticas de desarrollo una estrategia de caos controlado, aunque no proporcionan mucho detalle a su razonamiento. Los autores tambin se refieren al modelo de L. B. S. Racoon referido al caos y al ciclo de vida catico. En MSF 3.0 hay, como se ha visto, un comentario sobre la naturaleza cardica de los sistemas, en el sentido del concepto acuado por Dee Hock, quien llevara a la prctica este concepto en la gestin de su propia compaa, Visa. Hock sostiene que la ciencia de la complejidad, ligada a la comprensin de los sistemas autocatalticos, no lineales, complejos y adaptativos, habr de ser la ciencia ms importante del nuevo siglo. La visin cardica de Hock (cuyas ideas sobre no linealidad tienen ms de un punto en comn con las de Fred Brooks) ha inspirado un movimiento cardico de amplios alcances que va mucho ms all de las metodologas de desarrollo de software. El modelo de gestin Liderazgo-Colaboracin de Jim Highsmith, por ejemplo, se funda en las ideas de Hock. En Scrum se habla de caos permanentemente. Haciendo honor al nombre, el sitio de Scrum est en http://www.controlchaos.com. La descripcin de Craig Larman sobre Scrum incluye como bibliografa de referencia para comprender procesos adaptativos y autoorganizacin los dos textos clsicos de John
68
Holland, el padre del algoritmo gentico, quien tambin ha ejercido influencia sobre Highsmith, como ya se ha visto. Jeff Sutherland ha sealado la analoga entre los saltos y discontinuidades de los procesos de desarrollo giles y el equilibrio puntuado de los procesos evolutivos complejos. En las pginas de su sitio empresarial y en su bibliografa, Jeff DeLuca establece la estrecha relacin entre las premisas de FDD y las teoras del caos determinista y de la complejidad, vinculndolas con el pensamiento no lineal de Fred Brooks y con la concepcin del control de caos de Jim Highsmith.
En su presentacin de Adaptive Software Development, Highsmith afirma que su prctica se basa en estar en equilibrio en el filo del caos: proporcionar suficiente gua para evitar caer en el caos, pero no demasiada, para no suprimir la emergencia y la creatividad. Este modelo basado en la analoga entre empresas/equipos/proyectos y sistemas adaptativos complejos, es, por mucho, el ms vinculado a las nuevas ciencias de la complejidad y el caos [Hig00a]. Un ejemplo de estos sistemas podra ser una bandada de pjaros que se sincroniza sin que exista un lder que ejerza control y determine su direccin; cada pjaro sigue reglas simples y locales, pero en la macro-escala la bandada exhibe orden y un claro comportamiento colectivo emergente. Estas ideas han inspirado un modelo de gestin basado en cooperacin y competencia. Una visin semejante se presenta en el modelo de Mary y Tom Poppendieck de Lean Development, donde se considera el comportamiento de sistemas sociales de insectos como una manifestacin de trabajo en equipo, soluciones adaptativas y capacidades emergentes. LD promueve un diseo semejante a los de XP y Scrum, enfatizando sus aspectos evolutivos. En una entrevista a Kent Beck y Martin Fowler, el primero afirm que mientras SEI se encuentra en el campo modernista, XP es ms bien posmoderno. Sus races filosficas se encuentran en la teora de los sistemas complejos y sus capacidades se generan a travs de procesos emergentes. Es significativo que este juicio haya sido expresado por el creador de la Programacin Extrema.
Anti-agilidad: La crtica de los Mtodos giles A pesar de que nadie en sus cabales se opondra a que se lo considere gil, adaptable y sensible a los requerimientos del cliente, es natural que se generara oposicin a los que en ocasiones la reaccin frente a ellos adoptara una fuerte actitud combativa. Si los giles han sido implacables en su caricatura de las metodologas rigurosas, los adversarios que se han ganado no se han quedado atrs en sus rplicas. En esta contienda hay algunas observaciones de carcter tcnico, pero la irona prevalece. Lo que sigue es apenas una muestra. Uno de los ataques ms duros y tempranos proviene de una carta de Steven Rakitin a la revista Computer, bajo la rbrica El Manifiesto genera cinismo. Refirindose a la estructura opositiva del Manifiesto, Rakitin expresa que en su experiencia, los elementos de la derecha (vinculados a la mentalidad planificadora) son esenciales, mientras que los de la izquierda slo sirven como excusas para que los hackers escupan cdigo irresponsablemente sin ningn cuidado por la disciplina de ingeniera. As como hay una lectura literal y una estrecha del canon de CMM, Rakitin practica una
69
interpretacin hacker de propuestas de valor tales como responder a cambio en vez de seguir un plan y encuentra que es un generador de caos. La interpretacin hacker de ese mandamiento sera algo as como: Genial! Ahora tenemos una razn para evitar la planificacin y codificar como nos d la gana. Ms tarde, un par de libros de buena venta, Questioning Extreme Programming de Pete McBreen y Extreme Programming Refactored: The case against XP de Matt Stephens y Doug Rosenberg promovieron algunas dudas sobre XP pero no llegaron a constituirse como impugnaciones convincentes por su uso de evidencia circunstancial, su estilo redundante, su tono socarrn y su falta de mtodo argumentativo. Que a ltimo momento se redima a XP sugiriendo mejoras y refactorizaciones no ayuda a la causa de un dictamen anunciado desde sus ttulos. Mucho ms fundamentado es el estudio puramente crtico de Edward Berard, quien seala un buen nmero de falacias y medias verdades en el discurso gil pero no logra, por alguna razn que se nos escapa, que su crtica levante vuelo. Gerold Keefer, de AVOCA GmbH, ha publicado ya dos versiones de un estudio titulado (con guio a los expertos que reconozcan la alusin a Dijkstra) Extreme Programming considerado daino para el desarrollo confiable de software. Algunos de los hechos tenidos en cuenta son que no slo el primero, sino tambin el segundo proyecto de referencia de XP fueron cancelados; que las cifras que proporciona Beck sobre el costo del cambio metodolgico no son tomadas en serio ni siquiera en el seno de la comunidad XP; que resultados de investigaciones en curso cuestionan la viabilidad de la programacin orientada por pruebas4, cuyo proceso puede consumir hasta el 30% o 40% de los recursos de un proyecto; y que reportes de proyectos de gran envergadura demuestran su insuperable problema de escalabilidad, que se manifiesta antes de lo que se cree. Otros argumentos de Keefer apuntan a los altos costos y magros resultados de la programacin en pares; a las malas prcticas resultantes de la negacin a documentar; al retorno a la programacin de garage y a la idea de que el cdigo se documenta a s mismo cuestionadas por Brooks hace treinta aos; a la escasa verosimilitud de las historias de xito de C3 y VCAPS, etctera. Por aadidura, XP no se expide sobre proyectos con alcances, precios y fechas fijas, ni sobre requerimientos no funcionales como performance y seguridad, ni sobre ambientes de desarrollo fsicamente distribuidos, ni (a pesar de su insistencia en reutilizacin y patrones) sobre integracin de componentes listos para usar (COTS). A Keefer, por ltimo, no le persuade la premisa de hacer la cosa ms simple que pueda funcionar, sino que prefiere la postura de Einstein: Que sea lo ms simple posible, pero no ms simple que eso. Inesperadamente, el promotor de RAD SteveMcConnell se ha opuesto con vehemencia a las ideas ms radicales del movimiento gil. Se ha manifestado contrario tanto a las estrategias tcnicas como a las tcticas promocionales; dice McConnell: Esta industria tiene una larga historia en cuanto a pegarse a cuanta moda sale, pero luego se ncuentra, cuando los bombos y platillos se enfran, que estas tendencias no logran el xito que sus evangelistas prometieron. Los cargos de McConnell contra XP son numerosos. En primer lugar, diferentes proyectos requieren distintos procesos; no se puede escribir software de avinica para un contrato de defensa de la misma manera en que se escribe un sistema de inventario para un negocio de alquiler de videos. Adems, las reglas de XP son excesivamente rgidas; casi nadie aplica las 12 en su totalidad, y pocas de ellas son nuevas: Tom Gilb propona lineamientos similares muchos aos atrs. Dadas las premisas desaliadas y las falsas publicidades, McConnell expresa que el fenmeno parece un caso de hipnosis colectiva [Baer03].
70
En diversas presentaciones pblicas y en particular en SD West 2004, McConnell ha considerado la programacin sin diseo previo, el uso atropellado de XP, la programacin automtica y la costumbre de llamar gil a cualquier prctica como algunas de las peores ideas en construccin de software del ao 2000. Un miembro de Rational, John Smith, opina que la terminologa de XP encubre una complejidad no reconocida; mientras las palabras artefacto y producto de trabajo no figuran en los ndices de sus libros cannicos, Smith cuenta ms de 30 artefactos encubiertos: Historias, Restricciones, Tareas, Tareas tcnicas, Pruebas de aceptacin, Cdigo de software, Entregas, Metforas, Diseos, Documentos de diseo, Estndares de codificacin, Unidades de prueba, Espacio de trabajo, Plan de entrega, Plan de iteracin, Reportes y notas, Plan general y presupuesto, Reportes de progreso, Estimaciones de historias, Estimaciones de tareas, Defectos, Documentacin adicional, Datos de prueba, Herramientas de prueba, Herramientas de gestin de cdigo, Resultados de pruebas, Spikes (soluciones), Registros de tiempo de trabajo, Datos mtricos, Resultados de seguimiento. La lista, dice Smith, es indicativa, no exhaustiva. En un proyecto pequeo, RUP demanda menos que eso. Al no tratar sus artefactos como tales, XP hace difcil operarlos de una manera disciplinada y pasa por ser ms ligero de lo que en realidad es. Hay otras dificultades tambin; a diferencia de RUP, en XP las actividades no estn ni identificadas ni descriptas. Las cosas que se hacen estn tratadas anecdticamente, con diversos grados de prescripcin y detalle. Finalmente hay prcticas en XP que decididamente escalan muy mal, como la refactorizacin, la propiedad colectiva del cdigo, las metforas en lugar de una arquitectura tangible y las entregas rpidas, que no tienen en cuenta siquiera cuestiones elementales de la logstica de despliegue. Smith afirma no estar formulando una crtica, pero pone en duda incluso, por su falta de escalabilidad, que XP est haciendo honor a su nombre. Por otra parte, en toda la industria se sabe que la refactorizacin en general no escala muy bien. Eso se manifiesta sobre todo en proyectos grandes en los que hay exigencias no funcionales que son clsicas quebradoras de arquitectura, como ser procedimientos ad hoc para resolver problemas de performance, seguridad o tolerancia a fallas. En estos casos, como dice Barry Boehm [Boe02a], ninguna dosis de refactorizacin ser capaz de armar a Humpty Dumpty nuevamente.
71
CONCLUSIN
La mayora de los mtodos de desarrollo de S.W proclaman ser EL MTODO! En mi opinin eso no es asi. Tomemos por ejemplo UML a pesar de su status de estndar ampliamente reconocido y utilizado, UML siempre ha sido muy criticado por su carencia de una semntica precisa, lo que ha dado lugar a que la interpretacin de un modelo UML no pueda ser objetiva. Otro problema de UML es que no se presta con facilidad al diseo de sistemas distribuidos. En tales sistemas cobran importancia factores como transmisin, serializacin, persistencia, etc. UML no cuenta con maneras de describir tales factores. No se puede, por ejemplo, usar UML para sealar que un objeto es persistente o remoto, o que existe en un servidor que corre continuamente y que es compartido entre varias instancias de ejecucin del sistema analizado. Ademas de introducion otro nivel de abstraccin que generalmente complica mas las cosas. Como el desarrrollo de S.W es una tcnica nueva, el tiempo ira decantando cuales estrategias son buenas para determinada rea de desarrollo y cuales no. No existe un sistema que abarque todos los posibles reas, pensar de otra forma es un error que puede costar caro.
Referencias bibliogrficas
http://es.wikipedia.org/wiki/Lean_software_development http://www.netobjectives.com/blogs/lean-agile-software-development-chapter3-bigpicture http://es.wikipedia.org/wiki/Teoria_del_caos http://epistemologic.com/category/process/lean-software/ http://tech.groups.yahoo.com/group/leanprogramming/ http://tecnonirvana.org/blog/2007/07/15/libera-tus-proyectos-con-lean-softwaredevelopment/ http://albertolacalle.com/hci/lean.htm Alianza gil, http://www.agilealliance.org Manifiesto para el Desarrollo de Software gil, http://www.agilemanifesto.org Ron Jeffries http://www.xProgramming.com Don Wells http://www.extremeProgramming.org http://agilesoftwaredevelopment.com/leanprinciples Larman, Craig. Agile & Iterative Development: A Managers Guide, Addison-Wesley. Poppendieck, Mary & Tom Poppendieck. Lean Software Development: An Agile Toolkit. Addison-Wesley. Schwaber, Ken, & Mike Beedle. Agile Software Development with Scrum. Prentice Hall.
72

Tesis Final

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tesis Final

Cargado por

Copyright:

Formatos disponibles

DESARROLLO AGIL Y LEAN SOFTWARE DEVELOPMENT

German E. Schmidt LU: 41066

German E. Schmidt LU: 41066

German E. Schmidt LU: 41066

German E. Schmidt LU: 41066

Manifiesto de desarrollo gil de software

Esto es aunque valoramos los elementos derecha valoramos ms los de la izquierda.

German E. Schmidt LU: 41066

German E. Schmidt LU: 41066

German E. Schmidt LU: 41066

Caractersticas del Software.

German E. Schmidt LU: 41066

German E. Schmidt LU: 41066

El desarrollo tradicional del software

German E. Schmidt LU: 41066

Separacin de Diseo y Construccin

German E. Schmidt LU: 41066

German E. Schmidt LU: 41066

La imprevisibilidad de los Requisitos

German E. Schmidt LU: 41066

German E. Schmidt LU: 41066

Estadstica realizada sobre 8 proyectos de Software Estadounidenses.

rea: Sistemas de Defensa en Tiempo Real

Costo de los Cambios en la Construccin de SW

costo del cambio

suposicin metodologa gil tiempo

German E. Schmidt LU: 41066

Los problemas y errores comunes de los mtodos no giles

German E. Schmidt LU: 41066

German E. Schmidt LU: 41066

German E. Schmidt LU: 41066

German E. Schmidt LU: 41066

German E. Schmidt LU: 41066

Caractersticas del desarrollo gil.

German E. Schmidt LU: 41066

Beneficios de usar desarrollo gil

Desarrollo guiado por valor

Mejor manejo de riesgos e incertidumbre

German E. Schmidt LU: 41066

Aplicabilidad del desarrollo gil

German E. Schmidt LU: 41066

Metodologas giles de Desarrollo

German E. Schmidt LU: 41066

X.P Extreme Programming

Las Historias de Usuario

German E. Schmidt LU: 41066

Gestor: Es el vnculo entre clientes y programadores, ayuda a que el equipo trabaje

German E. Schmidt LU: 41066

German E. Schmidt LU: 41066

German E. Schmidt LU: 41066

6. Muerte del Proyecto

German E. Schmidt LU: 41066

German E. Schmidt LU: 41066

Propiedad colectiva del cdigo

40 horas por semana

German E. Schmidt LU: 41066

Algunas de las crticas de Xp

German E. Schmidt LU: 41066

German E. Schmidt LU: 41066

German E. Schmidt LU: 41066

German E. Schmidt LU: 41066

German E. Schmidt LU: 41066

German E. Schmidt LU: 41066

German E. Schmidt LU: 41066