Chapter 3 – Agile Software

Development
Lecture 1

Lectura 1

1
Topicos cubiertos
• Métodos ágiles
• Desarrollo ágil y basado en planes.
• Programación extrema
• Gestión de proyectos ágiles
• Escalando métodos ágiles
Desarrollo de software rapido
• El desarrollo rápido y entrega ahora es a menudo el requisito más importante para los
sistemas de software.
• Las empresas operan con un requisito de cambio rápido y es prácticamente imposible
producir un conjunto de requisitos de software estables.
• El software tiene que evolucionar rápidamente para reflejar las cambiantes necesidades
comerciales.
• Desarrollo rápido de software
• Las especificaciones, el diseño y la implementación están entrelazados
• El sistema se desarrolla como una serie de versiones con partes interesadas involucradas
en la evaluación de versiones
• Las interfaces de usuario a menudo se desarrollan utilizando un IDE y un conjunto de
herramientas gráficas.
Métodos ágiles
• La insatisfacción con los gastos generales involucrados en los métodos de
diseño de software de los años ochenta y noventa condujo a la creación de
métodos ágiles. Estos métodos:
• Centrarse en el código en lugar del diseño
• Se basan en un enfoque iterativo para el desarrollo de software.
• Están destinados a entregar software de trabajo rápidamente y
evolucionar esto rápidamente para cumplir con los requisitos cambiantes.
• El objetivo de los métodos ágiles es reducir los gastos generales en el
proceso del software (por ejemplo, limitando la documentación) y poder
responder rápidamente a los requisitos cambiantes sin un trabajo excesivo
Manifiesto ágil
• Estamos descubriendo mejores formas de desarrollar software
haciéndolo y ayudando a otros a hacerlo. A través de este trabajo
hemos llegado a valorar:
• Individuos e interacciones sobre procesos y herramientas Software de
trabajo sobre documentación integral Colaboración del cliente sobre
negociación de contratos Responder al cambio sobre seguir un plan
• Es decir, si bien hay valor en los elementos de la derecha, valoramos
más los elementos de la izquierda.
Los principios de los métodos ágiles
• Involucramiento del cliente :
• Los clientes deben participar estrechamente en todo el proceso de desarrollo. Su función es proporcionar y priorizar los
nuevos requisitos del sistema y evaluar las iteraciones del sistema.
• Entrega incremental:
• El software se desarrolla en incrementos con el cliente especificando los requisitos que se incluirán en cada incremento.
• La gente no procesa:
• Las habilidades del equipo de desarrollo deben ser reconocidas y explotadas. Se debe dejar que los miembros del equipo
desarrollen sus propias formas de trabajo sin procesos prescriptivos.
• Aceptar el cambio:
• Espere que los requisitos del sistema cambien y, por lo tanto, diseñe el sistema para acomodar estos cambios.
• Mantener la simplicidad:
• Concéntrese en la simplicidad tanto en el software que se está desarrollando como en el proceso de desarrollo. Siempre
que sea posible, trabaje activamente para eliminar la complejidad del sistema
Aplicabilidad de los métodos ágiles
• Desarrollo de productos donde una compañía de software está
desarrollando un producto pequeño o mediano para la venta.
• Desarrollo de sistemas personalizados dentro de una organización,
donde existe un compromiso claro del cliente para involucrarse en el
proceso de desarrollo y donde no hay muchas reglas y regulaciones
externas que afecten el software.
• Debido a su enfoque en equipos pequeños y estrechamente
integrados, existen problemas para escalar métodos ágiles a sistemas
grandes
Problemas con los métodos ágiles
• Puede ser difícil mantener el interés de los clientes que participan en
el proceso.
• Los miembros del equipo pueden ser inadecuados para la intensa
participación que caracteriza los métodos ágiles.
• Dar prioridad a los cambios puede ser difícil cuando hay múltiples
partes interesadas.
• Mantener la simplicidad requiere un trabajo extra.
• Los contratos pueden ser un problema como con otros enfoques para
el desarrollo iterativo.
Métodos ágiles y mantenimiento del
software
• La mayoría de las organizaciones gastan más en el mantenimiento del software
existente que en el desarrollo de software nuevo. Por lo tanto, para que los
métodos ágiles sean exitosos, deben soportar el mantenimiento y el desarrollo
original.
• Dos cuestiones clave:
• ¿Se pueden mantener los sistemas que se desarrollan utilizando un enfoque ágil,
dado el énfasis en el proceso de desarrollo de minimizar la documentación formal?
• ¿Se pueden usar métodos ágiles de manera efectiva para desarrollar un sistema en
respuesta a las solicitudes de cambio de los clientes?
• Pueden surgir problemas si no se puede mantener el equipo de desarrollo original.
Desarrollo ágil impulsado por plan
• Desarrollo impulsado por el plan
• Un enfoque basado en planes para la ingeniería de software se basa en etapas
de desarrollo separadas con los resultados que se producirán en cada una de
estas etapas planificadas de antemano.
• No necesariamente un modelo en cascada: es posible un desarrollo incremental
basado en planes
• La iteración ocurre dentro de las actividades.
• Desarrollo ágil
• La especificación, el diseño, la implementación y las pruebas se entrelazan y los
resultados del proceso de desarrollo se deciden mediante un proceso de
negociación durante el proceso de desarrollo de software.
Desarrollo ágil impulsado por plan
Problemas técnicos, humanos,
organizativos.
• La mayoría de los proyectos incluyen elementos de procesos ágiles y basados en planes.
Decidir sobre el saldo depende de:
• ¿Es importante tener una especificación y un diseño muy detallados antes de pasar a la
implementación? Si es así, probablemente necesite usar un enfoque basado en un plan.
• ¿Es realista una estrategia de entrega incremental, en la que entregas el software a los
clientes y obtienes retroalimentación rápida de ellos? Si es así, considere usar métodos
ágiles.
• ¿Qué tan grande es el sistema que se está desarrollando? Los métodos ágiles son más
efectivos cuando el sistema se puede desarrollar con un pequeño equipo de ubicación
conjunta que puede comunicarse informalmente. Es posible que esto no sea posible
para sistemas grandes que requieren equipos de desarrollo más grandes, por lo que
puede ser necesario utilizar un enfoque basado en un plan.
Problemas técnicos, humanos,
organizativos
• ¿Qué tipo de sistema se está desarrollando?
• Se pueden requerir enfoques basados en planes para sistemas que requieren mucho análisis antes
de la implementación (por ejemplo, sistema en tiempo real con requisitos de tiempo complejos).
• ¿Cuál es la vida útil esperada del sistema?
• Los sistemas de larga duración pueden requerir más documentación de diseño para comunicar las
intenciones originales de los desarrolladores del sistema al equipo de soporte.
• ¿Qué tecnologías están disponibles para apoyar el desarrollo del sistema?
• Los métodos ágiles se basan en buenas herramientas para realizar un seguimiento de un diseño en
evolución.
• ¿Cómo se organiza el equipo de desarrollo?
• Si el equipo de desarrollo se distribuye o si parte del desarrollo se subcontrata, es posible que
necesite desarrollar documentos de diseño para comunicarse entre los equipos de desarrollo.
Problemas técnicos, humanos,
organizativos
• Existen problemas culturales u organizativos que pueden afectar el desarrollo del sistema?
• Las organizaciones de ingeniería tradicionales tienen una cultura de desarrollo basado en
planes, ya que esta es la norma en ingeniería.
• ¿Qué tan buenos son los diseñadores y programadores en el equipo de desarrollo?
•   A veces se argumenta que los métodos ágiles requieren mayores niveles de habilidad que
los enfoques basados en planes en los que los programadores simplemente traducen un
diseño detallado en código
• ¿El sistema está sujeto a regulación externa?
• Si un sistema tiene que ser aprobado por un regulador externo (por ejemplo, el software de
aprobación de la FAA que es crítico para la operación de una aeronave), probablemente se
le solicitará que presente documentación detallada como parte del caso de seguridad del
sistema.
Programación extrema
• Quizás el método ágil más conocido y más utilizado.
• Extreme Programming (XP) adopta un enfoque "extremo" para el
desarrollo iterativo.
• Se pueden construir nuevas versiones varias veces al día;
• Los incrementos se entregan a los clientes cada 2 semanas;
• Todas las pruebas deben ejecutarse para cada compilación y la
compilación solo se acepta si las pruebas se ejecutan correctamente.
XP y principios ágiles
• El desarrollo incremental es compatible a través de lanzamientos de
sistema pequeños y frecuentes.
• La participación del cliente significa el compromiso del cliente a
tiempo completo con el equipo.
• Las personas no procesan a través de la programación en pareja, la
propiedad colectiva y un proceso que evita largas horas de trabajo.
• Cambio admitido a través de versiones regulares del sistema.
• Mantener la simplicidad a través de la refactorización constante del
código.
El ciclo de lanzamiento de
programación extrema
Prácticas de programación extremas
(a)
• Planificación incremental
• Los requisitos se registran en las tarjetas de historias y las historias que se incluirán en un lanzamiento están
determinadas por el tiempo disponible y su relativa prioridad. Los desarrolladores dividen estas historias en
"Tareas" de desarrollo. Ver Figuras 3.5 y 3.6.
• Pequeños lanzamientos
• Primero se desarrolla el conjunto útil mínimo de funcionalidades que proporciona valor comercial. Las
versiones del sistema son frecuentes y agregan gradualmente funcionalidad a la primera versión.
• Diseño simple
• Suficiente diseño se lleva a cabo para cumplir con los requisitos actuales y no más.
• Prueba de primer desarrollo
• Se utiliza un marco de prueba de unidad automatizado para escribir pruebas para una nueva pieza de
funcionalidad antes de que se implemente esa funcionalidad.
• Refactorización
• Se espera que todos los desarrolladores refactoricen el código continuamente tan pronto como se
encuentren posibles mejoras en el código. Esto mantiene el código simple y mantenible.
Prácticas de programación extremas
(b)
• Programación en pareja
• Los desarrolladores trabajan en parejas, verifican el trabajo de los demás y brindan el apoyo para hacer siempre un buen trabajo.
• Propiedad colectiva
• Los pares de desarrolladores trabajan en todas las áreas del sistema, por lo que no se desarrollan islas de experiencia y todos los
desarrolladores se hacen responsables de todo el código. Cualquiera puede cambiar cualquier cosa.
• Integración continua
• Tan pronto como se completa el trabajo en una tarea, se integra en todo el sistema. Después de dicha integración, todas las pruebas
unitarias en el sistema deben pasar.
• Marcha sostenible
• Grandes cantidades de horas extras no se consideran aceptables ya que el efecto neto es a menudo reducir la calidad del código y la
productividad a mediano plazo.
• Cliente en el sitio
• Un representante del usuario final del sistema (el cliente) debe estar disponible a tiempo completo para el uso del equipo de XP. En un
proceso de programación extremo, el cliente es miembro del equipo de desarrollo y es responsable de llevar los requisitos del sistema al
equipo para su implementación.
Escenarios de requisitos

