P. 1
Tesis Final

Tesis Final

|Views: 1.819|Likes:
Publicado porGerman_Schmidt_8483

More info:

Published by: German_Schmidt_8483 on Jun 21, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

06/12/2013

pdf

text

original

Sections

  • INTRODUCCIÓN
  • Manifiesto de desarrollo ágil de software
  • PRINCIPIOS ÁGILES
  • Características del Software
  • El desarrollo tradicional del software
  • La imprevisibilidad de los Requisitos
  • Costo de los Cambios en la Construcción de SW
  • Los problemas y errores comunes de los métodos no ágiles
  • 1. Personas
  • Características del desarrollo ágil
  • Beneficios de usar desarrollo ágil
  • Desarrollo guiado por valor
  • Mejor manejo de riesgos e incertidumbre
  • Mejora de la productividad
  • Aplicabilidad del desarrollo ágil
  • Metodologías Ágiles de Desarrollo
  • X.P Extreme Programming
  • Las Historias de Usuario
  • Roles XP
  • Proceso XP
  • 1. Exploración
  • 2. Planificación de la Entrega
  • 3. Iteraciones
  • 4. Producción
  • 5. Mantenimiento
  • 6. Muerte del Proyecto
  • El juego de la planificación
  • Entregas pequeñas
  • Metáfora
  • Pruebas
  • Refactorización (Refactoring)
  • Programación en parejas
  • Propiedad colectiva del código
  • Integración continúa
  • 40 horas por semana
  • Cliente in-situ
  • Estándares de programación
  • Algunas de las críticas de Xp
  • SCRUM
  • Roles en Scrum
  • Reuniones en Scrum
  • Scrum de Scrum
  • Documentos
  • Crystal
  • Características
  • Dynamic Systems Development Method (DSDM)
  • Fases en la construcción de un sistema
  • Feature Driven Development (F.D.D)
  • Roles
  • Adaptive Software Development
  • Conclusion
  • LEAN SOFTWARE DEVELOPMENT
  • OBJETIVOS
  • Los principios Lean
  • Nociones previas importantes
  • Buscar la fuente de los errores en el sistema
  • Los siete principios
  • Eliminar los residuos
  • Ampliar el aprendizaje
  • Decida lo más tarde posible
  • Reaccionar tan rápido como sea posible
  • Potenciar el equipo
  • Crear la integridad
  • Respetar a las personas
  • Un poco mas de LEAN
  • Crear conocimiento
  • Entregar rápidamente
  • Criticas al L.S.D
  • Agilidad, Caos y Complejidad
  • CONCLUSIÓN
  • Referencias bibliográficas

DESARROLLO AGIL Y LEAN SOFTWARE DEVELOPMENT

TESIS
GERMAN E. SCHMIDT L.U: 41066

German E. Schmidt LU: 41066

1

Í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

German E. Schmidt LU: 41066

2

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

German E. Schmidt LU: 41066

3

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. cuesta más de lo presupuestado. Se trata de un compromiso público en buscar nuevas y mejores formas de desarrollar programas poniendo énfasis en las personas y sus interacciones. Una posible mejora es incluir en los procesos de desarrollo más actividades. a la colaboración con el cliente y al desarrollo incremental del software con iteraciones muy cortas. porque tantos proyectos de desarrollo software no tener tiempo. pero también han presentado problemas en otros muchos. y muchos programadores trabajando duramente y generando ganancias para las empresas y toda la sociedad. Cabe hacerse la siguiente pregunta. las cuales dan mayor valor al individuo. Por una parte tenemos aquellas propuestas más tradicionales que se centran especialmente en el control del proceso. 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. Estas propuestas han demostrado ser efectivas y necesarias en un gran número de proyectos. y las herramientas y notaciones que se usarán. Las metodologías ágiles están revolucionando la manera de producir software. Schmidt LU: 41066 4 . basándose en los puntos débiles detectados. la colaboración y la respuesta continua el cambio. los artefactos que se deben producir. 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. German E. Sin embargo. programadores y usuarios para que "el nuevo sistema" funcione como corresponde en tiempo y forma. explorando dos formas de hacer las cosas y compartiendo experiencias. Esta es la filosofía de las metodologías ágiles. 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.INTRODUCCIÓN El desarrollo de software no es una tarea fácil. como por ejemplo el factor humano o el producto software. estableciendo rigurosamente las actividades involucradas. 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. más artefactos y más restricciones. Prueba de ello es que existen numerosas propuestas metodológicas que inciden en distintas dimensiones del proceso de desarrollo.

Schmidt LU: 41066 5 . es más importante construir un buen equipo que construir el entorno. German E. etc. etc. pero el equipo falla. Colaboración con el cliente sobre de negociación contractual. 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. Una buena estrategia es hacer planificaciones detalladas para unas pocas semanas y planificaciones mucho más abiertas para unos pocos meses. pero el disponer más recursos que los estrictamente necesarios también puede afectar negativamente. Por ello.Manifiesto de desarrollo ágil de software Estamos descubriendo formas mejores desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. aunque no se tenga un proceso bien definido. en la tecnología. Respuesta ante el cambio sobre seguir un plan. las herramientas (compiladores. según los requisitos que el cliente manifestaba en ese momento. Muchas veces se comete el error de construir primero el entorno y esperar que el equipo se adapte automáticamente.) son importantes para mejorar el rendimiento del equipo. en el equipo. 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. En resumen. • • • Esto es aunque valoramos los elementos derecha valoramos más los de la izquierda. depuradores. control de versiones. la regla a seguir es “no producir documentos a menos que sean necesarios de forma inmediata para tomar un decisión importante”. el éxito no está asegurado. Así mismo. es más fácil conseguir el objetivo final. Si una vez iniciado el proyecto. Estos documentos deben ser cortos y centrarse en lo fundamental. Esta colaboración entre ambos será la que marque la marcha del proyecto y asegure su éxito. la planificación no debe ser estricta puesto que hay muchas variables en juego. Por lo tanto. un nuevo miembro se incorpora al equipo de desarrollo. No se necesitan desarrolladores brillantes. Si se sigue un buen proceso de desarrollo. A través este trabajo hemos aprendido a valorar: • individuos en interacciones sobre procesos y herramientas. Es mejor crear el equipo y que éste configure su propio entorno de desarrollo en base a sus necesidades. La habilidad de responder a los cambios que puedan surgir a los largo del proyecto (cambios en los requisitos. se propone que exista una interacción constante entre el cliente y el equipo de desarrollo. debe ser flexible para poder adaptarse a los cambios que puedan surgir. Aunque se parte de la base de que el software sin documentación es un desastre. sin embargo.) determina también el éxito o fracaso del mismo. La gente es el principal factor de éxito de un proyecto software. software funcionando sobre documentación extensiva. si el equipo funciona. sino desarrolladores que se adapten bien al trabajo en equipo.

