INSTITUTO POLITÉCNICO NACIONAL
UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERÍA Y CIENCIAS SOCIALES Y ADMINISTRATIVAS
UNIDAD DE APRENDIZAJE: Metodología de la Investigación Interdisciplinaria SECUENCIA: 4NM71 PROFESOR(A): Lic. Miguel Ángel Rojas López Portillo NOMBRE DEL TRABAJO DE INVESTIGACIÓN: PANORAMA SOBRE METODOLOGÍAS DE DESARROLLO DE SOFTWARE ÁGILES INTEGRANTES DEL EQUIPO: Bedolla Perez Felix Sahed Espinoza Trujano Luis Enrique Martínez Márquez Oscar Fernando Moncada Jasso Iram Padilla Santana Carlo Gilmar
ÍNDICE INTRODUCCIÓN INTRODUCCIÓN ............... ............................... ................................. .................................. ................................. ................................. .............................. ............. 8 CAPÍTULO I MARCO METODOLÓGICO ........................................................................... 9 1.1 PLANTEAMIENTO DEL PROBLEMA ............................................................... 9 1.2 OBJETIVOS OBJETIVOS.......................................... .......................................................... ................................. ................................. ......................... ......... 10 1.3 TÉCNICAS E INSTRUMENTOS DE MEDICIÓN ............................................ 11 1.4 UNIVERSO Y MUESTRA ............................................................................... 11 1.5 JUSTIFICACIÓ JUSTIFICACIÓN N ................ ................................. ................................. ................................ ................................. ............................ ........... 11 1.6 HIPÓTESIS..... HIPÓTESIS..................... ................................. ................................. ................................. ................................. .............................. .............. 12 CAPÍTULO II MARCO TEÓRICO ..................................................................................... 13 2.1 UN RECORRIDO SOBRE EL CONTEXTO HISTÓRICO ......... ................... ................... ............. .... 13 2.2 MANIFIESTO PARA EL DESARROLLO ÁGIL DE SOFTWARE ......... ................... .............. 16 2.3 LOS PRINCIPIOS ÁGILES ............................................................................. 17 2.4 EL PARADIGMA ÁGIL .................................................................................... 19 CAPÍTULO III. METODOLOGÍA SCRUM ......................................................................... 22 3.1 CONCEPTO CONCEPTO ................. ................................. ................................ ................................. ................................. ................................. .................22 3.2 REGLAS REGLAS ................ ................................. .................................. ................................. ................................. .................................. ...................... ..... 23 3.3 ROLES ................ ................................. ................................. ................................. ................................. ................................. ......................... ........24 3.4 ARTEFACTOS ARTEFACTOS......................................... ......................................................... ................................. ................................. ...................... ...... 27 3.5 EVENTOS O ACTIVIDADES .......................................................................... 31 3.6 FUNCIONAMI FUNCIONAMIENTO ENTO ............... ................................ ................................. ................................. .................................. ...................... ..... 33 3.7 TIPOS DE PROYECTO Y ORGANIZACIONES DONDE SE USA ................. ........ ........... 34 3.8 CERTIFICACION CERTIFICACIONES ES ............... ................................ ................................. ................................. .................................. ...................... ..... 36 3.9 BENEFICIOS Y DESVENTAJAS .................................................................... 38 CAPÍTULO IV. METODOLOGÍAS CRYSTAL ................................................................... 39 4.1 CONCEPTO CONCEPTO ................. ................................. ................................ ................................. ................................. ................................. .................39 4.2 ROLES DE LOS PARTICIPANTES ................................................................ 40 4.3 MATERIALES Y MÉTODOS ........................................................................... 41 4.4 FUNCIONAMI FUNCIONAMIENTO ENTO ............... ................................ ................................. ................................. .................................. ...................... ..... 41 4.5 APLICABILIDAD A PROYECTOS ................................................................... 42 4.6 CERTIFICACION CERTIFICACIONES ES ............... ................................ ................................. ................................. .................................. ...................... ..... 42 4.7 PRINCIPALES VENTAJAS Y DESVENTAJAS ......... .................. ................... ................... .................. ........... 42 4.8 CONCLUSIÓN DE LA METODOLOGÍA ......................................................... 43 CAPÍTULO V EXTREME PROGRAMMING ..................................................................... 43 5.1 CONCEPTO CONCEPTO ................. ................................. ................................ ................................. ................................. ................................. .................43 2
5.2 REGLAS REGLAS ................ ................................. .................................. ................................. ................................. .................................. ...................... ..... 43 5.2.1 REGLAS DE PLANIFICACIÓN ......... ................... ................... .................. ................... ................... ........... 44 5.2.2 REGLAS PARA EL DISEÑO ............................................................ 44 5.2.3 REGLAS PARA EL DESARROLLO.......... ................... ................... ................... ................... .............. 45 5.2.4 REGLAS PARA LAS PRUEBAS ...................................................... 45 5.3 VALORES DE LA PROGRAMACIÓN EXTREMA ......... ................... ................... .................. ............... ...... 45 5.4 PRÁCTICAS DE LA PROGRAMACIÓN EXTREMA ......... ................... ................... ................... .............. 45 5.5 ROLES DE LA PROGRAMACIÓN EXTREMA .......... ................... ................... ................... .................. ........... 48 5.6 ARTEFACTOS ARTEFACTOS......................................... ......................................................... ................................. ................................. ...................... ...... 50 5.7 FUNCIONAMI FUNCIONAMIENTO ENTO ............... ................................ ................................. ................................. .................................. ...................... ..... 50 5.8 TIPOS DE PROYECTO Y ORGANIZACIONES DONDE SE USA ................. ........ ........... 52 5.9 CERTIFICACION CERTIFICACIONES ES ............... ................................ ................................. ................................. .................................. ...................... ..... 53 CAPÍTULO VI. KANBAN .................................................................................................. 54 6.1 CONCEPTO CONCEPTO ................. ................................. ................................ ................................. ................................. ................................. .................54 6.2 FUNCIONES FUNCIONES............................................ ............................................................ ................................. ................................. ...................... ...... 55 6.3 CERTIFICACION CERTIFICACIONES ES ............... ................................ ................................. ................................. .................................. ...................... ..... 57 CONCLUSIONES CONCLUSIONES............... ............................... ................................. .................................. ................................. ................................. ............................ ........... 57 GLOSARIO GLOSARIO ................ ................................. ................................. ................................. ................................. ................................. ................................. ................... ... 60 FUENTES DE CONSULTA .............................................................................................. 63
3
ÍNDICE DESCRIPTIVO Capítulo I Marco Metodológi co
Presentamos los principales objetivos de nuestra investigación, así como aquello que nos motiva a realizar esta investigación. Capítulo II Marco Teórico
Las metodologías ágiles de desarrollo de software son un conjunto de marcos de trabajo que empezaron a popularizarse en la década de los 90’S, a inicios del siglo
XXI se escribió el manifiesto ágil que contiene los principales valores y prácticas ágiles como alternativa a las metodologías tradicionales. Capítulo III Metodología Scrum
Scrum se ha posicionado como una de las metodologías ágiles de desarrollo de software más populares en los últimos años, ya sea por su nivel de eficiencia, versatilidad y adaptabilidad. En este capítulo se describirán sus principios, ideología y funcionamiento los cuales nos brindaran un mejor entendimiento de cómo este popular marco de trabajo expone la doctrina “Agile”. Capítulo IV Metodologías Crystal
Crystal es una familia de metodologías de desarrollo ágil que consta de muchas variedades, las cuales dependen de varios factores como el tamaño del proyecto, su complejidad, tolerancia a fallos, etc. En este capítulo nos enfocamos en su derivado Clear para describir el funcionamiento de las demás. Capítulo V Extreme Programmi ng
Extreme Programming (Programación Extrema) es una disciplina de desarrollo del software centrada en desarrollar las relaciones interpersonales a través de valores, los cuales van de la mano de ciertas reglas estructuradas de metodologías previamente definidas para alcanzar una meta en común el cual es reducir el costo de cambio en los proyectos. Capítulo VI Kanban
4
Kanban es un método para la mejora de procesos industriales. No fue sino hasta que, a David Anderson, en 2010, se le ocurrió mejorar los procesos de construcción de software. Este capítulo explica cómo se aplica al desarrollo de software.
5
RESUMEN Capítulo III. SCRUM
Una de las metodologías ágiles para el desarrollo de software más populares es SCRUM, debido a que es muy organizada y muy aplicable en las organizaciones que necesitan llevar un mejor control sobre su programación de tiempos de entrega y la calidad con la que los productos son llevados a los interesados en los proyectos. En este capítulo encontraremos mucha terminología especializada que se detallará en el mismo. Mucha de la cual se refiere a los roles de los participantes del proyecto; a los periodos de entrega de resultados; lo que se piensa hacer para la siguiente entrega; los interesados en el desarrollo de la aplicación; al progreso con el que se cuenta hasta el momento, entre muchos otros. A pesar de contar con mucha terminología (lo cual puede parecer desalentador), animamos al lector a que la conozca pues existen varias certificaciones que mejorarán su desarrollo profesional. Capítulo IV. Crystal Clear
Al referirnos a metodologías de desarrollo Crystal, tenemos que hablar de una serie de herramientas de desarrollo que se adaptan de acuerdo al tamaño del equipo. Por motivos de extensión, hemos decidido limitarnos a hablar de aquella variedad de Crystal que engloba a los equipos de pocas personas: Crystal Clear, no obstante, muchas de las características aplican para todas las demás. A diferencia de SCRUM, se centra más en el desarrollo y tiene menos énfasis en la asignación de roles. Capítulo V. Extr eme Prog rammin g
En este capítulo se explicarán las características y principios fundamentales que basan a una de las metodologías menos complejas en cuanto a tamaños de equipo y estructura organizacional. Esto se debe a que su paradigma es centrado 6
en las personas, no en el desarrollo o en el proyecto en sí mismo; pero todo esto lo describiremos mejor en el capítulo. Capítulo VI. Kanban
Kanban surgió como una herramienta para mejorar los procesos industriales en tiempos donde era vasta la demanda de productos terminados. Cuando el auge del desarrollo de las aplicaciones tuvo su apogeo, también se generó la necesidad de obtener una mejora de los procesos de desarrollo de aplicaciones en varias de las metodologías existentes. Fue entonces cuando a alguien se le ocurrió adaptar la metodología Kanban de procesos industriales, a la informática. Durante el transcurso del capítulo mencionaremos a quién se le atribuye este hecho y por qué se diferencia tanto de las metodologías anteriormente anteriormente descritas.
7
INTRODUCCIÓN “Una computadora es para mí la herramienta más sorprendente que hayamos ideado. Es el equivalente a una bicicleta para nuestras mentes” -Steve mentes” -Steve Jobs
El término metodología según la Real Academia Española es un es un vocablo generado a partir de tres palabras de origen griego: metà (“más allá”), odòs (“camino”) y logos (“estudio”). La comprensión por extensión nos induce a aceptar que la metodología es una serie de procedimientos para alcanzar un fin específico. En el presente documento indagaremos en cada una de las metodologías ágiles de desarrollo de sistemas, empezando en el capítulo II, estableceremos el contexto histórico que influyó en el origen de las metodologías ágiles, después, presentamos los 12 principios del manifiesto ágil, que es un documento escrito por un grupo de desarrolladores y cuyo objetivo es presentar los valores principales para el proceso de creación de software. A través de investigación bibliográfica de fuentes confiables, presentamos al lector un breve, pero conciso contexto de las metodologías ágiles (Scrum, Crystal, Extreme Programming y Kanban) en el desarrollo del software actual (al momento de la revisión: mayo del 2016). De cada una de estas metodologías presentaremos los siguientes puntos: ● Concepto. ● Reglas. ● Roles. ● Artefactos. ● Eventos o Actividades. ● Funcionamiento. ● Tipos de proyecto y organizaciones donde se usan. ● Certificaciones. ● Ventajas y desventajas.
8
CAPÍTULO I MARCO METODOLÓGICO 1.1 PLANTEAMIENTO DEL PROBLEMA Los profesionales que en la actualidad se dedican a la industria de las Tecnologías de la Información deben tomar en cuenta la necesidad de estar apegados a las tendencias actuales orientadas por las tecnologías y prácticas demandadas por la industria en general. El portal DataCenter señala que un profesional que “tiene
competencias como las que se demandan su valor en el mercado sube un 10% o más según el Índice de Remuneración de Habilidades de TI y Certificaciones del Foote Partners LLC” (Search Data Center, 2016).
Y aunque lo importante y esencial debería ser la excelencia en el conocimiento técnico para la creación de software, se requiere que un profesional cultive otro tipo de habilidades que permitan potencializar la colaboración en equipo y agregue a su vez valor al negocio. negocio. Jeffrey Hammond, Hammond, vicepresidente vicepresidente y analista analista para el el desarrollo de aplicaciones aplicaciones de Forrested Research Inc. apunta: "los empresarios de hoy en día –la mayoría de los cuales no son negocios de software tradicionales – quieren ese algo extra de los desarrolladores que aporte valor a la organización" (Search Data Center, 2016). Es necesario transformar un negocio que se valga de proyectos de TI de manera organizacional de la mano de un nuevo paradigma. José Luis Noriega, director comercial de BBVA señala: “hay que dejar que se asiente un nuevo sistema IT,
formar a los equipos y obtener rendimiento de la inversión. Lo disruptivo hoy es conseguir transformar una compañía, de arriba abajo, en una máquina de gestionar las continuas alteraciones que ocurren en el contexto de negocio, no en el de IT, y de actuar ante ellas con agilidad, de mano del nuevo paradigma de las Metodologías Ágiles” (Centro de Innovación BBVA, 2016). Y este paradigma ha
ido subiendo posiciones entre las tendencias de gestión de proyectos. Por lo tanto ante la necesidad de un profesional por actualizarse en las tendencias y conocimientos actuales, por adquirir capacidades que aporten valor a la organización, y ante el surgimiento de este nuevo paradigma en la industria de las 9
Tecnologías de la Información, es conveniente comprender el surgimiento y desarrollo de las Metodologías Ágiles, así como entender las bases de las prácticas más importantes como lo son Scrum, Extreme Programming, Crystal, y Kanban, según el portal Search Data Center. 1.2 OBJETIVOS Objetivo general Conocer con fines exploratorios las principales metodologías (según José Canós en su artículo Metodologías Ágiles en el Desarrollo de Software 2003) ágiles de desarrollo de software, sus beneficios, desventajas, así como conocer el por qué fueron diseñadas. Objetivos específicos 1. Conocer qué significa el término “metodologías ágiles de desarrollo de software”, según la Real Academia Española.
2. Explicar qué es el manifiesto ágil y los principios que estipula para trabajar con las metodologías ágiles. 3. Describir algunas metodologías ágiles populares (según Patricio Letelier en su artículo su artículo Metodologías Ágiles en el Desarrollo de Software 2003), mencionando sus características y métodos con los que operan. 4. Describir las ventajas y desventajas que conlleva la utilización de cada una de ellas. 5. Lograr que el lector sepa elegir entre la metodología más conveniente para desarrollar un determinado proyecto, según los instrumentos y artefactos con los que cuenta actualmente, así como los requerimientos (como lo expone Daniel Jiménez en su artículo Test de metodologías ágiles, ¿Qué metodología es mejor: Scrum, Kanban o Scrumban? encontrado en el portal http://www.genbetadev.com) 6. Hacer una comparación con la forma tradicional de desarrollo de software con estas metodologías (Justo como lo hace Elena Gordillo Polo Consultora de TI en su blog https://inventtatte.com/metodologia-tradicional-vs-agil/) 7. Explorar el contexto histórico en el que surgieron las metodologías ágiles.
10
1.3 TÉCNICAS E INSTRUMENTOS DE MEDICIÓN La presente investigación no usará técnicas e instrumentos de medición debido a que pretendemos indagar a nivel documental. 1.4 UNIVERSO Y MUESTRA Debido a que nuestra investigación se enfoca a una búsqueda documental, no tendremos universo y muestra. 1.5 JUSTIFICACIÓN Las metodologías ágiles de desarrollo de software como Scrum, Kanban, Extreme Programming y Crystal, según el portal Search Data Center, han impactado en la manera en que se construyen los sistemas de información en los últimos años. Inclusive en la Encuesta de Salarios más actual del portal Gurú Software del 2015 la certificación de Scrum Master se ponderó como una de las mejores pagadas por encima de certificaciones como la de Seguridad, SAP, Java, UML, Linux, Android, entre otras. Así mismo enfocaremos nuestra investigación no sólo a los aspectos técnicos de cada metodología, también pretende describir los valores esenciales, mismos que aportan el valor organizacional, que según Jeffrey Hammon, necesitan las empresas. Aunado a esto el portal Search Data Center señala que un profesional con nociones sobre las tendencias actuales tiene una mejor remuneración económica. Nuestra indagación acercará los contenidos investigados a nuestros compañeros de clase, promoviendo una nueva visión en la creación y gestión de proyectos, así se divulgarán los nuevos marcos de trabajo motivando a nuestra comunidad a ahondar más en estos temas. Hemos optado por descubrir la esencia de las metodologías ágiles debido a la importancia que representa dentro de nuestra formación profesional, así como representa iniciar por vez primera una investigación científica formal.
11
El alcance de nuestra investigación se limita a fines exploratorios. Pretende ser una guía introductoria a las metodologías ágiles para los compañeros de nuestra carrera. 1.6 HIPÓTESIS Esta investigación no tendrá hipótesis debido a su enfoque documental, pero se plantean las siguientes preguntas de investigación a modo de guía conceptual para este proyecto de investigación: ● ¿Cuál es la importancia de las metodologías ágiles de desarrollo de
software? ● ¿Qué metodologías son las más utilizadas en las empresas de desarrollo
de software más grandes del mundo (como Facebook o twitter)? ● ¿Cómo funcionan las metodologías ágiles de desarrollo de software (scrum,
xp, crystal y kanban)? ● ¿Qué ventajas y desventajas existen al usar las metodologías ágiles de
desarrollo de software? ● ¿Qué roles existen en cada una de las metodologías ágiles desarrollo de
software (scrum, xp, crystal y kanban) y cuál es su función? ● ¿Qué certificaciones se ofrecen en el mercado para las metodologías ágiles
de desarrollo de software? ● ¿Qué artefactos utiliza cada metodología ágil de desarrollo (scrum, xp,
crystal y kanban) y como se usan en el proceso de creación de software? ● ¿En qué se basa la ideología ágil de desarrollo de software? ● ¿Qué beneficios nos ofrecen las metodologías ágiles con respecto a las
metodologías tradicionales de desarrollo de software? ● ¿En qué tipo de proyectos se pueden utilizar las metodologías ágiles de
desarrollo (scrum, xp, crystal y kanban)?
12
CAPÍTULO II MARCO TEÓRICO 2.1 UN RECORRIDO SOBRE EL CONTEXTO HISTÓRICO Es importante realizar un seguimiento sobre los hechos ocurridos anteriores a algún tema, recurrir al análisis histórico permite visualizar el presente como una sucesión de hechos encadenados iniciados en el tiempo pasado, y a través de ellos podemos establecer relaciones causales que permitan inferir la importancia que tienen para el presente. Es pertinente rescatar aquellos sucesos de mayor relevancia tanto en los hechos pasados que dieron pie a las Metodologías Ágiles, como un contexto histórico del devenir mundial y de la producción de tecnología de software. A continuación, realizaré una línea de tiempo, primero voy a resaltar los aspectos que considero como antecedentes directos del desarrollo de las Metodologías Ágiles: ● En 1939 Walter Shewhart populariza el uso de los ciclos cortos de
planificación en proyectos. ● En 1948 Taiichi Ohno implementó por vez primera el uso de “Kanban” en
los sistemas de fabricación de Toyota. ● En 1950 Se desarrolla el Jet hipersónico X-15 mediante un ciclo de
desarrollo iterativo. ● En 1951 William Deming propuso el primer método incremental IIDD “Iterative and Incremental Design and Development”. ● En 1969 se crea el PMI (Project Manager Institute). ● En 1970 se define por vez primera el “modelo en cascada”. ● En 1975 Bill Gates fundó Microsoft. ● En 1976 Steve Jobs fundó Apple. ● En 1978 Ohno publicó el libro “ The Toyota Production System” . ● En 1985 Tom Gilb publicó “Evolutionary Delivery versus the Waterfall Model”.
● En 1988 se populariza el término de “ Lean Manufacturing” . 13
● En 1995 nace el marco de trabajo “Scrum” como model o para desarrollo de software, Jim Coplien y L. Constantine crean la forma “Pair Programming”. ● En 1996 Kent Beck desarrolló el modelo “Extreme Programming”. ● En 1997 Jeff de Luca inventó el “Feature Driven Development” ● En 1998 T. Cockburn creó las metodologías “crystal”. ● En el 2001 se adoptó el
nombre de “metodologías ágiles” y se creó el
“manifiesto ágil”. ● En el 2002 Kent Beck desarrolló el “Test Driven Development”, mientras J. Grenning creó el “Planning Poker”, y se fundó la “Scrum Alliance”.
Aunque la primera fecha está en los inicios del siglo XX, la actividad se intensifica más en los años 70’S y 90’S.
¿Pero qué ocurría en ese periodo de tiempo? A continuación, menciono hechos importantes, así como detalles culturales en el acontecer mundial en el siglo XX: ● 1911 F. Taylor publicó “The Principles of Scientific Management” . ● 1914 Primera Guerra Mundial ● 1914 Revolución Bolchevique en Rusia. EU era el primer país industrial del
mundo pues tenía empresas que se dedicaban a la siderurgia, petróleo y combustibles, así como automóviles, y empezó a recibir personas que emigraban. ● 1929 Caída de la bolsa de valores en EU, y puesta en marcha del “New Deal”, el mercado internacional cae por las medidas adoptadas. ● 1931 se empezó a producir el automóvil modelo T de Henry Ford. ● 1939 Segunda Guerra Mundial ● 1945 EU se convirtió en el principal productor de alimentos, automóviles,
electrodomésticos, centros comerciales, entre muchos otros; pronto impulsó los derechos civiles, la exploración espacial, educación y asistencia médica. Existieron cambios importantes como que los países occidentales adoptaron políticas de crecimiento económico, modernización y pleno empleo a través del intervencionismo estatal. ● 1947 entró el “Plan Marshall” para reconstruir Europa. Inic ia la Guerra Fría
entre EEUU y la URSS.
14
● 1950 creación de la CECA, rumbo a la Unión Europea. En Europa crecía la
demanda de automóviles, en Francia se inaugura el primer tren años más tarde. ● 1956 Ludwing Von Bertalanffy publicó la Teoría General de los Sistemas. ● 1960 surgía la corriente
existencialista en obras de Sartre, Camus,
Beauvoir, el “teatro absurdo”: era una visión del mundo que implicaba una
idea negativa de la condición humana que señalaba que el hombre aparecía forzado a vivir en un mundo carente de valores y sentido. El existencialismo inglés se ocupó de cuestiones del lenguaje, lógica,
método,
relación
entre
significado
y
proposición
filosófica. Literatura como “Camino de Servidumbre” de Hayek, “La sociedad abierta y sus enemigos” de Popper, “Los Orígenes del totalitarismo” de Arendt, proponían ideas sobre articular una sociedad justa:
la idea del individuo como sujeto de la política y de la historia, pluralismo político, etc. Francis Bacon pintó figuras distorsionadas, claustrofóbicas, como expresión de soledad
y el desamparo del hombre.
● 1964 juegos olímpicos en Japón, marcaba el inicio de la potencia mundial,
ya se gestaban industrias como Toyota, Honda, Sony, Panasonic, Nissan, Nintendo. ● 1966 revolución cultural en China. ● 1969 llegada del hombre a la Luna. En Europa, después que, en EU, se
popularizaron los
ordenadores, computadores personales, instrumentos
de aplicación,
satélites. Para el inicio de la siguiente década Europa
ya era una
sociedad construida bajo los estándares de EU, pero con altos
niveles de desarrollo, bienestar social, desarrollo y empleo. ● Años 80’S EU figuraba a la cabeza de la revolución tecnológica asociada a
los ordenadores y la tecnología digital, así como sus universidades eran las más
prestigiosas como centros de investigación.
● 1990 Reunificación de Alemania, caída del Muro de Berlín. ● 1991 disolución de la URSS. ● 1996 B. Clinton como presidente de EU, el país ya gozaba de una
hegemonía mundial, bienestar económico, hipermodernidad, la cultura era uno de los núcleos del siglo XX, además de ser un enorme mercado de innovación tecnológica y de consumo de masas. 15
● 2001 caída de las torres gemelas. ● 2008 crisis económica internacional.
A grandes rasgos es posible ir equiparando las dos líneas del tiempo antes mencionadas, por lo que podemos ver que las Metodología Ágiles empezaron a surgir en los años 90'S, justo en un momento del escenario mundial donde el capitalismo ganaba terreno de la mano de EU tras la caída de la URSS y el aumento de su hegemonía, pero también en un momento en que podría parecer que
las
ideas
del
existencialismo
filosófico
maduraban
después
de
aproximadamente 30 años, impactando en el nuevo terreno fértil en el que comenzaba a desarrollarse la tecnología emergente a través de organizaciones líderes como Microsoft o Apple; ya para inicio del siglo XXI el manifiesto ágil describe una serie de principios para desarrollar software que poco tenían que ver con cuestiones técnicas, pues se enfocan más en valores humanos y prácticos. 2.2 MANIFIESTO PARA EL DESARROLLO ÁGIL DE SOFTWARE Apenas en el 2001 un grupo de desarrolladores y autores, escribieron un documento llamado “Manifiesto para el desarrollo ágil de software” con el objetivo
de brindar un contexto sobre los valores principales que aportan más beneficios al proceso donde se crea software, mejor conocido como “el manifiesto ágil”. Como
bien es señalado por Stellman & Greene “ Agile is also a mindset, because the right mindset can make a big difference in how effectively a team uses the practices.”
(Stellman & Greene, 2015:22) Este documento expresa las ideas que conviene preferir para un desarrollo ágil, como valorar más a los individuos y sus interacciones, sobre los procesos y herramientas; valorar más software funcionando qué documentación extensa, valorar más la colaboración con el cliente que una negociación sobre el contrato, y valorar más el responder al cambio, que seguir un plan predefinido. No quiere decir que las segundas opciones no sean importantes, lo son, pero se prefiere la primera alternativa. Uno de los clichés más comunes que se tiene es creer que el manifiesto está contra los procesos, herramientas, documentación, negociación de contrato y la 16
planeación; sin embargo, esto es una idea falsa. El manifiesto indica que estas ideas aportan menor valor al proceso de desarrollo que las que presenta como ideas prioritarias. Se intenta provocar una catarsis donde las organizaciones puedan identificarse con una u otra idea, al ver las que promociona el movimiento ágil como indispensables para que un proyecto adquiera valor. Aunque “there’s no single recipe that results in perfect software every time. Agile teams recognize this. Instead, they have ideas and ground rules that help to guide teams to make the right choices and avoid problems—or deal with those problems when they inevitably happen.” (Ibíd, 52)
2.3 LOS PRINCIPIOS ÁGILES El manifiesto ágil define 12 principios ágiles que se deben llevar a cabo en un proceso ágil. 1.- La principal prioridad es la satisfacción del cliente bajo una entrega temprana de valor en el software. Este principio es normalmente ignorado en las demás
formas de llevar a cabo procesos de creación de software. Es importante recordar que el cliente quiere valor a su organización, no una documentación técnica o ideas poco digeridas, mientras más temprano se inicie a desarrollar más pronto se podrán satisfacer las necesidades del cliente. Se menciona que “This first principle includes three distinct and important ideas: releasing software early, delivering value continuously, and satisfying the customer.” (Ibíd., 55)
2.- Bienvenidos los cambios en los requerimientos, incluso cuando ya se esté en la fase de desarrollo. Los procesos ágiles se acoplan a la dinámica de los
requerimientos, y se debe tener en cuenta que estos son muy variables al inicio, durante y al final del proyecto. Los clientes están compitiendo en un mercado dinámico, por lo tanto, deben adaptarse rápidamente ante estos cambios, aunque no quiere decir que todos los cambios son gratuitos o no conllevan esfuerzo. 3.- Liberar software funcionando en un periodo de 2 semanas hasta dos meses, prefiriendo el menor tiempo posible. Esto permite una entrega al cliente en una
etapa temprana en la que podrá probar el software y brindar una retroalimentación 17
temprana al equipo de desarrollo para indicarle si está entregando valor, o si debe cambiar la estrategia que estaba siguiendo. 4.- Las personas del negocio y los desarrolladores deben colaborar juntos para obtener un buen proyecto. Se entiende por “las personas del negocio” a aquellos
otros colaboradores importantes dentro de la organización, además del cliente directo, que pueden brindar información que aporte valor al proyecto. 5.- Construir proyectos con personas motivadas. Este principio enfatiza la
necesidad de un ambiente propicio para hacer un buen trabajo profesional, las personas no son recursos, y el desarrollo de software no es manufactura industrial. Los equipos de trabajo necesitan ser motivados, y confiar en ellos. 6.- La comunicación más eficiente es la conversación cara a cara. Aquí se enfatiza
la importancia de la comunicación entre todos los implicados del proyecto, debido a que esto no se ha tomado en cuenta, y ante los avances tecnológicos muchas veces se prefiere, por ejemplo, enviar correos electrónicos, o bien mensajes de texto creando una brecha comunicacional, que en la práctica lleva a malos entendidos y confusiones. 7.- Software funcionando es la principal medida de progreso. El cliente es la
primera persona interesada en que el software como producto final esté funcionando y aportando valor, por ello es importante que sea la medida de progreso del proyecto. Muchas veces, en proyectos no ágiles, se confía el progreso en el cumplimiento de un diagrama de Gantt, o un cronograma, es decir de documentos propios de una planeación temprana, sin embargo, la dinámica de los requerimientos hace que estas técnicas, cuyo campo es la manufactura, proporcionen datos equivocados. Es posible llevar la mitad de eventos de un cronograma, y decir que se lleva 50% de avance, pero el software realmente no funciona ni aporta valor a la organización. 8.- Un proceso ágil promueve un desarrollo sustentable. Los implicados del
proyecto deben ser capaces de encontrar un equilibrio colaborativo, equipos auto organizados, y colaborativos. 18
9.- La agilidad es promovida por la excelencia técnica y buenos diseños. La
excelencia técnica es necesaria para establecer un verdadero proceso ágil de creación de software. 10.- La simplicidad es esencial, el arte de maximizar el trabajo no hecho. No
programar no significa que el proyecto carezca de errores, si algo no es esencial en el producto no se hace, esto debido a que muchos equipos de desarrollo tienden a dilatar los requerimientos, así como aumentar el trabajo y esfuerzo para algo que al final no entregará valor a la organización. 11.- Las mejores arquitecturas, toma de requerimientos y diseños emergen de grupos auto organizados. En las metodologías no ágiles el analista escribe los
requerimientos, los arquitectos realizan la arquitectura del sistema, ambos comunicados al equipo de desarrollo por medio de documentos y minutas, por lo general esta brecha de comunicación termina generando confusiones. 12.- En intervalos regulares de tiempo un equipo refleja cómo es más efectivo.
Este es quizá el principio más importante sobre la agilidad, esta idea de reflejar el grado de colaboración y esfuerzo en un periodo corto de tiempo permite tomar consciencia de aquello que están haciendo bien, y aquello que están haciendo mal para mejorarlo. En general cualquier desarrollo ágil debe cumplir con estos principios, así como las técnicas que se usan y herramientas están enfocadas hacia ellos, “Agile is unique in the history of software engineering. It’s unlike the waves of “silver bullet” methodologies over the years, which promised to solve your team’s software problems through a combination of magic practices, brilliant software tools, and, not infrequently, large invoices from consulting companies.” (Ibíd, 81)
2.4 EL PARADIGMA ÁGIL La forma tradicional de realizar proyectos es primero establecer el conjunto de requerimientos que se debe cumplir, este conjunto se realiza una sola vez en la planeación, y es invariable. El responsable del proyecto asume las siguientes fases de la planeación extensa a partir de los requerimientos, estiman que tan 19
largo será el proceso, y crean el plan del proyecto para predecir la fecha en que terminarán el proyecto, esa fecha es comunicada al cliente quién agenda una cita para la entrega. En una reunión acuerdan los requerimientos con el cliente, y la segunda reunión es para la entrega del proyecto. El plan que se realiza, valga la redundancia, en la planeación no cambia, y maneja el comportamiento durante el tiempo que dura el desarrollo del producto hasta la entrega; pero la experiencia en el desarrollo muestra que esta forma de trabajo no es aplicable, pues los requerimientos siempre cambian, y al cambiar estropean la gran planificación a largo plazo que se realizó a partir de ellos; esto lleva a la entrega tardía de proyectos que no son totalmente funcionales. El paradigma para la conducción de proyectos ágiles es totalmente diferente, asume por principio que los requerimientos no son nunca fijos, y que cualquier toma inicial de requerimientos será solo el punto de inicio para nuevos. Se asume una fecha en la que se deberá liberar una versión temprana del producto, para obtener una retroalimentación y así poder ir definiendo aquellos factores que no fueron previstos anteriormente. Los requerimientos se priorizan en orden de importancia y se trabajan aquellos que se cree que podrán desarrollarse en el período de tiempo acordado. Como cada período de tiempo se deberá entregar una versión, permitirá que se vayan cubriendo poco a poco los requerimientos reales del cliente, que pueden ser aquellos que se previeron en la planificación, o no necesariamente. La retrospectiva que brinde la entrega temprana permitirá que esto sea posible. Podemos clasificar dos tipos de metodologías por un lado las “tradicionales” que
se basan en los conceptos básicos de la administración de proyectos, por lo general industriales, y las metodologías ágiles basadas en una forma evolutiva de lograr soluciones. En resumen, las metodologías tradicionales: ● Se basan en un modelo de predicción donde se define en una etapa
temprana el proceso del proyecto. ● Se detalla al inicio todas las especificaciones del proyecto. ● Se debe mencionar al principio el costo y esfuerzo. 20
● Es posible detallar cada parte del proceso desde la primera planificación.
Mientras las metodologías ágiles: ● Casi nunca es posible detallar todas las etapas del proceso. ● Es un proceso empírico, al inicio no se puede determinar el costo y
esfuerzo del proyecto en general. ● Al inicio es imposible especificar cada parte del proceso que conforma al
proyecto. Apenas en el año 2007 se tenía que 90% de los equipos que usaron las metodologías ágiles incrementaron su productividad, 85% redujeron los defectos del software que desarrollaron, 83% aceleraron el tiempo en entregar valor, y el 66% redujeron los costos del proyecto.
(Figura 1.4 disponible en “Becoming Agile”, pág. 12)
Otros beneficios de adoptar la agilidad en los equipos de desarrollo de software son las siguientes: ● Manejo oportuno de tiempos que evita la entrega tardía de proyectos que
no funcionan. ● Creación de proyectos con una mayor calidad en el software. ● Construcción de códigos entendibles. ● La agilidad se enfoca en satisfacer las necesidades del cliente y su
organización. ● La agilidad permite una auto gestión del tiempo de trabajo del equipo. 21
Por lo tanto, hemos desglosado las generalidades de los valores que persiguen las Metodologías Ágiles en el desarrollo de Software, dado que su uso está aumentando cada vez más es para nosotros interesante ahondar al respecto, de forma que describiremos las metodologías más populares en los siguientes capítulos.
CAPÍTULO III. METODOLOGÍA SCRUM 3.1 CONCEPTO Scrum es una metodología ágil de desarrollo, que permite desarrollar software de manera incremental, de alto valor en entornos donde los requerimientos no están bien establecidos y donde se requiere de rapidez, así como flexibilidad en los resultados obtenidos. Scrum también es considerado un “framework” o marco de trabajo, es decir, nos
aporta un conjunto de herramientas que nos permiten realizar un proceso iterativo e incremental para la gestión y desarrollo de software. “Scrum es un marco de trabajo por el cual las personas pueden acometer
problemas complejos adaptativos, a la vez que entregar productos del máximo valor posible productiva y creativamente” (Schwaber, 2013, p.4). “Scrum es un modelo de desarrollo ágil caracterizado por: ● Adoptar una estrategia de desarrollo incremental, en lugar de la
planificación y ejecución completa del producto. ● Basar la calidad del resultado más en el conocimiento tácito de las
personas en equipos auto organizados, que en la calidad de los procesos empleados. ● Solapamiento de las diferentes fases del desarrollo, en lugar de realizar una
tras otra en un ciclo secuencial o de casca da.” (Palacio, 2014, p. 16). Cabe señalar que SCRUM no es una serie de pasos metódicos establecidos que garantizan el éxito de proyecto, más bien, es una serie de herramientas que se 22
basan en valores, principios y prácticas ágiles que garanticen una mejor organización del trabajo y una comunicación más acertada con el cliente. “Scrum is not a standardized process where you methodically follow a series of
sequential steps that are guaranteed to produce, on time and on budget, a highquality product that delights customers. Instead, Scrum is a framework for organizing and managing work” (Kenneth, 2013, p.13).
3.2 REGLAS Este conjunto de herramientas o modelo de trabajo funciona bajo un esquema de reglas bien definidas donde cada una de estas tiene una función específica para el éxito del proyecto. Las reglas de SCRUM se dividen en 3 secciones: roles, eventos y artefactos donde la interacción entre estos componentes conforma el funcionamiento del modelo SCRUM. “Las reglas de Scrum relacionan los eventos, roles y artefactos, gobernando las relaciones e interacciones entre ellos” (Schwaber, 2013, p.4).
(Figura 1.5 “Reglas o Prácticas Scrum” disponible en “Essential Scrum”, pág. 14)
23
3.3 ROLES Los roles en Scrum son las funciones que desempeñan cada uno de los involucrados en el proyecto, de estos tenemos 2 principales categorías. Roles Cerdo : los cuales están involucrados directamente en el proceso Scrum.
(Comprometidos) Roles Gallina: los cuales en realidad no forman parte del proceso Scrum, pero
están involucrados en el ámbito del proyecto. (Implicados) Dentro de los roles cerdo existen 3 principales roles: el “Product Owner” el “Scrum Master” y el “Equipo de desarrollo” los cuales son los responsables del proyecto, que en su conjunto reciben el nombre de “Scrum Team”.
(Figura 1.6 “Scrum Team” disponible en “Essential Scrum”, pág. 15)
Este equipo es auto organizado y multifuncional según lo menciona Schwaber. “Los equipos auto organizados eligen la mejor forma de llevar a cabo su trabajo y
no son dirigidos por personas externas al equipo. Los equipos multifuncionales tienen todas las competencias necesarias para llevar a cabo el trabajo sin depender de otras personas que no son parte del equipo. El modelo de equipo en Scrum está diseñado para optimizar la flexibilidad, la creatividad y la productividad.” (Schwaber, 2013, p.6).
Además, este equipo entrega productos de forma ágil, es decir, siguiendo los principios del manifiesto ágil de forma iterativa e incremental y así obteniendo una retroalimentación constante. 24
“Las entregas incrementales de producto “Terminado” aseguran que siempre estará disponible una versión potencialmente útil y funcional del producto” (Ibídem,
2013, p.6). El “Product Owner” o “dueño del producto” es el encargado de tomar las decisiones del proyecto desde la perspectiva del negocio, es decir, es el encargado de dirigir al Scrum Team en la dirección que el cliente desea. Es el enlace de comunicación entre el cliente y el Scrum Team, el cual traduce las necesidades de este en “historias de usuario”, las prioriza y las coloca en el “Product Backlog”, artefactos que serán detallados posteriormente. “El Dueño de Producto es el responsable de maximizar el valor del producto y del trabajo del Equipo de Desarrollo.” (Ibídem, 2013, p.6).
Es importante señalar que el dueño del producto es una sola persona y es la única que puede cambiar la “lista del producto”, el representa los deseos de los clientes
y las opiniones del Scrum Team, pero para que funcione este modelo todos deben respetar sus d ecisiones y cualquier cambio en la “lista de producto” o requerimientos deberá ser por medio de esta persona. El “equipo de desarrollo” es un grupo de 5 a 9 personas integrado por expertos en informática tales como analistas de sistemas, programadores, testers, administradores de bases de datos, etc. Los cuales son responsables por el diseño, construcción y pruebas del producto deseado. “Los Equipos de Desarrollo son estructurados y empoderados por la organización
para organizar y gestionar su propio trabajo. La sinergia resultante optimiza la eficiencia y efectividad del Equipo de Desarrollo” (Ibídem, 2013, p.7).
Ellos se auto gestionan para lograr de la mejor manera los objetivos determinados por el “Product Owner”, además en Scrum no se identifican títulos para cada
integrante de este equipo, todos son desarrolladores independientemente del trabajo que realice.
25
Para proyectos grandes donde se requiere de un gran número de personas, en lugar de tener un Scrum Team con todos los integrantes, normalmente se divide en varios Scrum Teams para que el número de personas no varíe y así se realice el trabajo de la manera más eficiente posible. “El tamaño óptimo del Equipo de Desarrollo es lo suficientemente pequeño como
para permanecer ágil y lo suficientemente grande como para completar una cantidad de trabajo significativa. Tener menos de tres miembros en el Equipo de Desarrollo reduce la interacción y resulta en ganancias de productividad más pequeñas y tener más de nueve miembros en el equipo requiere demasiada coordinación. Los Equipos de Desarrollo grandes generan demasiada complejidad como para que pueda gestionarse mediante un proceso empírico”. (Ibídem, 2013,
p.7). El “Scrum Master” es el encargado de hacer que todos los involucrados estén apegados a los principios, valores y prácticas de Scrum. Su principal función es el “coaching” y el liderazgo manteniendo una sinergia en todo el equipo, es decir,
mantiene al equipo centrado en los objetivos y elimina cualquier impedimento organizacional que se presente, además mantiene la armonía y motivación entre los integrantes del Scrum Team. Este personaje siempre está reflejando el rumbo del equipo, podemos considerar que es el “espejo” del equipo. Además, es un facilitador que organiza las
reuniones diarias, proporciona los elementos para realizar los artefactos y eventos, y no permite que alguien externo al Scrum Team interrumpa el trabajo del equipo. “The Scrum Master does whatever it takes to make the Scrum Team successful,
such as removing organizational impediments, facilitating meetings, acting as a gatekeeper so no one unnecessary interrupts the team's work.” (Sutherland, 2012,
p.12). El Scrum Master es un líder que está a disposición del Scrum Team ayudando a personas externas al equipo a entender las interacciones del equipo y el funcionamiento de Scrum, a adoptar este modelo y planificar la implementación 26
Scrum en la organización. Además, ayuda al equipo mismo a ejecutar técnicas para gestionar el trabajo de manera efectiva. En los roles gallina se encuentran 2 principales roles, los “usuarios” y los “stakeholders”. Estos no son parte del proceso Scrum, sin embargo, se deben
tener en cuenta ya que están afectados por el proyecto y forman parte de la comunicación cliente-desarrollador. Los “usuarios” son las personas finales en el proceso, aquellos que utilizaran el software, de ahí su importancia para saber a quién va dirigida la solución informática. Los “stakeholders” son los clientes, proveedores y altos mandos que hacen posible el proyecto. Para ellos el proyecto producirá un beneficio por lo que participan en las revisiones del sprint. 3.4 ARTEFACTOS Los artefactos Scrum son objetos de valor que representan el trabajo del equipo, estos son de diversas formas los cuales de una manera transparente permiten el entendimiento, inspección y adaptación del proceso Scrum por parte del Scrum Team. El primer artefacto recibe el nombre de “Product Backlog”, “lista de producto” o “Pila de producto” la cual es una lista ordenada o priorizada de los requeri mientos
conocidos o todo lo que podría ser necesario en el producto. Esta sigue la filosofía de Scrum: “Hacer el trabajo de más valor primero”. Además, esta lista es realizada
por el Product Owner, el cual es el responsable de determinar la secuencia del trabajo y determinar qué características se incluyen en la lista siendo el único que puede hacer modificaciones en la misma, pero con la retroalimentación y colaboración del Scrum Team y de los Stakeholders. Cabe mencionar que esta lista no es fija, ya que puede estarse modificando (refactorizando), agregando nuevas tareas o defectos que se necesitan reparar siendo meramente dinámica y revisada por el product owner cada que las 27
condiciones del negocio cambian. Entre los factores que se consideran para ponderar y priorizar los elementos de la lista se encuentran valor, costo, conocimiento y riesgo los cuales determinan qué característica estará hasta arriba de este artefacto y cuales hasta abajo. Cada una de estos elementos tiene el nombre de “historias de usuario” las cuales se refieren a funcionalidades entregables, no a trabajos internos del tipo “diseño de la base de datos”.
(Figura 1.7 “Product Backlog” disponible en “Essential Scrum”, pág. 19)
El “Sprint Backlog” es una lista de ítems provenientes del Product Backlog, los cuales van a ser implementados en el sprint, es decir, es la selección de las características convertidas en actividades de la lista general que se van a realizar en el incremento. Otra forma de visualizarlo sería como los objetivos seleccionados a cumplir durante el sprint. Estos ítems son la descomposición de las historias de usuario seleccionadas del Product Backlog convirtiéndolas en actividades, siendo esta selección de ítems una tarea del Scrum Team completo. En esta lista cada ítem está asignado a un miembro del equipo indicando cuanto tiempo y esfuerzo se prevé para terminarla. Además, al ser una descomposición en unidades pequeñas de las historias de usuario se puede monitorear el avance diario e identificar las problemáticas que puedan surgir.
28
Esta lista sirve como comunicación visual del equipo pues en ella se observa el progreso de cada persona en cada una de las tareas asignadas, pudiendo ser modificada únicamente por el Scrum Team durante el Sprint. “La Lista de Pendientes del Sprint es el conjunto de elementos de la Lista de
Producto seleccionados para el Sprint, más un plan para entregar el Incremento de producto y conseguir el Objetivo del Sprint. La Lista de Pendientes del Sprint es una predicción hecha por el Equipo de Desarrollo acerca de qué funcionalidad formará parte del próximo Incremento y del trabajo necesario para entregar esa funcionalidad en un Incremento Terminado” (Schwaber, 2013, p.16).
(Figura 1.9 “Sprint Backlog” disponible en “Essential Scrum”, pág. 22) El “Burn down Chart” es una gráfica que muestra la cantidad de ítems del Product Backlog pendientes al comienzo de cada Sprint. Con esto es mucho más fácil visualizar el progreso del proyecto, monitoreando la velocidad y capacidad de trabajo. Es una gráfica descendente o burn down ya que al inicio del proyecto están pendientes todos los requerimientos y conforme se avanza disminuyen hasta que
29
se completan, siendo una recta el progreso lineal e ideal y una curva el progreso real del proyecto.
(Figura 2.0 “Burn Down Chart” disponible en “The Scrum Handbook”, pág.35) El “incremento” es la parte del producto final terminada, o los ítems del Product Backlog realizados en el Sprint, este incremento debe tener las cualidades de estar completamente terminado, es decir, que es completamente operativa, está probado y en condiciones de ser entregadas al cliente. “El Incremento es la suma de todos los elementos de la Lista de Producto
completados durante un Sprint y el valor de los incrementos de todos los Sprints anteriores. Al final de un Sprint, el nuevo Incremento debe estar “Terminado”, lo
cual significa que está en condiciones de ser utilizado y que cumple la Definición de “Terminado” del Equipo Scrum. El incremento debe estar en condiciones de
utilizar se sin importar si el Dueño de Producto decide liberarlo o no.” (Íbidem, 2013, p.17).
30
3.5 EVENTOS O ACTIVIDADES Los eventos son bloques de tiempo definido, es decir, tienen una duración máxima. Con esto se evitan reuniones innecesarias que entorpezcan el trabajo del equipo. Todos los eventos suceden dentro del sprint, y una vez que este comience no puede alargarse o acortarse. Cabe mencionar que todos los eventos están diseñados para lograr la inspección y la adaptación del proyecto, por lo que la falta de alguno de estos mermará la calidad del producto y la oportunidad de mejora. El “Sprint” es un ciclo iterativo de duración definida, aproximadamente de un mes de duración el cual no puede ser alargado se termine el incremento o no. En este evento se desarrolla una funcionalidad del producto para producir nuevos incrementos funcionales, en el suceden todos los demás eventos Scrum, los cuales hacen que el producto sea diseñado, codificado y probado haciendo que el mismo evolucione. El “Grooming” es la actividad en la cual se definen, estiman y priorizan los ítems del product backlog. En si la realización del mismo, como se puede apreciar en la siguiente imagen.
(Figura 2.1 “Grooming” disponible en “Essential Scrum”, pág. 19)
Después sigue el “Sprint Planning” en donde se planifica el trabajo a realizar durante el Sprint, este plan es creado por el Scrum Team completo. Este evento tiene una duración máxima de 8hrs y es el Scrum Master quien se encarga de que el evento se ejecute de manera eficaz y en tiempo. 31
“La Reunión de Planificación de Sprint responde a las siguientes preguntas: ● ¿Qué puede entregarse en el Incremento resultante del Sprint que
comienza? ● ¿Cómo se conseguirá hacer el trabajo necesario para entregar el Incremento?” (Ibídem, 2013, p.10).
En este evento se define el “Sprint Goal” que es la meta que puede ser alcanzada durante el Sprint, este debe estar en mente durante todo el evento para que se trabaje hacia la misma dirección. Además, en este evento se crea el “Sprint backlog” que se explicó con anterioridad.
El “Daily Scrum” es una reunión diaria de 15 minutos de duración aproximadamente, en la cual se discute el estado del proyecto. En este el equipo de desarrollo sincroniza sus actividades y crea un plan para las siguientes actividades del día. Por otra parte, se inspecciona el trabajo ya hecho desde el último daily scrum y se hace una proyección de lo que se podría lograr para el próximo. “El Scrum Diario se realiza a la misma hora y en el mismo lugar todos los días
para reducir la complejidad. Durante la reunión, cada miembro del Equipo de Desarrollo explica: ● ¿Qué hice ayer que ayudó al Equipo de Desarrollo a lograr el Objetivo del
Sprint? ● ¿Qué haré hoy para ayudar al Equipo de Desarrollo a lograr el Objetivo del
Sprint? ● ¿Veo algún impedimento que evite que el Equipo de Desarrollo o yo
logremos el Objetivo del Sprint ?” (Ibídem, 2013, p.12). En el “Sprint Execution” se realizan todas las tareas asignadas en el Sprint Backlog necesarias para lograr los objetivos y las características del producto terminadas, este se realiza justo después de que el Scrum Team está de acuerdo con el contenido especificado en el Sprint Planning. 32
Estas tareas no tienen un orden específico, y el development team puede realizarlas como ellos deseen auto organizándose y gestionando para la realización de las mismas siempre y cuando se terminen a tiempo y logren los objetivos marcados. El “Sprint Review” se enfoca en hacer el análisis e inspección del incremento generado, haciendo adaptaciones al Product Backlog si es necesario. En este evento se hace una revisión de lo que se añadió al producto, y participan tanto el Scrum Team completo como los stakeholders. En este evento se discuten las cosas que podrían hacerse para optimizar el valor del producto, sin embargo, es una reunión informal donde el principal objetivo es facilitar la retroalimentación de información y fomentar la colaboración. “The goal of this activity is to inspect and adapt the product that is being built.”
(Kenneth, 2013, p.) Por último, está el “Sprint Retrospective” donde los integrantes del Scrum Team dejan sus impresiones del sprint recién terminado justo después de hacer el sprint review y antes de hacer el próximo sprint planning. La principal meta de esta reunión es la mejora continua de proceso. Al igual que el daily scrum, esta reunión tiene un tiempo definido de 4 horas. En esta reunión se discute que fue lo que pasó durante el sprint, que funcionó y que no, para llegar a acuerdos los cuales resaltan los cambios y adaptaciones que se deben realizar. 3.6 FUNCIONAMIENTO El proceso Scrum se basa en el sprint, donde suceden todas las actividades. Este inicia con el grooming, donde se define el product backlog para el caso del primer sprint y se adapta para los demás sprints priorizando y ordenando las características del producto, después se realiza el sprint planning donde se definen qué características del product backlog se harán en el sprint, se descomponen en tareas cuantificadas y se ordenan en el sprint backlog estimando 33
el tiempo en que se tardará en hacer cada tarea y proponiendo estrategias para su correcta realización. Una vez definido qué y quienes harán el trabajo se procede con la ejecución del sprint que básicamente es la parte de desarrollo del producto, en esta parte suceden reuniones diarias para tener una retroalimentación del trabajo y se monitorea el progreso de las tareas que se están realizando y las ya realizadas. Después del tiempo definido para el sprint sucede el sprint review donde se hace un recuento de lo que se ha hecho y se obtiene el incremento creado en el sprint, para posteriormente iniciar el Sprint retrospective, donde se analiza lo que se ha hecho bien y lo que se ha hecho mal, para así proponer acuerdos y adaptaciones que aseguren la calidad del producto. Al final se repite el proceso, de ahí que se diga que es cíclico e iterativo hasta que se completen todos los sprints definidos, o bien, hasta que el producto esté en el punto que el cliente lo acepte.
(Figura 2.2 “Scrum Process” disponible en “Essential Scrum”, pág. 17)
3.7 TIPOS DE PROYECTO Y ORGANIZACIONES DONDE SE USA El uso de la metodología Scrum está indicado para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde los requisitos son 34
cambiantes o poco definidos, donde la innovación, la competitividad, la flexibilidad y la productividad son fundamentales. “La cultura de la empresa proveedora del proyecto debe estar alineada con la
filosofía de una gestión ágil de proyectos como Scrum. Debe fomentar: ● El trabajo en equipo y la colaboración entre todas las personas implicadas
en un proyecto. ● Equipos autogestionados a los que se ha delegado la responsabilidad y
autoridad para hacer su trabajo, en contraposición a la dirección y control de personas que ejercería un jefe de proyecto tradicional (en lugar del jefe de proyecto existe la figura del Facilitador). ● La creatividad del equipo. ● La transparencia y la mejora continua, tanto del contexto de la organización
y del proyecto y como de las herramienta s del equipo” (Loayza Salazar, 2010, p.55). Muchas empresas de renombre han hecho uso de la metodología Scrum para desarrollar sus productos, en la siguiente tabla observamos ejemplos de organizaciones que usan o han usado Scrum. Sectores
Ejemplos de empresas que util izan Scrum
Media y Telcos
BBC,
BellSouth,
British
Telecom,
DoubleYou,
Motorola, Nokia, Palm, Qualcomm, Schibsted, Sony/Ericsson, Telefónica I+D, TeleAtlas, Verizon Software, Hardware
Adobe, Autentia, Biko2, Central Desktop, Citrix, Gailén, IBM, Intel, Microfocus, Microsoft, Novell, OpenView
Labs,
Plain
Concepts,
Primavera,
Proyectalis, Softhouse, Valtech, VersionOne. Internet
Amazon, Google, mySpace, Yahoo
ERP
SAP
35
Banca e Inversión
Bank of America, Barclays Global Investors, Key Bank, Merrill Lynch
Sanidad y Salud
Patientkeeper, Philips Medical
Defensa y Aeroespacial
Boeing, General Dynamics, Lockheed Martin
Juegos
Blizzard, High Moon Studios, Crytek, Ubisoft, Electronic Arts
Otros
3M, Bose, GE, UOC, Ferrari Tabla. Casos de éxito usando Scrum (Ídem, 2010, p.62). 3.8 CERTIFICACIONES
Por lo menos existen 7 opciones en el mercado para obtener la certificación en desarrollo usando la metodología Scrum y cada una de estas ofrecen enfoques diferentes y otras ofrecen un panorama mundial. “1. Scrum Alliance
Uno de los sitios más antiguos y respetados que brinda varias certificaciones, aunque en los mercados hispanoparlantes la más conocida es la de Scrum Master. ● Scrum Master Certificado (CSM) ● Propietario de producto (CPO) ● Desarrollador Scrum (CSD)
A su vez, se ofrecen dos certificaciones para aquellos que requieran especializarse en Scrum y Agile: ● Profesional certificado (CSD) ● Coach de Scrum (CSC)
2. Organización Scrum (Scrum.org )
Ken Schwaber fue uno de los fundadores de Scrum Alliance que luego decidió apartarse y seguir su camino. Varios de sus exámenes están abiertos al público sin necesidad de tomar sus cursos y ofrecen un nivel de dificultad alto. 36
● Scrum Master profesional 1 y 2 (PSM I, PSM II) ● Propietario de producto profesional 1 y 2(PSPO I, PSPO II) ● Desarrollador profesional 1 (PSD I)
3. PMI-ACP (pmi .org)
El conocido Instituto de gestión de proyectos, el cual finalmente además de su clásico programa de cursos y certificaciones relacionadas a metodologías tradicionales, comenzó a ofrecer la certificación de Practicante Ágil luego de llevar adelante un período de prueba durante 2011. Ellos cuentan con una comunidad de práctica de Ágil y recomiendan decenas de libros para la preparación del examen (muchos de los cuales son los mismos que sugiere ScrumAlliance) y también hay ediciones específicas que se centran en la preparación del examen. 4. NetObjectives
Ofrecen certificación de Scrum Master, Propietario del producto y varios cursos sobre Lean y Ágil. A diferencia con las instituciones anteriores, también brindan los exámenes de SAFe (Scaled Agile Framework), lo cual es un marco de trabajo Scrum orientado a compañías de gran porte. 5. ICAgile
Está especializado en ofrecer material consistente y principalmente de calidad para universidades y organizaciones. Tienen 3 niveles de certificación, las que evalúan el conocimiento adquirido, pero también la experiencia del participante. Cuentan con un modelo que apoya a Universidades y empresas que deseen albergar cursos estándares sobre todos los aspectos de Ágil (no solamente Scrum). Es una excelente opción para Facultades u otras organizaciones similares que requieran enseñar los distintos tópicos de forma unificada. 6. Academia de Ágil d istribuido, SAFe (scaledagileacademy.com)
Ofrece certificaciones para empresas de gran porte mediante una versión de Scrum adaptada. A grandes rasgos, el marco de trabajo consiste en sincronizar diferentes pilas de producto a varios niveles y la aparición de nuevos roles, así como la extensión de los roles clásicos. 37
El modelo ofrece consistencia para las compañías que emplean actualmente metodologías tradicionales y desean moverse hacia Scrum. ● Consultor SAFe (SAFe program Consultant) ● Agilista (SAFe program Agilist) ● Practitioner (SAFe program Practitioner)
En SAFe la empresa simplemente seguirá prácticas, sin impulsar un cambio de corporativo real, con las consecuencias que ello puede traer. 7. Probador (tester) certificado Ágil (Instituto internacional de calidad de software, agile-tester.org)
Es una organización de origen alemán que cuenta con un curso de 5 días centrado en la especialización de “testers” para un entorno Ágil. Ellos creen que
no puede ser simplemente enseñado y tiene que ser demostrado con prácticas. Es por ello que el curso ocupa plenamente 5 días donde se evalúan no solamente las herramientas, sino que también las interacciones entre las personas. Al momento tienen alrededor de 2000 personas certificadas, lo cual es un número bajo comparado con otras organizaciones, pero una excelente opción si se piensa que ataca un nicho específico de mercado” (Bühler, E, 2014).
3.9 BENEFICIOS Y DESVENTAJAS Como toda metodología, Scrum no es sinónimo de perfección, si bien nos ofrece muchos beneficios para el desarrollo de proyectos, existen también desventajas al usar esta metodología; y tiene que ver con la buena ejecución de cada tarea, así como con el conocimiento o experiencia que se tenga al usar esta metodología. “Ventajas de Scrum: ● Gestión regular de las expectativas del cliente: el cliente establece sus
expectativas indicando el valor que le aporta cada requisito del proyecto y cuando espera que esté completado. ● Flexibilidad y adaptación: de manera regular el cliente redirige el proyecto
en función de sus nuevas prioridades, de los cambios en el mercado, de los 38
requisitos completados que le permiten entender mejor el producto, de la velocidad real de desarrollo, etc. ● Retorno de inversión (ROI): de manera regular, el cliente maximiza el ROI
del proyecto. Cuando el beneficio pendiente de obtener es menor que el coste de desarrollo, el cliente puede finalizar el proyecto. ● Mitigación de riesgos: desde la primera iteración el equipo tiene que
gestionar los problemas que pueden aparecer en una entrega del proyecto. Al hacer patentes estos riesgos, es posible iniciar su mitigación de manera anticipada. ● Productividad y calidad: de manera regular el equipo va mejorando y
simplificando su forma de trabajar. ● Alineamiento entre cliente y equipo: los resultados y esfuerzos del proyecto
se miden en forma de objetivos y requisitos entregados al negocio. Todos los participantes en el proyecto conocen cuál es el objetivo a conseguir. El producto se enriquece con las aportaciones de todos. ● Equipo motivado: las personas están más motivadas cuando pueden usar
su creatividad para resolver problemas y cuando pueden decidir organizar su trabajo. Desventajas Scrum: ● Requiere delegar responsabilidades al equipo, incluso permite fallar si es
necesario. ● Es una metodología que difiere del resto, y esto causa cierta resistencia en
su aplicación para algunas personas” (Loayza Salazar, 2010, p.55).
CAPÍTULO IV. METODOLOGÍAS CRYSTAL 4.1 CONCEPTO “Crystal es una familia de metodologías con un código genético en común, uno
que enfatiza entregas frecuentes, comunicación cercana y mejora reflectiva. No hay una sola metodología Crystal, sino varias para distintos tipos de proyectos. Cada proyecto u organización usa el “código genético” para generar nuevos miembros de la familia.” (Cockburn, 2004, p. 4). 39
El nombre Crystal viene de mi caracterización de proyectos que implican dos dimensiones, tamaño y criticalidad, que coinciden con el de los minerales, color y dureza [...] Proyectos más grandes, requieren de más coordinación y comunicación, representados con colores gradualmente más oscuros (Claro, Amarillo, Naranja, Rojo, y así sucesivamente). Proyectos para sistemas que pueden causar más daño, necesitan dureza añadida en la metodología, más validación y reglas de verificación (Íbidem, p. 4).
Para ilustrar su forma de trabajo, se tomará como ejemplo una de las variedades que nos ofrece Crystal: Crystal Clear . Los equipos que trabajan con Crystal Clear tienen el paradigma de trabajar en equipo – su intención es darle menos peso al trabajo de documentación, pues creen que lo importante es darle al usuario la solución que pide, y no confundirlo con documentación – usualmente trabajan con ideas plasmadas en un pizarrón, donde asientan los requerimientos del usuario y el diseño de la solución entregable. “Ellos estriban en desarrollar una mente comunitaria. Se sientan al
inicio y entienden el problema que quieren resolver, trabajan en el tratamiento que le brindarán y comienzan a trabajar” (Íbidem, pp. 19, 20).
4.2 ROLES DE LOS PARTICIPANTES • Patrocinador • Usuario experto • Diseñador principal 40
• Diseñador programador • Experto en negocios • Coordinador • Probador (Tester) • Escritor de documentación (Writer)
4.3 MATERIALES Y MÉTODOS • Lápiz • Plumones o pintarrones • Libretas o papel • Pizarrón • Computadoras personales • Prototipos • Lluvia de ideas • Reuniones grupales • Autocrítica • Valores de equipo • Conexiones con el usuario • Desarrollo incremental iterativo • Casos de uso • Entregables • Pruebas
4.4 FUNCIONAMIENTO A grandes rasgos, existe un proceso bien definido para trabajar con esta metodología: 1. Obtención de requerimientos del o los usuarios interesados (Los cuales pueden ser los ejecutivos patrocinadores). 2. Definición de infraestructura y requerimientos tecnológicos. 3. Elaborar un plan de entrega (la frecuencia con la que se entregarán los prototipos).
41
a. En cada entrega se deben discutir el propósito de las pantallas y su secuencia. b. También se deben realizar las pruebas necesarias al sistema, como pruebas de regresión o unitarias, en pequeñas reuniones referentes al diseño. 4. Entregar una versión de prueba a las dos semanas, misma que el usuario revisará y servirá como base para reforzar los requerimientos y hacer ajustes en errores descubiertos para las siguientes iteraciones. 4.5 APLICABILIDAD A PROYECTOS Computadoras centrales (mainframes), sistemas de arquitectura cliente servidor, sistemas basados en red (con bases de datos centrales o distribuidas). Puede ser moldeado para sistemas en tiempo real con reglas adicionales para planear y verificar los problemas de sincronización del sistema. No está destinado para sistemas a prueba de fallos, ya que le falta reseñas duras de arquitectura para tolerancia a fallos y recuperación (Cockburn, 2004, pp. 19, 20). 4.6 CERTIFICACIONES CMMI – Agile / Lean Development and CMMI 4.7 PRINCIPALES VENTAJAS Y DESVENTAJAS Ventajas
• Gran tolerancia a la notación del código fuente generado (siempre y cuando
el equipo esté de acuerdo). •
Las entregas acordadas son a corto plazo, por lo general de uno a tres meses.
• Está diseñada para el cambio. • Reducción de costos. • Planificación más transparente para los clientes. • Retroalimentación activa con los clientes.
42
Desventajas
• Las pruebas de regresión y programación en pares tienen poca tolerancia. • El tamaño del equipo debe ser de 2 – 8 personas únicamente. • Delimita el alcance del proyecto con el cliente.
4.8 CONCLUSIÓN DE LA METODOLOGÍA La familia de metodologías de desarrollo Crystal es una buena alternativa para agilizar el proceso de construcción de software cuando se quiere trabajar en un equipo mediano, pues existe mucha comunicación interna con los colaboradores del proyecto, y externa con los interesados en su desarrollo; también es una metodología muy flexible y orientada a los resultados, dado que no es muy forzoso terminar con cientos de páginas de documentación para tener el software construido.
CAPÍTULO V EXTREME PROGRAMMING 5.1 CONCEPTO La Programación Extrema es una metodología ágil “centrada en desarrollar las
relaciones interpersonales como clave del éxito del desarrollo del software, promoviendo ciertos valores, entre ellos, el trabajo en equipo, desarrollar el aprendizaje de los desarrolladores y creando un clima de trabajo óptimo” (Beck, Kent,1999). 5.2 REGLAS Una de las características de eXtreme Programming es que muchos de, sí no todos, sus ingredientes son de sobra conocidos dentro de la rama de la ingeniería del software desde hace tiempo, incluso desde sus comienzos. Para que exista una regla, debe de existir una persona del proyecto que la cumpla, un objeto o artefacto que la verifique y un evento que la contenga, así identificamos los roles, eventos y artefactos de la programación extrema.
43
Según Joskowicz (2008), podemos englobar estos elementos desde la perspectiva del desarrollo de la programación extrema: • Reglas para la Planificación • Reglas para el Diseño • Reglas para el Desarrollo • Reglas para las Pruebas
5.2.1 REGLAS DE PLANIFICACIÓN En planificación es esencial seguir la regla que nos indica que la comunicación activa entre el cliente, desarrolladores y coordinadores o gerentes, es el punto de inicio del proyecto, aquí el proyecto debe de cumplir las siguientes características (Frowler, 2001): ● Planes simples sin complejidad ● Planes realizados por el equipo sin agentes externos ● Los planes no son predicciones a futuro son estimaciones que son
susceptibles a cambios Para lograr el cometido el proyecto recopila historias de usuario, una vez obtenidas los programadores estiman el trabajo requerido para cumplir las historias, utilizando la evaluación de riesgos de la metodología espiral, se detecta las historias que sean un obstáculo para la entrega, se utilizan (spikes) para determinar riesgos para generar una toma de decisiones. A continuación, se genera una reunión de planificación con los integrantes del equipo para generar el plan de entrega (Release Plan), a partir de este plan se genera un plan de iteraciones para entregas del producto y reuniones diarias para coordinar los esfuerzos. 5.2.2 REGLAS PARA EL DISEÑO La Programación Extrema hace especial énfasis en diseño simples y claros, el equipo los puede desarrollar siguiendo el siguiente valor que es la sencillez en conjunto de buenas prácticas que son la recodificación y las metáforas.
44
5.2.3 REGLAS PARA EL DESARROLLO La principal regla que sigue la programación extrema en el desarrollo del proyecto es que todo el trabajo debe ser una gran propiedad colectiva con reglas estándares aceptadas por todo el equipo, las principales prácticas que siguen esta regla son: programación en parejas, programación dirigida por pruebas, integraciones permanentes. 5.2.4 REGLAS PARA LAS PRUEBAS En el aspecto de pruebas, Beck (1999) nos explica que todo módulo del sistema debe de liberarse a través de pruebas unitarias, detección de errores y aprobando las pruebas de aceptación. 5.3 VALORES DE LA PROGRAMACIÓN EXTREMA Para garantizar el éxito de un proyecto de Programación Extrema, el equipo debe poner en práctica estos valores: ● Comunicación: La XP ayuda mediante sus prácticas a la
comunicación entre los integrantes del grupo de trabajo. ● Sencillez: Los programas deben de ser sencillos y tener la
funcionalidad requerida en los documentos de requisitos ● Retroalimentación: Las pruebas que se realizan al proyecto
mantienen informados al equipo de desarrollo sobre el grado de fiabilidad del sistema. ● Valentía: Es necesario asumir retos, afrontar los problemas, siempre
mejorar algo que ya funciona. 5.4 PRÁCTICAS DE LA PROGRAMACIÓN EXTREMA El principal objetivo de la programación extrema es disminuir la mítica curva exponencial del costo del cambio a lo largo del proyecto, lo suficiente para que el diseño evolutivo funcione. XP apuesta por un crecimiento lento del costo del cambio y con un comportamiento asintótico, de acuerdo con (Joskowicz,2008) existen las siguientes prácticas en la programación extrema. La Planificación 45
En esta fase de la programación extrema, el cliente establece la prioridad de cada historia de usuario, de acuerdo con el valor que aporta para el negocio. Los programadores estiman el esfuerzo asociado a cada historia de usuario. Se ordenan las historias de usuario según prioridad y esfuerzo, y se define el contenido de la entrega y/o iteración, apostando por enfrentar lo de más valor y riesgo cuanto antes. Esta práctica se realiza durante la planificación de la entrega, en la planificación de cada iteración y cuando sea necesario reconducir el proyecto. Entregas pequeñas
La idea es producir rápidamente versiones del sistema que sean operativas, aunque obviamente no cuenten con toda la funcionalidad pretendida para el sistema, pero sí que constituyan un resultado de valor para el negocio. Una entrega no debería tardar más 3 meses. Metáfora
Una metáfora es una historia compartida que describe cómo debería funcionar el sistema. Fowler (2001), explica que “la práctica de la metáfora consiste en formar un conjunto de nombres que actúen como vocabulario para hablar sobre el dominio del problema. Este conjunto de nombres ayuda a la nomenclatura de clases y métodos del sistema”.
Diseño simpl e
Kent Beck (1999) asegura que “en cualquier momento el diseño adecuado para el software es aquel que: supera con éxito todas las pruebas, no tiene lógica duplicada, refleja claramente la intención de implementación de los programadores y tiene el menor número posible de clases y métodos”.
Pruebas
La producción de código está dirigida por las pruebas unitarias. Las pruebas unitarias son establecidas antes de escribir el código y son ejecutadas constantemente ante cada modificación del sistema. Los clientes escriben las pruebas funcionales para cada historia de usuario que deba validarse.
46
Refactorización (Refactoring )
La Refactorización es una técnica de análisis que permite al equipo de programación extrema replantear el orden de los módulos lógicos y físicos del sistema tal y como señala (Robert Martin, 2002) que “el diseño del sistema de software es una cosa viviente por lo que se puede imponer todo en un inicio, pero en el transcurso del tiempo este diseño evoluciona conforme cambia la funcionalidad del sistema”. Para mantener un diseño apropiado, es necesario
realizar actividades de cuidado continuo durante el ciclo de vida del proyecto. Programación en parejas
La programación en parejas es una de las principales fortalezas de XP, los puntos a favor de esta técnica es una mejor detección de errores y por consiguiente las métricas de calidad del sistema aumentan, según Cockburn y Williams (2000), el conocimiento no se reserva a un solo grupo de “programadores” sino que todos
los miembros del equipo pueden modificar y reparar el código del sistema en parejas. En los estudios realizados por Cockburn y Williams el tiempo promedio para que el equipo trabaje en parejas con un rendimiento considerable varía de 3 a 4 meses. Propiedad co lectiva del código
Cualquier programador puede cambiar cualquier parte del código en cualquier momento. Esta práctica motiva a todos a contribuir con nuevas ideas en todos los segmentos del sistema, evitando a la vez que algún programador sea imprescindible para realizar cambios en alguna porción de código. Integración conti nua
Cada pieza de código es integrada en el sistema una vez que esté lista. Así, el sistema puede llegar a ser integrado y construido varias veces en un mismo día. Todas las pruebas son ejecutadas y tienen que ser aprobadas para que el nuevo código sea incorporado definitivamente. 40 horas por semana
Se debe trabajar un máximo de 40 horas por semana. No se trabajan horas extras en dos semanas seguidas. Si esto ocurre, probablemente está ocurriendo un 47
problema que debe corregirse. El trabajo extra desmotiva al equipo. Los proyectos que requieren trabajo extra para intentar cumplir con los plazos suelen al final ser entregados con retraso. En lugar de esto se puede realizar el juego de la planificación para cambiar el ámbito del proyecto o la fecha de entrega. Cliente in-situ
El cliente tiene que estar presente y disponible todo el tiempo para el equipo. Gran parte del éxito del proyecto XP se debe a que es el cliente quien conduce constantemente el trabajo hacia lo que aportará mayor valor de negocio y los programadores pueden resolver de manera inmediata cualquier duda asociada. La comunicación oral es más efectiva que la escrita, ya que esta última toma mucho tiempo en generarse y puede tener más riesgo de ser mal interpretada. Estándares de programación
XP enfatiza la comunicación de los programadores a través del código, con lo cual es indispensable que se sigan ciertos estándares de programación (del equipo, de la organización u otros estándares reconocidos para los lenguajes de programación utilizados). Los estándares de programación mantienen el código legible para los miembros del equipo, facilitando los cambios. 5.5 ROLES DE LA PROGRAMACIÓN EXTREMA Según Newkirk (2001) existen siete roles en un equipo de programación extrema a saber: Programador
El programador escribe las pruebas unitarias y produce el código del sistema. Debe existir una comunicación y coordinación adecuada entre los programadores y otros miembros del equipo. Cliente
El cliente escribe las historias de usuario y las pruebas funcionales para validar su implementación. Además, asigna la prioridad a las historias de usuario y decide
48
cuáles se implementan en cada iteración centrándose en aportar mayor valor al negocio. Uno de los ideales es que 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” (Beck,1999).
Encargado de pr uebas (Tester)
El encargado de pruebas ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas. Encargado de seguimiento (Tracker)
El encargado de seguimiento proporciona realimentación al equipo en el proceso XP. Su responsabilidad es verificar el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para mejorar futuras estimaciones. También “ realiza el seguimiento del progreso de cada iteración y evalúa si los objetivos son alcanzables con las restricciones de tiempo y recursos presentes” (Newkirk,2001).
Entrenador (Coach) Es responsable del proceso global. Es necesario “que conozca a fondo el proceso XP para proveer guías a los miembros del equipo de forma que se apliquen las prácticas XP y se siga el proceso correctamente” (Beck,1999).
Consultor
Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto. Guía al equipo para resolver un problema específico. Gestor (Big Boss)
Es el vínculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinación.
49
5.6 ARTEFACTOS Los artefactos de la programación extrema, que dicho en otras palabras son herramientas del equipo de desarrollo, son las siguientes: historias de usuario y tarjetas CRC (Beck,1999). Historias de usuario
Las historias de usuario representan una breve descripción del comportamiento del sistema deseado por el usuario, sin términos técnicos, se realiza una historia de usuario por cada función del sistema, se emplean para realizar estimaciones del tiempo y para el lanzamiento de las funciones, reemplazan un gran número de documentos de requisitos y emplean pruebas de sistema para su verificación. Tarjetas CRC (CLASE- RESPONSABILIDAD-COLABORADOR)
Una clase es “cualquier persona, cosa, evento, concepto, pantalla o reporte” (Jacobson,2001). Las responsabilidades de una clase son las cosas que conoce y
las que realiza, sus atributos y métodos. Los colaboradores de una clase son las demás clases con las que trabaja en conjunto para llevar a cabo sus responsabilidades. 5.7 FUNCIONAMIENTO Un proyecto XP tiene éxito cuando el cliente selecciona los objetivos del sistema 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 en los siguientes pasos: 1. El cliente define un objetivo a desarrollar del sistema. 2.
El programador estima el esfuerzo necesario para su implementación.
3. El cliente selecciona qué construir, de acuerdo con sus prioridades y las restricciones de tiempo. 4. El programador construye el objetivo. 5. Vuelve al paso 1. El ciclo de vida ideal de XP consiste de seis fases [Beck, 1999]: 1. Exploración 2. Planificación de la Entrega (Release) 50
3. Iteraciones 4. Producción 5. Mantenimiento 6. Muerte del Proyecto. Fase I: Exploración
En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son de interés para la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas, tecnologías y prácticas que se utilizarán en el proyecto. Fase II: Planifi cación de la Entrega
Cuando se realiza la planificación de la entrega, el cliente a través de reuniones con programadores, establece la prioridad de cada historia de usuario, y correspondientemente, los programadores y/o analistas realizan una estimación del esfuerzo necesario de cada una de ellas. Se toman acuerdos sobre el contenido de la primera entrega y se determina un cronograma en conjunto con el cliente. Una entrega debería obtenerse en no más de tres meses. El desarrollo de esta fase se realiza en pocos días generalmente de dos a tres días. Fase III: Iteraciones
Todo programa construido bajo programación extrema se construye a través de iteraciones, una iteración es un ciclo de desarrollo de la programación extrema. En la primera iteración se puede intentar establecer una arquitectura del sistema (por arquitectura del sistema entendemos todo módulo lógico o físico del sistema y la forma de comunicación entre ellos) que pueda ser utilizada durante el resto del proyecto. Esto se logra escogiendo las historias que generen la creación de los módulos, sin embargo, esto no siempre es posible ya que es el cliente quien decide qué historias se implementarán en cada iteración (para maximizar el valor de negocio). Al final de la última iteración el sistema estará listo para entrar en producción. Fase IV: Produ cció n
51
En la fase de producción el sistema requiere de pruebas adicionales y revisiones de rendimiento antes de que sea trasladado al entorno del cliente. Al mismo tiempo, se deben tomar decisiones sobre la inclusión de nuevas características a la versión actual, debido a cambios durante esta fase. Es posible que el tiempo que toma cada iteración se reduzca, de tres a una semana. Fase V: Mantenimiento
Mientras la primera versión se encuentra en producción, el proyecto XP debe mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas iteraciones. Para realizar esto se requiere de tareas de soporte para el cliente. De esta forma, la velocidad de desarrollo puede bajar después de la puesta del sistema en producción. La fase de mantenimiento puede requerir nuevo personal dentro del equipo y cambios en su estructura. Fase VI: Muerte del Proyecto
Es cuando el cliente no tiene más historias para ser incluidas en el sistema. Esto requiere que se satisfagan las necesidades del cliente en otros aspectos como rendimiento y confiabilidad del sistema. En la muerte del proyecto “generamos la documentación final del sistema y no se realizan más cambios en la arquitectura. La muerte del proyecto también ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando no hay presupuesto para mantenerlo” (Beck,1999).
5.8 TIPOS DE PROYECTO Y ORGANIZACIONES DONDE SE USA Por lo general cada metodología tiene un entorno donde es aplicable, ninguna metodología soluciona todo tipo de proyectos, la programación extrema se recomienda para proyectos medianos y en el que los requerimientos no se puedan obtener hasta una vez iniciado el proyecto, aun así, diversos estudios incluidos en (Nord, 2004) aseguran que la programación extrema puede ser utilizado en conjunto con otras metodologías del software. Si bien no hay un consenso en el número máximo de desarrolladores, todos parecen coincidir en números no mayores a 20. Sus propias prácticas así lo 52
requieren, ya que, por ejemplo, mantener las “Stand -up meeting” con más de 20 personas parece poco razonable. El entorno físico en el que se realizan los desarrollos deben ser adecuados a la metodología. Escritorios amplios, con un ordenador y dos sillas, mesas redondas para trabajo en equipo, ambientes que permitan la permanente comunicación y colaboración, son algunos de los requerimientos de infraestructura para poder implementar esta metodología. La participación e involucramiento del cliente en el proceso es fundamental. El cliente debe conocer y aprobar la metodología, y destinar los recursos necesarios. De otra manera, el proyecto no podrá ser llevado a cabo. Finalmente, los participantes del equipo de desarrollo deben estar compenetrados con el proyecto y su metodología. Deben aceptar compartir sus códigos y ser responsables por el código que escribieron otros. 5.9 CERTIFICACIONES En contraparte con la metodología Scrum , la programación extrema no cuenta con certificaciones reconocidas por el autor y/o similares , la mayoría de las certificaciones citadas son creadas por institutos , escuelas o empresas para ofrecer al estudiante un marco de trabajo de la programación extrema , es necesario aclarar que las certificaciones son para reforzar el currículum vitae del ingeniero en sistemas, la programación extrema lleva un camino de 15 años de conocimiento basado en la experiencia de un campo dinámico como es la ingeniería del software , por esta razón se desarrollan workshops(talleres), donde un grupo de expertos es el encargado de ofrecer experiencias sobre un tema en especial, en este caso sobre la programación extrema, en México, desgraciadamente son muy pocas las organizaciones que ofrecen este tipo de talleres , además este tipo de organizaciones están centralizadas en las grandes metrópolis del país, existe actualmente una asociación llamada México First “que se encarga de proveer acuerdos entre empresas de capacitación con profesionistas en los términos de descuentos”, al momento de la investigación no
existía alguna certificación enfocada en programación extrema, el presente listado son de empresas extranjeras que ofrecen talleres para profesionistas que aspiren a dominar la programación extrema. 53
Industrial logic
Industrial Logic es una empresa americana que ofrece talleres a profesionistas TI (Tecnologías de la Información) en metodologías ágiles, actualmente ofrecen una capacitación de 4 días sobre programación extrema.
CAPÍTULO VI. KANBAN 6.1 CONCEPTO “Kanban no es una m etodología de desarrollo de software o un enfoque para la
administración de proyectos. Se requiere de un proceso ya establecido para que Kanban pueda ser aplicado para cambiar incrementalmente el proceso subyacente” – David Anderson, Kanban (Stellman, Greene, 2015, p. 315). “Kanban es un método para mejora de procesos usado por equipos ágiles. Los
equipos que usan Kanban comienzan por entender la manera en la que construyen software actualmente, y hacen mejoras a ello con el tiempo. Como Scrum y XP, Kanban requiere de una mentalidad. Específicamente, requiere de la mentalidad magra.” (Ídem).
Andrew Stellman y Jennifer Greene también nos mencionan en su obra que cuando los equipos emplean Kanban, se enfocan en eliminar los desperdicios de sus procesos justo como lo harían en un proceso industrial. Los autores también reconocen que este método comenzó a aplicarse como metodología de desarrollo de software cuando fue adaptado por David Anderson en su libro “The Kanban Method”, en el cual se estipula que el en foque de Kanban
se orienta a ayudar a un equipo de trabajo a mejorar sus procesos de construcción de software, a diferencia de SCRUM, cuyo enfoque se centra en la gestión de proyectos, o XP, en donde se busca tener un desarrollo de software óptimo, con buenas prácticas de programación.
54
“Kanban no es un método para la gestión de proyectos, pero ciertamente esto no
significa que Kanban no es para los Administradores de Proyectos. De hecho, David Anderson publicó una serie de publicaciones de blog que explican exactamente cómo los administradores de proyectos encajan en Kanban y ofrece una clase de Gestión de Proyectos con Kanban” (Stellman, Greene, 2015, p. 321).
Según los autores, los roles están definidos por metodologías existentes como SCRUM o XP. Kanban sencillamente ayuda en la mejora de los procesos. Para Stellman y Greene (2015) los principios fundamentales de Kanban son: 1. Comenzar por lo que haces ahora. 2. Acordar en perseguir un cambio incremental y evolutivo. 3. Inicialmente, respetar las reglas actuales, responsabilidad y títulos de trabajo. Después se deben adoptar las siguientes prácticas base: ● Visualizar. ● Limitar el trabajo en progreso (WIP). ● Administrar el flujo. ● Hacer explícitamente las políticas de proceso. ● Implementar ciclos de retroalimentación. ● Mejorar la colaboración, evolucionar experimentalmente (usando modelos y
el método científico).
6.2 FUNCIONES Kanban no es una metodología, o marco de trabajo ágil. Si bien Scrum se enfoca a la gestión de proyectos a través de varias técnicas que modifican los comportamientos organizacionales del equipo, mientras XP se enfoca a las prácticas y ambientes de programación, Kanban se enfoca más que nada a establecer una mentalidad diferente. Nace como un pensamiento dirigido a la manufactura para eliminar los derroches dentro de un proceso industrial.
55
Dentro de la industria del software, Kanban a través de los principios antes mencionados, se enfoca principalmente a mejorar la forma de construir software a través de una toma de consciencia del proceso que se lleva a cabo para realizar esto. ¿Cómo iniciar? Si bien Kanban no dicta una forma de iniciar un proyecto, lo que hace es empezar por reconocer cómo se está iniciando el proyecto, llevando a poner a lápiz y papel las actividades que en ese momento se están realizando, quién las está haciendo, y cómo se están realizando. Esto acelera esta toma de consciencia, ya que así se puede ir visualizando cómo está trabajando un equipo de desarrollo para crear un producto de software, y a su vez será posible ver cómo funciona el marco de trabajo adoptado, así como los hábitos de colaboración que de él surgen para entonces poder establecer políticas o reglas que permitan medir estos comportamientos y guiarlos hacia una mejor inclusión. Así mismo esto promueve los ciclos de retroalimentación, al poder ver el flujo de actividades es notorio poder ejercer una visión más crítica del proceso, y poder enfocarse a eliminar los derroches de tiempo, esfuerzo y material, y reconocer un sistema organizacional enfocado al desarrollo del software. Lejos de ser un monitor de quién contrata al equipo de desarrollo sirve como instrumento para que sea el propio equipo quien se conozca y pueda tomar decisiones que lo lleven a una mejora continua real. El instrumento más usado son los tableros de kanban que consisten en una tabla con columnas que representan las etapas del proceso, en él se colocan tarjetas que representan las tareas a realizar, conforme cada tarea vaya avanzando, se debe actualizar en el tablero, de modo que así se visualizará el avance del proyecto.
56
Kanban puede combinarse por ejemplo con Scrum, una vez que se tenga el backlog de actividades del Sprint, esas tareas ya ponderadas pueden ser llevadas al tablero para visualizar el flujo de trabajo del equipo a través del tiempo.
6.3 CERTIFICACIONES Una organización que ofrece certificaciones es Lean Agile Prosperity Management Value Inova.
● Kanban Methodologist Certificado ● Kanban Leader Certificado Certificaciones Kanban [en línea], ©Valueinnova LLC, [Fecha de consulta:
20/04/2016]
CONCLUSIONES Ideas principales (Felix): ● IDEAS PRINCIPALES: ● *Alta colaboración con el cliente ● *Alta Respuesta al Cambio ● *Conocimiento construido por el equipo ● *Enfocado a la sencillez de la construcción de los programas. 57
● *La planificación es adaptable a los imprevistos del proyecto ● *Enfocadas a reducir el costo innecesario de los proyectos.
Conclusiones de Carlo: ● Las metodologías ágiles (MA) se basan principalmente en valores
humanos ● Las MA ponen al descubierto el flujo de trabajo e información de una
organización ● Las MA no son metodologías que “aumentan” el ritmo de entrega de
productos ● Las MA se basan en ciclos cortos de planificación, desarrollo,
retrospectivas. ● Para su funcionamiento necesitan la participación del cliente u
organización. ● Scrum es un marco de trabajo orientado a la gestión del proyecto ● Scrum prioriza en entregar valor constante ● Scrum hace hincapié en la comunicación efectiva en el equipo. ● Las metodologías Crystal y XP se enfocan a la parte técnica como lo
es la programación. ● Kanban se adapta de maravilla a las MA porque permite visualizar el
ritmo del proceso de trabajo, así como el grado de integración en el equipo. ● Las MA muestran que la creación de tecnología como lo es el
software requiere de un alto grado de colaboración y comunicación entre los miembros del equipo que desarrollan. Conclusiones (Iram): ● Se basan en los principios agile ● Son basadas en la comunicación constante ● Siempre hay retroalimentación, (Se monitorea el trabajo) ● Equipos de trabajo auto organizados ● Crean productos funcionales desde el inicio ● Son una forma mucho más organizada, eficiente y controlada de realizar
productos intangibles ● se basan en corrección de errores y reajuste continuo del camino a llegar 58
● crean productos con mucho más valor y más apegados a las necesidades
del cliente ● Su popularidad se origina por el dinamismo, la velocidad y eficiencia del
trabajo ● Surgen como necesidad de ver progreso a corto tiempo en el trabajo a
realizar Ideas principales (Enrique): ● Observamos que estas metodologías se complementan entre sí. ● Hacer énfasis en que esto no solo es teoría, sino que como ya vimos en el
contenido del documento existen diversas empresas de prestigio que han usado con éxito estas metodologías. ● Cada metodología puede usarse no solo para el desarrollo de software sino
también la mejora en procesos. Conclusiones generales
Las metodologías ágiles de desarrollo surgieron como necesidad de ver resultados a corto plazo y reducir costos en cuanto a construcción de software. Su piedra angular de funcionamiento radica en seguir una serie de valores y principios de trabajo en equipo que fueron definidos en el manifiesto ágil, mismo que fue seguido por el advenimiento de las metodologías que hemos expuesto en este trabajo, así como muchas otras. Una palabra clave del modus operandi en la mayoría de metodologías, un común denominador, es el hecho de que siempre se trabaja en equipo y existe casi siempre una comunicación estrecha con quienes lo conforman. Asimismo, debe notarse que la conexión con el cliente y mantener bien definidos sus requerimientos, es la clave para crear productos funcionales y de valor que lo dejen satisfecho con el producto final, mediante entregas en periodos definidos que le muestren los avances de desarrollo. Cada metodología tiene sus particularidades y su enfoque: SCRUM se orienta al trabajo por objetivos, XP opta por trabajar manteniendo un enfoque al código fuente al igual que Crystal, Kanban es reconocido por conocer y mejorar los procesos actuales de construcción, con esto podemos concluir que estas metodologías nos brindan una manera más eficiente y organizada de realizar proyectos de software, que al ser un producto 59
intangible requieren una estructuración más organizada del proceso de construcción del producto además de una cercanía y apego a las necesidades de los clientes. Al final el único que decide qué paradigma seguir -- dejarse guiar por el trabajo colaborativo y comunicativo o seguir una serie de reglas inflexibles -- es el mismo equipo de trabajo que toma decisiones con base en los resultados y rendimiento que les brinda todo el universo de metodologías de desarrollo. Es decir, estas metodologías son una guía y marco de trabajo que son escalables y adaptables a la infinidad de tipos de proyectos que existen en la industria de las tecnologías de la información. De ahí su importancia como instrumento de trabajo y que toda persona relacionada con el área de las tecnologías de la información (en especial la administración de proyectos) debe tener presente como herramienta eficiente para crear productos informáticos de valor y con un alto grado de calidad.
GLOSARIO Backlog: Lista priorizada de características donde se plasman las actividades
más importantes.
60
Coaching: Método que consiste en acompañar, instruir y entrenar a una persona
o a un grupo de ellas, con el objetivo de conseguir cumplir metas o desarrollar habilidades específicas. Cliente: Elemento principal en un proyecto de programación extrema, es aquel
que inicia las historias de usuarios y por ende el proyecto. CMMI: Capability Maturity Model Integration o Integración de modelos de madurez
de capacidades. Es un modelo para la mejora y evaluación de procesos para el desarrollo, mantenimiento y operación de sistemas de software. Criticalidad: La calidad, estado o grado de ser de alta importancia. Casos de uso: Los casos de uso se crean para refinar un conjunto de requisitos
de acuerdo con una función o tarea. Los casos de uso definen qué harán los usuarios o funciones en la solución y un proceso empresarial define cómo realizarán esas funciones. Diagrama de Gantt: Es una popular herramienta gráfica cuyo objetivo es mostrar
el tiempo de dedicación previsto para diferentes tareas o actividades a lo largo de un tiempo total determinado. Existencialismo: Corriente filosófica europea que considera que la cuestión
fundamental en el ser es la existencia, en cuanto existencia humana, y no la esencia, y que respecto al conocimiento es más importante la vivencia subjetiva que la objetividad. Estándares de Codificación : En Programación Extrema es un conjunto de reglas
para la programación y documentación del sistema. Encargado de Seguimiento: En programación extrema, es el encargado de dar
retroalimentación al equipo, verifica el grado de acierto de las iteraciones. Framework: un conjunto estandarizado de conceptos, prácticas y criterios para
enfocar un tipo de problemática particular que sirve como referencia, para enfrentar y resolver nuevos problemas de índole similar. Failover: La conmutación por error, o failover, es un modo de funcionamiento de
respaldo en el que las funciones de un componente de sistema son asumidas por componentes del sistema secundario cuando el componente principal no está disponible ya sea debido a una falla o por el tiempo de inactividad programado. Grooming: actividad en la cual se definen, estiman y priorizan los ítems del
backlog. 61
Historia de Usuario: Artefacto de identificación de requerimientos utilizado en la
fase inicial de programación extrema. Iteración: Ciclo de producción de software más pequeño en un proyecto de
programación extrema. Iterativo: Término que indica una acción repetitiva. Lean Manufacturing: Es un modelo de gestión enfocado a la creación de flujo
para poder entregar el máximo valor para los clientes, utilizando para ello los mínimos recursos necesarios: es decir ajustados. Metáfora: En Programación Extrema, es el concepto global del sistema a
implementar. Mainframe: Computadora grande, poderosa y costosa utilizada principalmente en
empresas que necesitan procesar gran cantidad de datos o soportar gran cantidad de usuarios. Planning Poker: Es una técnica para calcular una estimación basada en el
consenso, en su mayoría utilizada para estimar el esfuerzo o el tamaño relativo de las tareas de desarrollo de software. PMI: El Project Management Institute (PMI) es una organización internacional sin
fines de lucro que asocia a profesionales relacionados con la Gestión de Proyectos. Plan de Entrega: Cronograma acordado entre clientes y equipo de desarrollo, en
el que se fija una fecha para la liberación del sistema. Plan de Iteraciones: Cronograma de actividades para que el equipo de desarrollo
libere una característica del sistema. Scrum Alliance: Organización que desarrolla y difunde marcos de Scrum para
trasladar al sector TIC la forma de trabajo ágil, iterativo e incremental Teoría General de los Sistemas: Es el estudio interdisciplinario de los sistemas,
en general, con el propósito de dilucidar los principios que pueden ser aplicados a todo tipo de sistemas en todos los niveles anidados en todos los campos de la investigación. The Principles of Scientific Management: Es una monografía publicada por
Frederick Winslow Taylor en 1911, la cual ordenó los principios de la administración científica, es un texto trascendental de la organización moderna y teoría de la decisión que ha motivado a estudiantes y administradores acerca de la técnica administrativa. 62
Stakeholders: Personas involucradas en un proyecto o en una empresa. Tester: Persona encargada de realizar pruebas, revisar estándares y
normatividades en el software. WIP: Del inglés “Work In Progress”, es un material que se ha ingresado al proceso
de producción, pero aún no es un producto terminado.
FUENTES DE CONSULTA Stellman, A. & Greene, J. (2015). Learning Agile . United States of America, California: O'Reilly Media, Inc.
63
Cockburn, A. (2004). Crystal Clear: A human powered Methodology for small teams including The Seven Properties of Effective Software Projects. Humans and Technology. Satpathy, T. (2016). Una guía para el CONOCIMIENTO DE SCRUM GUÍA SBOK. Editorial Scrum Study. Davies, R. & Sedley, L. (2013). Agile Coaching. EUA: Pragmatic Bookshelf. Smith & Sidky. (2013). Becoming Agile in an imperfect world, EUA: Editorial Manning. Stellman & Greene. (2015). Learning Agile: Understanding SCRUM, XP, LEAN, and KANBAN. EUA: Editorial O’Reilly. Fusi, J. (2013). Breve Historia del mundo contemporáneo. España: Editorial Galaxia Gutenberg. Rubin, K. (2013). Essential Scrum: A practical guide to the most popular agile process. EUA: Editorial Pearson. Sutherland, J. (2012). The Scrum Handbook. EUA: Editorial Scrum Inc. Schwaber & Sutherland. (2013). La guía de Scrum. Traducción al español. EUA: Editorial Scrum Inc. Kniberg, H. (2007). Scrum y XP desde las trincheras: Como hacemos Scrum. Traducción al español. EUA. Palacio, J. (2014). Gestión de Proyectos Scrum Manager. Argentina: Editorial Creative Commons. Loayza Salazar, D. (2010). Método para elección de una metodología ágil híbrida en una MYPE desarrolladora de software, caso práctico: elección de SCRUM y XP en la empresa AQSOFT. Licenciatura. Universidad Nacional Mayo de San Marcos. 64
Bühler, E (2014). 7 lugares donde obtener tu certificación Agile/Scrum. Recuperado
de:
https://agilib.org/2014/02/05/7-lugares-donde-obtener-tu-
certificacion-agilescrum/ Beck, K. (2000). Extreme programming eXplained. Reading, MA: Editorial AddisonWesley. Cockbun, A. & Williams, L. (2000). The Costs and Benefits of Pair Programming. Humans and Technology Technical Report. Fowler,
M.
(2001).
Is
Design
Dead?
Recuperado
de:
www.martinfowler.com/articles/designDead.html acobson, I. (1994). Object-Oriented Software Engineering. Editorial Addisonesley. Newkirk, J. & Martin R. (2001). Extreme Programming in Practice. Editorial Addison-Wesley. Cobb, C. (2016). What kind of projects are the best to use extreme programming? Recuperado de: https://www.quora.com/What-kind-of-projects-are-the-best-to-useextreme-programming/answer/Chuck-Cobb3?__snids__=1623331793&__nsrc__=1&__filter__=all. Fernández, J. (2016). Introducción a las metodologías ágiles Otras formas de analizar y desarrollar. Recuperado de: https://www.exabyteinformatica.com/uoc/Informatica/Tecnicas_avanzadas_de_ing enieria_de_software/Tecnicas_avanzadas_de_ingenieria_de_software_(Modulo_3 ).pdf Rumpe, B. & Schröder, A. (2002). Quantitative Survey on Extreme Programming Projects. Munich University of Technology: Software & Systems Engineering, Search Data Center, 2016, "Encuesta de VersionOne muestra cómo está el desarrollo
ágil
en
2015",
recuperado
de
http://searchdatacenter.techtarget.com/es/foto-articulo/4500252735/Encuesta-de65
VersionOne-muestra-como-esta-el-desarrollo-agil-en-2015/5/Que-tal-popular-esel-proceso-Scrum Centro de Innovación BBVA, 2016, "Tendencias tecnológicas en 2016", recuperado
de
http://www.centrodeinnovacionbbva.com/noticias/tendencias-
tecnologicas-en-2016#sthash.sqj4gCgl.dpuf Search Data Center, 2016, "Habilidades del desarrollador de software para el futuro
programador
de
ensueño",
recuperado
de
http://searchdatacenter.techtarget.com/es/cronica/Habilidades-del-desarrolladorde-software-para-el-futuro-programador-de-ensueno Gurú Software, 2015, "Estudio de Salarios del 2015", recuperado de http://sg.com.mx/revista/50/estudio-salarios-sg-2015#.VzscEN9ysf4
TABLERO DEL EQUIPO CARLO -Capítulo 2
IRAM
KIKE
FERNANDO
FELIX
-Realización
-Capturo V 66
