Tesis Final

German E. Schmidt LU: 41066 1

DESARROLLO AGIL Y LEAN SOFTWARE DEVELOPMENT

TESIS

GERMAN E. SCHMIDT L.U: 41066


ÍNDICE INTRODUCCIÓN........................................................................................................................................ 4

MANIFIESTO DE DESARROLLO ÁGIL DE SOFTWARE.......... ........................................................ 5

PRINCIPIOS ÁGILES ................................................................................................................................ 6

CARACTERÍSTICAS DEL SOFTWARE................................................................................................. 8

EL DESARROLLO TRADICIONAL DEL SOFTWARE ............. ........................................................ 10

SEPARACIÓN DE DISEÑO Y CONSTRUCCIÓN ............................................................................... 11

LA IMPREVISIBILIDAD DE LOS REQUISITOS.............. .................................................................. 13

COSTO DE LOS CAMBIOS EN LA CONSTRUCCIÓN DE SW........................................................................... 15

LOS PROBLEMAS Y ERRORES COMUNES DE LOS MÉTODOS NO ÁGILES........................... 16

1. PERSONAS............................................................................................................................................. 16 2. PROCESO......................................................................................................................................... 19

CARACTERÍSTICAS 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 METODOLOGÍAS Á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. Exploración..................................................................................................................................... 27 2. Planificación de la Entrega ............................................................................................................ 27 3. Iteraciones ...................................................................................................................................... 28 4. Producción...................................................................................................................................... 28 5. Mantenimiento ................................................................................................................................ 28 6. Muerte del Proyecto........................................................................................................................ 29

EL JUEGO DE LA PLANIFICACIÓN............................................................................................................... 29 Entregas pequeñas.............................................................................................................................. 29 Metáfora.............................................................................................................................................. 29 Pruebas ............................................................................................................................................... 30 Refactorización (Refactoring)............................................................................................................. 30 Programación en parejas.................................................................................................................... 30 Propiedad colectiva del código........................................................................................................... 31 Integración continúa........................................................................................................................... 31 40 horas por semana........................................................................................................................... 31 Cliente in-situ...................................................................................................................................... 31 Estándares de programación .............................................................................................................. 32


ALGUNAS DE LAS CRÍTICAS DE XP............................................................................................................ 32

SCRUM ....................................................................................................................................................... 33

ROLES EN SCRUM ..................................................................................................................................... 34 REUNIONES EN SCRUM ............................................................................................................................. 35 SCRUM DE SCRUM .................................................................................................................................... 35 DOCUMENTOS.......................................................................................................................................... 36

CRYSTAL................................................................................................................................................... 38

CARACTERÍSTICAS.................................................................................................................................... 39 EL CÓDIGO GENÉTICO.............................................................................................................................. 42 CONCLUSIÓN............................................................................................................................................ 43

DYNAMIC SYSTEMS DEVELOPMENT METHOD (DSDM) .......... .................................................. 44

FASES EN LA CONSTRUCCIÓN DE UN SISTEMA........................................................................................... 45

FEATURE DRIVEN DEVELOPMENT (F.D.D) .................................................................................... 48

ROLES ...................................................................................................................................................... 50 CONCLUSIÓN............................................................................................................................................ 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 más tarde posible................................................................................................................ 59 Reaccionar tan rápido 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 rápidamente......................................................................................................................... 66

CRITICAS AL L.S.D................................................................................................................................... 67

AGILIDAD, CAOS Y COMPLEJIDAD .................................................................................................. 68

CONCLUSIÓN........................................................................................................................................... 72

REFERENCIAS BIBLIOGRÁFICAS...................................................................................................... 72


INTRODUCCIÓN El desarrollo de software no es una tarea fácil. Prueba de ello es que existen numerosas propuestas metodológicas que inciden en distintas dimensiones del proceso de desarrollo. Por una parte tenemos aquellas propuestas más 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 usarán. Estas propuestas han demostrado ser efectivas y necesarias en un gran número de proyectos, pero también han presentado problemas en otros muchos. Una posible mejora es incluir en los procesos de desarrollo más actividades, más artefactos y más restricciones, basándose en los puntos débiles detectados. Sin embargo, el resultado final sería un proceso de desarrollo más complejo que puede incluso limitar la propia habilidad del equipo para llevar a cabo el proyecto. Otra aproximación es centrarse en otras dimensiones, como por ejemplo el factor humano o el producto software. Esta es la filosofía de las metodologías ágiles, las cuales dan mayor valor al individuo, a la colaboración 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 drásticamente los tiempos de desarrollo pero manteniendo una alta calidad. Las metodologías ágiles están 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 metodologías 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 también se ve muy seguido que los proyectos sufren retrasos y no se obtienen los resultados esperados pese el talento y esfuerzo puesto en acción 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 más 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 público en buscar nuevas y mejores formas de desarrollar programas poniendo énfasis en las personas y sus interacciones, la colaboración 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 través este trabajo hemos aprendido a valorar:

• individuos en interacciones sobre procesos y herram ientas. 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 más fácil 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 más recursos que los estrictamente necesarios también puede afectar negativamente. En resumen, es más 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 automáticamente. Es mejor crear el equipo y que éste configure su propio entorno de desarrollo en base a sus necesidades.

• software funcionando sobre documentación extensiva. Aunque se parte de la base de que el software sin documentación es un desastre, la regla a seguir es “no producir documentos a menos que sean necesarios de forma inmediata para tomar un decisión 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 más le van a servir para ponerse al día son: el propio código y la interacción con el equipo.

• Colaboración con el cliente sobre de negociación co ntractual. Las características particulares del desarrollo de software hace que muchos proyectos hayan fracasado por intentar cumplir unos plazos y unos costes preestablecidos al inicio del mismo, según los requisitos que el cliente manifestaba en ese momento. Por ello, se propone que exista una interacción constante entre el cliente y el equipo de desarrollo. Esta colaboración 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 tecnología, en el equipo, etc.) determina también el éxito o fracaso del mismo. Por lo tanto, la planificación 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 más abiertas para unos pocos meses.

Esto es aunque valoramos los elementos derecha valoramos más los de la izquierda.


PRINCIPIOS ÁGILES Los valores anteriores inspiran los doce principios del manifiesto. Estos principios son las características que diferencian un proceso ágil de uno tradicional. Los dos primeros son generales y resumen gran parte del espíritu á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 más, a la vez que logran una mayor satisfacción del cliente. Este principio implica además que la estructura del software debe ser flexible para poder incorporar los cambios sin demasiado coste añadido. 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 documentación de análisis o de diseño.

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 interacción 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 demás (proceso, entorno, gestión, etc.) queda en segundo plano. Si cualquiera de ellos tiene un efecto negativo sobre los individuos debe ser cambiado.

6. El diálogo cara a cara es el método más eficiente y efectivo para comunicar

información dentro de un equipo de desarrollo. Los miembros de equipo deben hablar entre ellos, éste es el principal modo de comunicación. 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 documentación generada o la fase en la que se encuentre, sino por el código generado y en funcionamiento. Por ejemplo, un proyecto se encuentra al 50% si el 50% de los requisitos ya están en funcionamiento.


8. Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberían ser capaces de mantener una paz constante. No se trata de desarrollar lo más rápido posible, sino de mantener el ritmo de desarrollo durante toda la duración del proyecto, asegurando en todo momento que la calidad de lo producido es máxima.

Finalmente los últimos principios están más directamente relacionados con el equipo de desarrollo, en cuanto metas a seguir y organización del mismo.

9. La atención continua a la calidad técnica y al buen diseño mejora la agilidad. Producir código claro y robusto es la clave para avanzar más rápidamente en el proyecto. La atención continua a la calidad técnica y al buen diseño mejora la agilidad. Producir código claro y robusto es la clave para avanzar más rápidamente en el proyecto.

10. La simplicidad es esencial. Tomar los caminos más simples que sean consistentes con los objetivos perseguidos. Si el código producido es simple y de alta calidad será más sencillo adaptarlo a los cambios que puedan surgir.

11. Las mejores arquitecturas, requisitos y diseños 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 cómo llegar a ser más efectivo, y según esto ajusta su comportamiento. Puesto que el entorno está cambiando continuamente, el equipo también debe ajustarse al nuevo escenario de forma continua. Puede cambiar su organización, sus reglas, sus convenciones, sus relaciones, etc., para seguir siendo ágil.


Características 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 están formados por miles de funciones con

interfaces complejas entre ellas. • Es excesivamente maleable. El Software se desarrolla, no se fabrica. • En cualquier sistema de producción podemos observar dos fases la de desarrollo y

la de fabricación. � El desarrollo es lento y costoso. � La fabricación en serie y con costes estables.

• Con el Software ocurre lo mismo pero ... � Muchas aplicaciones se desarrollan a medida, sin usar componentes

existentes. � La fabricación no se considera tal.

El software es excesivamente maleable. • Todo el mundo exige que se realicen cambios sobre el Software como respuesta a

pequeños cambios del entorno. • Además no es fácil comprender su comportamiento, según 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 utilización que se hace de el. • El tratamiento comercial que tiene. • En relación con la funcionalidad que aporta a la maquina. • Exigencia en eficiencia y los factores críticos que se le exigen. Según la utilización del software: • De Gestión: Se trata del software que da soporte a los procesos comerciales y

manejo de información que tienen por objetivo permitir a las gestiones una mejor gestión.

• Producción y control de procesos: Es el software que da soporte a los procesos productivos y conducentes a desarrollar las actividades propias de cada negocio.

• Robótica: Software que se centra en controlar y automatizar el comportamiento de engendros mecánicos que colaboran con los seres humanos en diversos campos, desde la ortopedia hasta la exploración de otros planetas.

• De ingeniería y Científico: Da soporte a los procesos creativos y de diseño de las personas, se caracteriza por cálculos matemáticos complejos. Ejemplo de ello son las herramientas CAD o el soporte a seguimiento de acontecimientos en el espacio.

• Ofimático: Software que permite a las personas utilizar los ordenadores en las tareas que habitualmente se realizan en oficinas.


• De Formación y divulgación: Software que tiene por objetivo el transferir conocimientos al ser humano.

• Domótico: Software que se utiliza para controlar el hábitat del ser humano, a pequeña escala. Va desde las alarmas hasta el control de temperaturas de un hogar.

• Ocio y Juegos: En esta categoría 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 mínimo, y el diseño del sistema se hace con muchas decisiones a corto plazo. Esto realmente funciona muy bien si el sistema es pequeño, pero conforme el sistema crece llega a ser cada vez más difícil agregar nuevos aspectos al mismo. Además los errores llegan a ser cada vez más frecuentes y más difíciles de encontrar. La seña típica de tal sistema es una larga fase de pruebas después 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 metodologías imponen un proceso disciplinado sobre el desarrollo de software con el fin de hacerlo más predecible y eficiente. Lo hacen desarrollando un proceso detallado con un fuerte énfasis en planificar inspirado por otras disciplinas de la ingeniería. Las metodologías ingenieriles han estado presentes durante mucho tiempo. No se han distinguido precisamente por ser muy exitosas. Aún menos por su popularidad. La crítica más frecuente a estas metodologías es que son burocráticas. Hay tanto que hacer para seguir la metodología que el ritmo entero del desarrollo se retarda. La forma tradicional de desarrollar programas se basa en procesos redefinidos con una documentación muy precisa y extensa, una planificación inicial súper detallada que debe seguirse estrictamente. Esta forma de trabajar surgió naturalmente hace unos 50 años como una adaptación manejo de proyectos de ingeniería, que no lo más parecido a desarrollar programas que se conocía en ese momento, y funcionó razonablemente bien en el comienzo. También hay que tener en cuenta que en esa época las computadoras eran grandes y extremadamente caras, la mayor parte la inversión informática se hallaba en los equipos y por este motivo los programas se hacían a medida para que las máquinas adquiridas puedan realizar unas tareas muy concretas. Los proyectos de desarrollo actuales incluyen desafíos muy diferentes a los que presentan a construir puentes y casas por lo sorprende que los métodos tradicionales (de tipo ingenieril) esta en crisis. Tradicionalmente los proyectos se dividen en etapas bien definidas:

• Análisis de factibilidad. • Análisis de requerimientos. • Diseño • Programación. • Testeo.

Generalmente se trata de que haya retroalimentación 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 diseño. Sin embargo, esta forma de generar programas genera serios inconvenientes, debido a que el comienzo del proyecto, es cuando menos se conocen las características 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 duración del mismo. Se argumenta a favor de esto, que cuenta con profesionales que conozcan el área de aplicación del problema, solución esta dificultad.


La información 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 método tradicional no cumple los objetivos, no se termina tiempo, y resulta mucho más 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 características específicas que nadie creado aún, lo cual es muy cierto para la mayoría los proyectos de software. Porque en caso contrario, la organización 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 "métodos ágiles" de desarrollar programas y manejo de proyectos en general, cuyas características serán enunciadas a continuación.

Separación de Diseño y Construcción La inspiración usual para las metodologías han sido disciplinas como las ingenierías civil o mecánica. 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 diseño, 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 compañía diferente, para ser construidos. Se supone que el proceso de la construcción seguirá los dibujos. En la práctica los constructores se encuentran con algunos problemas, pero éstos son normalmente poco importantes.Como los dibujos especifican las piezas y cómo deben unirse, actúan como los fundamentos de un plan de construcción 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 construcción razonablemente predecibles. También dice en detalle cómo deben hacer su trabajo las personas que participan en la construcción. Esto permite que la construcción requiera menos pericia intelectual, aunque se necesita a menudo mucha habilidad manual.

Así que lo que vemos aquí son dos actividades fundamentalmente diferentes. El diseño, qué es difícil de predecir y requiere personal caro y creativo, y la construcción que es más fácil de predecir. Una vez que tenemos el diseño, podemos planear la construcción. Una vez que tenemos el plan de construcción, podemos ocuparnos de la construcción de una manera más predecible. En ingeniería civil la construcción es mucho más costosa y tardada que el diseño y la planeación.

