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

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

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

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

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

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

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

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

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

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

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

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

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.5 2 2. Á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. costo del cambio metodología tradicional suposición metodología ágil tiempo German E. a medida que avanza el tiempo.5 1 1.5 3 3. Como se puede apreciar. Schmidt LU: 41066 15 . 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

¿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. en las entregas frecuentes de productos. las demás fases presentan las características del modelo iterativo e incremental ya tratado. Schmidt LU: 41066 45 . Sin embargo.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. 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. lo que diferencia a DSDM de dicho modelo son los principios alrededor de los cuales se estructura y que hacen énfasis en los equipos de desarrollo. en el feedback con el cliente.

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

Algunas técnicas sugeridas en DSDM son las sesiones JAD para capturar los requerimientos del software y la realización de prototipos para descifrar aquellas ambigüedades que se presentan en el relevamiento y también para derribar las barreras comunicacionales entre analistas y usuarios. el cual se va refinando hasta tenerse la aplicación deseada. Schmidt LU: 41066 47 . y diseño. usabilidad. El énfasis queda en manifiesto en los prototipos que se sugieren para cada etapa: negocio. 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. En resumen. encontramos en DSDM una metodología ágil creada en el Reino Unido a partir de un consorcio con participación de empresas de primera línea. El enfoque propuesto consiste en la utilización de un prototipo evolutivo. German E.la consistencia de los componentes construidos respecto a esta y al cumplimiento de los estándares técnicos. El mismo contiene las características principales de las metodologías ágiles y contiene prácticas tendientes al enfoque RAD. performance y capacidad.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master Your Semester with a Special Offer from Scribd & The New York Times

Cancel anytime.