• En XP, un cliente o usuario es parte del equipo de XP y es responsable

de tomar decisiones sobre los requisitos.
• Los requisitos del usuario se expresan como escenarios o historias de
usuarios.
• Estos están escritos en tarjetas y el equipo de desarrollo los divide en
tareas de implementación. Estas tareas son la base del cronograma y
las estimaciones de costos.
• El cliente elige las historias para incluirlas en la próxima versión en
función de sus prioridades y las estimaciones de programación.
Una historia de "prescripción de
medicamentos"
Ejemplos de tarjetas de tareas para
prescribir medicamentos.
XP y cambio

• La sabiduría convencional en ingeniería de software es diseñar para el

cambio. Vale la pena gastar tiempo y esfuerzo anticipando los
cambios, ya que esto reduce los costos más adelante en el ciclo de
vida.
• Sin embargo, XP mantiene que esto no vale la pena, ya que los
cambios no se pueden anticipar de manera confiable.
• Más bien, propone una mejora constante del código (refactorización)
para facilitar los cambios cuando tienen que implementarse.
Refactorización
• El equipo de programación busca posibles mejoras de software y
realiza estas mejoras incluso cuando no hay necesidad inmediata de
ellas.
• Esto mejora la comprensión del software y, por lo tanto, reduce la
necesidad de documentación.
• Los cambios son más fáciles de realizar porque el código está bien
estructurado y es claro.
• Sin embargo, algunos cambios requieren una refactorización de la
arquitectura y esto es mucho más costoso.
Ejemplos de refactorización
• Reorganización de una jerarquía de clases para eliminar el código
duplicado.
• Poner en orden y renombrar atributos y métodos para que sean más
fáciles de entender.
• La sustitución del código en línea con llamadas a métodos que se han
incluido en una biblioteca de programas.
Puntos Claves
• Los métodos ágiles son métodos de desarrollo incremental que se centran
en el desarrollo rápido, lanzamientos frecuentes del software, reducen los
gastos generales del proceso y producen código de alta calidad. Involucran
al cliente directamente en el proceso de desarrollo.
• La decisión de utilizar un enfoque de desarrollo ágil o basado en un plan
debe depender del tipo de software que se desarrolle, las capacidades del
equipo de desarrollo y la cultura de la empresa que desarrolla el sistema.
• La programación extrema es un método ágil bien conocido que integra
una gama de buenas prácticas de programación, como lanzamientos
frecuentes del software, mejora continua del software y participación del
cliente en el equipo de desarrollo.
Chapter 3 – Agile Software
Development
• Lecture 2
Prueba en XP
• Las pruebas son fundamentales para XP y XP ha desarrollado un
enfoque en el que el programa se prueba después de cada cambio
realizado.
• Funciones de prueba de XP:
• Prueba de primer desarrollo.
• Desarrollo de pruebas incrementales a partir de escenarios.
• Participación del usuario en el desarrollo y validación de pruebas.
• Los arneses de prueba automatizados se utilizan para ejecutar todas
las pruebas de componentes cada vez que se crea una nueva versión.
Test-first development
• Escribir pruebas antes del código aclara los requisitos que se
implementarán.
• Las pruebas se escriben como programas en lugar de datos para que
puedan ejecutarse automáticamente. La prueba incluye una
verificación de que se ha ejecutado correctamente.
• Por lo general, se basa en un marco de prueba como Junit.
• Todas las pruebas anteriores y nuevas se ejecutan automáticamente
cuando se agrega una nueva funcionalidad, verificando así que la
nueva funcionalidad no haya introducido errores.
Involucramiento del cliente
• El papel del cliente en el proceso de prueba es ayudar a desarrollar
pruebas de aceptación para las historias que se implementarán en la
próxima versión del sistema.
• El cliente que forma parte del equipo escribe pruebas a medida que
avanza el desarrollo. Por lo tanto, todo el código nuevo se valida para
garantizar que sea lo que el cliente necesita.
• Sin embargo, las personas que adoptan el rol de cliente tienen un tiempo
limitado disponible y, por lo tanto, no pueden trabajar a tiempo completo
con el equipo de desarrollo. Pueden sentir que proporcionar los
requisitos fue una contribución suficiente y, por lo tanto, pueden ser
reacios a involucrarse en el proceso de prueba.
Descripción del caso de prueba para el
control de dosis
Prueba de automatización