Son: 1. Este principio implica además que la estructura del software debe ser flexible para poder incorporar los cambios sin demasiado coste añadido. no planificaciones. Los dos primeros son generales y resumen gran parte del espíritu ágil. 6. El estado de un proyecto no viene dado por la documentación generada o la fase en la que se encuentre. El software que funciona es la medida principal de progreso. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto. Este principio es una actitud que deben adoptar los miembros del equipo de desarrollo. gestión. con el menor intervalo de tiempo posible entre entregas. 4. sino por el código generado y en funcionamiento. Construir el proyecto en torno a individuos motivados. 5. un proyecto se encuentra al 50% si el 50% de los requisitos ya están en funcionamiento.PRINCIPIOS ÁGILES Los valores anteriores inspiran los doce principios del manifiesto. Los cambios en los requisitos deben verse como algo positivo. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva. 7. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses. 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. 2. El proceso de desarrollo necesita ser guiado por el cliente. Por ejemplo. German E. 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. por lo que la interacción con el equipo es muy frecuente. etc.) queda en segundo plano. todo los demás (proceso. Estos principios son las características que diferencian un proceso ágil de uno tradicional. Les va a permitir aprender más. Las entregas al cliente se insisten en que sean software. . Un proceso es ágil si a las pocas semanas de empezar ya entrega software que funcione aunque sea rudimentario. no es lo que el equipo espera. éste es el principal modo de comunicación. 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. Si cualquiera de ellos tiene un efecto negativo sobre los individuos debe ser cambiado. Los miembros de equipo deben hablar entre ellos. a la vez que logran una mayor satisfacción del cliente. El paradigma orientado a objetos puede ayudar a conseguir esta flexibilidad. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor. Luego existen una serie de principios que tienen que ver directamente con el proceso de desarrollo de software a seguir: 3. Se pueden crear documentos pero no todo estará en ellos. ni documentación de análisis o de diseño. entorno. Schmidt LU: 41066 6 .

German E. 10..8. etc. En intervalos regulares. desarrolladores y usuarios deberían ser capaces de mantener una paz constante. La atención continua a la calidad técnica y al buen diseño mejora la agilidad. sus reglas. Los procesos ágiles promueven un desarrollo sostenible. Tomar los caminos más simples que sean consistentes con los objetivos perseguidos. en cuanto metas a seguir y organización del mismo. para seguir siendo ágil. el equipo reflexiona respecto a cómo llegar a ser más efectivo. 12. 11. Es el propio equipo el que decide la mejor forma de organizarse. Los promotores. sino de mantener el ritmo de desarrollo durante toda la duración del proyecto. La simplicidad es esencial. sus convenciones. Schmidt LU: 41066 7 . Todo el equipo es informado de las responsabilidades y éstas recaen sobre todos sus miembros. La atención continua a la calidad técnica y al buen diseño mejora la agilidad. Finalmente los últimos principios están más directamente relacionados con el equipo de desarrollo. Las mejores arquitecturas. Producir código claro y robusto es la clave para avanzar más rápidamente en el proyecto. y según esto ajusta su comportamiento. Producir código claro y robusto es la clave para avanzar más rápidamente en el proyecto. el equipo también debe ajustarse al nuevo escenario de forma continua. Puesto que el entorno está cambiando continuamente. No se trata de desarrollar lo más rápido posible. 9. Si el código producido es simple y de alta calidad será más sencillo adaptarlo a los cambios que puedan surgir. Puede cambiar su organización. requisitos y diseños surgen de los equipos organizados por sí mismos. sus relaciones. de acuerdo a los objetivos que se persigan. asegurando en todo momento que la calidad de lo producido es máxima.

El software es excesivamente maleable. • Exigencia en eficiencia y los factores críticos que se le exigen. • 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. no se fabrica. • Todo el mundo exige que se realicen cambios sobre el Software como respuesta a pequeños cambios del entorno. • Con el Software ocurre lo mismo pero . Los sistemas actuales están formados por miles de funciones con interfaces complejas entre ellas. La fabricación no se considera tal. El Software se desarrolla. El Software se desarrolla. German E. o La curva ideal de fallos del Software. • • • • • Es inmaterial e invisible El comprador lo puede evaluar cuando ya ha sido construido. Schmidt LU: 41066 8 . desde la ortopedia hasta la exploración de otros planetas.Características del Software. El desarrollo es lento y costoso. Muchas aplicaciones se desarrollan a medida. sin usar componentes existentes. • En relación con la funcionalidad que aporta a la maquina. Ejemplo de ello son las herramientas CAD o el soporte a seguimiento de acontecimientos en el espacio. • El tratamiento comercial que tiene. o La curva real de fallos del Software. • 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.. La fabricación en serie y con costes estables. Clasificaciones del software desde diversos puntos de vista: • La utilización que se hace de el. • En cualquier sistema de producción podemos observar dos fases la de desarrollo y la de fabricación. • De ingeniería y Científico: Da soporte a los procesos creativos y de diseño de las personas. 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. Es complejo.. • Además no es fácil comprender su comportamiento. se caracteriza por cálculos matemáticos complejos. no se fabrica. • Ofimático: Software que permite a las personas utilizar los ordenadores en las tareas que habitualmente se realizan en oficinas. según Pressman: o La curva de fallos del Hardware. Es excesivamente maleable.

Schmidt LU: 41066 9 . a pequeña escala. German E. Va desde las alarmas hasta el control de temperaturas de un hogar. Domótico: Software que se utiliza para controlar el hábitat del ser humano.• • • De Formación y divulgación: Software que tiene por objetivo el transferir conocimientos al ser humano. 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.

pero conforme el sistema crece llega a ser cada vez más difícil agregar nuevos aspectos al mismo. Sin embargo. se toman las decisiones mayor relevancia. Las metodologías ingenieriles han estado presentes durante mucho tiempo. Aún menos por su popularidad. No se han distinguido precisamente por ser muy exitosas. debido a que el comienzo del proyecto.El desarrollo tradicional del software El desarrollo de software es una actividad problematica. que no lo más parecido a desarrollar programas que se conocía en ese momento. y el diseño del sistema se hace con muchas decisiones a corto plazo. El software se escribe con un plan subyacente mínimo. También hay que tener en cuenta que en esa época las computadoras eran grandes y extremadamente caras. • Testeo. • Diseño • Programación. y funcionó razonablemente bien en el comienzo. por ejemplo que existe un momento en el que se mejoren los requerimientos en base a comentarios. Además los errores llegan a ser cada vez más frecuentes y más difíciles de encontrar. sugerencias y necesidades de los responsables del diseño. 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. Las metodologías imponen un proceso disciplinado sobre el desarrollo de software con el fin de hacerlo más predecible y eficiente. • Análisis de requerimientos. Esto realmente funciona muy bien si el sistema es pequeño. Generalmente se trata de que haya retroalimentación entre las etapas contiguas. Hay tanto que hacer para seguir la metodología que el ritmo entero del desarrollo se retarda. solución esta dificultad. Se argumenta a favor de esto. 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. impacto e importancia para el resto del proyecto. Esta forma de trabajar surgió naturalmente hace unos 50 años como una adaptación manejo de proyectos de ingeniería. Lo hacen desarrollando un proceso detallado con un fuerte énfasis en planificar inspirado por otras disciplinas de la ingeniería. La forma tradicional de desarrollar programas se basa en procesos redefinidos con una documentación muy precisa y extensa. de tal forma. German E. Schmidt LU: 41066 10 . La crítica más frecuente a estas metodologías es que son burocráticas. esta forma de generar programas genera serios inconvenientes. es cuando menos se conocen las características del problema a resolver. 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. 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. una planificación inicial súper detallada que debe seguirse estrictamente. frecuentemente caracterizada por la frase "codifica y compilar". La seña típica de tal sistema es una larga fase de pruebas después de que el sistema ha sido terminado. Tradicionalmente los proyectos se dividen en etapas bien definidas: • Análisis de factibilidad. que cuenta con profesionales que conozcan el área de aplicación del problema.

Se supone que el proceso de la construcción seguirá los dibujos. Muchas decisiones de diseño. esto ocurre con mayor frecuencia en casos en que el grupo de desarrollo debiera crear algo totalmente nuevo. Los ingenieros trabajan sobre una serie de esquemas que indican precisamente qué hay que construir y como deben juntarse estas cosas. Para hacerlo debemos separar el plan de la construcción. Así que lo que vemos aquí son dos actividades fundamentalmente diferentes. a menudo una compañía diferente. En ingeniería civil la construcción es mucho más costosa y tardada que el diseño y la planeación. para ser construidos. lo cual es muy cierto para la mayoría los proyectos de software. podemos ocuparnos de la construcción de una manera más predecible. podemos armar un plan de construcción y entonces podemos dar planes a los programadores como una actividad de construcción. actúan como los fundamentos de un plan de construcción detallado. Como propuesta para solucionar estos problemas han surgido una serie de "métodos ágiles" de desarrollar programas y manejo de proyectos en general. 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. o de características específicas que nadie creado aún. Una vez que tenemos el plan de construcción. cuyas características serán enunciadas a continuación. El diseño. ¿Qué forma toma este plan? Para muchos. Los dibujos se entregan entonces a un grupo diferente. 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. éste es el papel de notaciones de diseño como el UML. También dice en detalle cómo deben hacer su trabajo las personas que participan en la construcción. aunque se necesita a menudo mucha habilidad manual. se toman conforme los dibujos se producen. Dicho plan define las tareas que necesitan hacerse y las dependencias que existen entre estas tareas. 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. como la manera de controlar la carga sobre un puente.Como los dibujos especifican las piezas y cómo deben unirse. En la práctica los constructores se encuentran con algunos problemas. y resulta mucho más caro que lo presupuestado. Porque en caso contrario. Esto permite que la construcción requiera menos pericia intelectual. German E. no se termina tiempo. Una vez que tenemos el diseño. pero éstos son normalmente poco importantes. Tales disciplinas enfatizan que hay que planear antes de construir. y la construcción que es más fácil de predecir.La información recogida a lo largo del tiempo demuestra que contar con expertos es importante. Esto permite un plan de trabajo y un presupuesto de construcción razonablemente predecibles. Schmidt LU: 41066 11 . En particular. Si podemos hacer todas las decisiones significativas usando UML. podemos planear la construcción. la organización compré directamente un producto sistema ya hecho en lugar de desarrollarlo por ellos mismos. Así el acercamiento de muchas metodologías es: queremos un plan de trabajo predecible que pueda usar gente del más bajo nivel. pero no soluciona la crisis. qué es difícil de predecir y requiere personal caro y creativo.

Los procesos creativos no se planean fácilmente. como el modo en que juegan las fuerzas. Otro problema es el costo comparativo. Mientras esto es útil trae errores al diseño que sólo se descubren durante la codificación y pruebas. Cuando se construye un puente. Incluso los diseñadores experimentados. Estas ideas llevan a algunas conclusiones importantes: • • • En software la construcción es tan barata que es casi gratis. sólo 15% del proyecto son código y pruebas unitarias. Aun cuando se consideren las pruebas parte de la construcción. 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. se sorprenden a menudo cuando convierten dichos diseños en software. El problema con un diseño tipo UML es que puede parecer muy bueno en el papel. • Debemos ser muy cautos al usar la metáfora de la ingeniería tradicional para construir software. 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. En software todo el esfuerzo está en el diseño. el costo del esfuerzo en el plan es aproximadamente un 10% del total. Además los problemas importantes. de modo que requiere de personas creativas y talentosas. ¿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. De hecho cualquier cosa que pueda tratarse como construcción puede y debe automatizarse. German E. Steve McConnell sugiere que para un proyecto grande. En software la cantidad de tiempo gastada codificando es mucho. siendo el resto la construcción. mucho menor. de modo que la previsibilidad bien puede ser una meta imposible. pero resultar seriamente fallido a la hora de la programación. una inversión casi perfecta de las proporciones de la construcción del puente. Esto genera una pregunta importante sobre la naturaleza del diseño en software comparado con su papel en otras ramas de la ingeniería. son dóciles al análisis matemático. el plan es todavía 50% del total. Es un tipo diferente de actividad y por ende requiere un proceso diferente. La única verificación que podemos hacer con los diagramas UML es la revisión cuidadosa.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. Schmidt LU: 41066 12 . Los modelos que los ingenieros civiles usan está basado en muchos años de práctica guardados en códigos ingenieriles.

porque entonces "saben" que el software es fácil de cambiar. Una forma es tratar los requisitos cambiantes como el resultado de una pobre ingeniería de requisitos. Sin una buena idea del costo. Después de todo se supone que el software es "suave". Casi todo en el desarrollo de software depende de los requisitos. 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. conseguir la firma del cliente sobre estos requisitos. 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. Un problema con esto es que simplemente tratar de entender las opciones para los requisitos es duro. no será tan bueno en seis meses. Si no se pueden obtener requisitos estables no se puede obtener un plan predecible. 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.La imprevisibilidad de los Requisitos Hay un dicho que se oye en cada proyecto problemático. Es aun peor si ellos han estado alguna vez en desarrollo de software. y los individuos son difíciles de predecir y cuantificar. la pregunta es qué hacemos al respecto. Y muchos cambios en el mundo de negocios son completamente imprevisibles: cualquiera que diga otra cosa está mintiendo. Schmidt LU: 41066 13 . German E. el mundo de negocios no va a detenerse por él. y entonces preparar procedimientos que limiten los cambios de requisitos después de la firma. ¿cómo puede el cliente decidir si quiere pagar por ese pedido? La estimación es difícil por muchas razones. 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. difícil de planear y costear. o ya ha hecho mil millones en la bolsa de valores. Pero aun cuando se pudiera controlar todo esto y realmente se pudiera conseguir un conjunto exacto y estable de requisitos. Aún cuando el cliente pueda corregir sus requisitos. En la economía de hoy las fuerzas de negocios fundamentales cambian el valor de los rasgos de software demasiado rápidamente. El cliente termina solicitando algo que el vendedor no puede cotizar con exactitud. En parte por lo mucho que depende de los individuos involucrados. En el negocio de construcción de software los cambios en los requisitos son la norma. En parte porque el desarrollo de software es una actividad de diseño. sino que deben de serlo. Así no sólo son cambiables los requisitos. El que podría ser un buen conjunto de requisitos ahora. Es aun más duro porque la organización del desarrollo normalmente no proporciona la información del costo en los requisitos. Toma mucha energía conseguir que los clientes de software corrijan los requisitos. probablemente aún no estamos a salvo. En parte porque los materiales básicos cambian rápidamente.

Esto lleva a la gente a usar una metodología en malas circunstancias. y muchos de los modelos para llevar la relación con el cliente. y entonces no pueden manejar la situación cuando el plan se cae en pedazos. Como en tantos problemas la parte más difícil está simplemente en comprender que el problema existe. Durante algún tiempo usted podrá pretender que el plan es válido. De eso se trata la adaptabilidad. La previsibilidad es una propiedad muy deseable. 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. German E. Usted acaba viendo el plan y la realidad flotando aparte. Hay una tentación fuerte para hacer eso. sin embargo no se cree que el software comercial encaje en esa categoría. Ése es un golpe duro. Hay algunos desarrollos de software dónde la previsibilidad es posible. lleva a situaciones en donde las personas construyen un plan temprano. no. Schmidt LU: 41066 14 . Los beneficios de la previsibilidad son tan grandes. Uno de los grandes peligros es pretender que se puede seguir un proceso predecible cuando no se puede. que es difícil dejarlos ir. La mayoría de los metodologistas quieren que sus metodologías sean usadas por todos.¿Es Imposible la Previsibilidad? En general. No obstante creer que se puede ser predecible cuando no se puede. Para éste se necesita un tipo diferente de proceso. de modo que no entienden ni publican sus condiciones límite. ya no son ciertos. Más bien hace falta un proceso que pueda dar control sobre la imprevisibilidad. Normalmente la caída es dolorosa. como usar una metodología predictiva en una situación imprevisible. Así si usted está en una situación impredecible no puede usar una metodología predictiva. Pero en algún punto la deriva es demasiada y el plan se cae en pedazos. De cualquier modo dejar ir la previsibilidad no significa que hay que volver al caos ingobernable. Significa que tantos modelos para controlar proyectos.

5 1 1.5 Millones de dolares 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. costo del cambio metodología tradicional suposición metodología ágil tiempo German E. a medida que avanza el tiempo. Área: Sistemas de Defensa en Tiempo Real Pagado pero no entregado Entregado pero no utilizado abandonado o rechazado Utilizado después de cambios Utilizado como se entrego 0 0. Schmidt LU: 41066 15 .5 2 2. 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. Como se puede apreciar.5 3 3.

El resultado es predecible: rehacer el trabajo de la manzana podrida. Personas A continuación aparecen algunos de los errores clásicos relacionados con las personas. 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. Algunos directivos fomentan el comportamiento heroico cuando se concentran con demasiada firmeza en actitudes del tipo "ser capaz de". para dar recompensas al final del proyecto que resultan ser de menos de un dólar por cada hora extra. sus consecuencias se han hecho fáciles de predecir. Motivación débil. 1. directivos y clientes normalmente tienen buenas razones para tomar las decisiones que toman. Ni siquiera saben que tienen que emprender acciones correctoras hasta que el daño ya está hecho. Pero lo que hacen tiene más de malo que de bueno. Como dijo Tom DeMarco. y la apariencia seductora de los errores clásicos es una de las razones de que esos errores se cometan tan a menudo. El énfasis en los comportamientos heroicos fomenta correr un riesgo extremo. Y los errores rara vez producen los resultados que la gente espera. 1. 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.3. las actitudes <<ser capaz de>> convierten pequeños contratiempos en auténticos desastres. Hazañas. e impide la cooperación entre los múltiples elementos que contribuyen al proceso de desarrollo del software. 1.Los problemas y errores comunes de los métodos no ágiles Los desarrolladores. Estudio tras estudio ha mostrado que la motivación probablemente tiene mayor efecto sobre la productividad y la calidad que ningún otro factor. pero el jefe del equipo no hace nada. y como irse de vacaciones mientras el equipo esta trabajando incluso los días de fiesta. el equipo sabe que uno de ellos es una manzana podrida. 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. 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 resultado es un modelo de planificación al límite en el que las amenazas de desajuste del plan no se detectan. Schmidt LU: 41066 16 . Un fallo al tratar con personal problemático también amenaza la velocidad de desarrollo.1. Pero debido a que se han cometido muchas veces. Algunos desarrolladores de software ponen un gran énfasis en la realización de hazañas en los proyectos. no se conocen o ni se informan a la cadena de directivos hasta el último minuto.2. 1. German E. los directivos de estos proyectos coartan su capacidad de tomar medidas correctivas. Elevando estas actitudes por encima de informes del estado exacto y a veces pesimista. Empleados problemáticos incontrolados.

Las fricciones entre los clientes y los desarrolladores pueden presentarse de distintas formas. Alrededor del 60 por 100 indican que no tienen suficiente silencio ni privacidad. Ejemplo. 1. En el caso medio.7. 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. Los entornos repletos y ruidosos alargan los planes de desarrollo. 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. incluyendo una planificación realista. Este es quizás el más clásico de los errores clásicos. Fricciones entre los clientes y los desarrolladores. y de que puede ser malo. La mayoría de los desarrolladores consideran sus condiciones de trabajo como insatisfactorias. Para remediar estas fricciones se consume tiempo.6. pobre diseño de la interfaz de usuario y. 1.4.1. las fricciones entre clientes y desarrolladores de software llegan a ser tan severas que ambas partes consideran la cancelación del proyecto (Jones. Pueden ser simplemente conflictos de personalidad entre dos grupos. y los efectos secundarios de la mala comunicación incluyen el pobre entendimiento de los requerimientos. Falta de un promotor efectivo del proyecto. no tener razones técnicas para pensar que un software se podrá desarrollar en 6 meses. German E.8. La incapacidad del jefe de proyecto para corregir esta expectativa irreal será la principal fuente de problemas. 1. 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. el rechazo del cliente a aceptar el producto acabado. 1. y distraen tanto a desarrolladores como a clientes del trabajo real en el proyecto. 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. Todos los principales participantes del esfuerzo de desarrollo de software deben implicarse en el proyecto. Schmidt LU: 41066 17 . Oficinas repletas y ruidosas. el control de cambios y la introducción de nuevos métodos de desarrollo. Para soportar muchos de los aspectos del desarrollo rápido es necesario un promotor del proyecto de alto nivel. Expectativas pocos realistas. Añadir gente a un proyecto retrasado con echar nafta al fuego. añadir más gente puede quitar más productividad a los miembros del equipo existente de la que añaden los nuevos miembros. contribuyen a la percepción de que el plan de desarrollo es demasiado largo.9. Añadir más personal a un proyecto retrasado. los directivos o los desarrolladores de un proyecto se buscan problemas al pedir fondos basándose en estimaciones de planificación demasiado optimistas. El principal efecto de esta fricción es la mala comunicación. Falta de participación de los implicados. Aunque por sí mismas las expectativas irreales no alargan el plan. Cuando un proyecto se alarga. 1994).5. pero ése es el plazo en que lo quiere el comité ejecutivo de la compañía. Sin un promotor ejecutivo efectivo. en el peor caso. 1. Una de las causas más comunes de fricciones entre los desarrolladores y sus clientes o los directivos son las expectativas poco realistas. En otros casos.

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. creando fronteras para el proyecto que mantienen cerradas a los que no son miembros del equipo. 1. clientes y cualquiera que se juegue algo con el proyecto. miembros del equipo. pero tenemos una buena comunicación para otras cosas. 1. y tienen un poco de suerte. 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. La cooperación estrecha sólo se produce si se han implicado todos los participantes. La razón número uno de que los proyectos de Sistemas de Información tuviesen éxito es la implicación del usuario. Falta de participación del usuario. serán capaces de concluir con éxito".Incluyendo a los promotores. Hay cuatro tipos diferentes de orientaciones políticas. Los "aislacionistas" están solos. ejecutivos. que es imposible conseguir sin una buena participación. Schmidt LU: 41066 18 . "Nuestro equipo no hace mucho trabajo para la coordinación de las interfaces entre las distintas partes del producto. Realmente consisten en cerrar los ojos y esperar que todo funcione cuando no se tienen las bases razonables para pensar que será así. 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. Los "investigadores" se centran en explorar y reunir la información. y nada va mal. Las ilusiones al comienzo del proyecto llevan a grandes explosiones al final. permitiendo una coordinación precisa del esfuerzo para el desarrollo rápido. German E. Primar la política en vez de los resultados es fatal para el desarrollo orientado a la velocidad. 1. responsables del equipo. Los "políticos" están especializados en la "gestión".12. y las interfaces son relativamente simples. Muchos problemas del desarrollo del software se deben a la ilusión. Política antes que desarrollo. personal de ventas.11.10. centrándose en las relaciones con sus directivos. usuarios finales. Ilusiones. así que probablemente sólo necesitaremos un día o dos para eliminar los errores" Las ilusiones no son sólo optimismo. pero piensan que quizás si trabajan duro.

También supone una excesiva presión para los desarrolladores. y caer entonces en el modo de trabajo de codificar y corregir. no podemos esperar obtenerlo. son todos demasiado predecibles. A continuación se muestran algunos de los peores errores relacionados con el proceso. 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. Abandono de planificación bajo presión. y puesto que el análisis de requerimientos. la arquitectura y el diseño no producen código directamente. 2. Planificación excesivamente optimista. quienes a largo plazo se ven afectados en su moral y su productividad.2. este tiempo normalmente se pierde en el proceso de aprobar y hacer el presupuesto. y reduciendo las actividades críticas para el desarrollo. y entonces se está a las puertas de un plan agresivo. el trabajo no tiene coordinación ni elegancia. Gestión de riesgos insuficiente. Los resultados de este error. Planificación insuficiente. No es poco común que un proyecto desperdicie meses o años en un inicio difuso. Schmidt LU: 41066 19 . 2. 2. con un costo de 10 a 100 veces superior a haberlo hecho bien inicialmente. A partir de este punto. Los proyectos se aceleran intentando acortar las actividades "no esenciales". Si no podemos encontrar cinco horas para hacer el trabajo correctamente la primera vez.5.6.4. El fallo de no gestionar uno solo de estos riesgos es un error clásico. Proceso Los errores relacionados con el proceso malgastan el talento y el esfuerzo del personal. 2. y esto es lo habitual. El problema no está en el abandono del plan.1. Los proyectos que normalmente escatiman en sus actividades iniciales tendrán que hacer ese trabajo en otro momento. Como con los errores clásicos. Ejemplo. ¿cómo vamos a encontrar 50 para hacerlo correctamente más tarde? German E. minando la planificación efectiva. si no ejercemos una gestión activa de los riesgos.2. Si no planificamos para conseguir un desarrollo rápido. 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. como el análisis de requerimientos o el diseño. son los candidatos fáciles. Fijar un plan excesivamente optimista predispone a que el proyecto falle por infravalorar el alcance del proyecto. también conocido como "saltar a la codificación". 2. Pérdida de tiempo en el inicio difuso. un equipo abandona su plan después de fallar en la primera entrega. sino más bien en fallar al no crear un plan alternativo. 2. Son los llamados "riesgos". Algunos errores no son lo suficientemente habituales como para considerarlos clásicos. 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. El "inicio difuso" es el tiempo que transcurre antes de que comience el proyecto.3. Los equipos de desarrollo hacen planes y rutinariamente los abandonan cuando se tropiezan con un problema en la planificación. Escatimar en las actividades iniciales.

Control insuficiente de la directiva.9. algunos proyectos de desarrollo rápido intentan forzar la convergencia media docena de veces o más antes de que finalmente se produzca. Escatimar en el control de calidad. 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. 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. 2.10. olvida las tareas menos visibles. eliminando las revisiones del diseño y del código. por lo que necesitará varios ciclos de diseño de poder finalizar completamente el sistema. imprimir la documentación final. Poco control de la directiva para detectar a tiempo los signos de posibles retrasos en el plan.2. Aprenderemos más del producto conforme lo estamos construyendo. 2. Planificar ponerse al día más adelante. En los proyectos que se hacen con prisa se suele cortar por lo sano. eliminar las funciones que no van a estar listas a tiempo y demás. la cantidad de tiempo necesaria para construirlo cambiará también. mejorar el rendimiento del producto.11. Omitir tareas necesarias en la estimación. Si el producto que estamos construyendo cambia. El crecimiento de las nuevas prestaciones sin ajustar el plan garantiza que no se alcanzará la fecha de entrega. pulir el programa de instalación. 2. Puesto que no es posible forzar la convergencia del producto cuando se desea. Diseño inadecuado. Estos conocimientos necesitan reflejarse en la reestimación del plan. incorporar entradas en el sistema final de ayuda. Los intentos adicionales de convergencia no benefician al producto. German E. hay una tendencia a forzar prematuramente la convergencia.12. El énfasis en el diseño está más orientado a la conveniencia que a la calidad. Otro tipo de error es la reestimación que se debe a cambios en el producto. Convergencia prematura o excesivamente frecuente. Si hemos trabajado en un proyecto durante 6 meses.8. Un tipo de reestimación es responder inapropiadamente el retraso del plan. Schmidt LU: 41066 20 . Sólo son una pérdida de tiempo y prolongan el plan. Si la gente no guarda cuidadosamente datos de proyectos anteriores. pero son tareas que se han de añadir.7. Proyectos acelerados generan un diseño indeterminado. eliminando la planificación de las pruebas y realizando sólo pruebas superficiales. Bastante antes de que se haya programado entregar un producto. incluyendo más sobre lo que nos llevará construirlo. 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. El esfuerzo omitido suele aumentar el plan de desarrollo en un 20 o 30 por 100.en primer lugar debemos ser capaces de decir si va por buen camino. y los pocos controles definidos al comienzo se abandonan cuando el proyecto comienza a tener problemas. 2. hay un impulso para preparar el producto para la entrega. En proyectos hechos con prisa. Antes de encarrilar un proyecto. pero nunca se hace. Un caso especial de escatimar en las actividades iniciales es el diseño inadecuado.

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. A medida que se avanza en el proyecto se conoce más y se reduce el error hasta llegar a la certeza. procesos y código. mejorando o implementando. 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. Periódicamente el cliente evalúa el estado del programa que se está creando. o no llevó al equipo obtener los resultados esperados. 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. intentando extraer algunas conclusiones útiles. • Sugerir mejoras o funcionaria valiosa que no se había considerado. lo que repercute en un producto de mejor calidad. estimada el principio de un proyecto variaría entre 4x y 0. Además los usuarios o clientes reciben periódicamente prototipos a medida que el producto se va construyendo. lo que permite detectar problemas y resolverlos antes que se desaten las crisis que afecta la calidad el tiempo o del costo desarrollo. Adicionalmente los desarrolladores suelen trabajar mucho en equipo y también en parejas.Características del desarrollo ágil. A nivel procesos se realizan frecuentes reuniones retrospectivas donde los integrantes de los equipos comentan y discuten en profundidad sus aciertos. 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. que luego se va incrementando y mejorando.25x. desgraciadamente esta ocurre sólo cuando se finaliza el proyecto. Schmidt LU: 41066 21 . 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. para poder repetirlos y convertirlos en hábitos y así también como el trabajo no se realizó en forma correcta. 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. German E. lo que asegura que el entregado al final del proyecto coincida con lo esperado. empowerment: consiste en otorgar autonomía para tomar decisiones al equipo de desarrollo. por ejemplo costó esfuerzo. Cono de incertidumbre Boehm y Steve McConnell indican que cualquier variable x del proyecto. mejor documentado y simple de mantener. así también como una mejora constante en la forma de trabajo de los equipos. revisando juntos el código resolviendo problemas en lugar de tratar de cubrirlos. lo cual les permite: • evaluar el trabajo realizado. 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. Los principales tipos de feedback ocurren a nivel producto. Feedback: constante presente en varios niveles permite el desarrollo incremental y el crecimiento adaptativo de la programación. • Advertir sobre problemas que se detecten.

y modificar la dirección del proyecto basado en lo que hemos aprendido hasta el momento. es decir. o en el caso de tecnologías no conocidas por el equipo. en cambio los beneficios obtenidos urgentes de brindar visibilidad. Si organizamos el proyecto de manera que cliente reciba ese 20% de funcionalidad lo antes posible. German E. en los que los requerimientos son poco conocidos. que se utiliza también en otras áreas de Scrum. se realiza el proyecto de manera de entregar el producto funcionando en intervalos cortos. Por ejemplo: Si estamos arrollando un producto que será puesto en producción con servidores que deben adquirirse. Para lograr estas ventajas se requiere tanto de cambios internos en el equipo. En estos casos. Esto puede modificar como organicemos el trabajo. el método Srum no define prácticas técnicas (como hacer las cosas). Por ejemplo. • Mejora de la productividad. Mejor manejo de riesgos e incertidumbre Cuando se analizan proyectos. empezar a recibir el valor del resultado del proyecto antes. sin grandes costos para ninguna de las partes. Desarrollo guiado por valor en muchas situaciones con los sistemas se presente una relación de parapeto. Esto puede ser que incluso se replantee la necesidad o que cambie la definición del resto del proyecto. como en el cliente. 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.Beneficios de usar desarrollo ágil las mejoras obtenidas por usar el método de desarrollo ágil dependen de la situación. a un nivel suficiente como para ser destinadas con una confianza suficiente. Sus es Proyecto complejo: sus la planificación requiere que se pueda identificar una lista completa de las tareas que debemos realizar. Esta situación es particularmente notoria en caso proyectos complejos. Esta es una de las aplicaciones del concepto de inspeccionar y adaptar. ya sea sin esa restricción. Esto es difícil en algunos contextos. • Mejor manejo de riesgos e incertidumbre. estamos en el área marcada como proyectos complicados o complejos. intentamos planificar la ejecución para lograr minimizar los riesgos y utiliza los recursos de manera más eficiente posible. Pero hay algunas mejoras que típicamente se tienen con el desarrollo ágil: • desarrollo guiado por valor. en el que se priorizan las mejoras según la necesidad del negocio. probablemente lo ideal sería esperar hasta tener una prueba de performance con el producto completamente desarrollado. y un marco de trabajo de mejora continua. para poder asegurar que estará disponible. es decir comprado entregado instalado y configurado para el momento en que se necesite. Con esta idea en la cabeza. y en este caso el balance entre planificar y no planificar se corre hacia la menos planificación. según la definición de complejo que será continuación. o el ambiente de negocios nuevo. Schmidt LU: 41066 22 . en el cual un 20% de la funcionalidad provee un 80% del valor. lo que facilita encontrar las áreas de mejora. es necesario que mencionemos el equipo necesario con 12 meses de anticipació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.

German E. Schmidt LU: 41066

23

Metodologías Ágiles Metodologías Tradicionales Basadas en heurísticas provenientes de Basadas en normas provenientes de prácticas de producción de código estándares seguidos por el entorno de desarrollo Especialmente preparados para cambios Cierta resistencia a los cambios durante el proyecto Impuestas internamente (por el equipo de Impuestas externamente desarrollo) Proceso menos controlado, con pocos Proceso mucho más controlado, con principios numerosas políticas/normas No existe contrato tradicional o al menos Existe un contrato prefijado es bastante flexible El cliente es parte del equipo de desarrollo El cliente interactúa con el equipo de desarrollo mediante reuniones Grupos pequeños (<10 integrantes) y Grupos grandes y posiblemente trabajando en el mismo sitio distribuidos Pocos artefactos Más artefactos Pocos roles Más roles Menos énfasis en la arquitectura del La arquitectura del software es esencial y software 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

German E. Schmidt LU: 41066

24

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.

German E. Schmidt LU: 41066

25

2. El cliente selecciona qué construir. Guía al equipo para resolver un problema específico. 3. Encargado de seguimiento: proporciona realimentación al equipo en el proceso XP. Cliente: escribe las historias de usuario y las pruebas funcionales para validar su Implementación. 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. El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos: 1. Además. Entrenador: es responsable del proceso global. comunicando los resultados para mejorar futuras estimaciones. De la misma forma el German E. Vuelve al paso 1. 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. de acuerdo con sus prioridades y las restricciones de tiempo. Ejecuta las pruebas regularmente. 5. 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. 4. El programador construye ese valor de negocio. 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. Su labor esencial es de coordinación. Consultor: es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto. difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas. En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. El cliente define el valor de negocio a implementar. Schmidt LU: 41066 26 . Encargado de pruebas: ayuda al cliente a escribir las pruebas funcionales. Debe existir una comunicación y coordinación adecuada entre los programadores y otros miembros del equipo. Determina cuándo es necesario realizar algún cambio para lograr los objetivos de cada iteración. Su responsabilidad es verificar el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado. Gestor: Es el vínculo entre clientes y programadores. ya que se perderá calidad en el software o no se cumplirán los plazos. No se debe presionar al programador a realizar más trabajo que el estimado. 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. El programador estima el esfuerzo necesario para su implementación. ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas.Roles XP Programador: escribe las pruebas unitarias y produce el código del sistema.

establecida en puntos por iteración. equivale a una semana ideal de programación. La planificación se puede realizar basándose en el tiempo o el alcance. los programadores realizan una estimación del esfuerzo necesario de cada una de ellas. Una entrega debería obtenerse en no más de tres meses. 4. Planificación de la entrega (Release). Las historias generalmente valen de 1 a 3 puntos. Se prueba la tecnología y se exploran las posibilidades de la arquitectura del sistema construyendo un prototipo. basándose principalmente en la suma de puntos correspondientes a las historias de usuario que fueron terminadas en la última iteración. 2. 3. 2. Las estimaciones de esfuerzo asociado a la implementación de las historias la establecen los programadores utilizando como medida el punto. Mantenimiento. La fase de exploración toma de pocas semanas a pocos meses. Un punto. los clientes plantean a grandes rasgos las historias de usuario que son de interés para la primera entrega del producto. La German E. para asegurarse que el sistema tenga el mayor valor de negocio posible con cada iteración. tecnologías y prácticas que se utilizarán en el proyecto. 6. 5. Muerte del Proyecto. y correspondientemente. Planificación de la Entrega En esta fase el cliente establece la prioridad de cada historia de usuario. El ciclo de vida ideal de XP consiste de seis fases: 1. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas. Exploración En esta fase. Por otra parte. dependiendo del tamaño y familiaridad que tengan los programadores con la tecnología. Exploración. Se toman acuerdos sobre el contenido de la primera entrega y se determina un cronograma en conjunto con el cliente.cliente tiene la obligación de manejar el ámbito de entrega del producto. Producción. el equipo de desarrollo mantiene un registro de la “velocidad” de desarrollo. Esta fase dura unos pocos días. Iteraciones. 1. Schmidt LU: 41066 27 .

se deben tomar decisiones sobre la inclusión de nuevas características a la versión actual. Las ideas que han sido propuestas y las sugerencias son documentadas para su posterior implementación. Esto se logra escogiendo las historias que fuercen la creación de esta arquitectura. 3. determinándose cuántos puntos se pueden completar. En la primera iteración se puede intentar establecer una arquitectura del sistema que pueda ser utilizada durante el resto del proyecto. sin embargo. debido a cambios durante esta fase. se multiplica el número de iteraciones por la velocidad del proyecto. La fase de mantenimiento puede requerir nuevo personal dentro del equipo y cambios en su estructura. esto no siempre es posible ya que es el cliente quien decide qué historias se implementarán en cada iteración. Schmidt LU: 41066 28 . Los elementos que deben tomarse en cuenta durante la elaboración del Plan de la Iteración son: • historias de usuario no abordadas. obteniendo el número de iteraciones necesarias para su implementación.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. el proyecto XP debe mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas iteraciones. 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. cada una de ellas es asignada a un programador como responsable. De esta forma. Todo el trabajo de la iteración es expresado en tareas de programación. Al final de la última iteración el sistema estará listo para entrar en producción. Para realizar esto se requiere de tareas de soporte para el cliente. • pruebas de aceptación no superadas en la iteración anterior • tareas no terminadas en la iteración anterior. Al planificar según alcance del sistema. • velocidad del proyecto. 5. German E. se divide la suma de puntos de las historias de usuario seleccionadas entre la velocidad del proyecto. de tres a una semana. la velocidad de desarrollo puede bajar después de la puesta del sistema en producción. 4. Mantenimiento Mientras la primera versión se encuentra en producción. pero llevadas a cabo por parejas de programadores. El Plan de entrega está compuesto por iteraciones de no más de tres semanas. Es posible que se rebaje el tiempo que toma cada iteración. Al planificar por tiempo. Iteraciones Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. Al mismo tiempo.

6. Este conjunto de nombres ayuda a la nomenclatura de clases y métodos del sistema. Esto requiere que se satisfagan las necesidades del cliente en otros aspectos como rendimiento y confiabilidad del sistema. 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. aunque obviamente no cuenten con toda la funcionalidad pretendida para el sistema pero si que constituyan un resultado de valor para el negocio. Se genera la documentación final del sistema y no se realizan más cambios en la arquitectura. Una entrega no debería tardar más 3 meses. Schmidt LU: 41066 29 . Se ordenan las historias de usuario según prioridad y esfuerzo. Muerte del Proyecto Es cuando el cliente no tiene más historias para ser incluidas en el sistema. de acuerdo con el valor que aporta para el negocio. Esta práctica se puede ilustrar como un juego. 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. donde existen dos tipos de jugadores: Cliente y Programador. 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. XP apuesta por un crecimiento lento del costo del cambio y con un comportamiento asintótico. Diseño simple German E. 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. Entregas pequeñas La idea es producir rápidamente versiones del sistema que sean operativas. El sistema es definido mediante una metáfora o un conjunto de metáforas compartidas por el cliente y el equipo de desarrollo. y se define el contenido de la entrega y/o iteración. Metáfora En XP no se enfatiza la definición temprana de una arquitectura estable para el sistema. Los programadores estiman el esfuerzo asociado a cada historia de usuario. 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. El cliente establece la prioridad de cada historia de usuario. Una metáfora es una historia compartida que describe cómo debería funcionar el sistema. en la planificación de cada iteración y cuando sea necesario reconducir el proyecto. apostando por enfrentar lo de más valor y riesgo cuanto antes. 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. El juego de la planificación Es un espacio frecuente de comunicación entre el cliente y los programadores. Este juego se realiza durante la planificación de la entrega.

se posibilita la transferencia de conocimientos de programación entre los miembros del equipo. no se le puede imponer todo en un inicio. no tiene lógica duplicada. Las pruebas unitarias son establecidas antes de escribir el código y son ejecutadas constantemente ante cada modificación del sistema. De hecho. El sistema de software es una cosa viviente. pero en el transcurso del tiempo este diseño evoluciona conforme cambia la funcionalidad del sistema. refleja claramente la intención de implementación de los programadores y tiene el menor número posible de clases y métodos. este cuidado continuo sobre el diseño es incluso más importante que el diseño inicial. simplificarlo y hacerlo más flexible para facilitar los posteriores cambios. En este contexto de desarrollo evolutivo y de énfasis en pruebas constantes. los problemas de programación se resuelven más rápido. 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. Pruebas La producción de código está dirigida por las pruebas unitarias. Para mantener un diseño apropiado. varias personas entienden las diferentes partes sistema. los programadores conversan mejorando así el flujo de información y la dinámica del equipo. Dichos beneficios se consiguen después de varios meses de practicar la programación en parejas. los diseños son mejores y el tamaño del código menor (continua discusión de ideas de los programadores). La complejidad innecesaria y el código extra debe ser removido inmediatamente.Se debe diseñar la solución más simple que pueda funcionar y ser implementada en un momento determinado del proyecto. 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. German E. la automatización para apoyar esta actividad es crucial. un buen diseño inicial se degradará. La refactorización mejora la estructura interna del código sin alterar su comportamiento externo. 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). Un concepto pobre al inicio puede ser corregido con esta actividad continua. Los clientes escriben las pruebas funcionales para cada historia de usuario que deba validarse. Schmidt LU: 41066 30 . mejorar su legibilidad. es necesario realizar actividades de cuidado continuo durante el ciclo de vida del proyecto. y finalmente. En los estudios realizados por Cockburn y Williams este lapso de tiempo varía de 3 a 4 meses. pero sin ella. los programadores disfrutan más su trabajo. por consiguiente la tasa de errores del producto final es más baja. Kent Beck dice que en cualquier momento el diseño adecuado para el software es aquel que: supera con éxito todas las pruebas.