Así el acercamiento de muchas metodologías es: queremos un plan de trabajo predecible que pueda usar gente del más bajo nivel. Para hacerlo debemos separar el plan de la construcción. Por consiguiente necesitamos entender cómo hacer el diseño de software de modo que la construcción pueda ser sencilla una vez que el plan esté hecho.

¿Qué forma toma este plan? Para muchos, éste es el papel de notaciones de diseño como el UML. Si podemos hacer todas las decisiones significativas usando UML, podemos armar un plan de construcción y entonces podemos dar planes a los programadores como una actividad de construcción.


Pero aquí surgen preguntas cruciales. ¿Es posible armar un plan que sea capaz de convertir el código en una actividad de construcción predecible? Y en tal caso, ¿es la construcción suficientemente grande en costo y tiempo para hacer valer la pena este enfoque?

Todo esto trae a la mente más preguntas. La primera es la cuestión de cuán difícil es conseguir un diseño UML en un estado que pueda entregarse a los programadores. El problema con un diseño tipo UML es que puede parecer muy bueno en el papel, pero resultar seriamente fallido a la hora de la programación. Los modelos que los ingenieros civiles usan está basado en muchos años de práctica guardados en códigos ingenieriles. Además los problemas importantes, como el modo en que juegan las fuerzas, son dóciles al análisis matemático. La única verificación que podemos hacer con los diagramas UML es la revisión cuidadosa. Mientras esto es útil trae errores al diseño que sólo se descubren durante la codificación y pruebas. Incluso los diseñadores experimentados, se sorprenden a menudo cuando convierten dichos diseños 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 construcción. En software la cantidad de tiempo gastada codificando es mucho, mucho menor. Steve McConnell sugiere que para un proyecto grande, sólo 15% del proyecto son código y pruebas unitarias, una inversión casi perfecta de las proporciones de la construcción del puente. Aun cuando se consideren las pruebas parte de la construcción, el plan es todavía 50% del total. Esto genera una pregunta importante sobre la naturaleza del diseño en software comparado con su papel en otras ramas de la ingeniería.

Esta clase de preguntas llevaron a Jack Reeves a sugerir que de hecho el código fuente es un documento de diseño y que la fase de construcción está en realidad en la compilación y el ligado. De hecho cualquier cosa que pueda tratarse como construcción puede y debe automatizarse.

Estas ideas llevan a algunas conclusiones importantes:

• En software la construcción es tan barata que es casi gratis.

• En software todo el esfuerzo está en el diseño, de modo que requiere de personas creativas y talentosas.

• Los procesos creativos no se planean fácilmente, de modo que la previsibilidad bien puede ser una meta imposible.

• Debemos ser muy cautos al usar la metáfora de la ingeniería tradicional para construir software. Es un tipo diferente de actividad y por ende requiere un proceso diferente.


La imprevisibilidad de los Requisitos Hay un dicho que se oye en cada proyecto problemático. Los desarrolladores vienen y me dicen "el problema con este proyecto es que los requisitos cambian todo el tiempo". Lo sorprendente de esta situación es que sorprenda a cualquiera. En el negocio de construcción 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 ingeniería de requisitos. La idea detrás de la ingeniería 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 después de la firma.

Un problema con esto es que simplemente tratar de entender las opciones para los requisitos es duro. Es aun más duro porque la organización del desarrollo normalmente no proporciona la información del costo en los requisitos. El cliente termina solicitando algo que el vendedor no puede cotizar con exactitud. Sin una buena idea del costo, ¿cómo puede el cliente decidir si quiere pagar por ese pedido?

La estimación es difícil por muchas razones. En parte porque el desarrollo de software es una actividad de diseño, difícil de planear y costear. En parte porque los materiales básicos cambian rápidamente. En parte por lo mucho que depende de los individuos involucrados, y los individuos son difíciles de predecir y cuantificar.

La naturaleza intangible del software también afecta. Es muy difícil saber qué valor aporta un rasgo de software hasta que se usa en realidad. Sólo cuando se usa realmente una versión temprana de algún software se empieza a entender cuáles rasgos son valiosos y cuáles no.

Esto lleva al punto irónico de que es de esperarse que los requisitos sean cambiables. Después de todo se supone que el software es "suave". Así no sólo son cambiables los requisitos, sino que deben de serlo. Toma mucha energía 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 fácil de cambiar.

Pero aun cuando se pudiera controlar todo esto y realmente se pudiera conseguir un conjunto exacto y estable de requisitos, probablemente aún no estamos a salvo. En la economía de hoy las fuerzas de negocios fundamentales cambian el valor de los rasgos de software demasiado rápidamente. El que podría ser un buen conjunto de requisitos ahora, no será tan bueno en seis meses. Aún 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.


¿Es Imposible la Previsibilidad? En general, no. Hay algunos desarrollos de software dónde la previsibilidad es posible, sin embargo no se cree que el software comercial encaje en esa categoría. 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 metodologías no es buena en identificar condiciones límite: los lugares donde la metodología pasa de apropiada en inapropiada. La mayoría de los metodologistas quieren que sus metodologías sean usadas por todos, de modo que no entienden ni publican sus condiciones límite. Esto lleva a la gente a usar una metodología en malas circunstancias, como usar una metodología predictiva en una situación imprevisible.

Hay una tentación 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 situación cuando el plan se cae en pedazos. Usted acaba viendo el plan y la realidad flotando aparte. Durante algún tiempo usted podrá pretender que el plan es válido. Pero en algún punto la deriva es demasiada y el plan se cae en pedazos. Normalmente la caída es dolorosa.

Así si usted está en una situación impredecible no puede usar una metodología predictiva. Ése es un golpe duro. Significa que tantos modelos para controlar proyectos, y muchos de los modelos para llevar la relación con el cliente, ya no son ciertos. Los beneficios de la previsibilidad son tan grandes, que es difícil dejarlos ir. Como en tantos problemas la parte más difícil está simplemente en comprender que el problema existe.

De cualquier modo dejar ir la previsibilidad no significa que hay que volver al caos ingobernable. Más bien hace falta un proceso que pueda dar control sobre la imprevisibilidad. De eso se trata la adaptabilidad.


Costo de los Cambios en la Construcción de SW En la siguiente figura se muestra el costo de producir cambios en el software que se desarrolla mediante una metodología tradicional versus el costo de producir cambios en el software que se desarrolla mediante alguna de las metodologías ágiles. Como se puede apreciar, a medida que avanza el tiempo, el costo es exponencial en el caso de la construcción mediante una metodología tradicional.

Estadística realizada sobre 8 proyectos de Software Estadounidenses.

Área: Sistemas de Defensa en Tiempo Real

0 0.5 1 1.5 2 2.5 3 3.5Millones de dolares

Pagado pero no entregado

Entregado pero no utilizado

abandonado o rechazado

Utilizado después de cambios

Utilizado como se entrego

costo del cambio

tiempo

metodología tradicional

suposición metodología ágil


Los problemas y errores comunes de los métodos no ágiles Los desarrolladores, directivos y clientes normalmente tienen buenas razones para tomar las decisiones que toman, y la apariencia seductora de los errores clásicos 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 fáciles de predecir. Y los errores rara vez producen los resultados que la gente espera. 1. Personas

A continuación aparecen algunos de los errores clásicos relacionados con las personas. 1.1. Motivación débil. Estudio tras estudio ha mostrado que la motivación

probablemente tiene mayor efecto sobre la productividad y la calidad que ningún 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 días de fiesta, para dar recompensas al final del proyecto que resultan ser de menos de un dólar por cada hora extra.

1.2. Empleados problemáticos incontrolados . Un fallo al tratar con personal

problemático también amenaza la velocidad de desarrollo. Un fallo al tomar una decisión cuando se trata con un empleado problemático es una de las quejas más 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. Hazañas. Algunos desarrolladores de software ponen un gran énfasis en la

realización de hazañas en los proyectos. Pero lo que hacen tiene más 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 planificación al límite 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 pequeño equipo de desarrollo y sus jefes inmediatos toman como rehenes a una compañía 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 cooperación entre los múltiples 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 daño ya está hecho. Como dijo Tom DeMarco, las actitudes <<ser capaz de>> convierten pequeños contratiempos en auténticos desastres.


1.4. Añadir más personal a un proyecto retrasado . Este es quizás el más clásico de los errores clásicos. Cuando un proyecto se alarga, añadir más gente puede quitar más productividad a los miembros del equipo existente de la que añaden los nuevos miembros. Añadir gente a un proyecto retrasado con echar nafta al fuego.

1.5. Oficinas repletas y ruidosas. La mayoría 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 están en oficinas silenciosas y privadas tienden a funcionar significativamente mejor que aquellos que ocupan cubículos 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 después de que éstos hayan sido fijados. Pueden ser simplemente conflictos de personalidad entre dos grupos. El principal efecto de esta fricción es la mala comunicación, y los efectos secundarios de la mala comunicación incluyen el pobre entendimiento de los requerimientos, pobre diseño 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 cancelación 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 más comunes de fricciones

entre los desarrolladores y sus clientes o los directivos son las expectativas poco realistas. Ejemplo, no tener razones técnicas 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 compañía. 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 basándose en estimaciones de planificación demasiado optimistas. Aunque por sí mismas las expectativas irreales no alargan el plan, contribuyen a la percepción 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 rápido es necesario un promotor del proyecto de alto nivel, incluyendo una planificación realista, el control de cambios y la introducción de nuevos métodos 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 participación de los implicados . Todos los principales participantes

del esfuerzo de desarrollo de software deben implicarse en el proyecto.


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 cooperación estrecha sólo se produce si se han implicado todos los participantes, permitiendo una coordinación precisa del esfuerzo para el desarrollo rápido, que es imposible conseguir sin una buena participación.

1.10. Falta de participación del usuario. La razón número uno de que los

proyectos de Sistemas de Información tuviesen éxito es la implicación 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 más tarde retrasarán el proyecto.

1.11. Política antes que desarrollo. Hay cuatro tipos diferentes de orientaciones

políticas. Los "políticos" están especializados en la "gestión", centrándose en las relaciones con sus directivos. Los "investigadores" se centran en explorar y reunir la información. Los "aislacionistas" están solos, creando fronteras para el proyecto que mantienen cerradas a los que no son miembros del equipo. Primar la política 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 ilusión.

Cuántas 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 quizás si trabajan duro, y nada va mal, y tienen un poco de suerte, serán capaces de concluir con éxito". "Nuestro equipo no hace mucho trabajo para la coordinación de las interfaces entre las distintas partes del producto, pero tenemos una buena comunicación para otras cosas, y las interfaces son relativamente simples, así que probablemente sólo necesitaremos un día o dos para eliminar los errores" Las ilusiones no son sólo 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 planificación coherente y pueden ser la raíz de más problemas en el software que todaslas otras causas combinadas.


2. Proceso Los errores relacionados con el proceso malgastan el talento y el esfuerzo del personal. A continuación se muestran algunos de los peores errores relacionados con el proceso.

2.1. Planificación excesivamente optimista . Los retos a los que se enfrenta alguien que desarrolla una aplicación en tres meses son muy diferentes de aquellos a los que se enfrenta alguien que desarrolla una aplicación que necesita un año. Fijar un plan excesivamente optimista predispone a que el proyecto falle por infravalorar el alcance del proyecto, minando la planificación efectiva, y reduciendo las actividades críticas para el desarrollo, como el análisis de requerimientos o el diseño. También supone una excesiva presión para los desarrolladores, quienes a largo plazo se ven afectados en su moral y su productividad.

2.2. Gestión de riesgos insuficiente. Algunos errores no son lo suficientemente

habituales como para considerarlos clásicos. Son los llamados "riesgos". Como con los errores clásicos, si no ejercemos una gestión activa de los riesgos, con qué sólo vaya mal una cosa se pasará de tener un proyecto con un desarrollo rápido a uno con un desarrollo lento. El fallo de no gestionar uno solo de estos riesgos es un error clásico.

2.3. Planificación insuficiente. Si no planificamos para conseguir un desarrollo

rápido, no podemos esperar obtenerlo.

2.4. Abandono de planificación bajo presión. Los equipos de desarrollo hacen planes y rutinariamente los abandonan cuando se tropiezan con un problema en la planificación. El problema no está en el abandono del plan, sino más 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 después de fallar en la primera entrega, y esto es lo habitual. A partir de este punto, el trabajo no tiene coordinación ni elegancia.

2.5. Pérdida 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 común que un proyecto desperdicie meses o años en un inicio difuso, y entonces se está a las puertas de un plan agresivo. Es mucho más fácil 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 análisis de requerimientos, la arquitectura y el diseño no producen código directamente, son los candidatos fáciles. Los resultados de este error, también conocido como "saltar a la codificación", son todos demasiado predecibles. Los proyectos que normalmente escatiman en sus actividades iniciales tendrán 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, ¿cómo vamos a encontrar 50 para hacerlo correctamente más tarde?


2.7. Diseño inadecuado . Un caso especial de escatimar en las actividades iniciales

es el diseño inadecuado. Proyectos acelerados generan un diseño indeterminado, no asignado suficiente tiempo para él y originado un entorno de alta presión que hace difícil la posibilidad de considerar alternativas en el diseño. El énfasis en el diseño está más orientado a la conveniencia que a la calidad, por lo que necesitará varios ciclos de diseño 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 diseño y del código, eliminando la planificación de las pruebas y realizando sólo pruebas superficiales. Acortar en un día las actividades de control de calidad al comienzo del proyecto probablemente supondrá de 3 a 10 días 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 documentación final, incorporar entradas en el sistema final de ayuda, pulir el programa de instalación, eliminar las funciones que no van a estar listas a tiempo y demás. 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 rápido intentan forzar la convergencia media docena de veces o más antes de que finalmente se produzca. Los intentos adicionales de convergencia no benefician al producto, Sólo son una pérdida de tiempo y prolongan el plan.

2.11. Omitir tareas necesarias en la estimación. Si la gente no guarda

cuidadosamente datos de proyectos anteriores, olvida las tareas menos visibles, pero son tareas que se han de añadir. El esfuerzo omitido suele aumentar el plan de desarrollo en un 20 o 30 por 100.