• La automatización de pruebas significa que las pruebas se escriben como

componentes ejecutables antes de implementar la tarea
• Estos componentes de prueba deben ser independientes, deben simular el envío
de la entrada a probar y deben verificar que el resultado cumpla con las
especificaciones de salida. Un marco de prueba automatizado (por ejemplo, Junit)
es un sistema que facilita la escritura de pruebas ejecutables y el envío de un
conjunto de pruebas para su ejecución.
• Como las pruebas están automatizadas, siempre hay un conjunto de pruebas que
pueden ejecutarse rápida y fácilmente
• Cada vez que se agrega alguna funcionalidad al sistema, las pruebas se pueden
ejecutar y los problemas que ha introducido el nuevo código se pueden detectar
de inmediato.
Dificultades de prueba de XP

• Los programadores prefieren programar a las pruebas y, a veces, toman

atajos al escribir pruebas. Por ejemplo, pueden escribir pruebas
incompletas que no verifican todas las posibles excepciones que puedan
ocurrir.
• Algunas pruebas pueden ser muy difíciles de escribir de forma
incremental. Por ejemplo, en una interfaz de usuario compleja, a menudo
es difícil escribir pruebas unitarias para el código que implementa la
"lógica de visualización" y el flujo de trabajo entre pantallas.
• Es difícil juzgar la integridad de un conjunto de pruebas. Aunque es posible
que tenga muchas pruebas del sistema, su conjunto de pruebas puede no
proporcionar una cobertura completa.
Programación en pareja