contar con el cliente al menos en las reuniones de planificación. El trabajo extra desmotiva al equipo. No se trabajan horas extras en dos semanas seguidas. Schmidt LU: 41066 31 . anticiparse a los problemas asociados estableciendo llamadas telefónicas frecuentes y conferencias. Todas las pruebas son ejecutadas y tienen que ser aprobadas para que el nuevo código sea incorporado definitivamente. En [12] Jeffries indica que se debe pagar un precio por perder la oportunidad de un cliente con alta disponibilidad. reforzando el compromiso de trabajo en equipo. Integración continúa Cada pieza de código es integrada en el sistema una vez que esté lista. 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. 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. Los proyectos que requieren trabajo extra para intentar cumplir con los plazos suelen al final ser entregados con retraso. 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. German E. La comunicación oral es más efectiva que la escrita. En lugar de esto se puede realizar el juego de la planificación para cambiar el ámbito del proyecto o la fecha de entrega. Si esto ocurre. el sistema puede llegar a ser integrado y construido varias veces en un mismo día. el equipo de desarrollo está más preparado para modificar el código cuando sea necesario. Cliente in-situ El cliente tiene que estar presente y disponible todo el tiempo para el equipo. ya que esta última toma mucho tiempo en generarse y puede tener más riesgo de ser mal interpretada. Así. evitando a la vez que algún programador sea imprescindible para realizar cambios en alguna porción de código. probablemente está ocurriendo un problema que debe corregirse. Esta práctica motiva a todos a contribuir con nuevas ideas en todos los segmentos del sistema. 40 horas por semana Se debe trabajar un máximo de 40 horas por semana.Propiedad colectiva del código Cualquier programador puede cambiar cualquier parte del código en cualquier momento. debido a la confianza en la identificación y corrección de los errores de integración. Martin Fowler en [7] afirma que el desarrollo de un proceso disciplinado y automatizado es esencial para un proyecto controlado. establecer visitas frecuentes de los programadores al cliente para validar el sistema.

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