2.12. Planificar ponerse al día más adelante. Un tipo de reestimación 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 más tarde, pero nunca se hace. Aprenderemos más del producto conforme lo estamos construyendo, incluyendo más sobre lo que nos llevará construirlo. Estos conocimientos necesitan reflejarse en la reestimación del plan. Otro tipo de error es la reestimación que se debe a cambios en el producto. Si el producto que estamos construyendo cambia, la cantidad de tiempo necesaria para construirlo cambiará también. El crecimiento de las nuevas prestaciones sin ajustar el plan garantiza que no se alcanzará la fecha de entrega.


Características del desarrollo ágil. En los proyectos con desarrollo ágil se busca que todos los esfuerzos se usen en la creación 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. Además los usuarios o clientes reciben periódicamente 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 había considerado.

Distinguir entre tareas relevantes y las que no agregan valor se consigue a través de la creación de contextos con alto nivel de empowerment y feedback. empowerment: consiste en otorgar autonomía 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 programación, así también 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 código. Periódicamente el cliente evalúa 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 través del desarrollo incremental: el producto puede probarse desde las primeras semanas y meses del proyecto al menos en cuanto su funcionalidad básica, 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 hábitos y así también 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 atención. Adicionalmente los desarrolladores suelen trabajar mucho en equipo y también en parejas, revisando juntos el código 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 variaría entre 4x y 0.25x. A medida que se avanza en el proyecto se conoce más y se reduce el error hasta llegar a la certeza, desgraciadamente esta ocurre sólo cuando se finaliza el proyecto.


Beneficios de usar desarrollo ágil las mejoras obtenidas por usar el método de desarrollo ágil dependen de la situación. Por ejemplo, el método Srum no define prácticas técnicas (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 según la necesidad del negocio. Pero hay algunas mejoras que típicamente 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 relación 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 definición 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 dirección 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 también 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 ningún 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 situación es particularmente notoria en caso proyectos complejos, según la definición de complejo que será continuación. Mejor manejo de riesgos e incertidumbre Cuando se analizan proyectos, intentamos planificar la ejecución para lograr minimizar los riesgos y utiliza los recursos de manera más eficiente posible. Por ejemplo:

Si estamos arrollando un producto que será puesto en producción con servidores que deben adquirirse, es necesario que mencionemos el equipo necesario con 12 meses de anticipación, 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 restricción, probablemente lo ideal sería esperar hasta tener una prueba de performance con el producto completamente desarrollado. Sus es

Proyecto complejo : sus la planificación 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 difícil en algunos contextos, en los que los requerimientos son poco conocidos, o el ambiente de negocios nuevo, o en el caso de tecnologías 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 planificación.


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, también 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 más. 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 más 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 físico, forma de liderazgo y toma de decisiones, tiene un papel preponderante. En el desarrollo ágil se incorpora la autoorganización, el liderazgo facilitador, el trabajo en equipo, la transparencia, los grupos pequeños 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 más o menos favorables para su implementación, se puede afirmar que el desarrollo ágil que ha sido aplicado con éxito tanto en empresas así tanto como en equipos pequeños. Con respecto a los tipos de aplicaciones, ha sido aplicado en equipos médicos con riesgo de vida que requiere aprobación de la FDA, como en el manejo de pagos electrónicos, sistemas de alta disponibilidad, de alto volumen, etc. la línea lo más recomendado es que se utilicen equipo que trabaja en un único lugar físico pero aún así, ha sido usado por equipo distribuidos y con subcontrataciones. Comparación entre la vista del producto y la vista del proyecto muchas compañías 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 comunicación entre ellos más 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 través 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 podría ayudar a que el equipo obtenga retroalimentación de cliente y que incorpore esa información a próximas entregas. Antes de resumir algunas metodologías ágiles, vamos a enumerar las principales diferencias respecto de las metodologías tradicionales (“no ágiles”). La siguiente tabla muestra esquemáticamente estas diferencias que no se refieren sólo al proceso en sí, sino también al contexto de equipo y organización que es más favorable a cada uno de estas filosofías de procesos de desarrollo de software.


Metodologías Ágiles Metodologías Tradicionales Basadas en heurísticas provenientes de prácticas de producción de código

Basadas en normas provenientes de estándares seguidos por el entorno de desarrollo

Especialmente preparados para cambios durante el proyecto

Cierta resistencia a los cambios

Impuestas internamente (por el equipo de desarrollo)

Impuestas externamente

Proceso menos controlado, con pocos principios

Proceso mucho más controlado, con numerosas políticas/normas

No existe contrato tradicional o al menos es bastante flexible

Existe un contrato prefijado

El cliente es parte del equipo de desarrollo El cliente interactúa con el equipo de desarrollo mediante reuniones

Grupos pequeños (<10 integrantes) y trabajando en el mismo sitio

Grupos grandes y posiblemente distribuidos

Pocos artefactos Más artefactos Pocos roles Más roles Menos énfasis en la arquitectura del software

La arquitectura del software es esencial y se expresa mediante modelos

Metodologías Ágiles de Desarrollo A principios de la década 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 ingeniería de software con el nombre de Rapid Application Development. RAD consistía en un entorno de desarrollo altamente productivo, en el que participaban grupos pequeños de programadores utilizando herramientas que generaban código en forma automática 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 metodologías ágiles no inventaron la noción de los procesos iterativos e incrementales, los cuales eran usados desde décadas pasadas inclusive en momentos en que el modelo en cascada era el estándar. Entre las metodologías ágiles más 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


X.P Extreme Programming XP es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentación continua entre el cliente y el equipo de desarrollo, comunicación 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 técnico. Los principios y prácticas son de sentido común pero llevadas al extremo, de ahí proviene su nombre. A continuación presentaremos las características esenciales de XP organizadas en los tres apartados siguientes: historias de usuario, roles, proceso y prácticas. Las Historias de Usuario Las historias de usuario son la técnica utilizada en XP para especificar los requisitos del software. Se trata de tarjetas de papel en las cuales el cliente describe brevemente las características que el sistema debe poseer, sean requisitos funcionales o no funcionales. El tratamiento de las historias de usuario es muy dinámico y flexible, en cualquier momento historias de usuario pueden romperse, reemplazarse por otras más específicas o generales, añadirse 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 información contenida en la historia de usuario, existen varias plantillas sugeridas pero no existe un consenso al respecto. En muchos casos sólo se propone utilizar un nombre y una descripción o sólo una descripción, más quizás una estimación de esfuerzo en días. Ejemplo de ficha en la cual pueden reconocerse los siguientes contenidos:

• Fecha • tipo de actividad (nueva, corrección, mejora) • prueba funcional • número de historia • prioridad técnica y del cliente • referencia a otra historia previa • riesgo • estimación técnica • descripción • notas y una lista de seguimiento con la fecha • estado • cosas por terminar y comentarios.

Las historias de usuario son descompuestas en tareas de programación y asignadas a los programadores para ser implementadas durante una iteración.


Roles XP Programador: escribe las pruebas unitarias y produce el código del sistema. Debe existir una comunicación y coordinación adecuada entre los programadores y otros miembros del equipo. Cliente : escribe las historias de usuario y las pruebas funcionales para validar su Implementación. Además, asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración centrándose en aportar mayor valor al negocio. El cliente es sólo uno dentro del proyecto pero puede corresponder a un interlocutor que está representando a varias personas que se verán 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 realimentación 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. También realiza el seguimiento del progreso de cada iteración y evalúa si los objetivos son alcanzables con las restricciones de tiempo y recursos presentes. Determina cuándo es necesario realizar algún cambio para lograr los objetivos de cada iteración. Entrenador: es responsable del proceso global. Es necesario que conozca a fondo el proceso XP para proveer guías a los miembros del equipo de forma que se apliquen las prácticas XP y se siga el proceso correctamente. Consultor : es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto. Guía al equipo para resolver un problema específico. Gestor: Es el vínculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinación. 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 través 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 implementación. 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 más trabajo que el estimado, ya que se perderá calidad en el software o no se cumplirán los plazos. De la misma forma el


cliente tiene la obligación de manejar el ámbito de entrega del producto, para asegurarse que el sistema tenga el mayor valor de negocio posible con cada iteración. El ciclo de vida ideal de XP consiste de seis fases:

1. Exploración. 2. Planificación de la entrega (Release). 3. Iteraciones. 4. Producción. 5. Mantenimiento. 6. Muerte del Proyecto.

1. Exploración En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son de interés para la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas, tecnologías y prácticas que se utilizarán en el proyecto. Se prueba la tecnología y se exploran las posibilidades de la arquitectura del sistema construyendo un prototipo. La fase de exploración toma de pocas semanas a pocos meses, dependiendo del tamaño y familiaridad que tengan los programadores con la tecnología.

2. Planificación de la Entrega En esta fase el cliente establece la prioridad de cada historia de usuario, y correspondientemente, los programadores realizan una estimación 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 debería obtenerse en no más de tres meses. Esta fase dura unos pocos días. Las estimaciones de esfuerzo asociado a la implementación de las historias la establecen los programadores utilizando como medida el punto. Un punto, equivale a una semana ideal de programación. 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 iteración, basándose principalmente en la suma de puntos correspondientes a las historias de usuario que fueron terminadas en la última iteración. La planificación se puede realizar basándose en el tiempo o el alcance. La


velocidad del proyecto es utilizada para establecer cuántas historias se pueden implementar antes de una fecha determinada o cuánto tiempo tomará implementar un conjunto de historias. Al planificar por tiempo, se multiplica el número de iteraciones por la velocidad del proyecto, determinándose cuántos puntos se pueden completar. Al planificar según alcance del sistema, se divide la suma de puntos de las historias de usuario seleccionadas entre la velocidad del proyecto, obteniendo el número de iteraciones necesarias para su implementación.

3. Iteraciones Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan de entrega está compuesto por iteraciones de no más de tres semanas. En la primera iteración 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 creación de esta arquitectura, sin embargo, esto no siempre es posible ya que es el cliente quien decide qué historias se implementarán en cada iteración. Al final de la última iteración el sistema estará listo para entrar en producción. Los elementos que deben tomarse en cuenta durante la elaboración del Plan de la Iteración son:

• historias de usuario no abordadas. • velocidad del proyecto. • pruebas de aceptación no superadas en la iteración anterior • tareas no terminadas en la iteración anterior.

Todo el trabajo de la iteración es expresado en tareas de programación, cada una de ellas es asignada a un programador como responsable, pero llevadas a cabo por parejas de programadores.

4. Producción La fase de producción 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 inclusión de nuevas características a la versión actual, debido a cambios durante esta fase. Es posible que se rebaje el tiempo que toma cada iteración, de tres a una semana. Las ideas que han sido propuestas y las sugerencias son documentadas para su posterior implementación.

5. Mantenimiento Mientras la primera versión se encuentra en producción, 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 después de la puesta del sistema en producción. La fase de mantenimiento puede requerir nuevo personal dentro del equipo y cambios en su estructura.


6. Muerte del Proyecto Es cuando el cliente no tiene más 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 documentación final del sistema y no se realizan más cambios en la arquitectura. La muerte del proyecto también ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando no hay presupuesto para mantenerlo. Prácticas XP La principal suposición 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 diseño evolutivo funcione. XP apuesta por un crecimiento lento del costo del cambio y con un comportamiento asintótico. Esto se consigue gracias a las tecnologías disponibles para ayudar en el desarrollo de software y a la aplicación disciplinada de las prácticas. El juego de la planificación Es un espacio frecuente de comunicación entre el cliente y los programadores. El equipo técnico realiza una estimación del esfuerzo requerido para la implementación de las historias de usuario y los clientes deciden sobre el ámbito y tiempo de las entregas y de cada iteración. Esta práctica 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 según prioridad y esfuerzo, y se define el contenido de la entrega y/o iteración, apostando por enfrentar lo de más valor y riesgo cuanto antes. Este juego se realiza durante la planificación de la entrega, en la planificación de cada iteración y cuando sea necesario reconducir el proyecto.

Entregas pequeñas La idea es producir rápidamente 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 debería tardar más 3 meses.

Metáfora En XP no se enfatiza la definición temprana de una arquitectura estable para el sistema. Dicha arquitectura se asume evolutiva y los posibles inconvenientes que se generarían por no contar con ella explícitamente en el comienzo del proyecto se solventan con la existencia de una metáfora. El sistema es definido mediante una metáfora o un conjunto de metáforas compartidas por el cliente y el equipo de desarrollo. Una metáfora es una historia compartida que describe cómo debería funcionar el sistema. La práctica de la metáfora consiste en formar un conjunto de nombres que actúen como vocabulario para hablar sobre el dominio del problema. Este conjunto de nombres ayuda a la nomenclatura de clases y métodos del sistema. Diseño simple


Se debe diseñar la solución más simple que pueda funcionar y ser implementada en un momento determinado del proyecto. La complejidad innecesaria y el código extra debe ser removido inmediatamente. Kent Beck dice que en cualquier momento el diseño adecuado para el software es aquel que: supera con éxito todas las pruebas, no tiene lógica duplicada, refleja claramente la intención de implementación de los programadores y tiene el menor número posible de clases y métodos.

Pruebas La producción de código está dirigida por las pruebas unitarias. Las pruebas unitarias son establecidas antes de escribir el código y son ejecutadas constantemente ante cada modificación 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 automatización para apoyar esta actividad es crucial.

Refactorización (Refactoring) La refactorización es una actividad constante de reestructuración del código con el objetivo de remover duplicación de código, mejorar su legibilidad, simplificarlo y hacerlo más flexible para facilitar los posteriores cambios. La refactorización mejora la estructura interna del código 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 diseño evoluciona conforme cambia la funcionalidad del sistema. Para mantener un diseño apropiado, es necesario realizar actividades de cuidado continuo durante el ciclo de vida del proyecto. De hecho, este cuidado continuo sobre el diseño es incluso más importante que el diseño inicial. Un concepto pobre al inicio puede ser corregido con esta actividad continua, pero sin ella, un buen diseño inicial se degradará.

Programación en parejas Toda la producción de código debe realizarse con trabajo en parejas de programadores. Según Cockburn y Williams en un estudio realizado para identificar los costos y beneficios de la programación en parejas, las principales ventajas de introducir este estilo de programación son: muchos errores son detectados conforme son introducidos en el código (inspecciones de código continuas), por consiguiente la tasa de errores del producto final es más baja, los diseños son mejores y el tamaño del código menor (continua discusión de ideas de los programadores), los problemas de programación se resuelven más rápido, se posibilita la transferencia de conocimientos de programación entre los miembros del equipo, varias personas entienden las diferentes partes sistema, los programadores conversan mejorando así el flujo de información y la dinámica del equipo, y finalmente, los programadores disfrutan más su trabajo. Dichos beneficios se consiguen después de varios meses de practicar la programación en parejas. En los estudios realizados por Cockburn y Williams este lapso de tiempo varía de 3 a 4 meses.


Propiedad colectiva del código Cualquier programador puede cambiar cualquier parte del código en cualquier momento. Esta práctica motiva a todos a contribuir con nuevas ideas en todos los segmentos del sistema, evitando a la vez que algún programador sea imprescindible para realizar cambios en alguna porción de código.

Integración continúa Cada pieza de código 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 día. Todas las pruebas son ejecutadas y tienen que ser aprobadas para que el nuevo código sea incorporado definitivamente. La integración continua a menudo reduce la fragmentación de los esfuerzos de los desarrolladores por falta de comunicación 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á más preparado para modificar el código cuando sea necesario, debido a la confianza en la identificación y corrección de los errores de integración.

40 horas por semana Se debe trabajar un máximo 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 planificación 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 comunicación oral es más efectiva que la escrita, ya que esta última toma mucho tiempo en generarse y puede tener más 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 situación son las siguientes: intentar conseguir un representante que pueda estar siempre disponible y que actúe como interlocutor del cliente, contar con el cliente al menos en las reuniones de planificación, establecer visitas frecuentes de los programadores al cliente para validar el sistema, anticiparse a los problemas asociados estableciendo llamadas telefónicas frecuentes y conferencias, reforzando el compromiso de trabajo en equipo.


Estándares de programación XP enfatiza la comunicación de los programadores a través del código, con lo cual es indispensable que se sigan ciertos estándares de programación (del equipo, de la organización u otros estándares reconocidos para los lenguajes de programación utilizados). Los estándares de programación mantienen el código legible para los miembros del equipo, facilitando los cambios. Críticas a eXtreme Programming Algunas de las críticas de Xp Xp tiene muchas críticas especialmente contra la programación por parejas por parte de muchos programadores con gran sentimiento de posesión del código, 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. También se critica el mito de las 40 horas semanales ya que es un lujo para las exigencias del mercado. También hay críticas hacia Xp que dicen que solo puede funcionar con programadores muy buenos. Xp es mas una filosofía de trabajo que una metodología. Por otro lado ninguna de las practicas defendidas por Xp son invención de este método, Xp lo que hace es ponerlas todas juntas. Xp esta diseñado para grupos de pequeños programadores, más de 10 ya seria muy complicado, y mas aun para que estén en el mismo centro de trabajo.


SCRUM SCRUM es un término de Rugby, es la agrupación de los miembros del equipo. De esta manera el equipo trata de recorrer la distancia hacia la meta como una unidad, pasándose la pelota entre ellos. Define un marco para la gestión de proyectos, que se ha utilizado con éxito durante los últimos 10 años. Está especialmente indicada para proyectos con un rápido cambio de requisitos. Sus principales características se pueden resumir en dos. El desarrollo de software se realiza mediante iteraciones, denominadas sprints, con una duración de 30 días. El resultado de cada sprint es un incremento ejecutable que se muestra al cliente. La segunda característica importante son las reuniones a lo largo proyecto. Éstas son las verdaderas protagonistas, especialmente la reunión diaria de 15 minutos del equipo de desarrollo para coordinación e integración. Scrum es un marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software. Aunque Scrum estaba enfocado a la gestión de procesos de desarrollo de software, puede ser utilizado en equipos de mantenimiento de software, o en una aproximación de gestión de programas. Características de Scrum Scrum es un modelo de referencia que define un conjunto de prácticas 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 días (la magnitud es definida por el equipo), el equipo crea un incremento de software potencialmente entregable (utilizable). El conjunto de características 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 reunión de Sprint Planning. Durante esta reunión, 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 están congelados durante el sprint. Scrum permite la creación de equipos autoorganizados impulsando la co-localización de todos los miembros del equipo, y la comunicación verbal entre todos los miembros y disciplinas involucrados en el proyecto.


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 desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido, y centrándose en maximizar la capacidad del equipo de entregar rápidamente 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 fácil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar. Roles en Scrum En Scrum se definen varios roles, estos están divididos en dos grupos: cerdos y gallinas. De esta forma:

• Los cerdos: están comprometidos a desarrollar el software de forma regular y frecuente. Están comprometidos con el proyecto y el proceso Scrum.

• Las Gallinas: sólo 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 aproximación ágil es la práctica de involucrar en el proceso a los usuarios, expertos del negocio y otros interesados (stakeholders). Es importante que esa gente participe y entregue retroalimentación 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.


• ScrumMaster (o Facilitador): El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección 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 pequeño equipo de 5 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (diseñador, 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 definición sería 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. Sólo 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 día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto se llama "daily standup". El scrum tiene unas guías específicas:

• La reunión 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 plástico del cuello, etc.).

• Todos son bienvenidos, pero sólo los "cerdos" pueden hablar. • La reunión tiene una duración fija de 15 minutos, de forma independiente del

tamaño del equipo. • Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la

reunión corta). • La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días.