• En XP, los programadores trabajan en parejas, sentados juntos para

desarrollar código.
• Esto ayuda a desarrollar la propiedad común del código y difunde el
conocimiento en todo el equipo.
• Sirve como un proceso de revisión informal ya que cada línea de código es
vista por más de 1 persona.
• Fomenta la refactorización ya que todo el equipo puede beneficiarse de esto.
• Las mediciones sugieren que la productividad del desarrollo con la
programación de pares es similar a la de dos personas que trabajan
independientemente..
Programación en pareja
• En la programación por pares, los programadores se sientan juntos en
la misma estación de trabajo para desarrollar el software.
• Los pares se crean dinámicamente para que todos los miembros del
equipo trabajen entre sí durante el proceso de desarrollo.
• El intercambio de conocimiento que ocurre durante la programación
de pares es muy importante ya que reduce los riesgos generales para
un proyecto cuando los miembros del equipo se van.
• La programación de pares no es necesariamente ineficiente y existe
evidencia de que un par que trabaja en conjunto es más eficiente que
2 programadores que trabajan por separado.
Ventajas de la programación de
pares
• Apoya la idea de propiedad colectiva y responsabilidad del sistema.
• Las personas no se hacen responsables de los problemas con el código. En
cambio, el equipo tiene la responsabilidad colectiva de resolver estos
problemas.
• Actúa como un proceso de revisión informal porque cada línea de código es
vista por al menos dos personas.
• Ayuda a admitir la refactorización, que es un proceso de mejora del software.
• Cuando se utiliza la programación de pares y la propiedad colectiva, otros se
benefician inmediatamente de la refactorización, por lo que es probable que
respalden el proceso.
Gestión de proyectos ágiles