puede ser utilizado en equipos de mantenimiento de software. un periodo entre 15 y 30 días (la magnitud es definida por el equipo). Scrum permite la creación de equipos autoorganizados impulsando la co-localización de todos los miembros del equipo. lo que significa que los requisitos están congelados durante el sprint. El conjunto de características que forma parte de cada sprint viene del Product Backlog. De esta manera el equipo trata de recorrer la distancia hacia la meta como una unidad. Los roles principales en Scrum son: • ScrumMaster: que mantiene los procesos y trabaja de forma similar al director de proyecto. denominadas sprints. Aunque Scrum estaba enfocado a la gestión de procesos de desarrollo de software. y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto. Entonces. Durante esta reunión. y la comunicación verbal entre todos los miembros y disciplinas involucrados en el proyecto. Sus principales características se pueden resumir en dos. el equipo determina la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente sprint. La segunda característica importante son las reuniones a lo largo proyecto. Schmidt LU: 41066 33 . El desarrollo de software se realiza mediante iteraciones. es la agrupación de los miembros del equipo. El resultado de cada sprint es un incremento ejecutable que se muestra al cliente. • Team: que incluye a los desarrolladores. que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar. Características de Scrum Scrum es un modelo de referencia que define un conjunto de prácticas y roles. el Product Owner identifica los elementos del Product Backlog que quiere ver completados y los hace del conocimiento del equipo. que se ha utilizado con éxito durante los últimos 10 años. Los elementos del Product Backlog que forman parte del sprint se determinan durante la reunión de Sprint Planning. pasándose la pelota entre ellos. con una duración de 30 días. especialmente la reunión diaria de 15 minutos del equipo de desarrollo para coordinación e integración. Está especialmente indicada para proyectos con un rápido cambio de requisitos. nadie puede cambiar el Sprint Backlog. German E. Durante el sprint. el equipo crea un incremento de software potencialmente entregable (utilizable). • ProductOwner: que representa a los interesados externos o internos. o en una aproximación de gestión de programas. 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. Durante cada sprint.SCRUM SCRUM es un término de Rugby. Define un marco para la gestión de proyectos. Éstas son las verdaderas protagonistas.

deseos. Los roles gallina en realidad no son parte del proceso Scrum. El Product Owner escribe historias de usuario. y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada. Schmidt LU: 41066 34 . y las coloca en el Product Backlog. Las necesidades. Scrum adopta una aproximación pragmática. las prioriza. • Las Gallinas: sólo interesados en el proyecto. De esta forma: • Los cerdos: están comprometidos a desarrollar el software de forma regular y frecuente. no se ve comprometida como el cerdo que va al matadero. Existen varias implementaciones de sistemas para gestionar el proceso de Scrum. Se asegura de que el equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio. Por lo tanto. German E. que van desde notas amarillas "post-it" y pizarras hasta paquetes de software. pero deben tenerse en cuenta. expertos del negocio y otros interesados (stakeholders). Están comprometidos con el proyecto y el proceso Scrum. estos están divididos en dos grupos: cerdos y gallinas. Una de las mayores ventajas de Scrum es que es muy fácil de aprender. 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. y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder a requisitos emergentes. • El Product Owner: representa la voz del cliente. aceptando que el problema no puede ser completamente entendido o definido. Roles en Scrum En Scrum se definen varios roles. Un aspecto importante de una aproximación ágil es la práctica de involucrar en el proceso a los usuarios. distorsionar o entorpecer el proyecto Scrum. ideas e influencias de los roles 'gallina' se tienen en cuenta.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). pero no de forma que pueda afectar. La gallina alimenta al proyecto "poniendo huevos". y requiere muy poco esfuerzo para comenzarse a utilizar.

Como bien lo dice la paradoja. ScrumTeam o Equipo: El equipo tiene la responsabilidad de entregar el producto.• ScrumMaster (o Facilitador): El Scrum es facilitado por un ScrumMaster. El ScrumMaster es el que hace que las reglas se cumplan. enfocándose especialmente en áreas de solapamiento e integración. • La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días.para quien llegue tarde (por ejemplo: dinero. Schmidt LU: 41066 35 . Un pequeño equipo de 5 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (diseñador. de forma independiente del tamaño del equipo. 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. • • • • Reuniones en Scrum Daily Scrum: Cada día de un sprint. • Todos son bienvenidos. se realiza la reunión sobre el estado de un proyecto. flexiones. Scrum de Scrum Cada día normalmente después del “Daily Scrum” • Estas reuniones permiten a los grupos de equipos discutir su trabajo.). El ScrumMaster no es el líder del equipo (porque ellos se auto-organizan). Esto se llama "daily standup". • Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunión corta). etc). desarrollador. llevar colgando una gallina de plástico del cuello. A menudo hay castigos acordados por el equipo. cada miembro del equipo contesta a tres preguntas: 1. Usuarios: Es el destinatario final del producto. sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. ¿Qué has hecho desde ayer? 2. ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo? (Es el papel del ScrumMaster recordar estos impedimentos). Durante la reunión. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. • La reunión tiene una duración fija de 15 minutos. German E. El scrum tiene unas guías específicas: • La reunión comienza puntualmente a su hora. Managers: Es la gente que establece el ambiente para el desarrollo del producto. ¿Qué es lo que estás planeando hacer hoy? 3. Sólo participan directamente durante las revisiones del sprint. pero sólo los "cerdos" pueden hablar. Inversores): Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producirá el beneficio acordado que lo justifica. etc. • Asiste una persona asignada por cada equipo.

tanto del valor para el negocio. Documentos Product backlog El product backlog es un documento de alto nivel para todo el proyecto. El propósito de la retrospectiva es realizar una mejora continua del proceso. una “Reunión de Planificación del Sprint” se lleva a cabo. priorizadas según su retorno sobre la inversión (ROI) . Al final de cada sprint. el equipo deberá presentar los avances logrados. Es abierto y cualquiera puede modificarlo. 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. funcionalidades deseables. Schmidt LU: 41066 36 . Contiene descripciones genéricas de todos los requerimientos. La constancia hace a la concentración y la mejor productividad del equipo de trabajo. en la cual todos los miembros del equipo dejan sus impresiones sobre el sprint recién superado. Es el qué va a ser construido. Esta estimación ayuda al product owner a ajustar la línea temporal y. ¿Qué hará tu equipo antes que nos volvamos a reunir? 3. 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. • Seleccionar qué trabajo se hará • Preparar. y deberían entregar un producto con características de utilizable por el cliente. • 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. Es recomendado que la duración de los sprints sea constante y definida por el equipo en base a su propia experiencia. como del esfuerzo de desarrollo requerido. añadiendo además las siguientes cuatro preguntas: 1.La agenda será la misma que la del Daily Scrum. de manera limitada. 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. aunque sin relajarlo demasiado. ¿Hay algo que demora o estorba a tu equipo? 4. se lleva a cabo una retrospectiva del sprint. con el equipo completo. ¿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). etc. Contiene estimaciones grosso modo. la prioridad de las German E. 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í. el Sprint Backlog que detalla el tiempo que tomará hacer el trabajo. ¿Qué ha hecho tu equipo desde nuestra última reunión? 2.

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.Muchas Reuniones y algunas muy largas. 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. existen críticos y personas que lo han descartado. creando debates más largos de lo necesario. supeditando la misma a valores medibles. como la de estimación: Curiosamente este punto es uno de los pilares fundamentales de Scrum. y si se modifican algunos requisitos la pendiente variará o incluso valdrá cero en algunos tramos. German E. 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. debido a que su ROI será más alto. Si durante el proceso se añaden nuevos requisitos la recta tendrá pendiente ascendente en determinados segmentos. Por ejemplo. dado que creen que es innecesario muchas veces durante el desarrollo del sprint. Schmidt LU: 41066 37 . 3. Si una tarea es mayor de 16 horas. que se suelen alargar a 3/4 horas y la verdad es que puede resultar agotador. Existe también una crítica hacia las reuniones de estimación. aunque sean reuniones de cinco minutos.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. Justifican que en todos los proyectos se necesitan dosis de estas características para que se consiga un producto completo. son tomadas por los miembros del equipo del modo que les parezca oportuno. Pero existen personan que critican el hecho de tener que reunirse todos los días. podremos ver el progreso del proyecto. Algunas de las críticas de Scrum No todo en Scrum es un mundo maravilloso. momento en el cual el proyecto se ha terminado (no hay más requisitos pendientes de ser completados en el Backlog). la espontaneidad. deberá ser rota en mayor detalle. las genialidades absurdas.diferentes tareas. al realizar reuniones para que fluya la comunicación entre todos los agentes implicados. Dibujando una línea que conecte los puntos de todos los Sprints completados. si dos características tienen el mismo valor de negocio la que requiera menos tiempo de desarrollo tendrá probablemente más prioridad. sobre todo si no se preparan bien y se dejan las historias abiertas. etc. Básicamente sus quejas se centraban en los siguientes tres puntos: 1.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. 2. Las tareas en el sprint backlog nunca son asignadas. disminuye la creatividad. que les lleva a crear unas gráficas muy bonitas de cara a los clientes. Las tareas se dividen en horas con ninguna tarea de duración superior a 16 horas.