Durante la reunión, cada miembro del equipo contesta a tres preguntas:

1. ¿Qué has hecho desde ayer? 2. ¿Qué es lo que estás planeando hacer hoy? 3. ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo? (Es el

papel del ScrumMaster recordar estos impedimentos). Scrum de Scrum Cada día normalmente después del “Daily Scrum”

• Estas reuniones permiten a los grupos de equipos discutir su trabajo, enfocándose especialmente en áreas de solapamiento e integración.

• Asiste una persona asignada por cada equipo.


La agenda será la misma que la del Daily Scrum, añadiendo además las siguientes cuatro preguntas:

1. ¿Qué ha hecho tu equipo desde nuestra última reunión? 2. ¿Qué hará tu equipo antes que nos volvamos a reunir? 3. ¿Hay algo que demora o estorba a tu equipo? 4. ¿Estás a punto de poner algo en el camino del otro equipo?

Reunión de Planificación del Sprint Al inicio del ciclo Sprint (cada 15 o 30 días), una “Reunión de Planificación 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 cuánto del trabajo es probable que se realice durante el

actual Sprint • Ocho horas como límite

Al final del ciclo Sprint, dos reuniones se llevaran a cabo: la “Reunión de Revisión del Sprint” y la “Retrospectiva del Sprint” Reunión de Revisión 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 límite

