1 Agilidad, Disciplina o Caos Agilidad, Disciplina o Caos Reflexiones sobre el desarrollo de software II Jornada Gerencia de proyectos de software Bogotá, Marzo 25 de 2004
2 1 2 3 Agenda Preguntas y respuestasPlantear algunos de los problemas que se presentan en el desarrollo de software. Introducir los conceptos de disciplina y agilidad 1 2 Reflexionar sobre algunas de las soluciones que a estos problemas plantean los métodos denominados ágiles y las aproximaciones más formales al desarrollo de software 3 Preguntas y respuestas Agilidad, disciplina o caos
3 1 2 3 Agenda Preguntas y respuestasPlantear algunos de los problemas que se presentan en el desarrollo de software. Introducir los conceptos de disciplina y agilidad 1 2 Reflexionar sobre algunas de las soluciones que a estos problemas plantean los métodos denominados ágiles y las aproximaciones más formales al desarrollo de software 3 Preguntas y respuestas Agilidad, disciplina o caos
4 Que sucedería si … Que sucede cuando ….Usted le respondiera a su compañía que no tiene ni idea cuánto va a demorar un nuevo proyecto de software del cual usted es responsable? Un productor de software le contesta a un potencial cliente que no sabe cuánto tiempo toma y cuánto cuesta un proyecto de software sobre el cual están hablando? Que sucede cuando …. Usted le responde a su compañía cuánto va demorar el proyecto (y hasta desarrolla un cronograma detallado)? El productor de software se compromete en términos de costo y tiempo (y en su propuesta incluye un cronograma que deja muy satisfecho al cliente)? Agilidad, disciplina o caos
5 Que haría si … A usted, que considera que la documentación es una pérdida de tiempo, un proveedor de software externo no le presentara un diagrama de arquitectura de la aplicación que usted le contrató, se la entregara sin documentación, etc.? Usted, que es conciente de la importancia de la documentación, tiene que decidir entre salir a producción un mes después, o hacerlo antes sacrificando la misma (Time to market)? La burocracia de su compañía no permite elicitar los requerimientos de un nuevo sistema con la celeridad que se requiere? La informalidad o falta de método no permite que el software sea construido de tal manera que satisfaga los requerimientos del cliente y usuarios finales (“Yo entendí eso ”, “No me dijeron”, “Si le dije”)? Agilidad, disciplina o caos
6 Que haría si … Después de cuatro cronogramas el grupo de ingenieros sigue incumpliendo? Los cambiaría? Llamaría a un asesor? Se tiraría por la ventana? Nada? Si los usuarios siguen cambiando los requerimientos a pesar de múltiples reuniones, compromisos, conversaciones con la presidencia, peleas, etc.? Luego de entregar a tiempo un proyecto con aproximaciones no formales, el software parece un crispetero, es lento, se cae a toda hora y no le gusta a los usuarios? Si ya se le acabó el presupuesto y sabe que aún tiene meses hombre de trabajo por delante? Agilidad, disciplina o caos
7 y han conducido a los metodologistas a asumir posiciones extremas.Estas y otras cuestiones han estado siempre en el centro de la discusión en cuanto a Ingeniería de software se refiere … y han conducido a los metodologistas a asumir posiciones extremas. Incorrectamente, a juicio del autor, se plantea a cuestión como si se tratara de una decisión entre Disciplina y Agilidad. Incorrectamente, a juicio del autor, se predica la universalidad de uno y otro enfoque Agilidad, disciplina o caos
8 Se oponen estos dos conceptosSe oponen estos dos conceptos? Será cierto que algo ágil no puede ser disciplinado y algo disciplinado no puede ser ágil? Agilidad. Rapidez y buena coordinación Disciplina. Apego a procedimientos establecidos. Auto control. Agilidad, disciplina o caos
9 No se oponen. Se complementan (*)Alta Jerárquica Gran organización Disciplina Nueva organización (Startup) Burocrática Baja Agilidad Baja Alta (*) Collins. Matriz de disciplina creativa. Agilidad, disciplina o caos
10 “La disciplina es la base de cualquier esfuerzo exitoso“La disciplina es la base de cualquier esfuerzo exitoso. Los atletas entrenan, los músicos practican … y los ingenieros aplican procesos. Sin estos fundamentos, puede darse el éxito ocasional, pero la consistencia profesional y el éxito a largo plazo son limitados. Donde la disciplina arraiga y fortalece, la agilidad libera e inventa. Le permite a los atletas hacer la jugada inesperada, a los músicos improvisar … y a los ingenieros ajustarse a los cambios en tecnología …” Versión. Barry Boehm and Richard Turner. Balancing Agility and Discipline. Agilidad, disciplina o caos
11 1 2 3 Agenda Preguntas y respuestasPlantear algunos de los problemas que se presentan en el desarrollo de software. Introducir los conceptos de disciplina y agilidad 1 2 Reflexionar sobre algunas de las soluciones que a estos problemas plantean los métodos denominados ágiles y las aproximaciones más formales al desarrollo de software 3 Preguntas y respuestas Agilidad, disciplina o caos
12 Las dos aproximaciones, aparentemente antagónicas, son conocidas en la literatura como ….Metodologías guiadas por un plan. Algunos las consideran como la aproximación tradicional al desarrollo de software. Metodologías ágiles. Entre las mas conocidas se encuentran XP, SCRUM, UP (RUP), etc. Algunos no consideran RUP como ágil, pues es una mezcla. Agilidad, disciplina o caos
13 Algunos relacionan las metodologías guiadas por un plan con el desarrollo en cascada tradicional porque …. Las Metodologías guiadas por un plan surgieron hace algunos años, cuando se intentaba producir software con una aproximación en cascada. Los primeros intérpretes de CMM, por ejemplo, adaptaron el modelo a ese ciclo de vida, influenciados por el tipo de Ingeniería de Sistemas que requería, en aquel entonces, el DoD de los EE.UU., y compañías como Siemens, Hitachi, IBM, etc. Como se verá, las aproximaciones modernas reconocen una mezcla de aproximaciones denominadas ágiles y aproximaciones guiadas por un plan. Agilidad, disciplina o caos
14 El modelo en cascada …… … obedece a la mala adaptación de la planeación predictiva al desarrollo de software Salvo excepciones, el modelo en cascada no funciona bien en el desarrollo de software Agilidad, disciplina o caos
15 En este modelo, se aborda una secuencia definitiva de eventos, tal cual se hace en la planeación predictiva Requerimientos Análisis y diseño Diseño detallado Codificación Pruebas Operaciones Agilidad, disciplina o caos
16 Lo cual normalmente no funciona …..Manufactura predecible Desarrollo de nuevo producto Es posible completar las especificaciones y luego construir el producto de manera repetida Raramente es posible crear desde el comienzo especificaciones que no cambien Cerca al comienzo, se pueden hacer estimaciones confiables de esfuerzo y costo Cerca al comienzo no es posible estimar. La confiabilidad crece en la medida que avanza el proyecto Es posible identificar, definir, programar y ordenar todas las actividades en detalle Cerca al comienzo no es posible hacerlo pues se trata de un nuevo producto (casi siempre) La adaptación a cambios impredecibles no es la norma pues la rata de cambios es baja La adaptación a los cambios es la norma. La rata de cambios es elevada Agilidad, disciplina o caos
17 Y conduce a … Sobre costos, proyectos muy demorados en el tiempo, baja calidad. En general, proyectos impredecibles. Integración en etapas finales y problemas tardíos de diseño Mucho re trabajo Software que no satisface las necesidades de clientes y usuarios Foco en documentos y reuniones formales de diseño (IWKIWISI). Quizá por esta razón se habla que las aproximaciones basadas en planes producen muchos documentos Insatisfacción generalizada de los interesados (Cliente, usuarios, grupo de ingeniería, proveedor del software, etc.) Etcétera Agilidad, disciplina o caos
18 Lo que significa …. Pérdida de dinero (sobre costos, necesidaddel producto, etc.) Cuestionamiento al grupo de ingeniería (interno o externo) Abordar el problema incorrecto Hoy en día no triunfan las empresas mas poderosas económicamente, lo hacen las más rápidas y más innovadoras Agilidad, disciplina o caos
19 Y todos …. Agilidad, disciplina o caos
20 Por qué se persiste en un modelo que no funciona?“Para cada problema complejo, existe una solución simple, ordenada e incorrecta” (Mencken). Ejemplos: La tierra es plana, todo gira alrededor de la tierra, la creación del hombre, etc. El desarrollo es cascada, que se le atribuye a Royce [1970], tuvo una gran influencia, sobre todo a partir de las necesidades de la ingeniería de sistemas, no la ingeniería de software (Royce realmente pregonó el desarrollo iterativo) El desarrollo en cascada es fácil de explicar. El iterativo e incremental es mas complejo Puede dar la ilusión , en algunas personas, de un proceso ordenado, predecible y medible Agilidad, disciplina o caos
21 Por qué se persiste en un modelo que no funciona?Porque no se quiere hacer el esfuerzo para buscar otras formas de hacerlo Por presión de compradores, la cual a su vez proviene de los CEO, CIO, etc. “Cuánto se demora”, “Cuánto vale”, etc. Por la legislación de compras de los gobiernos Porque la Ingeniería de Software no es fácil, aunque no es para seres especiales Agilidad, disciplina o caos
22 Todas las aproximaciones Ágiles La respuesta a los problemas de la aproximación en cascada y basadas en documentos son las aproximaciones denominadas Ágiles Todas las aproximaciones Ágiles son un subconjunto de las aproximaciones Iterativas Agilidad, disciplina o caos
23 Las aproximaciones iterativas mas conocidas son …XP (eXtreme Programming) Scrum UP (o su versión RUP) ASD (Adaptive Software Development) Crystal Evo (como referencia) Agilidad, disciplina o caos
24 El desarrollo Iterativo es …Una aproximación para construir software (o cualquier cosa), en la cual el ciclo de vida se descompone en varias iteraciones en secuencia. Cada iteración es un mini – proyecto autocontenido Agilidad, disciplina o caos
25 El objetivo de cada iteración consiste en …Liberar un sistema parcialmente completo, probado, integrado y estable. Algunas iteraciones son internas, otras se liberan a operaciones. Agilidad, disciplina o caos
26 Las nuevas aproximaciones están basadas en ideas ya viejasIID no es nuevo … Los japoneses utilizaron IID para el desarrollo de nuevos productos en electrónica de consumo, vehículos, etc. IBM publicó en 1972 documentos que contenían esta aproximación EVO (Evolutionary Project Management) data de los años 60. Alexander Proudfoot aplicó a fines de los 40, lo que el denominó el SIS (Short Interval Scheduling) en una compañía de correo masivo en Chicago Las nuevas aproximaciones están basadas en ideas ya viejas Agilidad, disciplina o caos
27 Iterativo e Incremental significa …Feedback Feedback Iteración 1 Iteración 2 Iteración 3 Release 1 Feedback Feedback Iteración 4 Iteración 5 Iteración 6 Release 2 La longitud de cada iteración es de 1 a 6 semanas como máximo Agilidad, disciplina o caos
28 La planeación de iteraciones contiene elementos diferentes a la aproximación tradicional …Planeación basada en el riesgo o en el cliente El tiempo de cada iteración es fijo, pase lo que pase (timeboxing) No se aceptan cambios de interesados externos No se hacen cronogramas en su forma tradicional Se trabaja en varias disciplinas simultáneamente aunque el énfasis cambia (requerimientos, análisis, diseño, codificación, testing, etc.) Agilidad, disciplina o caos
29 El cono de incertidumbre se va estrechando a medida que avanza el proyectoEstimados y cronogramas prematuramente definidos 4X X Período realista para estimados 0.1 X I 1 I 2 Agilidad, disciplina o caos
30 Enfatiza mas sobre las posturas a la izquierda de sobreAunque el IID es la base, las aproximaciones ágiles adoptan otra serie de paradigmas … Manifiesto Ágil Individuos y sus interacciones sobre procesos y herramientas Software sobre documentación comprensiva Colaboración del cliente sobre contratos Respuesta a los cambios sobre el seguimiento de un plan Enfatiza mas sobre las posturas a la izquierda de sobre Agilidad, disciplina o caos
31 Y aproximaciones metodológicas diferentes …..XP (eXtreme Programming) Conocimiento tácito basado en interacción muy fuerte del grupo Poca o ninguna documentación Customer On site Desarrolladores y clientes trabajan en el mismo sitio Pair Programming Si la revisión de código es buena la llevamos al extremo Test first programming Si el testing es bueno lo llevamos al extremo Diseño simple Diseñe para la batalla no para la guerra (YAGNI) Refactoring Cuando encuentre algo que sea necesario cambiar, cámbielo Agilidad, disciplina o caos
32 Y aproximaciones metodológicas diferentes …..XP (eXtreme Programming) Propiedad colectiva del código Cualquiera puede cambiarlo Grupo auto controlado Los procesos no están definidos Planeación de release e Iteración basado en la selección del cliente Paradójicamente, XP y SCRUM son quizá las aproximaciones mas disciplinadas que existen, y requieren de mucho talento en los integrantes del grupo. Se resquebrajan fácilmente sin disciplina y talento ... Agilidad, disciplina o caos
33 … y pueden presentar problemas seriosEl conocimiento tácito promueve la agilidad, pero presenta serios problemas de escalamiento cuando el grupo crece o no tiene el talento Se requieren personas muy talentosas El diseño simple (YAGNI) puede llegar a ser muy riesgoso y costoso, en proyectos de alguna importancia donde pueda preverse el cambio. El Peer Review ha mostrado mejores resultados que el Pair Programming La carencia de procesos definidos puede llevar al caos. Es muy disciplinado y controlado el desarrollo (“Chaordic”). Agilidad, disciplina o caos
34 … y puede presentar problemas seriosEs útil en grupos pequeños, requerimientos cambiantes o desconocidos Vamos a cambiar otra vez el plan? “Yo no le puedo dar mantenimiento a eso, no existe documentación de ninguna naturaleza” Agilidad, disciplina o caos
35 Balance entre adaptación y optimización (*)Alto Habilidades, conocimiento Bajo Liviana Procesos, documentación Pesada (*) Tomado de Cockburn y Highsmith Agilidad, disciplina o caos
36 La solución ha consistido en introducir elementos basados en el planMejor definición de milestones para evitar “acabar sin acabar” Planes que abarquen la definición y prueba de arquitectura Mejor elicitación de requerimientos, cuando es posible Utilización de patrones de diseño y soluciones de arquitectura en lugar de YAGNI Procesos definidos pero no mecánicos. Métodos formales de monitoreo (CEP) Crystal y RUP son buenos ejemplos de aproximaciones mixtas Agilidad, disciplina o caos
37 Seleccione su aproximación basado en el riesgoNo se vuelva un defensor a ultranza de una u otra aproximación. Al fin y al cabo usted lo que requiere es: Producir software de buena calidad, que cumpla los requerimientos de su cliente Estar en capacidad de mantenerlo y evolucionarlo No ser persona dependiente No insista en lo que no funciona, eso solo lo conducirá al caos Agilidad, disciplina o caos
38 1 2 3 Agenda Preguntas y respuestasPlantear algunos de los problemas que se presentan en el desarrollo de software. Introducir los conceptos de disciplina y agilidad 1 2 Reflexionar sobre algunas de las soluciones que a estos problemas plantean los métodos denominados ágiles y las aproximaciones más formales al desarrollo de software 3 Preguntas y respuestas Agilidad, disciplina o caos
39 En Dios confiamos, todos los demás traigan datosDeming, a propósito del CEP Indeed, not only is software worker demand desperate in the US, but also all over the world. It is believed that the global market suffers from a one-million, five-hundred thousand tech-worker shortage. Worst of all, many analysts believe such a shortage is threatening the growth of the economy in most developed countries Here are some more quotes to prove my point: Agilidad, disciplina o caos