Crystal sugiere que escojas el color de la metodología para un proyecto en función de su criticidad y tamaño. El desarrollo de software se considera un juego cooperativo de invención y comunicación.C puede ser usado en proyectos pequeños y como casi todos los otros métodos. más rigurosidad necesitamos disponer en el desarrollo del proyecto. por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas. indica pérdida de dinero esencial.D. • Naranja para equipos entre 20 a 50 persona. técnicas y procesos. Cuanto más crítico sea el sistema que queremos desarrollar. indica pérdida de dinero discrecional. y lo hacen de la siguiente manera: • C.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. limitado por los recursos a utilizar. generalmente nuestro. • Azul para equipos entre 100 a 200 personas. Schmidt LU: 41066 38 . es decir dinero que probablemente no es nuestro y no podemos disponer de el libremente. Indica la pérdida de vidas por el fallo del sistema. es decir del que podemos disponer. • E. 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.C)es para equipos de hasta 8 personas o menos. En la figura anterior aparecen unos caracteres (C. vida. C. así como tener políticas de trabajo en equipo definidas.E y L) e indican las perdidas potenciales por fallos del sistema. de Life en ingles. • Roja para equipos entre 50 a 100 personas. Estas políticas dependerán del tamaño del equipo por ejemplo: • Cristal Clear (C. German E. CC consiste en valores. • D. indica pérdida de confort debido a un fallo del sistema. • Amarillo para equipos entre 10 a 20 personas. El equipo de desarrollo es un factor clave. • L.

El equipo de desarrollo es un factor clave. El otro método elaborado en profundidad es el Naranja. pero puede ser diaria. Crystal Clear no requiere ninguna estrategia o técnica. Los siguientes son los principales: • Cuando el número de personas aumenta. Como casi todos los otros métodos. apto para proyectos de duración estimada en 2 años. también aumenta la necesidad de coordinar. semanal o mensual. 6. Comunicación osmótica. Una variante especial es disponer en la sala de un experto diseñador senior y discutir respecto del tema que se trate. Saber lo que se está haciendo y tener la tranquilidad y el tiempo para hacerlo. protección legal. Los siete valores o propiedades de CC son: 1. y es la que se ha de describir a continuación. discutir. CC puede ser usado en proyectos pequeños. pero siempre es útil tener unas cuantas a mano para empezar. 2. como dispositivos activos. Entrega frecuente. con la pregunta y la respuesta en el mismo espacio de tiempo. Todos juntos en el mismo cuarto. Foco. Consiste en entregar software a los clientes con frecuencia. por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas. 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. Tomarse un pequeño tiempo (unas pocas horas cada o una vez al mes) para pensar bien qué se está haciendo. Fácil acceso a usuarios expertos. Schmidt LU: 41066 39 . tienen modos de éxito y modos de fallo. • 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. 3. técnicas y procesos. • Las personas se comunican mejor cara a cara. entre otros. limitado por los recursos a utilizar. Seguridad personal. no solamente en compilar el código. Lo primero son promesas. así como tener políticas de trabajo en equipo definidas. Tener alguna comunicación con expertos desarrolladores.Menos énfasis en la documentación exhaustiva y más en versiones que corran y puedan ser probadas. La frecuencia dependerá del proyecto. • Cuando el potencial de daños se incrementa. El desarrollo de software se considera un juego cooperativo de invención y comunicación. 5. son: German E. Los otros dos aún se están desarrollando. Hablar con los compañeros cuando algo molesta dentro del grupo. cotejar notas. Las estrategias comunes a otras Metodologías Ágiles. otras se enfatiza la auditoria. 4. Cada proyecto necesita sus propios métodos. • El factor más significativo es “comunicación”. CC consiste en valores. confiabilidad. La más exhaustivamente documentada es Crystal Clear. la tolerancia a variaciones se ve afectada. Mejora reflexiva. lo segundo hechos. Características Las personas. reflexionar.

Se suele entrevistar a más de un responsable para tener visiones más ricas. su tiempo de ejecución. se usan también en Scrum. Es mejor buscar pequeños triunfos iniciales que aspirar a una gran victoria tardía Esqueleto ambulante. la tecnología. • Planeamiento Blitz. y las alinea en secuencias de desarrollo preferidas. La palabra clave es “brevedad”. • Encuentros diarios de pie. La idea es que la gente pueda “degustar” la nueva metodología. En cuanto a las técnicas. • Talleres de reflexión. Las tarjetas se agrupan en períodos de tres semanas llamados iteraciones que se agrupan en entregas. No se trata de discutir problemas. proyecto. la fecha de las entregas según dependencias técnicas y de negocios y para equilibrar las entregas en paquetes de igual tamaño. • Estimación Delphi con estimaciones de pericia. Re-arquitectura incremental. los requerimientos. 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. teniendo en cuenta los tiempos referidos y el valor de negocio de cada función. Se ha demostrado que no es conveniente interrumpir el desarrollo para corregir la arquitectura. En este juego. Es una lámina pegada en algún lugar que el equipo pueda observar mientras trabaja o camina. Los programadores escriben en cada tarjeta el tiempo estimado para desarrollar cada función. Una forma de presentar Crystal Clear puede consumir entre 90 minutos y un día. • Gráficos de quemado. el plan del proyecto y el proceso. se favorecen: • Entrevistas de proyectos. Se trata de una técnica de graficación para descubrir demoras y problemas tempranamente en el proceso. • Miniatura de procesos. esperando que los demás German E. El patrocinador del usuario escribe la secuencia de prioridades. Tiene que ser comprensible para el observador casual. cinco a diez minutos como máximo. con una historia de usuario o función visible en cada una. El equipo debe detenerse treinta minutos o una hora para reflexionar sobre sus convenciones de trabajo. se ponen tarjetas indexadas en una mesa. el modelo de dominio. manteniendo el sistema en ejecución mientras ella se modifica. Más bien la arquitectura debe evolucionar en etapas. Su nombre viene de los gráficos de quemado de calorías de los regímenes dietéticos. entendida de un vistazo y renovada periódicamente para que valga la pena visitarla. Victoria temprana. evitando que se descubra demasiado tarde que todavía no se sabe cuánto falta. Schmidt LU: 41066 40 . Radiadores de información. En el proceso Delphi se reúnen los expertos responsables y proceden como en un remate para proponer el tamaño del sistema. llamada así porque se refiere al agregado de ítems con alta prioridad en el tope de las listas de trabajos pendientes. como la Lista Temprana. sino de identificarlos. usualmente no más largas de tres meses. El grupo finge que no hay dependencias entre tarjetas.• • • • • Exploración de 360° Verificar o tomar una muestra del valor de negocios del . discutir inconvenientes y mejoras y planear para el período siguiente. Es una transacción que debe ser simple pero completa. Una técnica puede ser el Juego de Planeamiento de XP. Para ello se hace una estimación del tiempo faltante para programar lo que resta al ritmo actual.

German E. En Metodologías Ágiles se definen tres niveles de experiencia: • Nivel 1 es capaz de “seguir los procedimientos”. Junto con el Usuario Experto produce la Lista de Actores-Objetivos y el Archivo de Casos de Uso y Requerimientos. sus programadores son diseñadores-programadores. Con la ayuda del equipo. sugerir atajos de teclado. o un equipo de varias personas. Diseñador Programador. Produce la Descripción Arquitectónica. mezclar e inventar procedimientos. mentor y programador más experto. los Borradores de Pantallas. Consigue los recursos y define la totalidad del proyecto. A continuación se describen los artefactos de los que son responsables los roles de CC: 1. los elementos que están sobre la línea se entregarán en la iteración siguiente. • Nivel 2 es capaz de “apartarse de los procedimientos específicos” y encontrar otros distintos • Nivel 3 es capaz de manejar con fluidez. 6. Experto en Negocios. Produce la Declaración de Misión con Prioridades de Compromiso (Tradeoff). el Estado del Proyecto. Puede ser un programador en tiempo parcial. El Diseñador Principal tiene roles de coordinador. Debe conocer las reglas y políticas del negocio. navegación. Se supone que debe ser al menos un profesional de Nivel 3. Diseñador-Programador. Junto con el Experto en Negocios produce la Lista de Actores-Objetivos y el Archivo de Casos de Uso y Requerimientos. 4. modos de operación. el Código Fuente. Los gráficos de quemado ilustran la velocidad del proceso. 3. Produce el Reporte de Bugs. Usuario Experto. Facilitador Técnico. Debe familiarizarse con el uso del sistema. pero cada quien se enfoca a su trabajo asignado. Escritor. prestando un ojo a lo que hace su compañero. Usuario Experto. arquitecto. Programación lado a lado. el Plan y Estado de Iteración y la Agenda de Visualización. Experto en Negocios. los que están por debajo en las restantes. el Modelo Común de Dominio. 5. Patrocinador. 7.• elementos se hundan bajo la línea de flotación. Arquitecto. Experto en Uso. Coordinador. las Pruebas y el Sistema Empaquetado. Verificador. En Crystal Naranja se agregan aun más roles: Diseñador de IU (Interfaz de Usuario). Esta es una ampliación de la Comunicación Osmótica al contexto de la programación. la versión de Crystal Clear establece proximidad. información a visualizar simultáneamente. Un programa en CC es “diseño y programa”. el Código de Migración. Mentor de Diseño. Punto de Reutilización. el Plan de Entrega. Schmidt LU: 41066 41 . Produce. produce el Mapa de Proyecto. quien tiene su propia máquina. la Lista de Riesgos. junto con el Diseñador Principal. Mucha gente siente que la programación en pares de XP involucra una presión excesiva. 2. Diseñador Principal. Coordinador. En otras Metodologías Ágiles la Lista temprana no es otra cosa que un grafico de retraso. En CC un diseñador que no programe no tiene cabida. Verificador. Diseñador Principal. analizando la diferencia entre las líneas proyectadas y efectivas de cada entrega. Diseñador de Base de Datos. Analista/Diseñador de Negocios. las Notas y Diagramas de Diseño. Hay ocho roles nominados en CC: Patrocinador.

Seguridad personal: lograr que cada miembro del team pueda sentirse cómodo con el trabajo y el entorno. 2. Entorno técnico con: o Testing automatizado (incorporación. por ejemplo. de UnitTest). pizarras y espacios destinados a que todos (miembros del equipo y visitas) puedan ver claramente el progreso del trabajo. El Equipo como Grupo es responsable de producir la Estructura y Convenciones del Equipo y los Resultados del Taller de Reflexión. 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. • Comunicación: Crystal Clear toma como uno de sus pilares a la comunicación. Un “modelo de juegos cooperativos” Este modelo ve al desarrollo de software como una serie de partidos que consisten en inventar y comunicar. Principios El grado de detalle necesario en documentar requerimientos. planeamiento. Produce el Manual de Usuario. Prioridades Crystal Clear establece un conjunto de prioridades y principios que sirven de guía para la toma de decisiones. Cada partido es diferente y tiene como objetivo entregar software y prepararse para el siguiente juego. • Crecimiento reflexivo: es necesario que el equipo lleve a cabo reuniones periódicas de reflexión que permitan crecer y hacernos más eficientes. Esto permite al equipo trabajar concentrado y en forma efectiva con un objetivo claro cada vez. • • • • • Estas tres propiedades son "obligatorias" para Crystal Clear. Schmidt LU: 41066 42 . Promueve prácticas como el uso de pizarrones. diseño. 4. varía según el proyecto.8. Concentración: las entregas frecuentes permiten que cada desarrollador puede enfocar de a un problema evitando dispersiones. 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. German E. El Código Genético Consiste en: 1. o Integración frecuente (uso de herramientas específicas como Cruise Control). Escritor. 3. etc. Propiedades • Frecuencia en las entregas: entregar al usuario funcionalidad "usable" con una frecuencia de entre 2 semanas y no más de un mes. las siguientes pueden agregarse en la medida de las necesidades de cada grupo y proyecto.

La entrega frecuente de código confiable y "funcionando" mantiene el foco y evita distracciones. Presta especial importancia a la ubicación física del grupo. donde la comunicación cumple el principal rol. Todo esto permite ir armando una metodología de trabajo que se adecue al equipo. el proyecto y los tiempos que se manejen. y también permiten la discusión productiva de líneas a seguir. Las reuniones diarias (introducidas por la metodología Scrum) acompañan el seguimiento y mantienen el foco en el próximo paso a seguir. con el entorno y las particularidades de cada asignación. Las reuniones de reflexión periódicas son fundamentales para que los miembros del equipo se expresen abiertamente. Da flexibilidad y prioriza la parte humana. 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. apuntando a lograr eficiencia. Técnicas Igual que con las estrategias. 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. Tres de las estrategias que están más relacionadas son las de apuntar a tener "Victorias Tempranas". Estrategias Ni las estrategias ni las técnicas son mandatorias para Crystal Clear. arrancar el desarrollo de lo que se denomina un "Esqueleto que Camine" y pensar siempre en hacer "Re-arquitectura Incremental" van de la mano. para revisar el trabajo hecho y evaluar qué cosas dan resultado y cuáles no o de empezar a trabajar. la re-arquitectura permitirá ir agregando más "cuerpo" al esqueleto inicial. Todo esto permite ir armando una metodología de trabajo que se adecue al equipo. A medida que se avanza en el proceso. hay una lista de técnicas propuestas por Crystal Clear. El riesgo en el método ágil son los Cambios de arquitectura son como ejercicios de trapecio German E. habitabilidad y confianza en los miembros del equipo. Pero es bueno tener en cuenta alguna de ellas al momento de empezar a trabajar. 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). Schmidt LU: 41066 43 . 6. El equipo ajusta constantemente su forma de trabajo para lograr que cada personalidad encaje con los otros miembros. Todas describen una forma de tomar ventaja del desarrollo incremental para establecer valor desde el principio. informal y preciso que pueda ser accedido por todos los miembros del equipo.• • Es imposible eliminar toda documentación pero puede ser reducida logrando un modo de comunicación más accesible. 5.

Implantación. DSDM define cinco fases en la construcción de un sistema. que empezó a utilizarlo y a capacitar a su personal en las prácticas y valores de DSDM. El involucramiento del usuario es imperativo. Un enfoque colaborativo y cooperativo entre todos los interesados es esencial. 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. Debido a este éxito. 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). 2. tomando las mejores practicas que se conocían en la industria y la experiencia traída por sus fundadores. formado originalmente por 17 miembros fundadores en Enero de 1994. Dado el enfoque hacia proyectos de características RAD esta metodología encuadra perfectamente en el movimiento de metodologías ágiles. Los equipos de DSDM deben tener el poder de tomar decisiones. 5. 9. El desarrollo iterativo e incremental es necesario para converger hacia una correcta solución del negocio. Durante el estudio del negocio se involucra al cliente de forma temprana. Este estudio sienta las bases para iniciar el desarrollo. 7. La conformidad con los propósitos del negocio es el criterio esencial para la aceptación de los entregables. El Consorcio. se inician las iteraciones durante las cuales: se bajará a detalle los features identificados anteriormente. 4. 5. el Consorcio comisionó al Presidente del Comité Técnico. Iteración del modelo funcional. Estudio de factibilidad. 2. German E. Posteriormente. El foco está puesto en la entrega frecuente de productos. liberó la primera versión de DSDM a principios de 1995. Los requerimientos están especificados a un alto nivel. Todos los cambios durante el desarrollo son reversibles. La estructura del método fue guiada por estos nueve principios: 1. se construirán los componentes de software. Iteración del diseño y construcción. 4.Dynamic Systems Development Method (DSDM) DSDM es la única de las metodologías aquí planteadas surgida de un Consorcio. Schmidt LU: 41066 44 . para tratar de entender la operatoria que el sistema deberá automatizar. El testing es integrado a través del ciclo de vida. Las mismas son: 1. 3. A partir de ese momento el método fue bien acogido por la industria. 6. la creación de un libro que explorara la realidad de implementar el método. se realizará el diseño de los mismos. Jennifer Stapleton. definiendo las features de alto nivel que deberá contener el software. 3. y se implantará el sistema en producción previa aceptación del cliente. Estudio del negocio. 8.

Schmidt LU: 41066 45 . 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 las entregas frecuentes de productos. las demás fases presentan las características del modelo iterativo e incremental ya tratado.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. Sin embargo. 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. en el feedback con el cliente. ¿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? German E.

Sin embargo. Asimismo. • Particionables en componentes de funcionalidad más pequeños si la aplicación es de gran tamaño. intervalo. en la que se fijan los objetivos de la iteración. el usuario embajador que equivaldría al on-site customer de XP. en caso que surjan imprevistos o se materialicen riesgos. Estos modelos esenciales deberán ser definidos antes que comience el desarrollo. 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. ciclo. • Acotados en el tiempo. Identifica al visionario como el encargado de asegurar que se satisfacen las necesidades del negocio. DSDM destaca la necesidad de colocar componentes de distinta prioridad en un mismo timebox. el coordinador técnico que es la persona encargada de mantener la arquitectura y verificar German E. Durante la Investigación se chequean que las actividades que componen el timebox se condicen con la arquitectura del sistema.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 manera de poder posponer a futuras iteraciones aquellos con menor prioridad. la fase de Consolidación consiste en completar los entregables. La siguiente fase. funciona tanto para el modelo de orientación a objetos como para el modelo estructurado. y deberán ser revisados en las sucesivas iteraciones para validad su contenido. • De baja o media complejidad computacional. los entregables a ser producidos. que brinda el conocimiento del negocio y define los requerimientos del software. 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. En DSDM. 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. efectuándose revisiones sobre las iteraciones anteriores a la actual. Finalmente. Refinamiento. ni siquiera impone el desarrollo bajo un paradigma específico.DSDM incluye roles claves en relación al management del proyecto. • Con un grupo de usuarios bien definidos y comprometidos al proyecto. consiste en la producción propiamente dicha de los artefactos planificados. • Con flexibilidad en los requerimientos. y realizar estimaciones de esfuerzo más precisas. Esta es una fase de carácter exploratorio. Schmidt LU: 41066 46 . verificando la calidad de los mismos. 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. cada timebox esta compuesta por actividades definidas en relación a entregables en vez de tareas. un timebox consta de tres fases que son: Investigación. También permiten controlar la calidad de los productos intermedios que se van generando. en las cuales también se conocen como iteración. la metodología no tiene ninguna prescripción respecto a las técnicas a ser usadas en el proyecto. El concepto de timebox es algo que está embebido en DSDM y en todas las metodologías ágiles. Refinamiento y Consolidación. Cada entregable generado durante el mismo es testeado/revisado dentro del mismo timebox.

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. 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 énfasis queda en manifiesto en los prototipos que se sugieren para cada etapa: negocio. y diseño. El enfoque propuesto consiste en la utilización de un prototipo evolutivo.la consistencia de los componentes construidos respecto a esta y al cumplimiento de los estándares técnicos. usabilidad. el cual se va refinando hasta tenerse la aplicación deseada. Schmidt LU: 41066 47 . 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. performance y capacidad. German E. En resumen. El mismo contiene las características principales de las metodologías ágiles y contiene prácticas tendientes al enfoque RAD.

German E. Por último.D. FDD se estructura alrededor de la definición de features que representan la funcionalidad que debe contener el sistema. 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. Posteriormente.Feature Driven Development (F. Schmidt LU: 41066 48 . 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. y tienen un alcance lo suficientemente corto como para ser implementadas en un par de semanas. dos de las cuales se realizan tantas veces como iteraciones se planifiquen en el desarrollo. 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. FDD posee también una jerarquía de features.D) Peter Coad es considerado uno de los referentes más importantes dentro de la ingeniería de software. cuando este último pidió ayuda a alguien de la comunidad de objetos para desarrollar una nueva metodología. Este tema será tratado más adelante en relación al enfoque de las metodologías ágiles en los productos entregados. 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. una metodología desarrollada alrededor del año 1998 que presenta las características de un proceso ágil. basada en el paradigma de OO. La misma derivó del trabajo de Coad sobre las Feature Lists (Listas de Funcionalidades). participaría en la creación de FDD. Coad junto con Jeff De Luca y otros. siendo el eslabón superior el de feature set que agrupa un conjunto de features relacionadas con aspectos en común del negocio.