Retrospectiva del Sprint (Sprint Retrospective) Después 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 recién superado. El propósito de la retrospectiva es realizar una mejora continua del proceso. Esta reunión tiene un tiempo fijo de cuatro horas. Sprint El Sprint es el período en el cual se lleva a cabo el trabajo en sí. Es recomendado que la duración de los sprints sea constante y definida por el equipo en base a su propia experiencia. Se puede comenzar con una duración de sprint en particular (2 o 3 semanas) e ir ajustándolo en base al ritmo del equipo, aunque sin relajarlo demasiado. Al final de cada sprint, el equipo deberá presentar los avances logrados, y deberían entregar un producto con características de utilizable por el cliente. Asimismo se recomienda no cambiar los objetivos del sprint o sprint backlog a menos que la falta de estos cambios amenacen al éxito del proyecto. La constancia hace a la concentración 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 genéricas de todos los requerimientos, funcionalidades deseables, etc. priorizadas según su retorno sobre la inversión (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 estimación ayuda al product owner a ajustar la línea temporal y, de manera limitada, la prioridad de las


diferentes tareas. Por ejemplo, si dos características tienen el mismo valor de negocio la que requiera menos tiempo de desarrollo tendrá probablemente más prioridad, debido a que su ROI será más alto. Sprint backlog El sprint backlog es un documento detallado donde se describe el cómo el equipo va a implementar los requisitos durante el siguiente sprint. Las tareas se dividen en horas con ninguna tarea de duración 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 gráfica mostrada públicamente que mide la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una línea que conecte los puntos de todos los Sprints completados, podremos ver el progreso del proyecto. Lo normal es que esta línea sea descendente (en casos en que todo va bien en el sentido de que los requisitos están bien definidos desde el principio y no varían nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay más requisitos pendientes de ser completados en el Backlog). Si durante el proceso se añaden 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 críticas de Scrum No todo en Scrum es un mundo maravilloso, existen críticos y personas que lo han descartado. Básicamente sus quejas se centraban en los siguientes tres puntos: 1- Muchas Reuniones y algunas muy largas, como la d e estimación: Curiosamente este punto es uno de los pilares fundamentales de Scrum, al realizar reuniones para que fluya la comunicación entre todos los agentes implicados. Pero existen personan que critican el hecho de tener que reunirse todos los días, aunque sean reuniones de cinco minutos, dado que creen que es innecesario muchas veces durante el desarrollo del sprint. Existe también una crítica hacia las reuniones de estimación, 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 más largos de lo necesario. 2- Tener que medir con métricas todos los procesos: En este punto los críticos responden que la obligación de medir todos los procesos, que les lleva a crear unas gráficas 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 presión a sus miembros que les hace anular ciertas cualidades como la inspiración, la espontaneidad, las genialidades absurdas, etc. Justifican que en todos los proyectos se necesitan dosis de estas características para que se consiga un producto completo.


Crystal Se trata de un conjunto de metodologías 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 reducción al máximo del número de artefactos producidos. El desarrollo de software se considera un juego cooperativo de invención y comunicación, 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 políticas de trabajo en equipo definidas. Estas políticas dependerán del tamaño 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 metodología para un proyecto en función de su criticidad y tamaño. Los proyectos más grandes suelen necesitar una mayor coordinación y metodologías más complejas que no los proyectos más pequeños. Cuanto más crítico sea el sistema que queremos desarrollar, más 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 pérdida de confort debido a un fallo del sistema. • D, indica pérdida de dinero discrecional, es decir del que podemos disponer,

generalmente nuestro. • E, indica pérdida 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 pérdida de vidas por el fallo del sistema.

C.C puede ser usado en proyectos pequeños y como casi todos los otros métodos, CC consiste en valores, técnicas y procesos.


Menos énfasis en la documentación exhaustiva y más en versiones que corran y puedan ser probadas. Lo primero son promesas, lo segundo hechos. Cada proyecto necesita sus propios métodos. Se trata de un conjunto de metodologías para el desarrollo de software caracterizadas por estar centradas en las personas que componen el equipo y la reducción al máximo del número de artefactos producidos. El desarrollo de software se considera un juego cooperativo de invención y comunicación, 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 políticas de trabajo en equipo definidas. Características Las personas, como dispositivos activos, tienen modos de éxito y modos de fallo. Los siguientes son los principales:

• Cuando el número de personas aumenta, también aumenta la necesidad de coordinar.

• Cuando el potencial de daños se incrementa, la tolerancia a variaciones se ve afectada.

• La sensibilidad del tiempo en que se debe estar en el mercado varía: a veces este tiempo debe acortarse al máximo y se toleran defectos, otras se enfatiza la auditoria, confiabilidad, protección 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 más significativo es “comunicación”. La más exhaustivamente documentada es Crystal Clear, y es la que se ha de describir a continuación. CC puede ser usado en proyectos pequeños. El otro método elaborado en profundidad es el Naranja, apto para proyectos de duración estimada en 2 años. Los otros dos aún se están desarrollando. Como casi todos los otros métodos, CC consiste en valores, técnicas 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 código. La frecuencia dependerá del proyecto, pero puede ser diaria, semanal o mensual.

2. Comunicación osmótica. Todos juntos en el mismo cuarto. Una variante especial es disponer en la sala de un experto diseñador senior y discutir respecto del tema que se trate.

3. Mejora reflexiva. Tomarse un pequeño 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 compañeros cuando algo molesta dentro del grupo.

5. Foco . Saber lo que se está haciendo y tener la tranquilidad y el tiempo para hacerlo.

6. Fácil acceso a usuarios expertos. Tener alguna comunicación con expertos desarrolladores.

Crystal Clear no requiere ninguna estrategia o técnica, pero siempre es útil tener unas cuantas a mano para empezar. Las estrategias comunes a otras Metodologías Ágiles, son:


• Exploración de 360°. Verificar o tomar una muestra del valor de negocios del proyecto, los requerimientos, el modelo de dominio, la tecnología, el plan del proyecto y el proceso.

• Victoria temprana. Es mejor buscar pequeños triunfos iniciales que aspirar a una gran victoria tardía

• Esqueleto ambulante. Es una transacción que debe ser simple pero completa. • Re-arquitectura incremental. Se ha demostrado que no es conveniente

interrumpir el desarrollo para corregir la arquitectura. Más bien la arquitectura debe evolucionar en etapas, manteniendo el sistema en ejecución mientras ella se modifica.

• Radiadores de información . Es una lámina pegada en algún lugar que el equipo pueda observar mientras trabaja o camina. Tiene que ser comprensible para el observador casual, entendida de un vistazo y renovada periódicamente para que valga la pena visitarla.

En cuanto a las técnicas, se favorecen:

• Entrevistas de proyectos. Se suele entrevistar a más de un responsable para tener visiones más ricas.

• Talleres de reflexión. El equipo debe detenerse treinta minutos o una hora para reflexionar sobre sus convenciones de trabajo, discutir inconvenientes y mejoras y planear para el período siguiente.

• Planeamiento Blitz. Una técnica puede ser el Juego de Planeamiento de XP. En este juego, se ponen tarjetas indexadas en una mesa, con una historia de usuario o función 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 función. El patrocinador del usuario escribe la secuencia de prioridades, teniendo en cuenta los tiempos referidos y el valor de negocio de cada función. Las tarjetas se agrupan en períodos de tres semanas llamados iteraciones que se agrupan en entregas, usualmente no más largas de tres meses.

• Estimación Delphi con estimaciones de pericia . En el proceso Delphi se reúnen los expertos responsables y proceden como en un remate para proponer el tamaño del sistema, su tiempo de ejecución, la fecha de las entregas según dependencias técnicas y de negocios y para equilibrar las entregas en paquetes de igual tamaño.

• Encuentros diarios de pie. La palabra clave es “brevedad”, cinco a diez minutos como máximo. 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 día. La idea es que la gente pueda “degustar” la nueva metodología.

• Gráficos de quemado. Su nombre viene de los gráficos de quemado de calorías de los regímenes dietéticos; se usan también en Scrum. Se trata de una técnica de graficación para descubrir demoras y problemas tempranamente en el proceso, evitando que se descubra demasiado tarde que todavía no se sabe cuánto falta. Para ello se hace una estimación 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 técnica 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 demás


elementos se hundan bajo la línea de flotación; los elementos que están sobre la línea se entregarán en la iteración siguiente, los que están por debajo en las restantes. En otras Metodologías Ágiles la Lista temprana no es otra cosa que un grafico de retraso. Los gráficos de quemado ilustran la velocidad del proceso, analizando la diferencia entre las líneas proyectadas y efectivas de cada entrega.

• Programación lado a lado. Mucha gente siente que la programación en pares de XP involucra una presión excesiva; la versión de Crystal Clear establece proximidad, pero cada quien se enfoca a su trabajo asignado, prestando un ojo a lo que hace su compañero, quien tiene su propia máquina. Esta es una ampliación de la Comunicación Osmótica al contexto de la programación.

Hay ocho roles nominados en CC: Patrocinador, Usuario Experto, Diseñador Principal, Diseñador Programador, Experto en Negocios, Coordinador, Verificador, Escritor. En Crystal Naranja se agregan aun más roles: Diseñador de IU (Interfaz de Usuario), Diseñador de Base de Datos, Experto en Uso, Facilitador Técnico, Analista/Diseñador de Negocios, Arquitecto, Mentor de Diseño, Punto de Reutilización. A continuación se describen los artefactos de los que son responsables los roles de CC:

1. Patrocinador . Produce la Declaración de Misión con Prioridades de Compromiso (Tradeoff). Consigue los recursos y define 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 operación, información a visualizar simultáneamente, navegación.

3. Diseñador Principal. Produce la Descripción Arquitectónica. Se supone que debe ser al menos un profesional de Nivel 3. En Metodologías Ágiles se definen tres niveles de experiencia: • Nivel 1 es capaz de “seguir los procedimientos”. • Nivel 2 es capaz de “apartarse de los procedimientos específicos” y

encontrar otros distintos • Nivel 3 es capaz de manejar con fluidez, mezclar e inventar procedimientos.

El Diseñador Principal tiene roles de coordinador, arquitecto, mentor y programador más experto.

4. Diseñador-Programador. Produce, junto con el Diseñador Principal, los Borradores de Pantallas, el Modelo Común de Dominio, las Notas y Diagramas de Diseño, el Código Fuente, el Código de Migración, las Pruebas y el Sistema Empaquetado. Un programa en CC es “diseño y programa”; sus programadores son diseñadores-programadores. En CC un diseñador 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 políticas 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 Iteración y la Agenda de Visualización.

7. Verificador. Produce el Reporte de Bugs. Puede ser un programador en tiempo parcial, o un equipo de varias personas.


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 Reflexión.

El Código Genético 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 guía para la toma de decisiones, estas son:

• Eficiencia en el desarrollo: para hacer que los proyectos sean económicamente 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 más de un mes.

• Comunicación: Crystal Clear toma como uno de sus pilares a la comunicación. Promueve prácticas 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 periódicas de reflexión que permitan crecer y hacernos más 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 cómodo

con el trabajo y el entorno. • Concentración : las entregas frecuentes permiten que cada desarrollador puede

enfocar de a un problema evitando dispersiones. • Fácil acceso a usuarios clave: tratar de hacer que el usuario sea una parte

más del equipo es fundamental para ir depurando errores de manera temprana. • Entorno técnico con:

o Testing automatizado (incorporación, por ejemplo, de UnitTest). o Integración frecuente (uso de herramientas específicas como Cruise

Control). 4. Principios El grado de detalle necesario en documentar requerimientos, diseño, planeamiento, etc, varía según el proyecto.


• Es imposible eliminar toda documentación pero puede ser reducida logrando un modo de comunicación más 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 asignación.

5. Estrategias Ni las estrategias ni las técnicas 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 están más 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 más "cuerpo" al esqueleto inicial. Todas describen una forma de tomar ventaja del desarrollo incremental para establecer valor desde el principio. 6. Técnicas Igual que con las estrategias, hay una lista de técnicas propuestas por Crystal Clear, de las cuales se pueden ir tomando las más convenientes según el momento en que se encuentra el proceso de desarrollo del proyecto. Las reuniones diarias (introducidas por la metodología Scrum) acompañan el seguimiento y mantienen el foco en el próximo paso a seguir, y también permiten la discusión productiva de líneas a seguir. Las reuniones de reflexión periódicas son fundamentales para que los miembros del equipo se expresen abiertamente, para revisar el trabajo hecho y evaluar qué cosas dan resultado y cuáles no o de empezar a trabajar. Todo esto permite ir armando una metodología de trabajo que se adecue al equipo, el proyecto y los tiempos que se manejen. Conclusión La guía de trabajo que presenta Crystal Clear es altamente recomendable para equipos pequeños. Da flexibilidad y prioriza la parte humana, apuntando a lograr eficiencia, habitabilidad y confianza en los miembros del equipo. Presta especial importancia a la ubicación física del grupo, donde la comunicación cumple el principal rol. La entrega frecuente de código confiable y "funcionando" mantiene el foco y evita distracciones. Todo esto permite ir armando una metodología de trabajo que se adecue al equipo, el proyecto y los tiempos que se manejen. El riesgo en el método ágil son los Cambios de arquitectura son como ejercicios de trapecio


Dynamic Systems Development Method (DSDM) DSDM es la única de las metodologías aquí planteadas surgida de un Consorcio, formado originalmente por 17 miembros fundadores en Enero de 1994. El objetivo del Consorcio era producir una metodología de dominio público 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 conocían en la industria y la experiencia traída por sus fundadores, liberó la primera versión de DSDM a principios de 1995. A partir de ese momento el método fue bien acogido por la industria, que empezó a utilizarlo y a capacitar a su personal en las prácticas y valores de DSDM. Debido a este éxito, el Consorcio comisionó al Presidente del Comité Técnico, Jennifer Stapleton, la creación de un libro que explorara la realidad de implementar el método. Dado el enfoque hacia proyectos de características RAD esta metodología encuadra perfectamente en el movimiento de metodologías ágiles. La estructura del método 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 propósitos del negocio es el criterio esencial para la

aceptación de los entregables. 5. El desarrollo iterativo e incremental es necesario para converger hacia una

correcta solución del negocio. 6. Todos los cambios durante el desarrollo son reversibles. 7. Los requerimientos están especificados a un alto nivel. 8. El testing es integrado a través del ciclo de vida. 9. Un enfoque colaborativo y cooperativo entre todos los interesados es esencial.

DSDM define cinco fases en la construcción de un sistema. Las mismas son:

1. Estudio de factibilidad. 2. Estudio del negocio. 3. Iteración del modelo funcional. 4. Iteración del diseño y construcción. 5. Implantación.

El estudio de factibilidad es una pequeña fase que propone DSDM para determinar si la metodología se ajusta al proyecto en cuestión. 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 diseño de los mismos, se construirán los componentes de software, y se implantará el sistema en producción previa aceptación del cliente.


Fases en la construcción 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 demás fases presentan las características 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 cuestión 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 aplicación computacionalmente compleja? • ¿Es la aplicación potencialmente grande? Si lo es, ¿puede ser particionada en • componentes funcionales más pequeños? • ¿Está el proyecto realmente acotado en el tiempo? • ¿Son los requerimientos flexibles y sólo especificados a un alto nivel?


Las mismas refieren a las características que se deben cumplir en los proyectos para poder utilizar el enfoque RAD de construcción. Se observa que aquellos proyectos que califiquen afirmativamente de acuerdo a dichas preguntas tendrán las siguientes características 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 más pequeños si la aplicación

es de gran tamaño. • 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 análisis sobre su aplicabilidad a un espectro bien definido de proyectos de software. Sin embargo, la metodología no tiene ninguna prescripción respecto a las técnicas a ser usadas en el proyecto, ni siquiera impone el desarrollo bajo un paradigma específico, funciona tanto para el modelo de orientación a objetos como para el modelo estructurado. Algo que sí sugiere el método es la generación de un conjunto mínimo de modelos necesarios para la sana progresión de la entrega del software y facilidad en el mantenimiento. Estos modelos esenciales deberán ser definidos antes que comience el desarrollo, y deberán 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 metodologías ágiles, en las cuales también se conocen como iteración, 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. También permiten controlar la calidad de los productos intermedios que se van generando, y realizar estimaciones de esfuerzo más precisas. Asimismo, cada timebox esta compuesta por actividades definidas en relación 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: Investigación, Refinamiento y Consolidación. Durante la Investigación se chequean que las actividades que componen el timebox se condicen con la arquitectura del sistema. Esta es una fase de carácter exploratorio, en la que se fijan los objetivos de la iteración, los entregables a ser producidos, efectuándose revisiones sobre las iteraciones anteriores a la actual. La siguiente fase, Refinamiento, consiste en la producción 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 Consolidación consiste en completar los entregables, verificando la calidad de los mismos. En esta fase que posee el hito de finalización del timebox se demostrará que se satisficieron los requerimientos de calidad definidos durante la Investigación.DSDM incluye roles claves en relación al management del proyecto. Identifica al visionario como el encargado de asegurar que se satisfacen las necesidades del negocio; el usuario embajador que equivaldría al on-site customer de XP, que brinda el conocimiento del negocio y define los requerimientos del software; el coordinador técnico que es la persona encargada de mantener la arquitectura y verificar


la consistencia de los componentes construidos respecto a esta y al cumplimiento de los estándares técnicos. Algunas técnicas sugeridas en DSDM son las sesiones JAD para capturar los requerimientos del software y la realización de prototipos para descifrar aquellas ambigüedades que se presentan en el relevamiento y también para derribar las barreras comunicacionales entre analistas y usuarios. El enfoque propuesto consiste en la utilización de un prototipo evolutivo, el cual se va refinando hasta tenerse la aplicación deseada. El énfasis queda en manifiesto en los prototipos que se sugieren para cada etapa: negocio, usabilidad, performance y capacidad, y diseño. En resumen, encontramos en DSDM una metodología ágil creada en el Reino Unido a partir de un consorcio con participación de empresas de primera línea. El mismo contiene las características principales de las metodologías ágiles y contiene prácticas tendientes al enfoque RAD. Algo que es importante de DSDM ha sido su aceptación en la industria y su refinamiento continuo lo que indica que las metodologías ágiles no son solo dominio de pequeños grupos de desarrollo sino que están siendo adoptadas por “pesos pesados” en las industrias.


Feature Driven Development (F.D.D) Peter Coad es considerado uno de los referentes más importantes dentro de la ingeniería de software. Coad ha sido uno de los principales pioneros detrás del movimiento de la orientación a objetos y empezó a trabajar con Ed Yourdon (uno de los creadores del Análisis Estructurado) a principios de los noventa, cuando este último pidió ayuda a alguien de la comunidad de objetos para desarrollar una nueva metodología, basada en el paradigma de OO. Posteriormente, Coad junto con Jeff De Luca y otros, participaría en la creación de FDD, una metodología desarrollada alrededor del año 1998 que presenta las características de un proceso ágil. La misma derivó del trabajo de Coad sobre las Feature Lists (Listas de Funcionalidades). FDD se estructura alrededor de la definición 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 también una jerarquía de features, siendo el eslabón superior el de feature set que agrupa un conjunto de features relacionadas con aspectos en común del negocio. Por último, establece el major feature set como el más alto nivel de agrupación de funcionalidad que abarca diferentes feature sets que contribuyen a proveer valor al cliente en relación a un subdominio dentro del dominio completo de la aplicación. Una de las ventajas de centrarse en las features del software es el poder formar un vocabulario común que fomente que los desarrolladores tengan un diálogo fluido con los clientes, desarrollando entre ambos un modelo común del negocio. Este tema será tratado más adelante en relación al enfoque de las metodologías ágiles en los productos entregados. La jerarquía de los features utiliza los siguientes formatos: • Para features: <acción> el <resultado> <de | para | sobre | por> un <objeto> • Para feature sets: <acción><-endo> un <objeto> • Para major feature sets: administración de <acción> Ejemplos: Calcular el total de la facturación de Noviembre (feature) Modificar el estado de las facturas de producción (feature) Haciendo una venta a un cliente (feature set) Cargando la facturación de los proveedores (feature set) Administración 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.


La primera actividad: consiste en Desarrollar un Modelo Global, que sugiere un cierto paralelismo con la construcción de la arquitectura del software. En la creación 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 proponía con sus primeras iteraciones: un conocimiento global de la aplicación a construir, el entendimiento del negocio en que esta embebida, un primer bosquejo de las features del software, y la definición de restricciones y cuestiones no funcionales. Para esto, se desarrollarán: diagramas de los paquetes, con las clases esenciales y las responsabilidades de las mismas; un documento similar al de Visión 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 podríamos 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 jerárquicamente para poder estructurar el trabajo de desarrollo; se realiza la priorización de las mismas basándose en la satisfacción al cliente – las prioridades sugeridas para las features por FDD son: A (debe tener), B (sería útil tener), C (agregar si es posible), o D (futuro); finalmente, se pondera la importancia de cada una para su posterior implementación – en caso que existan features que requieran más de dos semanas de desarrollo en esta actividad se particionarán 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 líder de proyecto, el líder de desarrollo y el programador jefe. A medida que se realiza la planificación se delinean los hitos de finalización de las iteraciones, dejando asentado cuales son los features y features sets que estarán construidos en dichos hitos. Parte de también incluye la delegación de responsabilidades a los programadores jefe que serán dueños de los features, estos a su vez asignarán las clases a dueños de clases seleccionados del equipo. Las últimas dos actividades: Diseñar por Feature y Construir por Feature, están relacionadas con la parte productiva del proceso en que se construye la aplicación de manera incremental. Empezando por el diseño que toma los features correspondientes a la iteración, el equipo de programadores liderado por el programador jefe identifica las clases, atributos y métodos que realizan la funcionalidad requerida. Mediante la


utilización de diagramas de secuencia de UML, se verifica que el diseño pueda ser implementado. Se realizará también una inspección del diseño 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 métodos 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 código. Esta actividad será realizada por el equipo asignado al feature en cuestión, y una vez que finaliza se promueve el código al Build correspondiente, siendo entregado a Administración de la Configuración. Roles

Roles claves: Gerente del proyecto : es quien tiene la última palabra en materia de visión, cronograma y asignación del personal. Arquitecto jefe : este rol puede dividirse en arquitecto de dominio y arquitecto técnico. 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 análisis de requerimientos y selecciona rasgos del conjunto a desarrollar en la siguiente iteración. Propietarios de clases : trabajan bajo la guía del programador jefe en diseño, codificación, prueba y documentación, 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 perfección el lenguaje y la tecnología. “Herramientista” (toolsmith) : construye pequeñas herramientas de desarrollo o mantiene bases de datos y sitios web. Administrador del sistema : controla el ambiente de trabajo, servidores, red…etc.

Roles Adicionales: “Tester”: verificador del sistema producido. Escritores de documentos técnicos : 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 diseña y construye el sistema. En relación a las actividades de management en FDD se recomienda una reunión semanal entre el Líder de proyecto y los programadores jefe; la misma debe ser breve, de no más de 30 minutos, y en la cual se reporta el status de los features que están siendo construidos por cada grupo. Por cada feature set que es implementado se tendrá


la información como indica la Figura 006 para medir el avance del proyecto, dándole visibilidad al management superior y al cliente. Conclusión Encontramos en FDD un proceso ágil orientado a la funcionalidad del software por sobre las tareas, sobre las cuales da guías mínimas. El proceso sugiere organizar bloques de features a ser construidos en forma incremental mediante iteraciones de dos semanas; provee estrategias de planeamiento para el líder de proyecto; fomenta la colaboración mediante la creación de equipos dirigidos por un programador jefe Algunos “agilistas” sienten que FDD es demasiado jerárquico para ser un método á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 década de 1990. Un rasgo llamativo de FDD es que no exige la presencia del cliente.


Adaptive Software Development Jim Highsmith en su libro es la mente detrás de este proceso ágil. ASD consiste en un cambio de filosofía en las organizaciones pasando de la transición del modelo Comando-Control al modelo Liderazgo-Colaboración. Basado en los conceptos de los Sistemas Adaptativos Complejos relacionada con la Inteligencia Artificial, Highsmith lleva los mismos al campo de la Ingeniería de Software en particular. Dada la complejidad inherente al software concluye que la aplicación de esta teoría es esencial para el nuevo escenario que plantea la economía 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 práctica con el modelo en cascada, en que se realiza una precisa planificación inicial mediante el WBS, el Gantt, y el Pert definiendo las tareas a realizar en detalle, luego se tiene las fases de construcción, y finalmente, se tiene el testing que brinda el feedback en relación al producto construido. ASD propone utilizar en cambio el ciclo de vida de la Figura 007, Especular-Colaborar-Aprender. El proyecto comienza con una fase de especulación en que en que se lleva a cabo la planificación tentativa del proyecto en función de las entregas que se irán realizando. La utilización del verbo Especular demuestra el interés 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 iteración, se aprenderán nuevas funcionalidades, se entenderán viejas cuestiones, y cambiarán los requerimientos. Gracias a centrarse en la especulación, ASD permite administrar estos proyectos de alto cambio y rápido desarrollo que se encuentran en el borde del caos. Respecto a la especulación, 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 cálculo se pueda conocer la funcionalidad a ser liberada en cada ciclo.Sin embargo, no es más que una especulación ya que el carácter adaptativo del proceso permite pequeñas desviaciones en un sentido – por lo que Highsmith sugiere que cada ciclo se componga de un mix entre funcionalidades críticas, ú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 exploración del dominio y de la aplicación, que puede llevar a cambiar el rumbo del proyecto – estos desvíos está representado por las flechas de divergencia en la siguiente figura:


La siguiente fase del ciclo de vida, Colaborar, es aquella en la que se construye la funcionalidad definida durante la especulación. ASD define un Componente como un grupo de funcionalidades o entregables a ser desarrollados durante un ciclo iterativo. Durante cada iteración el equipo colabora intensamente para liberar la funcionalidad planificada. También, existe la posibilidad de explorar nuevas alternativas, realizar pruebas de concepto, pudiendo eventualmente alterar el rumbo del proyecto profundamente. ASD no propone técnicas ni prescribe tareas al momento de llevar a cabo la construcción simplemente mencionando que todas las prácticas que sirvan para reforzar la colaboración serán preferidas, siguiendo de esta forma la línea de las metodologías ágiles respecto a la orientación 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 más grande del todo (comportamiento del sistema) a partir de la interacción 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 revisión de calidad que se realiza al final de cada ciclo. En la misma se analizan cuatro categorías de cosas para aprender:

• Calidad del resultado de la desde la perspectiva del cliente. • Calidad del resultado de la desde la perspectiva técnica. • El funcionamiento del equipo de desarrollo y las prácticas 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 aplicación y se anotan los requerimientos de cambio del cliente. Las revisiones al diseño, al código o a las pruebas permitirán aprender sobre la calidad de los mismos. En este caso, el énfasis estará puesto en aprender cuales han sido los errores o desvíos y poder resolverlos, y no en encontrar culpables. Asimismo, está es la etapa en que se evaluarán las exploraciones que se hayan realizado dando la capacidad de poder modificar la arquitectura del sistema si se ha encontrado algún 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 interacción entre las partes, la dinámica de grupo, y las técnicas empleadas. Para medir la performance y el grado de cohesión del mismo, se podrán realizar al final de cada ciclo pequeñas 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 relación al status del proyecto, se realizarán revisiones para determinar el estado del mismo en relación a lo planificado. En este momento, se detectarán posibles diferencias que pueden surgir de la exploración y que cambiarán el rumbo a que apuntaba el proyecto.


En la siguiente Figura se puede ver el detalle interno de cada fase como ya fue explicado, mostrándose con una flecha que trasciende las tres fases en sentido inverso, el bucle de aprendizaje. Este bucle es algo crítico para ASD ya que denota un cambio en el esquema tradicional de la vista de un sistema en que se tenía un bucle de control para detectar diferencias y corregirlas. Es decir, en las metodologías tradicionales las diferencias respecto a lo planificado eran vistas como errores que debían ser enmendados para que cumplieran lo pautado. ASD y las metodologías ágiles plantean la necesidad de que el feedback necesario sea para aprender, nos da la posibilidad de entender más respecto al dominio y construir la aplicación que mejor satisfaga las necesidades del cliente. Highsmith lo expone claramente en la siguiente frase: “En ambientes complejos, el seguir un plan al pie d e la letra produce el producto que retendíamos, pero no el producto que necesitamo s.”

Conclusion En conclusión, tenemos en ASD un marco filosófico basado en la teoría de Sistemas Adaptativos Complejos que nos permite encarar la construcción de software en forma ágil utilizando las prácticas que nos resulten convenientes en cada caso. En este sentido resulta similar a Scrum.


LEAN SOFTWARE DEVELOPMENT Lean es el nombre del método que usa Toyota para producir y desarrollar automóviles. Como desarrolladores de software no hacemos ninguna de esas dos cosas, así que ¿por qué nos debería interesar? La razón es simple: los principios básicos del método de Toyota son principios que en la realidad aplican en cualquier lugar. No son panaceas: los principios son universales, aunque puedan variar las prácticas específicas. El término 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 prácticas ágiles. La participación 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 más ampliamente aceptados en la comunidad de desarrollo ágil. Ejemplos de ello sería la utilización del término "Lean-Agile" por empresas de consultoría como NetObjectives Pace y CC, así como la inclusión de algunos de estos conceptos. OBJETIVOS

1. Construir un mapa de la cadena de valor para su organización 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 generación 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 básicas, las cuales determinan las capacidades de su proceso de desarrollo de software.

5. Cuantificar la capacidad de su organización 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 métodos clásicos de mejora de procesos a problemas reales en su ambiente.

8. Crear métricas que guíen la optimización de resultados para la organización en su totalidad.


Los principios Lean

El desarrollo Lean puede resumirse en siete principios, muy cerca en concepto de los principios fabricación Lean. Los principios que guian a Lean pueden aplicarse al software. Esto brinda una guía para aquellos que intentan desarrollar software de manera más efectiva. En esta serie de artículos, en vez de describir a Lean por si sólo, vamos a describir a Lean en términos de las prácticas Ágiles que sugiere. Hay mucho poder en este conocimiento: cuando un coach Ágil se encuentra en una situación donde no se puede seguir una práctica Ágil estándar, los principios Lean lo van a guiar hacia un mejor camino. Los principios de Lean también nos muestran cosas diferentes para mirar además de las prácticas Ágiles. Al volver algunas cosas explícitas se logra que los coach Ágiles tengan más variedad a su alcance para mejorar los métodos.

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 más importantes son: La mayoría de los errores son de naturaleza sistémica 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 utilización 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-In-Time) 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 quizás es la situación en la cual se encontraba algunas de las personas que estamos culpando la que ocasionó el problema. Veamos un ejemplo típico del desarrollo de software. Supongamos que se te asigna como responsable de escribir una característica para un sistema existente. Te dan la documentación 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 tenés que confiar en el documento. Escribis el código, se prueba, se le muestra la nueva característica al cliente, que dice q eso no fue lo que pidio. ¿A quién culparías? ¿Al cliente por no ser claro? ¿Al analista por escribir algo pobremente? ¿A vos mismo, por no poder seguir la especificación? ¿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 están trabajando juntas. En otras palabras, el "sistema" actual hace que cada persona trabaje de manera separada en roles específicos. No existen