• La responsabilidad principal de los gerentes de proyectos de software

es administrar el proyecto para que el software se entregue a tiempo
y dentro del presupuesto planificado para el proyecto.
• El enfoque estándar para la gestión de proyectos se basa en planes.
Los gerentes elaboran un plan para el proyecto que muestra qué se
debe entregar, cuándo se debe entregar y quién trabajará en el
desarrollo de los entregables del proyecto.
• La gestión ágil de proyectos requiere un enfoque diferente, que se
adapta al desarrollo incremental y las fortalezas particulares de los
métodos ágiles.
Scrum
• El enfoque Scrum es un método ágil general, pero se centra en gestionar el
desarrollo iterativo en lugar de prácticas ágiles específicas.
• Hay tres fases en Scrum.
• La fase inicial es una fase de planificación del esquema donde establece los
objetivos generales para el proyecto y diseña la arquitectura del software.
• Esto es seguido por una serie de ciclos de sprint, donde cada ciclo desarrolla
un incremento del sistema.
• La fase de cierre del proyecto concluye el proyecto, completa la
documentación requerida, como los marcos de ayuda del sistema y los
manuales de usuario, y evalúa las lecciones aprendidas del proyecto.
Proceso del Scrum
El ciclo de sprint

• Los sprints son de duración fija, normalmente de 2 a 4 semanas.

Corresponden al desarrollo de una versión del sistema en XP.
• El punto de partida para la planificación es el trabajo atrasado del
producto, que es la lista de trabajo a realizar en el proyecto.
• La fase de selección involucra a todo el equipo del proyecto que
trabaja con el cliente para seleccionar las características y
funcionalidades que se desarrollarán durante el sprint.
El ciclo de sprint

• Una vez que se acuerdan, el equipo se organiza para desarrollar el

software. Durante esta etapa, el equipo está aislado del cliente y de la
organización, y todas las comunicaciones se canalizan a través del
llamado "Scrum master".
• El papel del Scrum Master es proteger al equipo de desarrollo de
distracciones externas.
•   Al final del sprint, el trabajo realizado se revisa y se presenta a las
partes interesadas. Entonces comienza el siguiente ciclo de sprint
Trabajo en equipo en Scrum

• El "Scrum master" es un facilitador que organiza reuniones diarias, rastrea

el trabajo atrasado que se debe realizar, registra las decisiones, mide el
progreso contra el trabajo atrasado y se comunica con los clientes y la
administración fuera del equipo.
• Todo el equipo asiste a breves reuniones diarias donde todos los
miembros del equipo comparten información, describen su progreso
desde la última reunión, los problemas que han surgido y lo que está
planeado para el día siguiente.
• Esto significa que todos en el equipo saben lo que está sucediendo y, si
surgen problemas, pueden volver a planificar el trabajo a corto plazo para
hacerles frente.
Beneficios del Scrum
• El producto se divide en un conjunto de fragmentos manejables y
comprensibles.
• Los requisitos inestables no retrasan el progreso.
• Todo el equipo tiene visibilidad de todo y, en consecuencia, se mejora
la comunicación del equipo.
• Los clientes ven la entrega puntual de los incrementos y obtienen
comentarios sobre cómo funciona el producto.
• Se establece la confianza entre clientes y desarrolladores y se crea una
cultura positiva en la que todos esperan que el proyecto tenga éxito.
Escalando métodos ágiles

• Los métodos ágiles han demostrado ser exitosos para proyectos