el documento que podríamos llamar arquitectura y en el que figuran las opciones de modelado surgidas durante esta actividad.La primera actividad: consiste en Desarrollar un Modelo Global. 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. toma como input la lista priorizada de la fase anterior y establece los tiempos las futuras iteraciones. se desarrollarán: diagramas de los paquetes. A medida que se realiza la planificación se delinean los hitos de finalización de las iteraciones. B (sería útil tener). el líder de desarrollo y el programador jefe. Empezando por el diseño que toma los features correspondientes a la iteración. Una vez que se han identificado las mismas se las agrupa jerárquicamente para poder estructurar el trabajo de desarrollo. Las últimas dos actividades: Diseñar por Feature y Construir por Feature. por último. En esta actividad participan el líder de proyecto. 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. 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). La tercera actividad: Planificar por Feature. están relacionadas con la parte productiva del proceso en que se construye la aplicación de manera incremental. que sugiere un cierto paralelismo con la construcción de la arquitectura del software. Mediante la German E. o D (futuro). dejando asentado cuales son los features y features sets que estarán construidos en dichos hitos. el entendimiento del negocio en que esta embebida. un documento con los requerimientos no funcionales detectados. y la definición de restricciones y cuestiones no funcionales. el equipo de programadores liderado por el programador jefe identifica las clases. Para esto. un primer bosquejo de las features del software. con las clases esenciales y las responsabilidades de las mismas. estos a su vez asignarán las clases a dueños de clases seleccionados del equipo. comienza tomando el bosquejo de features formulado durante la actividad anterior para refinar las funcionalidades incluidas. finalmente. La segunda actividad: Construir una Lista de Features. un documento similar al de Visión en donde se plasmen los objetivos del proyecto y como el mismo ayuda al negocio. atributos y métodos que realizan la funcionalidad requerida. Schmidt LU: 41066 49 . C (agregar si es posible). Parte de también incluye la delegación de responsabilidades a los programadores jefe que serán dueños de los features. En la creación de este modelo participan tanto los expertos en el dominio como los desarrolladores.

siendo entregado a Administración de la Configuración. Cada programador implementará los métodos de las clases por las que este es responsable. “Guru” de lenguaje: conoce a la perfección el lenguaje y la tecnología. en la fase de Construir por Feature. se verifica que el diseño pueda ser implementado. y una vez que finaliza se promueve el código al Build correspondiente. analista de negocios o una mezcla de todo esto. Esta actividad será realizada por el equipo asignado al feature en cuestión. Por cada feature set que es implementado se tendrá German E. Schmidt LU: 41066 50 . Gerente de desarrollo: puede combinarse con arquitecto jefe o gerente de proyecto. Arquitecto jefe: este rol puede dividirse en arquitecto de dominio y arquitecto técnico. Posteriormente. Experto de dominio: que puede ser un cliente. Una vez que la clase pasa todas las pruebas. reporta al gerente de proyecto. la misma debe ser breve. Roles Roles claves: Gerente del proyecto: es quien tiene la última palabra en materia de visión. se procede a desarrollar las clases definidas en la actividad anterior. Administrador del sistema: controla el ambiente de trabajo. Roles Adicionales: “Tester”: verificador del sistema producido. “Herramientista” (toolsmith): construye pequeñas herramientas de desarrollo o mantiene bases de datos y sitios web. patrocinador. extendiendo las clases base de prueba para construir las pruebas unitarias. servidores.utilización de diagramas de secuencia de UML. codificación. prueba y documentación. FDD consiste en cinco procesos secuenciales durante los cuales se diseña y construye el sistema. red…etc. 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. Propietarios de clases: trabajan bajo la guía del programador jefe en diseño. 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. y un solo rol puede ser compartido por varias personas. y en la cual se reporta el status de los features que están siendo construidos por cada grupo. cronograma y asignación del personal. Se realizará también una inspección del diseño en los casos en que la complejidad de la funcionalidad lo requiera. se inspecciona el código. repartidos por rasgos. se encarga de resolver conflictos dentro del equipo de desarrollo. Roles de soporte: Administrador de entrega: controla el progreso del proceso revisando los reportes del programador jefe y manteniendo reuniones breves con él. Escritores de documentos técnicos: Un miembro del equipo puede tener otros roles a cargo. de no más de 30 minutos.

Schmidt LU: 41066 51 . quien dirige a los propietarios de clases. El proceso sugiere organizar bloques de features a ser construidos en forma incremental mediante iteraciones de dos semanas. sobre las cuales da guías mínimas. quienes dirigen equipos de rasgos. provee estrategias de planeamiento para el líder de proyecto.la información como indica la Figura 006 para medir el avance del proyecto. Conclusión Encontramos en FDD un proceso ágil orientado a la funcionalidad del software por sobre las tareas. FDD se utilizó por primera vez en grandes aplicaciones bancarias a fines de la década de 1990. porque demanda un programador jefe. German E. Otros sienten que la ausencia de procedimientos detallados de prueba en FDD es llamativa e impropia. 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. Un rasgo llamativo de FDD es que no exige la presencia del cliente. dándole visibilidad al management superior y al cliente.

Gracias a centrarse en la especulación. En cada iteración. útiles. 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. y el Pert definiendo las tareas a realizar en detalle. La utilización del verbo Especular demuestra el interés de Highsmith en demostrar la naturaleza impredecible de los sistemas complejos. Schmidt LU: 41066 52 . luego se tiene las fases de construcción. tomado del ciclo de Deming. y cambiarán los requerimientos. sabiendo a partir de ese momento que no será el lugar en que finalizará el proyecto. Respecto a la especulación. 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. se aprenderán nuevas funcionalidades. en que se aplica la secuencia Planificar-Ejecutar-Evaluar. en que se realiza una precisa planificación inicial mediante el WBS.Sin embargo. ASD propone utilizar en cambio el ciclo de vida de la Figura 007.Adaptive Software Development Jim Highsmith en su libro es la mente detrás de este proceso ágil. Dicho esquema es llevado a la práctica con el modelo en cascada. ASD permite administrar estos proyectos de alto cambio y rápido desarrollo que se encuentran en el borde del caos. En esta etapa se fija un rumbo determinado a ser seguido en el desarrollo. 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. Highsmith lleva los mismos al campo de la Ingeniería de Software en particular. se entenderán viejas cuestiones. 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. Comenzando por un cambio en el modelo de desarrollo determinista. Especular-ColaborarAprender. previendo los posibles retrasos que puedan existir mediante el movimiento de las funcionalidades de menor prioridad a futuros ciclos – y grandes desviaciones en otro. el Gantt. y opcionales. las cuales son utilizadas para la exploración del dominio y de la aplicación. y finalmente. que puede llevar a cambiar el rumbo del proyecto – estos desvíos está representado por las flechas de divergencia en la siguiente figura: German E. 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. se tiene el testing que brinda el feedback en relación al producto construido. Basado en los conceptos de los Sistemas Adaptativos Complejos relacionada con la Inteligencia Artificial.

se podrán realizar al final de cada ciclo pequeñas reuniones de postmortem. También. ASD define un Componente como un grupo de funcionalidades o entregables a ser desarrollados durante un ciclo iterativo.La siguiente fase del ciclo de vida. 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). German E. La fase final de ASD. el énfasis estará puesto en aprender cuales han sido los errores o desvíos y poder resolverlos. El funcionamiento del equipo de desarrollo y las prácticas que este utiliza. En relación al status del proyecto. En la misma se analizan cuatro categorías de cosas para aprender: • • • • Calidad del resultado de la desde la perspectiva del cliente. se detectarán posibles diferencias que pueden surgir de la exploración y que cambiarán el rumbo a que apuntaba el proyecto. Las revisiones al diseño. Colaborar. 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. realizar pruebas de concepto. En las mismas se discuten los aspectos del proceso que contribuyen al desarrollo y aquellos que deben ser descartados por su influencia negativa. Asimismo. En este caso. En este momento. consiste en la revisión de calidad que se realiza al final de cada ciclo. y no en encontrar culpables. El tercer proceso de feedback está relacionado con la interacción entre las partes. es aquella en la que se construye la funcionalidad definida durante la especulación. pudiendo eventualmente alterar el rumbo del proyecto profundamente. Para evaluar la calidad desde el punto de vista del cliente se sugieren utilizar grupos de enfoque en el cliente. Durante cada iteración el equipo colabora intensamente para liberar la funcionalidad planificada. Schmidt LU: 41066 53 . Para medir la performance y el grado de cohesión del mismo. al código o a las pruebas permitirán aprender sobre la calidad de los mismos. Calidad del resultado de la desde la perspectiva técnica. mediante los cuales se explora un modelo de la aplicación y se anotan los requerimientos de cambio del cliente. 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. Gracias a esta propiedad los grupos de desarrollo logran sacar lo mejor de si en la el borde del caos. se realizarán revisiones para determinar el estado del mismo en relación a lo planificado. y las técnicas empleadas. 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. la dinámica de grupo. El status del proyecto. existe la posibilidad de explorar nuevas alternativas. Aprender. siguiendo de esta forma la línea de las metodologías ágiles respecto a la orientación a componentes.

mostrándose con una flecha que trasciende las tres fases en sentido inverso. 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. 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. el seguir un plan al pie de la letra produce el producto que retendíamos.” Conclusion En conclusión. ASD y las metodologías ágiles plantean la necesidad de que el feedback necesario sea para aprender. En este sentido resulta similar a Scrum. Highsmith lo expone claramente en la siguiente frase: “En ambientes complejos. nos da la posibilidad de entender más respecto al dominio y construir la aplicación que mejor satisfaga las necesidades del cliente. 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. German E. Es decir.En la siguiente Figura se puede ver el detalle interno de cada fase como ya fue explicado. pero no el producto que necesitamos. Schmidt LU: 41066 54 .

Entender como administrar la calidad del software moviendo las actividades de testing hacia el comienzo y el centro del proceso de desarrollo. Reorganizar el proceso de desarrollo de software alrededor de ciclos cortos de desarrollo que permitan acelerar la generación de valor. 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. El término de desarrollo de software Lean tiene origen en un libro del mismo nombre. Crear métricas que guíen la optimización de resultados para la organización en su totalidad. 3. 4. La participación de Mary y Tom en la comunidad del desarrollo ágil de software. 8. El libro presenta los tradicionales principios Lean en forma modificada. Cuantificar la capacidad de su organización de desarrollo de software y limitar el trabajo a esa capacidad. las cuales determinan las capacidades de su proceso de desarrollo de software. OBJETIVOS 1. aunque puedan variar las prácticas específicas. Lograr el compromiso de la gente moviendo la responsabilidad y la toma de decisiones a los equipos de desarrollo. así como la inclusión de algunos de estos conceptos.LEAN SOFTWARE DEVELOPMENT Lean es el nombre del método que usa Toyota para producir y desarrollar automóviles. 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. German E. Schmidt LU: 41066 55 . Establecer el estado actual de sus disciplinas básicas. No son panaceas: los principios son universales. así como un conjunto de 22 instrumentos y herramientas para comparar las prácticas ágiles. ha dado lugar a dichos conceptos. Aplicar métodos clásicos de mejora de procesos a problemas reales en su ambiente. 2. Ejemplos de ello sería la utilización del término "Lean-Agile" por empresas de consultoría como NetObjectives Pace y CC. 7. incluyendo charlas en varias conferencias. 6. 5. escrito por Mary Poppendieck y Tom Poppendieck. que son más ampliamente aceptados en la comunidad de desarrollo ágil. Como desarrolladores de software no hacemos ninguna de esas dos cosas.

muy cerca en concepto de los principios fabricación Lean. 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. 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. nuestra tendencia normal es buscar a quien culpar. en vez de intentar maximizar la utilización de los recursos. No existen German E. Pero quizás es la situación en la cual se encontraba algunas de las personas que estamos culpando la que ocasionó el problema. y que es bueno tener en claro desde el principio. En otras palabras. Nunca se te da la oportunidad de hablar con alguien que realmente vaya a utilizar el software. sabemos que alguien tiene que tener la culpa del accidente. el problema tiene que ver con la forma en la que las personas están trabajando juntas. Supongamos que se te asigna como responsable de escribir una característica para un sistema existente. los principios Lean lo van a guiar hacia un mejor camino.Los principios Lean El desarrollo Lean puede resumirse en siete principios. Nociones previas importantes Antes. Al volver algunas cosas explícitas se logra que los coach Ágiles tengan más variedad a su alcance para mejorar los métodos. se le muestra la nueva característica al cliente. el "sistema" actual hace que cada persona trabaje de manera separada en roles específicos. Los dos primeros puntos son las bases del trabajo de Edwards Deming. Los principios de Lean también nos muestran cosas diferentes para mirar además de las prácticas Ágiles. en cambio. Schmidt LU: 41066 56 . vamos a describir a Lean en términos de las prácticas Ágiles que sugiere. vamos a ver algunos principios fundamentales sobre los que se basa Lean. sino que simplemente tenés que confiar en el documento. En esta serie de artículos. No nos cuestionamos este enfoque. Escribis el código. Deming es el hombre al cual los Japoneses les suelen atribuir la forma en la que producen bienes de alta calidad. 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. Esto brinda una guía para aquellos que intentan desarrollar software de manera más efectiva. Los principios que guian a Lean pueden aplicarse al software. Te dan la documentación de un analista del equipo que describe la funcionalidad que se tiene que escribir. Buscar la fuente de los errores en el sistema Cuando algo sale mal. que dice q eso no fue lo que pidio. muchas veces descripto como "Justo-A-Tiempo" (Just-InTime) fue agregado por Toyota y constituye un componente esencial de Lean. Veamos un ejemplo típico del desarrollo de software. se prueba. ¿A quién culparías? ¿Al cliente por no ser claro? ¿Al analista por escribir algo pobremente? ¿A vos mismo. en vez de describir a Lean por si sólo. • Se van a tomar mejores decisiones si se atiende la secuencia de tiempo del desarrollo. Por esto: • Se debe respetar a las personas para poder mejorar el sistema. El último punto.

y se propagan los errores. Los siete principios Eliminar los residuos El principio de eliminar los residuos (o muda. Ágil ofrece un soporte pobre para mejorar la comunicación entre los equipos. la mayoría se elimina porque la comunicación es mejor. Las prácticas Lean ayudan con la comunicación en estos contextos más grandes. La codificación parcial eventualmente abandonada durante el proceso de desarrollo es 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. en la forma de errores. que es un tipo específico de residuos en el léxico Toyota) ha sido tomado de las ideas de Taiichi Ohno . Producir todo lo que no necesita de inmediato. y la entrega rápida. la optimización del total. viendo como las diferentes prácticas apuntan a alguno de estos principios. arriba y abajo del flujo de valor. Defectos (menos calidad) En otras palabras. uno debería ser capaz de reconocer y ver. y por lo tanto deben ser eliminados. Las esperas ocasionadas por otras actividades. Schmidt LU: 41066 57 . esta es un residuo. analista. haciendo énfasis en la mejora continua del proceso. En Lean. Los procesos extra y funcionalidades que no utilizan con frecuencia por los clientes son residuos. y entre el equipo y el cliente. Mejorar la comunicación es uno de los objetivos principales de Ágil. El cliente. Se ha distinguido las actividades siguientes como residuos: • • • • • • Una parte de un automóvil almacenada a la espera de ser usada. Partes que necesitan esperar a que otras que se produzcan. German E. Este sistema es mejor. o a través de la compañía. aplicado al pensamiento Lean. las demoras de la comunicación causan demoras y desperdicios.mecanismos de feedback. En los artículos siguientes de esta serie vamos a describir a Lean en términos de prácticas Ágiles.el padre del Sistema de Producción Toyota. Movimiento innecesario de componentes. todo lo que no añade valor al cliente se considera un residuo. las prácticas Ágiles tienden a enfatizar la comunicación a un nivel local: entre el equipo. Pasos extra de procesamiento en la producción. Si alguna actividad podría ser superada o el resultado podría ser logrado sin ella. desafortunadamente. Aunque todavía es posible que surjan errores. Un "sistema" Ágil haría que las personas trabajen como equipo. desarrollador y testear hablarían entre ellos y decidirían juntos sobre las necesidades del cliente y la mejor forma de satisfacerla.

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.mientras más código se tenga. Por lo tanto. promoviendo así el nacimiento de la solución a través del diálogo con el cliente. Gastos generales de gestión que no producen valor real son residuos. Escribir menos código . más pruebas se van a necesitar. La acumulación de defectos debe evitarse ejecutando las pruebas tan pronto como el código está escrito. las distintas ideas podrían ser juzgados escribiendo código y construyendo. por lo que se necesitará más trabajo.cada uno de ellos junto con refactorización y pruebas de integración. los clientes comprenden mejor sus necesidades. Lo mismo debe hacerse iterativamente hasta incluso los procesos y procedimientos que parecen esenciales son eliminados. va a continuar repitiéndose (de una manera u otra). debemos asegurarnos que todos estos procesos son útiles y están enfocados en crear valor. Schmidt LU: 41066 58 . el practicante Lean observa al sistema para ver cómo eliminarlo porque es probable que cuando encontramos un error. hasta que arreglamos al sistema que lo provoca. • • • Brindar un liderazgo técnico y de mercado . pero es importante comprender lo que valoran nuestros clientes y conocer la tecnología que se está usando. logran aprender sobre el dominio del problema y buscar posibles soluciones para un mejor desarrollo. Durante los breves períodos de sesiones. En lugar de añadir más documentación o planificación detallada. El mejor enfoque para la mejora de un entorno de desarrollo de software es ampliar el aprendizaje. El desperdicio surge cuando se crean defectos. ayuda a determinar la fase actual de desarrollo y ajusta los esfuerzos para introducir mejoras en el futuro. se concentra en la comunicación de las limitaciones de soluciones futuras y no las posibles soluciones. El proceso de aprendizaje es acelerado por el uso de ciclos de iteración cortos . tanto los clientes como el equipo de desarrollo. Incrementando el feedback a través de cortas sesiones con los clientes. Eliminar el desperdicio es la guía principal de un practicante Lean.equipos o procesos son residuo. El desperdicio es evidente en el código que es más complejo de lo necesario. Defectos y menor calidad son los residuos. Otra idea en el proceso de aprendizaje y de comunicación con los clientes basado en el desarrollo. 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. basándose en el resultado de los esfuerzos del desarrollo. y los desarrolladores aprendan a satisfacer mejor estas necesidades.la organización puede ser exitosa si produce productos innovadores y tecnológicamente avanzados. Por ejemplo. En donde haya desperdicio. Existe desperdicio en el esfuerzo que se requiere para construir un producto: cualquier trabajo que no agrega valor. Se utiliza una técnica llamada value stream mapping de para distinguir y reconocer los residuos. Si escribiemos pruebas para funcionalidad que no se necesita estamos perdiendo el tiempo.debemos ser cuidados con todos los procesos que sigamos. German E. Crear sólamente cosas de valor . El segundo paso consiste en señalar las fuentes de los residuos y eliminarlos.