mecanismos de feedback, y se propagan los errores. Un "sistema" Ágil haría que las personas trabajen como equipo. El cliente, analista, desarrollador y testear hablarían entre ellos y decidirían juntos sobre las necesidades del cliente y la mejor forma de satisfacerla. Este sistema es mejor. Aunque todavía es posible que surjan errores, la mayoría se elimina porque la comunicación es mejor. Mejorar la comunicación es uno de los objetivos principales de Ágil; desafortunadamente, las prácticas Ágiles tienden a enfatizar la comunicación a un nivel local: entre el equipo, y entre el equipo y el cliente. Ágil ofrece un soporte pobre para mejorar la comunicación entre los equipos, arriba y abajo del flujo de valor, o a través de la compañía. Las prácticas Lean ayudan con la comunicación en estos contextos más grandes, haciendo énfasis en la mejora continua del proceso, la optimización del total, y la entrega rápida. En Lean, las demoras de la comunicación causan demoras y desperdicios, en la forma de errores, y por lo tanto deben ser eliminados. En los artículos siguientes de esta serie vamos a describir a Lean en términos de prácticas Ágiles, viendo como las diferentes prácticas apuntan a alguno de estos principios. Los siete principios

Eliminar los residuos El principio de eliminar los residuos (o muda, que es un tipo específico de residuos en el léxico Toyota) ha sido tomado de las ideas de Taiichi Ohno - el padre del Sistema de Producción Toyota. Se ha distinguido las actividades siguientes como residuos:

• Una parte de un automóvil 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 producción. • Defectos (menos calidad)

En otras palabras, aplicado al pensamiento Lean, todo lo que no añade valor al cliente se considera un residuo. Esto incluye:

• Código y funcionalidad innecesaria • Retraso en el proceso de desarrollo de software • Requisitos poco claros • Burocracia • Comunicación interna lenta

Con el fin de poder eliminar los residuos, uno debería ser capaz de reconocer y ver. Si alguna actividad podría ser superada o el resultado podría ser logrado sin ella, esta es un residuo. La codificación 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,


equipos o procesos son residuo. Defectos y menor calidad son los residuos. Gastos generales de gestión que no producen valor real son residuos. Se utiliza una técnica llamada value stream mapping de para distinguir y reconocer los residuos. El segundo paso consiste en señalar 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 técnico y de mercado - la organización puede ser exitosa si produce productos innovadores y tecnológicamente avanzados, pero es importante comprender lo que valoran nuestros clientes y conocer la tecnología que se está usando.

• Crear sólamente cosas de valor - debemos ser cuidados con todos los procesos que sigamos. Por ejemplo, debemos asegurarnos que todos estos procesos son útiles y están enfocados en crear valor.

• Escribir menos código - mientras más código se tenga, más pruebas se van a necesitar, por lo que se necesitará más trabajo. Si escribiemos pruebas para funcionalidad que no se necesita estamos perdiendo el tiempo.