pequeños y medianos que pueden ser desarrollados por un pequeño
equipo de ubicación conjunta.
• A veces se argumenta que el éxito de estos métodos se debe a la
mejora de las comunicaciones, que es posible cuando todos trabajan
juntos.
• Ampliar los métodos ágiles implica cambiarlos para hacer frente a
proyectos más grandes y más largos donde hay múltiples equipos de
desarrollo, tal vez trabajando en diferentes ubicaciones
Desarrollo de grandes sistemas.

• Los sistemas grandes suelen ser colecciones de sistemas de comunicación

separados, donde equipos separados desarrollan cada sistema. Con
frecuencia, estos equipos trabajan en diferentes lugares, a veces en
diferentes zonas horarias.
• Los sistemas grandes son "sistemas brownfield", es decir, incluyen e
interactúan con varios sistemas existentes. Muchos de los requisitos del
sistema están relacionados con esta interacción y, por lo tanto, no se
prestan realmente a la flexibilidad y al desarrollo incremental.
• Cuando se integran varios sistemas para crear un sistema, una fracción
significativa del desarrollo se refiere a la configuración del sistema en
lugar del desarrollo del código original
Desarrollo de grandes sistemas.

• Los sistemas grandes y sus procesos de desarrollo a menudo están

limitados por reglas y regulaciones externas que limitan la forma en
que pueden desarrollarse.
• Los sistemas grandes tienen un largo tiempo de adquisición y
desarrollo. Es difícil mantener equipos coherentes que conozcan el
sistema durante ese período ya que, inevitablemente, las personas
pasan a otros trabajos y proyectos.
• Los sistemas grandes generalmente tienen un conjunto diverso de
partes interesadas. Es prácticamente imposible involucrar a todos
estos diferentes interesados en el proceso de desarrollo.
Escalando y escalando

• La ampliación de escala "se refiere al uso de métodos ágiles para

desarrollar grandes sistemas de software que no pueden ser
desarrollados por un equipo pequeño.
• La "ampliación" se refiere a cómo se pueden introducir métodos ágiles
en una gran organización con muchos años de experiencia en
desarrollo de software.
• Al escalar métodos ágiles, es esencial mantener los fundamentos ágiles
• Planificación flexible, lanzamientos frecuentes del sistema, integración
continua, desarrollo basado en pruebas y buenas comunicaciones de
equipo.
 Escalado a sistemas grandes

• Escalado a sistemas grandes

• Para el desarrollo de sistemas grandes, no es posible centrarse solo en el código
del sistema. Necesita hacer más diseño inicial y documentación del sistema
• Los mecanismos de comunicación entre equipos deben diseñarse y utilizarse.
Esto debería involucrar conferencias telefónicas y de video regulares entre los
miembros del equipo y reuniones electrónicas breves y frecuentes donde los
equipos se actualizan entre sí sobre el progreso.
• La integración continua, donde todo el sistema se construye cada vez que
cualquier desarrollador registra un cambio, es prácticamente imposible. Sin
embargo, es esencial mantener versiones frecuentes del sistema y versiones
periódicas del sistema.
Escalar a grandes empresas

• Los gerentes de proyecto que no tienen experiencia en métodos ágiles pueden ser
reacios a aceptar el riesgo de un nuevo enfoque.
• Las grandes organizaciones a menudo tienen procedimientos y estándares de
calidad que se espera que todos los proyectos sigan y, debido a su naturaleza
burocrática, es probable que sean incompatibles con los métodos ágiles.
• Los métodos ágiles parecen funcionar mejor cuando los miembros del equipo
tienen un nivel de habilidad relativamente alto. Sin embargo, dentro de las
grandes organizaciones, es probable que haya una amplia gama de habilidades y
capacidades.
• Puede haber resistencia cultural a los métodos ágiles, especialmente en aquellas
organizaciones que tienen una larga historia de uso de procesos de ingeniería de
sistemas convencionales.
Puntos clave

• Una fortaleza particular de la programación extrema es el desarrollo

de pruebas automatizadas antes de que se cree una función de
programa. Todas las pruebas deben ejecutarse con éxito cuando se
integra un incremento en un sistema.
• El método Scrum es un método ágil que proporciona un marco de
gestión de proyectos. Se centra alrededor de un conjunto de sprints,
que son períodos de tiempo fijos cuando se desarrolla un incremento
del sistema.
• Escalar métodos ágiles para sistemas grandes es difícil. Los sistemas
grandes necesitan un diseño inicial y algo de documentación.