Esto no significa que no haya planificación involucrada en el proceso . Mantener una cultura de mejora continua . hasta que estas se basen en hechos y no en suposiciones y pronósticos inciertos.y que siempre tienen algún área que pueden mejorar. las actividades de planificación deben centrarse en las diferentes opciones y se las adapta a la situación actual. Cuanto más complejo es un proyecto. pero proporcionando la flexibilidad necesaria para una tardía toma de decisiones.deben saber que no son y no deben ser perfectas . German E. estableciendo las pautas para una acción rápida. lo que retrasa las decisiones tanto como sea posible. los mejores resultados se alcanzan con un enfoque basado en opciones. Enseñar métodos de resolución de problemas . así como se deben clarificar las situaciones confusas.deben saber que no son y no deben ser perfectas .lo más importante es mantener la dirección correcta. estableciendo hipótesis y realizando varios experimentos rápidos para verificar su validez. El enfoque iterativo promueve este principio.los equipos de desarrollo deberían comportarse como pequeños centros de investigación. lo vamos descubriendo día a día .debemos saber hacia donde queremos ir pero no conocemos el camino del todo. lo que podría ser muy costoso si se descubre después de la liberación del sistema. Esto también permite la adaptación tardía a los cambios y previene de las costosas decisiones delimitadas por la tecnología.los equipos de desarrollo deberían comportarse como pequeños centros de investigació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.por el contrario. Un enfoque de desarrollo de software ágil puede llevarles opciones antes a los clientes. o con las soluciones inventadas. Decida lo más tarde posible Como el desarrollo de software está siempre asociado con cierto grado de incertidumbre. Mantaner una cultura de mejora continua . Evaluar las diferentes opciones es eficaz tan pronto como queda claro que ellos no son libres. Enseñar métodos de resolución de problemas .crear un ambiente en donde las personas estén mejorando continuamente en lo que trabajan . o con las soluciones inventadas.• • • Crear equipos de diseño y construcción . así que debe permitirse el retraso los compromisos importantes y cruciales. la capacidad de adaptarse a los cambios y corregir los errores.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.y que siempre tienen algún área que pueden mejorar. • Agendar las decisiones irreversibles hasta el último momento responsable . más capacidad para el cambio debe incluirse en este.crear un ambiente en donde las personas estén mejorando continuamente en lo que trabajan . Crear equipos de diseño y construcción . por lo tanto. retrasar algunas decisiones cruciales hasta que los clientes se hayan reconocido mejor sus necesidades. Schmidt LU: 41066 59 . estableciendo hipótesis y realizando varios experimentos rápidos para verificar su validez.

) que en realidad no se necesitan y agregan complejidad. Algunos requerimientos son más importantes que otros. y por los requerimientos que crearán un riesgo técnico si no se los ataca tempranamente. El primero genera un código que va a ser dificil de cambiar. Este principio puede usarse para guiar a los requerimientos.es decir. al análisis y al diseño de un sistema. igual que yo (una forma de decir de que no pueden adivinar el futuro .los componentes deben estar lo más desacoplados posible para que puedan implementarse en cualquier orden.• • Romper con las dependencias . 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. no podemos volver atrás el tiempo. a menudo terminamos con hooks (clases. que es hacer algo lo más simple posible . Los métodos Ágiles se encargan de esto al hacernos enfocar en aquellos requerimientos que el cliente siente que son los más importantes. El otro enfoque es anticiparse a lo que pueda ocurrir y construir hooks dentro del sistema. Mantener opciones . Al tomar requerimientos debemos preguntarnos . El segundo enfoque genera código que es más complejo del necesario. Los desarrolladores tienden a tomar uno o dos enfoques distintos cuando se los fuerza a diseñar algo que no tienen muy claro. Estos requerimientos que son los más importantes para el negocio son los que usualmente le dan más valor al cliente. cuando nos anticipamos a resolver temas futuros. ¿Cuáles requerimientos puede provocar problemas si se los ignora? Estos requerimientos también tienen que atenderse. todos somos discapacitados en este sentido!). 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. Para también puede ser un compromiso a usar tiempo. Una vez que hayamos usado cierto tiempo en hacer algo. Esto ocurre porque la mayoría de los desarrolladores tienen una discapacidad para ver el futuro. Posponer el compromiso en el diseño. German E. Ambos de estos enfoques tienen desafios distintos. Esto ocurre porque no se considera la naturaleza cambiante del código cuando se lo escribe. Schmidt LU: 41066 60 . o hasta que no podamos esperar más a tomar esa decisión sobre qué hacer.desarrollar múltiples soluciones para todas las decisiones críticas y ver cuales funcionan mejor. etc. no puede deshacerse . Debería empezar con los requerimientos que invlucran funcionalidad que es la más importante para el negocio.hasta donde yo sé. Posponer el compromiso en los requerimientos y el análisis.¿en dónde debería usar mi tiempo? ¿Necesito discutir todos los requerimientos con el cliente? Claramente no. Muy a menudo pensamos en los compromisos como en una acción o decisión que hicimos. métodos.esta regla es dentro del contexto de otras acciones). 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. También hay que prestar atención a los riesgos arquitectónicos. Luego.

acortar los ciclos de entrega. tres equipos pueden diseñar soluciones al mismo problema. cada miembro del equipo evalúa lo que se ha hecho ayer.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. estabilizar el ambiente de trabajo (escuchá lo que te dice la velocidad). y lo que hay que hacer hoy y mañana. mejor es el aprendizaje y la comunicación dentro del equipo. las decisiones no pueden ser postergadas.rechazar cualquier trabajo hasta que se haya vaciado un lugar en la cola. más pronto se pueden recibir comentarios. se desecha. no en la utilización . repetir lo bueno y erradicar las prácticas que crean obstáculos. 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í. Esto requiere la transparencia del proceso. 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. un gran ejemplo de compromiso aplazado hasta el último momento posible. la organización del trabajo cambia en sistema autopropulsado: cada mañana durante una reunión inicial. • • • Trabajar en bloques pequeños . Esto les da la oportunidad de demorarse pensando lo que realmente necesitan. el cliente dispone los requisitos necesarios. no hay que tener miedo al quitar elementos de la cola . Limitar el trabajo a la capacidad . reconociendo sus necesidades específicas y el ambiente. Enfocarse en el tiempo del ciclo. y se incorporan en la siguiente iteració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 German E. La ideología de producción Just In Time podría aplicarse a programas de desarrollo. y pregunta por cualquier nueva entrada necesaria de parte de sus colegas o del cliente.reducir el tamaño del proyecto.Otra idea clave del Sistema de Desarrollo de Producto de la Toyota se establece a base de diseño. hasta que adquieran un mejor conocimiento. La velocidad asegura el cumplimiento de las necesidades actuales del cliente y no lo que este requería para ayer. que es también beneficioso para la comunicación del equipo. Schmidt LU: 41066 61 . Cuanto antes el producto final se entrega sin defectos considerables. por ejemplo.limitar la cola de tareas al mínimo (una o dos iteraciones por delante es suficiente). Sin velocidad. Cuando una solución se considera irrazonable. Si un nuevo sistema de frenos es necesario para un coche. Cuanto más cortas sean las iteraciones. Cada equipo aprende sobre el problema de espacio y diseños de una posible solución. Al principio. Los clientes valoran la entrega rápida de un producto de calidad. los diseños sobrevivientes se comparan y se elige uno. Al final de un periodo. 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 . quizá con algunas modificaciones basadas en el aprendizaje de los demás.

de manera que estos puedan explicar mejor qué acciones podrían tomarse. con la garantía de que el equipo puede elegir sus propios compromisos. evitando así la gran y estresante cantidad de información después de un largo periodo de desarrollo en el aislamiento. 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. El flujo de información debe ser constante en ambas direcciones . Las personas podrían ser los recursos desde el punto de vista de una hoja de datos estadísticos.a partir del cliente a los desarrolladores y viceversa. 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. las instalaciones. Una de las maneras más saludables hacia una arquitectura integrante es la refactorización. 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. y cualquier cosa que sea rutinaria. así como cualquier organización de negocios. entregar. 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 . La información necesaria es recibida por los pequeños lotes . así como ofrecer sugerencias para mejoras. pero en el desarrollo de software. Las personas necesitan motivación y un propósito superior para el cual trabajar – un objetivo alcanzable dentro de la realidad.no en una vasta cantidad y con una preferible comunicación cara a cara. el jefe de equipo debe proporcionar apoyo y ayuda en situaciones difíciles. eficiencia y capacidad de respuesta. Los desarrolladores deberían tener acceso a los clientes. así como asegurarse de que el escepticismo no arruine el espíritu de equipo. mantenibilidad. los roles cambian: a los directivos se les enseña a escuchar a los desarrolladores. Esto podría lograrse mediante la comprensión del dominio del problema y resolviéndolo al mismo tiempo. Hay que automatizar de una manera inteligente. de las pruebas y de la documentación para minimizar la complejidad. Automatizar: automatizar las pruebas. Otra creencia errónea ha sido considerar a las personas como recursos.cada vez que aparezca la oportunidad. no secuencialmente. como en un todo. En una técnica Work-Out. Schmidt LU: 41066 62 . 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.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 . sin ninguna documentación por escrito. realizar el refactor del código. German E.los administradores de decirle a los trabajadores de cómo hacer su propio trabajo. logrando equilibrio entre la flexibilidad. 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". la construcción.

si no agregan valor deben considerarse residuos. si bien permitió construir un proceso estático muy bueno para construir un tipo de auto. respetar a las personas incluye la noción de que el equipo que hace el trabajo es responsable por el proceso que siguen. El completo y automatizado proceso de construcción debe ir acompañada de una suite completa y automatizada de pruebas. la claridad. la refactorización es mantener la sencillez. sincronización y semántica que el sistema actual. Fomentar orgullo por el trabajo . por tanto. siempre están cambiando.darles a los líderes de equipo entrenamiento.fomentar la pasión y la participación del equipo hacia lo que hacen y cómo lo hacen. Primero. sino más bien un medio para un fin. tanto para desarrolladores y clientes. Mover la responsabilidad y la toma de decisiones al nivel más bajo posible . la integridad debe ser verificada con una prueba global. y atraer y retener personas disponibles para trabajar. 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. Por último. hoy en día la compensación monetaria está relativamente baja en la lista de razones por las que uno selecciona un empleo. Hay tres problemas con este pensamiento. mas se pierde del código base para futuras mejoras. 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". El proceso se convierte German E. 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. mejora continua del proceso. Ford tenía muy poco respeto por el conocimiento de sus trabajadores. Al final. Las pruebas automatizadas también son consideradas como parte del proceso de producción y. la mayoría de los procesos no son estáticos.ellos saben mejor que nadie cómo implementar algoritmos dificiles y aplicar tecnologías de última generación. la cantidad mínima de funcionalidades en el código. Y es así cómo se cambian los procesos en la línea de producción.tanto a la gerencia como a los trabajadores .es clave para permitir flexiblidad en el proceso. garantizando que el sistema hace lo que el cliente espera haga. . Respetar a las personas . Respetar a las personas • • • Capacitar a los líderes de equipo . Así como en la metodología ágil XP. Las repeticiones en el código son signo un mal diseños de código y deben evitarse.dejar que las personas piensen y decidan por su cuenta . Las pruebas automatizadas no deberían ser un objetivo. el proceso no ofrecía ninguna flexibilidad. específicamente para la reducción de defectos. En el desarrollo de software. ¿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. Schmidt LU: 41066 63 . Segundo. que tengan la misma versión. 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. guías y espacio libre para implmenetar el pensamiento Lean en su ambiente.Cuanto más funcionalidades se añaden a las del sistema. Hoy en día esta falta de respeto se traduciría en no poder retener empleados de calidad.

no funcionan. 2. es libre. Me pregunto entonces ¿Por qué lo seguimos haciendo?. en realidad.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. lo que necesitamos es una capa más de “control”. Limitar la implementación de estos patrones a aquellas características que sean relevantes. 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 microtareas a cada miembro del equipo le haya funcionado para que la gente se comprometa más con una fecha de entrega? Proyectos. antes de aplicarlo de manera concreta en una situación de la vida real. dentro de las restricciones que tienen. MoProSoft y cuántos acrónimos más. para las cuáles invertimos miles y miles de pesos en herramientas y cursos de CMM. Al parecer nuestras organizaciones y nosotros mismos pensamos que cuando algo no sale bien en nuestros equipos. LSD nos obliga a pensar. a cuestionarnos y a encontrar nuestras propias respuestas. Sólo cuando todos los principios de Lean se aplican al mismo tiempo. a tener “conformidad” con el proceso mágico que resolverá todos nuestros problemas. aprender con rapidez" . no rápido. ¿Como liberar a nuestros proyectos de balas de plata que no funcionan? Afortunados somos de tener Lean Software Development (LSD) a nuestro alcance. negligentes o apáticos. Se le considera parte de los Métodos Ágiles. El Diseño Emergente en el software es una combinación de tres disciplinas: 1. rebeldes. LSD se basa en aplicar al desarrollo de software. hay una base para el éxito en el desarrollo de software. el proceso cambia. los principios Lean que han hecho tan exitoso a Toyota y otras empresas. pero desde mi punto de vista están por encima de ellos. combinado con un fuerte "sentido común" en relación con el ambiente de trabajo. Anhelamos recetas secretas. Desarrollado con mucho éxito por los Poppiendick a partir de las sólidas experiencias de 3M y Toyota. Usar patrones de diseño para crear arquitectura de aplicaciones que son robustas y flexibles. es gratis y simplemente funciona. lo que necesitamos es tan solo un sólido conjunto de principios y sentido comun. el proceso es la base del equipo para construir software de la mejor manera que conocen. "Pensar en grande. Cuando esto cambia. Un poco mas de LEAN La manera de pensar ofrecida Lean tiene que ser bien entendida por todos los miembros de un proyecto. un “proceso” más definido y detallado que “obligue” a los programadores. German E. Schmidt LU: 41066 64 . En enfoque alternativo a estos dos es el Diseño Emergente. Levante la mano por favor. Luego. PMI.en su comprensión de cómo desarrollar software mejor. cual oro de tontos nos estén vendiendo. actos pequeños.