Eliminar el desperdicio es la guía 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 código que es más complejo de lo necesario. El desperdicio surge cuando se crean defectos. En donde haya desperdicio, el practicante Lean observa al sistema para ver cómo eliminarlo porque es probable que cuando encontramos un error, va a continuar repitiéndose (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 tamaño de producto final. El mejor enfoque para la mejora de un entorno de desarrollo de software es ampliar el aprendizaje. La acumulación de defectos debe evitarse ejecutando las pruebas tan p ronto como el código está escrito . En lugar de añadir más documentación o planificación detallada, las distintas ideas podrían ser juzgados escribiendo código y construyendo. El proceso de recopilación de requisitos de usuarios podría simplificarse mediante la presentación 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 iteración cortos - cada uno de ellos junto con refactorización y pruebas de integración . Incrementando el feedback a través 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 períodos 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, basándose 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 comunicación con los clientes basado en el desarrollo, se concentra en la comunicación de las limitaciones de soluciones futuras y no las posibles soluciones, promoviendo así el nacimiento de la solución a través del diálogo con el cliente.


• Crear equipos de diseño y construcción - el líder del equipo de desarrollo tiene que escuchar a los miembros y hacerles preguntas inteligentes que los insite a buscar respuestas y volver lo más 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 estén mejorando continuamente en lo que trabajan - deben saber que no son y no deben ser perfectas - y que siempre tienen algún área que pueden mejorar.

• Enseñar métodos de resolución de problemas - los equipos de desarrollo deberían comportarse como pequeños centros de investigación, estableciendo hipótesis y realizando varios experimentos rápidos para verificar su validez.

Crear equipos de diseño y construcción - el líder del equipo de desarrollo tiene que escuchar a los miembros y hacerles preguntas inteligentes que los incite a buscar respuestas y volver lo más 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 estén mejorando continuamente en lo que trabajan - deben saber que no son y no deben ser perfectas - y que siempre tienen algún área que pueden mejorar. Enseñar métodos de resolución de problemas - los equipos de desarrollo deberían comportarse como pequeños centros de investigación, estableciendo hipótesis y realizando varios experimentos rápidos para verificar su validez.

Decida lo más 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 posibl e, hasta que estas se basen en hechos y no en suposiciones y pronósticos inciertos. Cuanto más complejo es un proyecto, más 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 podría ser muy costoso si se descubre después de la liberación 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 también permite la adaptación tardía a los cambios y previene de las costosas decisiones delimitadas por la tecnología. Esto no significa que no haya planificación involucrada en el proceso - por el contrario, las actividades de planificación deben centrarse en las diferentes opciones y se las adapta a la situación actual, así como se deben clarificar las situaciones confusas, estableciendo las pautas para una acción rápida. Evaluar las diferentes opciones es eficaz tan pronto como queda claro que ellos no son libres, pero proporcionando la flexibilidad necesaria para una tardía toma de decisiones.

• Agendar las decisiones irreversibles hasta el últim o momento responsable - debemos saber hacia donde queremos ir pero no conocemos el camino del todo, lo vamos descubriendo día a día - lo más importante es mantener la dirección correcta.


• Romper con las dependencias - los componentes deben estar lo más desacoplados posible para que puedan implementarse en cualquier orden.

• Mantener opciones - desarrollar múltiples soluciones para todas las decisiones críticas y ver cuales funcionan mejor.

Posponer el compromiso significa posponer comprometerse a tomar una acción hasta que tener toda la información necesaria para tomar la decisión a la que nos comprometemos, o hasta que no podamos esperar más a tomar esa decisión sobre qué hacer. Este principio puede usarse para guiar a los requerimientos, al análisis y al diseño de un sistema. Posponer el compromiso en los requerimientos y el análisis. Muy a menudo pensamos en los compromisos como en una acción o decisión que hicimos. Para también 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 atrás el tiempo. Al tomar requerimientos debemos preguntarnos - ¿en dónde debería usar mi tiempo? ¿Necesito discutir todos los requerimientos con el cliente? Claramente no. Algunos requerimientos son más importantes que otros. Debería empezar con los requerimientos que invlucran funcionalidad que es la más importante para el negocio, y por los requerimientos que crearán un riesgo técnico si no se los ataca tempranamente. Estos requerimientos que son los más importantes para el negocio son los que usualmente le dan más valor al cliente. Los métodos Ágiles se encargan de esto al hacernos enfocar en aquellos requerimientos que el cliente siente que son los más importantes. Esta es una de las principales justificaciones del desarrollo por iteraciones. Pero como guía sobre qué trabajo hacer no es suficiente mirar a la importancia de las características según el cliente. También hay que prestar atención a los riesgos arquitectónicos. ¿Cuáles requerimientos puede provocar problemas si se los ignora? Estos requerimientos también tienen que atenderse. Posponer el compromiso en el diseño. Los desarrolladores tienden a tomar uno o dos enfoques distintos cuando se los fuerza a diseñar algo que no tienen muy claro. Un enfoque es hacer las cosas lo más simple posible sin hacer nada para atajar a los requerimientos futuros (no confundir con la regla de Extreme Programming, que es hacer algo lo más 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 código que va a ser dificil de cambiar. Esto ocurre porque no se considera la naturaleza cambiante del código cuando se lo escribe. El segundo enfoque genera código que es más complejo del necesario. Esto ocurre porque la mayoría 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, métodos, etc.) que en realidad no se necesitan y agregan complejidad.


Reaccionar tan rápido como sea posible En la era de la rápida evolución de tecnológica, no es el más grande quien sobrevive, sino el más rápido. Cuanto antes el producto final se entrega sin defec tos considerables, más pronto se pueden recibir comenta rios, y se incorporan en la siguiente iteración . Cuanto más cortas sean las iteraciones, mejor es el aprendizaje y la comunicación 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 requería 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 rápida de un producto de calidad. La ideología de producción Just In Time podría aplicarse a programas de desarrollo, reconociendo sus necesidades específicas y el ambiente. Esto se logra mediante la presentación de resultados y la necesidad de dejar que el equipo organizarse y dividiendo las tareas para lograr el resultado necesario para una iteración específica . Al principio, el cliente dispone los requisitos necesarios. Esto podría ser simplemente presentan en pequeñas fichas o historias – y los desarrolladores estimarán el tiempo necesario para la aplicación de cada tarjeta. Así, la organización del trabajo cambia en sistema autopropulsado: cada mañana durante una reunión inicial, cada miembro del equipo evalúa lo que se ha hecho ayer, y lo que hay que hacer hoy y mañana, y pregunta por cualquier nueva entrada necesaria de parte de sus colegas o del cliente. Esto requiere la transparencia del proceso, que es también beneficioso para la comunicación del equipo.Otra idea clave del Sistema de Desarrollo de Producto de la Toyota se establece a base de diseño. Si un nuevo sistema de frenos es necesario para un coche, por ejemplo, tres equipos pueden diseñar soluciones al mismo problema. Cada equipo aprende sobre el problema de espacio y diseños de una posible solución. Cuando una solución se considera irrazonable, se desecha. Al final de un periodo, los diseños sobrevivientes se comparan y se elige uno, quizá con algunas modificaciones basadas en el aprendizaje de los demás, un gran ejemplo de compromiso aplazado hasta el último momento posible. Las decisiones en el software también podrían beneficiarse de esta práctica para minimizar el riesgo provocado por un solo gran diseño realizado por adelantado.

• Trabajar en bloques pequeños - reducir el tamaño 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 prácticas que crean obstáculos.

• Limitar el trabajo a la capacidad - limitar la cola de tareas al mínimo (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 utilizac ión - agregar tareas pequeñas 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


Potenciar el equipo Ha habido una creencia tradicional en la mayoría de las empresas acerca de la toma de decisiones en la organización - los administradores de decirle a los trabajadores de cómo hacer su propio trabajo. En una técnica Work-Out, los roles cambian: a los directivos se les enseña a escuchar a los desarroll adores , de manera que estos puedan explicar mejor qué acciones podrían tomarse, así como ofrecer sugerencias para mejoras. Los directores de proyecto más experimentados simplemente han declarado la clave de éxito de los proyectos: "Buscar la buena gente y dejarles hacer su propio trabajo". Otra creencia errónea ha sido considerar a las personas como recursos. Las personas podrían ser los recursos desde el punto de vista de una hoja de datos estadísticos, pero en el desarrollo de software, así como cualquier organización de negocios, las personas necesitan algo más que la lista de tareas y la seguridad de que no será alterada durante la realización de las tareas. Las personas necesitan motivación y un propósito superior para el cual trabajar – un objetivo alcanzable dentro de la realidad, con la garantía de que el equipo puede elegir sus propios compromisos. Los desarrolladores deberían tener acceso a los clientes, el jefe de equipo debe proporcionar apoyo y ayuda en situaciones difíciles, así como asegurarse de que el escepticismo no arruine el espíritu de equipo.

Crear la integridad El siempre exigente cliente debe tener una experiencia general del sistema – a esto se llama percepción de integridad: ¿cómo 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 función bien juntos , como en un todo, logrando equilibrio entre la flexibilidad, mantenibilidad, eficiencia y capacidad de respuesta. Esto podría lograrse mediante la comprensión del dominio del problema y resolviéndol o al mismo tiempo , no secuencialmente. La información necesaria es recibida por los pequeños lotes - no en una vasta cantidad y con una preferible comunicación cara a cara, sin ninguna documentación por escrito. El flujo de información debe ser constante en ambas direcciones - a partir del cliente a los desarrolladores y viceversa, evitando así la gran y estresante cantidad de información después 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 línea de código. Automatizar: automatizar las pruebas, la construcción, 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 duplicación de código a CERO - cada vez que aparezca la oportunidad, realizar el refactor del código, de las pruebas y de la documentación para minimizar la complejidad. Una de las maneras más saludables hacia una arquitectura integrante es la refactorización.


Cuanto más funcionalidades se añaden a las del sist ema, mas se pierde del código base para futuras mejoras . Así como en la metodología ágil XP, la refactorización es mantener la sencillez, la claridad, la cantidad mínima de funcionalidades en el código. . Las repeticiones en el código son signo un mal diseños de código y deben evitarse. El completo y automatizado proceso de construcción debe ir acompañada de una suite completa y automatizada de pruebas, tanto para desarrolladores y clientes, que tengan la misma versión, sincronización y semántica 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 también son consideradas como parte del proceso de producción y, por tanto, si no agregan valor deben considerarse residuos. Las pruebas automatizadas no deberían ser un objetivo, sino más bien un medio para un fin, específicamente para la reducción de defectos.

Respetar a las personas

• Capacitar a los líderes de equipo - darles a los líderes de equipo entrenamiento, guías y espacio libre para implmenetar el pensamiento Lean en su ambiente.

• Mover la responsabilidad y la toma de decisiones al nivel más bajo posible - dejar que las personas piensen y decidan por su cuenta - ellos saben mejor que nadie cómo implementar algoritmos dificiles y aplicar tecnologías de última generación.

• Fomentar orgullo por el trabajo - fomentar la pasión y la participación del equipo hacia lo que hacen y cómo lo hacen.

¿Quién debería 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 más inteligente que los trabajadores y sólo se podía confiar en ellos para decidir cómo mejorar la producción de automóviles. Ford tenía muy poco respeto por el conocimiento de sus trabajadores. Hay tres problemas con este pensamiento. Primero, si bien permitió construir un proceso estático muy bueno para construir un tipo de auto, el proceso no ofrecía ninguna flexibilidad. Recordemos la frase famosa de Ford que decía que las personas podían tener un auto "de cualquier color siempre y cuando ese color fuera el negro". Segundo, la mayoría de los procesos no son estáticos; siempre están cambiando. Los trabajadores de todas las líneas 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í cómo se cambian los procesos en la línea de producción. Por último, Ford podía exigirle a sus trabajadores en una época donde el valor principal de los trabajos era poder ser de sostén para la familia; hoy en día la compensación monetaria está relativamente baja en la lista de razones por las que uno selecciona un empleo. Hoy en día esta falta de respeto se traduciría 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 noción de que el equipo que hace el trabajo es responsable por el proceso que siguen. El proceso se convierte


en su comprensión de cómo 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 situación de la vida real. "Pensar en grande, actos pequeños, no rápido; 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. Sólo cuando todos los principios de Lean se aplican al mismo tiempo, combinado con un fuerte "sentido común" en relación 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 gráfica de Gantt le haya ayudado a sacar un proyecto adelante…? • Aquel al cual la documentación le haya sido de ayuda vital en darle

mantenimiento al software de alguien más? • Si a un líder de proyecto al cual el asignar y el controlar el avance de micro-

tareas a cada miembro del equipo le haya funcionado para que la gente se comprometa más con una fecha de entrega?

Proyectos, para las cuáles invertimos miles y miles de pesos en herramientas y cursos de CMM, PMI, MoProSoft y cuántos acrónimos más, cual oro de tontos nos estén 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 más de “control”; un “proceso” más definido y detallado que “obligue” a los programadores, rebeldes, negligentes o apáticos, a tener “conformidad” con el proceso mágico que resolverá todos nuestros problemas. Anhelamos recetas secretas, en realidad, lo que necesitamos es tan solo un sólido 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 sólidas 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 Métodos Ágiles, pero desde mi punto de vista están 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 Diseño Emergente. El Diseño Emergente en el software es una combinación de tres disciplinas:

1. Usar patrones de diseño para crear arquitectura de aplicaciones que son robustas y flexibles.

2. Limitar la implementación de estos patrones a aquellas características que sean relevantes.


3. Escribir pruebas unitarias y de aceptaciónautomatizadas antes de escribir el código para mejorar el proceso de pensamiento y para crear una "red de seguridad" de pruebas.

Los patrones de diseño hacen que el código sea facil de cambiar, limitarse a escribir código para lo que se necesita hace que el sistema se mantenga pequeño (y menos complejo), y las pruebas mejoran al diseño y hacen que el cambio sea seguro. El Diseño Emergente en su conjunto permite que se pueda posponer el compromiso para una implementación 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 código que no se necesita. • Tener código altamente acoplado entre si. •

Al hacer un desarrollo iterativo evitamos escribir código 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 Diseño Emergente nos asiste en el desacoplamiento al permitirnos usar código sin agregar complejidad innecesaria al hacerlo.

Crear conocimiento La creación 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 rápidamente y evitamos construir cosas de menos valor. Creo que el desarrollo de software es más un proceso de descubrimiento que de construcción. En este aspecto es muy parecido al desarrollo de productos. Una definición útil del Desarrollo de Productos es que son las actividades colectivas, o sistemas, que una empresa utiliza pra convertir su tecnología e ideas en un flujo de productos que satisfacen las necesidades de los clientes y los objetivos estratégicos de la empresa (Kennedy 2003). Más aún: 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 sólo 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, haríamos 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.


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 más tiempo. Imaginemos haber terminado un proyecto de desarrollo de software y luego, al final, perdemos todo el código fuente. Si quisieramos re-crear el sistema, ¿cuánto tiempo nos llevaría? 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 mayoría de los desarrolladores diría que esto les tomaría 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 cómo construir eso".

Entregar rápidamente Otra razón para hacer desarrollo iterativo es poder entregar valor de manera rápida al cliente. Esto permite lograr una mayor penetración en el mercado, mayor credibilidad del negocio con el cliente, más lealdad y otros intangibles. Sin embargo, también genera ganancias de manera más temprana, permitienendo que las entregas iniciales paguen al desarrollo subsiguiente. Si bien los beneficios de entregar rápidamente 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 código. 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 aceptación antes de escribir el código. Esto mejora la conversación alrededor de los requerimientos y también asiste a los desarrolladores en comprender qué funcionalidad se necesita escribir. Construir calidad en el código se logra por los métodos mencionados anteriormente para eliminar el desperdicio. La mayoría de los desarrolladores gastan mucho tiempo descubriendo cómo arreglar errores que fueron reportados. Esto es por falta de pruebas automatizadas y por una pobre calidad de código que lo hace dificil de entender. Optimizar el total Uno de los cambios más grandes generados por el pensamiento Lean fue cambiar la creencia de la producción en masa de que se necesita optimizar cada paso paso, y llegar a comprender que para incrementar la eficiencia del proceso de producción se necesita mirar al flujo de valor desde el principio del ciclo de producción hasta su final. En otras palabras, hacer que cada máquina funcione lo más eficientemente posible no va a funcionar tan bien como si miráramos 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 diseñar, codificar o probar). Lean demostró que un flujo de "una pieza" (por ejemplo, enfocarse


en construir un ítem de manera completa) es un proceso mucho más eficiente que concentrarse en construir todas las partes más rápido. Criticas al L.S.D 1. Eliminar el derroche Eliminar el derroche parece simple, como no existe una métrica considerar que es imprescindible para el desarrollo de una aplicación a veces puede causar conflicto entre los diseñadores. La burocracia y la comunicación lenta dentro de las organizaciones grandes es un atributo intrínsico de las mismas esto quizás 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 método. 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 tecnología no trabaja bien, ETC. 4. Liberar Rápido De acuerdo, generar cosas que funcionen rápidamente es mucho mejor que el desarrollo de todo el sistema en paralelo. 5. Facultar al equipo La organización del grupo de personas es todo un tema en si mismo. El dominio del problema debe de ser quien determina el tipo de organización adecuada. 6. Construir Integridad Intriseca Nunca se prueba o inspecciones están de más. 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 método de trabajo no los componentes humanos. Por q si uno de resfria … estamos en problemas. Finalmente creo q este método de trabajo nos da un enfoque realista de cómo se debe de trabajar, en lugar de desgastarse produciendo documentos y modelos que la verdad según mi experiencia solo son un derroche de energía. 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 rápidamente recurriendo a otra empresa.


Agilidad, Caos y Complejidad Teoría del caos es la denominación popular de la rama de las matemáticas, la física y otras ciencias que trata ciertos tipos de sistemas dinámicos muy sensibles a las variaciones en las condiciones iniciales. Pequeñas variaciones en dichas condiciones iniciales, pueden implicar grandes diferencias en el comportamiento futuro; complicando la predicción a largo plazo. Esto sucede aunque estos sistemas son deterministas, es decir; su comportamiento está completamente determinado por sus condiciones iniciales. Los sistemas dinámicos se pueden clasificar básicamente en:

• Estables. Un sistema estable tiende a lo largo del tiempo a un punto, u órbita, según su dimensión (atractor o sumidero).

• Inestables. Un sistema inestable se escapa de los atractores • Caóticos. Y un sistema caótico manifiesta los dos comportamientos.Por un lado,

existe un atractor por el que el sistema se ve atraído, 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 teorías de la complejidad tratan de con diversas clases de procesos, fenómenos y sistemas: autómatas celulares, redes booleanas aleatorias, redes neuronales, programación evolutiva, memética, dinámica no lineal, criticalidad auto-organizada, modelos basados en agentes autónomos, metaheurísticas, atractores extraños, gramáticas recursivas, series de Fibonacci, orden emergente, fractales. La cuestión merece tratarse en un estudio específico; aquí sólo brindaremos un puñado de indicios sobre esta peculiar convergencia.

• Algunos de los ideólogos de Scrum se inspiran en conceptos tales como filo del caos y control de procesos caóticos, tal como se los describe en el conocido libro Chaos de James Gleick. También afirman que Microsoft implementa en sus prácticas de desarrollo una estrategia de caos controlado, aunque no proporcionan mucho detalle a su razonamiento. Los autores también se refieren al modelo de L. B. S. Racoon referido al caos y al ciclo de vida caótico.

• En MSF 3.0 hay, como se ha visto, un comentario sobre la naturaleza caórdica

de los sistemas, en el sentido del concepto acuñado por Dee Hock, quien llevara a la práctica este concepto en la gestión de su propia compañía, Visa. Hock sostiene que la ciencia de la complejidad, ligada a la comprensión de los sistemas autocatalíticos, no lineales, complejos y adaptativos, habrá de ser la ciencia más importante del nuevo siglo. La visión caórdica de Hock (cuyas ideas sobre no linealidad tienen más de un punto en común con las de Fred Brooks) ha inspirado un movimiento caórdico de amplios alcances que va mucho más allá de las metodologías de desarrollo de software. El modelo de gestión Liderazgo-Colaboración 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 descripción de Craig Larman sobre Scrum incluye como bibliografía de referencia para comprender procesos adaptativos y autoorganización los dos textos clásicos de John


Holland, el padre del algoritmo genético, quien también ha ejercido influencia sobre Highsmith, como ya se ha visto. Jeff Sutherland ha señalado la analogía entre los saltos y discontinuidades de los procesos de desarrollo ágiles y el “equilibrio puntuado” de los procesos evolutivos complejos.

• En las páginas de su sitio empresarial y en su bibliografía, Jeff DeLuca establece

la estrecha relación entre las premisas de FDD y las teorías del caos determinista y de la complejidad, vinculándolas con el pensamiento no lineal de Fred Brooks y con la concepción del control de caos de Jim Highsmith.

• En su presentación de Adaptive Software Development, Highsmith afirma que su

práctica se basa en “estar en equilibrio en el filo del caos”: proporcionar suficiente guía para evitar caer en el caos, pero no demasiada, para no suprimir la emergencia y la creatividad. Este modelo basado en la analogía entre empresas/equipos/proyectos y sistemas adaptativos complejos, es, por mucho, el más vinculado a las nuevas ciencias de la complejidad y el caos [Hig00a]. Un ejemplo de estos sistemas podría ser una bandada de pájaros que se sincroniza sin que exista un líder que ejerza control y determine su dirección; cada pájaro 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 gestión basado en cooperación y competencia.

• Una visión 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 manifestación de trabajo en equipo, soluciones adaptativas y capacidades emergentes. LD promueve un diseño 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 más bien posmoderno. “Sus raíces filosóficas se encuentran en la teoría de los sistemas complejos” y sus capacidades se generan a través de procesos emergentes. Es significativo que este juicio haya sido expresado por el creador de la Programación Extrema.

Anti-agilidad: La crítica de los Métodos Ágiles A pesar de que nadie en sus cabales se opondría a que se lo considere ágil, adaptable y sensible a los requerimientos del cliente, es natural que se generara oposición a los que en ocasiones la reacción frente a ellos adoptara una fuerte actitud combativa. Si los ágiles han sido implacables en su caricatura de las metodologías rigurosas, los adversarios que se han ganado no se han quedado atrás en sus réplicas. En esta contienda hay algunas observaciones de carácter técnico, pero la ironía prevalece. Lo que sigue es apenas una muestra. Uno de los ataques más duros y tempranos proviene de una carta de Steven Rakitin a la revista Computer, bajo la rúbrica “El Manifiesto genera cinismo”. Refiriéndose 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 sólo sirven como excusas para que los hackers escupan código irresponsablemente sin ningún cuidado por la disciplina de ingeniería. Así como hay una lectura literal y una estrecha del canon de CMM, Rakitin practica una


“interpretación 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 interpretación hacker de ese mandamiento sería algo así como: “¡Genial! Ahora tenemos una razón para evitar la planificación y codificar como nos dé la gana”. Más 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 socarrón y su falta de método argumentativo. Que a último momento se redima a XP sugiriendo mejoras y refactorizaciones no ayuda a la causa de un dictamen anunciado desde sus títulos. Mucho más fundamentado es el estudio puramente crítico de Edward Berard, quien señala un buen número de “falacias” y medias verdades en el discurso ágil pero no logra, por alguna razón que se nos escapa, que su crítica levante vuelo. Gerold Keefer, de AVOCA GmbH, ha publicado ya dos versiones de un estudio titulado (con guiño a los expertos que reconozcan la alusión a Dijkstra) “Extreme Programming considerado dañino para el desarrollo confiable de software”. Algunos de los hechos tenidos en cuenta son que no sólo el primero, sino también el segundo proyecto de referencia de XP fueron cancelados; que las cifras que proporciona Beck sobre el costo del cambio metodológico 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 programación 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 programación en pares; a las malas prácticas resultantes de la negación a documentar; al retorno a la “programación de garage” y a la idea de que “el código se documenta a sí mismo” cuestionadas por Brooks hace treinta años; a la escasa verosimilitud de las historias de éxito de C3 y VCAPS, etcétera. Por añadidura, 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 físicamente distribuidos, ni (a pesar de su insistencia en reutilización y patrones) sobre integración de componentes listos para usar (COTS). A Keefer, por último, no le persuade la premisa de “hacer la cosa más simple que pueda funcionar”, sino que prefiere la postura de Einstein: “Que sea lo más simple posible, pero no más simple que eso”. Inesperadamente, el promotor de RAD SteveMcConnell se ha opuesto con vehemencia a las ideas más radicales del movimiento ágil. Se ha manifestado contrario tanto a las estrategias técnicas como a las tácticas 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 enfrían, 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 aviónica para un contrato de defensa de la misma manera en que se escribe un sistema de inventario para un negocio de alquiler de videos. Además, las reglas de XP son excesivamente rígidas; casi nadie aplica las 12 en su totalidad, y pocas de ellas son nuevas: Tom Gilb proponía lineamientos similares muchos años atrás. Dadas las premisas desaliñadas y las falsas publicidades, McConnell expresa que “el fenómeno parece un caso de hipnosis colectiva” [Baer03].


En diversas presentaciones públicas y en particular en SD West 2004, McConnell ha considerado la programación sin diseño previo, el uso atropellado de XP, la programación automática y la costumbre de llamar “ágil” a cualquier práctica como algunas de las peores ideas en construcción de software del año 2000. Un miembro de Rational, John Smith, opina que la terminología de XP encubre una complejidad no reconocida; mientras las palabras “artefacto” y “producto de trabajo” no figuran en los índices de sus libros canónicos, Smith cuenta más de 30 artefactos encubiertos: Historias, Restricciones, Tareas, Tareas técnicas, Pruebas de aceptación, Código de software, Entregas, Metáforas, Diseños, Documentos de diseño, Estándares de codificación, Unidades de prueba, Espacio de trabajo, Plan de entrega, Plan de iteración, Reportes y notas, Plan general y presupuesto, Reportes de progreso, Estimaciones de historias, Estimaciones de tareas, Defectos, Documentación adicional, Datos de prueba, Herramientas de prueba, Herramientas de gestión de código, Resultados de pruebas, Spikes (soluciones), Registros de tiempo de trabajo, Datos métricos, Resultados de seguimiento. La lista, dice Smith, es indicativa, no exhaustiva. En un proyecto pequeño, RUP demanda menos que eso. Al no tratar sus artefactos como tales, XP hace difícil operarlos de una manera disciplinada y pasa por ser más ligero de lo que en realidad es. Hay otras dificultades también; a diferencia de RUP, en XP las actividades no están ni identificadas ni descriptas. Las “cosas que se hacen” están tratadas anecdóticamente, con diversos grados de prescripción y detalle. Finalmente hay prácticas en XP que decididamente escalan muy mal, como la refactorización, la propiedad colectiva del código, las metáforas en lugar de una arquitectura tangible y las entregas rápidas, que no tienen en cuenta siquiera cuestiones elementales de la logística de despliegue. Smith afirma no estar formulando una crítica, 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 refactorización en general no escala muy bien. Eso se manifiesta sobre todo en proyectos grandes en los que hay exigencias no funcionales que son clásicas “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 refactorización será capaz de armar a Humpty Dumpty nuevamente.


CONCLUSIÓN La mayoría de los métodos de desarrollo de S.W proclaman ser EL MÉTODO! En mi opinión eso no es asi. Tomemos por ejemplo UML a pesar de su status de estándar ampliamente reconocido y utilizado, UML siempre ha sido muy criticado por su carencia de una semántica precisa, lo que ha dado lugar a que la interpretación de un modelo UML no pueda ser objetiva. Otro problema de UML es que no se presta con facilidad al diseño de sistemas distribuidos. En tales sistemas cobran importancia factores como transmisión, serialización, persistencia, etc. UML no cuenta con maneras de describir tales factores. No se puede, por ejemplo, usar UML para señalar que un objeto es persistente o remoto, o que existe en un servidor que corre continuamente y que es compartido entre varias instancias de ejecución del sistema analizado. Ademas de introducion otro nivel de abstracción que generalmente complica mas las cosas. Como el desarrrollo de S.W es una técnica 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 bibliográficas http://es.wikipedia.org/wiki/Lean_software_development http://www.netobjectives.com/blogs/lean-agile-software-development-chapter3-big-picture 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-software-development/ 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 Manager’s 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.

Tesis Final

Documents

Transcript of Tesis Final