Entender como construirlo. Podemos mirar al desarrollo de producto en tres partes: 1. y las pruebas mejoran al diseño y hacen que el cambio sea seguro. • Tener código altamente acoplado entre si. Schmidt LU: 41066 65 . 2. Los patrones de diseño hacen que el código sea facil de cambiar. Constuirlo. • Al hacer un desarrollo iterativo evitamos escribir código que no se necesita. Creo que el desarrollo de software es más un proceso de descubrimiento que de construcción. Uso del desarrollo iterativo para minimizar complejidad y retrabajo Los principales motivos de la complejidad son: • Escribir código que no se necesita. Es decir. 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. haríamos bien en descubrir lo que constituye un desarrollo de producto de excelencia (Poppendieck y Poppendieck 2006). Crear conocimiento La creación de conomiento es una parte integrar del proceso Ágil. Construimos por etapas para descubrir lo que el cliente necesita. Entonces en un sentido muy real. podemos llamar al desarrollo de software como un subconjunto del desarrollo de productos. El Diseño Emergente nos asiste en el desacoplamiento al permitirnos usar código sin agregar complejidad innecesaria al hacerlo.3. Una definición útil del Desarrollo de Productos es que son las actividades colectivas. o sistemas. 3. si queremos comprender el desarrollo de software Lean. limitarse a escribir código para lo que se necesita hace que el sistema se mantenga pequeño (y menos complejo). El desarrollo de software es sólo un subconjunto del proceso de desarrollo del producto. el proceso en el cual se embebe el software el cual es el producto real en desarrollo. Al hacerlo de esta manera entregamos valor rápidamente y evitamos construir cosas de menos valor. Descubrir lo que necesita el cliente. 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. la actividad. En este aspecto es muy parecido al desarrollo de productos. Más aún: Es el producto. 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. Y así. 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). German E.

más lealdad y otros intangibles. Si bien los beneficios de entregar rápidamente son claros. requerimientos completos. a los desarrolladores y testers y definir pruebas de aceptación antes de escribir el código. Construir calidad en el código se logra por los métodos mencionados anteriormente para eliminar el desperdicio. 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. La mayoría de los desarrolladores gastan mucho tiempo descubriendo cómo arreglar errores que fueron reportados. 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. perdemos todo el código fuente. 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. Entregar rápidamente Otra razón para hacer desarrollo iterativo es poder entregar valor de manera rápida al cliente. En el mundo del software. sin intentar mejorarlo. Imaginemos haber terminado un proyecto de desarrollo de software y luego. El problema con optimizar cada paso es que genera inventarios grandes entre los pasos. Schmidt LU: 41066 66 . mayor credibilidad del negocio con el cliente. Construir la calidad desde adentro Para poder sostener la velocidad del desarrollo. Si quisieramos re-crear el sistema. ¿cuánto tiempo nos llevaría? Y por "re-crear" quiero decir reconstruirlo esencialmente de la misma manera. podemos dejar afuera cosas que no son necesarias. Esto mejora la conversación alrededor de los requerimientos y también asiste a los desarrolladores en comprender qué funcionalidad se necesita escribir. Esto permite lograr una mayor penetración en el mercado. Entonces. también genera ganancias de manera más temprana. es esencial que esto se haga de una manera sustentable. Lean demostró que un flujo de "una pieza" (por ejemplo.. enfocarse German E.En el desarrollo de software parece que gastamos la mayor parte del tiempo hablando del Paso 3.. Debemos enfocarnos en el proceso completo. Una mejora sugerida es juntar al cliente. sin embargo son los dos primeros pasos los que nos terminan llevando más tiempo. Sin embargo. al final. lo único. Construir calidad en el proceso les permite mejorarlo al eliminar los desperdicios que crea o necesita. En otras palabras. Esto es por falta de pruebas automatizadas y por una pobre calidad de código que lo hace dificil de entender. los equipos tienen que construir la calidad tanto en el proceso como en su código. permitienendo que las entregas iniciales paguen al desarrollo subsiguiente. codificar o probar). 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. pero sin diseñar. ¿qué se estuvo haciendo el otro 50%-80% del tiempo? Estuvimos "descubriendo lo que el cliente necesita" y "entendiendo cómo construir eso". estos "inventarios" representan al trabajo parcialmente terminado (por ejemplo.

Eliminar el derroche Eliminar el derroche parece simple. Las herramientas no son adecuadas. Liberar Rápido De acuerdo. si el programa no es lo que el cliente espera. La nueva tecnología no trabaja bien. en actividades como el desarrollo de S. Retrasar los compromisos En este punto estoy de acuerdo. German E. nos lo hara saber rápidamente recurriendo a otra empresa. 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. Lo indispensable debe ser el método de trabajo no los componentes humanos. idealmente seria lo optimo tener un grupo de desarrollo q se encargue de un tipo de dominio especifico pero esto casi nunca es así. generar cosas que funcionen rápidamente es mucho mejor que el desarrollo de todo el sistema en paralelo. 2. El dominio del problema debe de ser quien determina el tipo de organización adecuada. 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. Un ejemplo: El Warcraft III. Por q si uno de resfria … estamos en problemas.W generar cronogramas donde se especifica que se hace de acá a seis meces es irreal.S. 4. Por que por mas detallados y lindos q sean los documentos.D 1. en lugar de desgastarse produciendo documentos y modelos que la verdad según mi experiencia solo son un derroche de energía. Criticas al L. lanzado en el julio del 2002 sigue siendo mantenido y pacheado hasta la fecha por la empresa Blizzar. 6. Pueden ocurrir cosas inesperadas. 7. Construir Integridad Intriseca Nunca se prueba o inspecciones están de más.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. Pero es probable que uno pueda obtener ciertos conocimientos generales sobre como trabajar con un método. Ampliar el Aprendizaje No siempre se trabaja sobre el mismo dominio de problemas. ETC. 3. 5. Finalmente creo q este método de trabajo nos da un enfoque realista de cómo se debe de trabajar. Pensar en el todo Estoy de acuerdo no se puede tener alguien indispensable. Facultar al equipo La organización del grupo de personas es todo un tema en si mismo. Schmidt LU: 41066 67 . Cuando un producto mas se prueba este se va haciendo mas estable y mas adecuado a lo que el usuario quiere.

Por un lado. El modelo de gestión Liderazgo-Colaboración de Jim Highsmith. quien llevara a la práctica este concepto en la gestión de su propia compañía. habrá de ser la ciencia más importante del nuevo siglo. Esto sucede aunque estos sistemas son deterministas.Agilidad. no lineales. La cuestión merece tratarse en un estudio específico. atractores extraños. dinámica no lineal. pero sin tender a un atractor fijo Las teorías de la complejidad tratan de con diversas clases de procesos. pero a la vez. programación evolutiva. hay "fuerzas" que lo alejan de éste. Racoon referido al caos y al ciclo de vida caótico. 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 • German E.0 hay.controlchaos. S. Haciendo honor al nombre. Pequeñas variaciones en dichas condiciones iniciales. • Algunos de los ideólogos de Scrum se inspiran en conceptos tales como filo del caos y control de procesos caóticos. Inestables. series de Fibonacci. redes neuronales. 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. orden emergente. gramáticas recursivas. complicando la predicción a largo plazo. De esa manera. Un sistema estable tiende a lo largo del tiempo a un punto. el sitio de Scrum está en http://www. memética. Los autores también se refieren al modelo de L. tal como se los describe en el conocido libro Chaos de James Gleick. aquí sólo brindaremos un puñado de indicios sobre esta peculiar convergencia. metaheurísticas. un comentario sobre la naturaleza caórdica de los sistemas. fractales. También afirman que Microsoft implementa en sus prácticas de desarrollo una estrategia de caos controlado. existe un atractor por el que el sistema se ve atraído. la física y otras ciencias que trata ciertos tipos de sistemas dinámicos muy sensibles a las variaciones en las condiciones iniciales. B. como se ha visto. modelos basados en agentes autónomos. Caos y Complejidad Teoría del caos es la denominación popular de la rama de las matemáticas.com. pueden implicar grandes diferencias en el comportamiento futuro. criticalidad auto-organizada. Los sistemas dinámicos se pueden clasificar básicamente en: • • • Estables. redes booleanas aleatorias. el sistema permanece confinado en una zona de su espacio de estados. Hock sostiene que la ciencia de la complejidad. • En MSF 3. se funda en las ideas de Hock. complejos y adaptativos. según su dimensión (atractor o sumidero). Un sistema inestable se escapa de los atractores Caóticos. su comportamiento está completamente determinado por sus condiciones iniciales. es decir. Schmidt LU: 41066 68 . por ejemplo. aunque no proporcionan mucho detalle a su razonamiento. En Scrum se habla de caos permanentemente. Visa. fenómenos y sistemas: autómatas celulares. ligada a la comprensión de los sistemas autocatalíticos. en el sentido del concepto acuñado por Dee Hock. Y un sistema caótico manifiesta los dos comportamientos. u órbita.

• En las páginas de su sitio empresarial y en su bibliografía. enfatizando sus aspectos evolutivos.Holland. 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. quien también ha ejercido influencia sobre Highsmith. cada pájaro sigue reglas simples y locales. • En su presentación de Adaptive Software Development. el padre del algoritmo genético. 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. Uno de los ataques más duros y tempranos proviene de una carta de Steven Rakitin a la revista Computer. Jeff DeLuca establece la estrecha relación entre las premisas de FDD y las teorías del caos determinista y de la complejidad. Rakitin expresa que en su experiencia. los elementos de la derecha (vinculados a la mentalidad planificadora) son esenciales. LD promueve un diseño semejante a los de XP y Scrum. es natural que se generara oposición a los que en ocasiones la reacción frente a ellos adoptara una fuerte actitud combativa. pero no demasiada. bajo la rúbrica “El Manifiesto genera cinismo”. XP es más bien posmoderno. el más vinculado a las nuevas ciencias de la complejidad y el caos [Hig00a]. el primero afirmó que mientras SEI se encuentra en el campo modernista. Rakitin practica una German E. los adversarios que se han ganado no se han quedado atrás en sus réplicas. 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. Así como hay una lectura literal y una estrecha del canon de CMM. pero la ironía prevalece. es. Si los ágiles han sido implacables en su caricatura de las metodologías rigurosas. como ya se ha visto. Estas ideas han inspirado un modelo de gestión basado en cooperación y competencia. • • 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. 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. Schmidt LU: 41066 69 . pero en la macro-escala la bandada exhibe orden y un claro comportamiento colectivo emergente. para no suprimir la emergencia y la creatividad. Es significativo que este juicio haya sido expresado por el creador de la Programación Extrema. vinculándolas con el pensamiento no lineal de Fred Brooks y con la concepción del control de caos de Jim Highsmith. Lo que sigue es apenas una muestra. donde se considera el comportamiento de sistemas sociales de insectos como una manifestación de trabajo en equipo. adaptable y sensible a los requerimientos del cliente. por mucho. soluciones adaptativas y capacidades emergentes. Refiriéndose a la estructura opositiva del Manifiesto. Una visión semejante se presenta en el modelo de Mary y Tom Poppendieck de Lean Development. En una entrevista a Kent Beck y Martin Fowler. En esta contienda hay algunas observaciones de carácter técnico. “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. Este modelo basado en la analogía entre empresas/equipos/proyectos y sistemas adaptativos complejos.

que resultados de investigaciones en curso cuestionan la viabilidad de la programación orientada por pruebas4. precios y fechas fijas. pero “luego se ncuentra. 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. ni sobre ambientes de desarrollo físicamente distribuidos. 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. pero no más simple que eso”. 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”. ni (a pesar de su insistencia en reutilización y patrones) sobre integración de componentes listos para usar (COTS). Gerold Keefer. XP no se expide sobre proyectos con alcances. las reglas de XP son excesivamente rígidas. Por añadidura. un par de libros de buena venta. Algunos de los hechos tenidos en cuenta son que no sólo el primero. de AVOCA GmbH. ni sobre requerimientos no funcionales como performance y seguridad. a la escasa verosimilitud de las historias de éxito de C3 y VCAPS. 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. En primer lugar. diferentes proyectos requieren distintos procesos. sino que prefiere la postura de Einstein: “Que sea lo más simple posible. no le persuade la premisa de “hacer la cosa más simple que pueda funcionar”. a las malas prácticas resultantes de la negación a documentar. Más tarde. que su crítica levante vuelo. Dadas las premisas desaliñadas y las falsas publicidades. por alguna razón que se nos escapa. 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. 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”. Mucho más fundamentado es el estudio puramente crítico de Edward Berard. el promotor de RAD SteveMcConnell se ha opuesto con vehemencia a las ideas más radicales del movimiento ágil. McConnell expresa que “el fenómeno parece un caso de hipnosis colectiva” [Baer03]. que se manifiesta antes de lo que se cree. su estilo redundante. Además. y que reportes de proyectos de gran envergadura demuestran su insuperable problema de escalabilidad. quien señala un buen número de “falacias” y medias verdades en el discurso ágil pero no logra. cuyo proceso puede consumir hasta el 30% o 40% de los recursos de un proyecto. 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. dice McConnell: “Esta industria tiene una larga historia en cuanto a pegarse a cuanta moda sale”. Otros argumentos de Keefer apuntan a los altos costos y magros resultados de la programación en pares. etcétera. por último. Los cargos de McConnell contra XP son numerosos. Inesperadamente. su tono socarrón y su falta de método argumentativo. que estas tendencias no logran el éxito que sus evangelistas prometieron”.“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. y pocas de ellas son nuevas: Tom Gilb proponía lineamientos similares muchos años atrás. casi nadie aplica las 12 en su totalidad. cuando los bombos y platillos se enfrían. Schmidt LU: 41066 70 . German E. A Keefer. Se ha manifestado contrario tanto a las estrategias técnicas como a las tácticas promocionales.

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

wikipedia. etc. Ademas de introducion otro nivel de abstracción que generalmente complica mas las cosas.CONCLUSIÓN La mayoría de los métodos de desarrollo de S. UML siempre ha sido muy criticado por su carencia de una semántica precisa.extremeProgramming. Addison-Wesley. http://www.xProgramming. por ejemplo. Schwaber.wikipedia.agilemanifesto.htm Alianza Ágil. Ken. el tiempo ira decantando cuales estrategias son buenas para determinada área de desarrollo y cuales no. usar UML para señalar que un objeto es persistente o remoto. Lean Software Development: An Agile Toolkit. No se puede. & Mike Beedle. serialización.agilealliance. 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.com/blogs/lean-agile-software-development-chapter3-bigpicture http://es. Agile & Iterative Development: A Manager’s Guide. Tomemos por ejemplo UML a pesar de su status de estándar ampliamente reconocido y utilizado. UML no cuenta con maneras de describir tales factores. o que existe en un servidor que corre continuamente y que es compartido entre varias instancias de ejecución del sistema analizado. Agile Software Development with Scrum.com/category/process/lean-software/ http://tech. German E.org/wiki/Teoria_del_caos http://epistemologic. pensar de otra forma es un error que puede costar caro. Poppendieck. lo que ha dado lugar a que la interpretación de un modelo UML no pueda ser objetiva. Schmidt LU: 41066 72 .org Ron Jeffries http://www.com/hci/lean.groups.org/wiki/Lean_software_development http://www.org http://agilesoftwaredevelopment.W proclaman ser EL MÉTODO! En mi opinión eso no es asi. persistencia.com/group/leanprogramming/ http://tecnonirvana. Como el desarrrollo de S. Prentice Hall. http://www.org Manifiesto para el Desarrollo de Software Ágil.org/blog/2007/07/15/libera-tus-proyectos-con-lean-softwaredevelopment/ http://albertolacalle. Addison-Wesley.netobjectives.com Don Wells http://www. Referencias bibliográficas http://es.W es una técnica nueva. Craig.com/leanprinciples Larman.yahoo. Mary & Tom Poppendieck. No existe un sistema que abarque todos los posibles Áreas.

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->