METODOLOGÍAS ÁGILES
UNIDAD Nº I
Principios de agilidad.
www.iplacex.cl
SEMANA 1
Introducción
Desde hace varios años las empresas y áreas de desarrollo de software están con la doble
presión de entregar productos de software lo más rápido posible, pero sin descuidar la calidad
(Sommerville, 2011). Si bien la ingeniería de software ha ido evolucionando desde los años
sesenta aún está en una etapa temprana de madurez y continúa evaluando nuevos enfoques y
formas de desarrollo.
Desde el inicio del nuevo siglo se ha ido consolidando una nueva orientación: la Agilidad,
misma que promete la entrega de software de alto valor para el negocio, pero en ciclos de
desarrollo más breves. Para esto, esta nueva orientación enfatiza trabajar directamente con el
cliente a fin de para aprovechar rápidamente las oportunidades de negocio antes que la
competencia.
Como dichos negocios funcionan en un entorno cambiante, es muy difícil identificar al inicio del
proyecto todos los requerimientos que sean necesarios. Asumiendo esta limitación la agilidad
trabaja con requerimientos que se definen y priorizan directamente por los clientes,
construyendo el software que los implementa en pocas semanas. Esta cualidad permite una
rápida adaptación a la situación lo que ha llevado a utilizar el concepto de agilidad.
Trabajar con los requerimientos priorizados permite también que el software sea probado y
madure de forma natural mientras se desarrolla el proyecto.
Los métodos ágiles son métodos de desarrollo incremental, es decir con la entrega rápida al
cliente de funcionalidad probada. Al involucrar a los clientes en el proceso se obtiene una rápida
retroalimentación sobre los requerimientos cambiantes. También minimizan la cantidad de
documentación con el uso de comunicaciones directas en vez de reuniones formales con
documentos escritos.
Durante este curso se estudiarán los conceptos de agilidad, aplicando el marco de trabajo Scrum
tanto en su enfoque grupal como en el escalamiento necesario para coordinar varios equipos.
2 www.iplacex.cl
Ideas Fuerza
La agilidad se basa en los siguientes principios, mismos que serán desarrollados en el curso
(Sommerville, 2011, p. 60):
1. Participación del cliente: Los clientes deben intervenir estrechamente durante el
proceso de desarrollo. Su función consiste en ofrecer y priorizar nuevos requerimientos
del sistema y evaluar las iteraciones de este.
2. Entrega incremental: El software se desarrolla en incrementos y el cliente especifica los
requerimientos que se van a incluir en cada uno.
3. Personas, no procesos: Tienen que reconocerse y aprovecharse las habilidades del
equipo de desarrollo. Debe permitirse a los miembros del equipo desarrollar sus propias
formas de trabajar sin procesos establecidos.
4. Adoptar el cambio: Esperar a que cambien los requerimientos del sistema y, de este
modo, diseñar el sistema para adaptar dichas modificaciones.
5. Mantener simplicidad: Enfocarse en la simplicidad tanto en el software a desarrollar
como en el proceso de desarrollo. Siempre que sea posible, trabajar de manera activa
para eliminar la complejidad del sistema.
3 www.iplacex.cl
Desarrollo
1.Principios de agilidad
Los principios de la agilidad parecen razonables y productivos y sin duda lo son. Entonces, ¿por
qué simplemente no se utilizan en todo ámbito desplazando todos los otros enfoques?
La razón es que obliga a trabajar en equipo si se quiere ser productivo. Esto quiere decir que se
debe desarrollar explícitamente el concepto de trabajo en equipo para que todos los integrantes
se sientan cómodos y de esa manera se coordinen y complementen. Este es, a mi manera de
ver, el principal desafío de la agilidad.
A continuación, se desarrollarán los principios de agilidad ya enunciados.
Participación del cliente
Este es considerado el punto diferenciador entre la agilidad y los enfoques desarrollados
previamente. Tradicionalmente se ve al cliente como la fuente de los requerimientos y alguien
con quien reunirse periódicamente. De hecho, no es infrecuente que el cliente postergue o
cancele reuniones debido a razones urgentes y justificadas. Esta situación de ver al cliente como
una persona externa al equipo de trabajo hace que el equipo de desarrolle tenga dificultades
para entender tanto el modelo como el lenguaje del negocio. Por este motivo la agilidad rompe el
esquema considerándolo como parte del equipo del proyecto. Obviamente que si no es posible
trabajar con el cliente (o un representante de él) todos los días de manera directa no es posible
utilizar la agilidad como enfoque de desarrollo.
Por ese motivo Richard Telleria plantea que:
“Siempre se ha dicho que la participación del cliente es clave en el desarrollo de un proyecto. Lo
sabemos y confirmamos por nuestra propia experiencia. Incluso el manifiesto ágil lo recoge en
uno de sus cuatro valores principales, e incluso va un poco más allá: “colaboración con el cliente
por encima de la negociación contractual”.
4 www.iplacex.cl
Y si vamos a dos de sus doce principios:
Nuestra mayor prioridad es satisfacer al cliente, mediante la entrega temprana y continua de
software con valor.
Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos
ágiles aprovechan el cambio, para proporcionar ventaja competitiva al cliente.
Todos tenemos en mente a algún cliente con el que nos ha tocado tratar, o que nos ha hecho
pensar qué tipo de cliente somos o hemos sido. Seguro que algunos nos acordamos del típico
cliente impertinente, que incluso en ocasiones podría parecer, por cuestiones
incomprensiblemente extrañas, ajeno al proyecto o interesado en que ni siquiera éste saliera
adelante. Por el contrario, otras veces “disfrutamos” de un cliente inquieto, que está literalmente
encima de nosotros y nos dificulta, lentifica o pervierte nuestra cadencia de trabajo. ¿Quién no
ha afirmado en alguna ocasión eso de…? “Si el cliente no nos molestara tanto, le podríamos
entregar su trabajo antes”.
Probablemente la mayoría se inclinaría por un cliente que se mueva entre estos dos extremos,
como seres humanos que somos cuando tenemos una cosa pensamos en la otra y viceversa.
Efectivamente, el cliente ideal debería estar pendiente del proyecto, pero, asimismo, ser muy
consciente del marco ágil en el que se encuentra. Y, por consiguiente, respetar la metodología
de principio a fin, que se dice muy fácil, pero es lo realmente complicado en una adopción Agile.
Aunque en ocasiones no lo parezca, el hecho de que el cliente intervenga aparentemente
cuando le viene en gana, no es siempre su culpa. Dicho de otro modo, tenemos mucho qué
hacer para educar, preferentemente evitar o minimizar este ruido. Imaginemos entonces que
tenemos un cliente educado, empático, inteligente, pero al que simplemente no le hemos
explicado nuestro marco de trabajo, no conoce nuestra filosofía ágil; incluso ni siquiera las
características del equipo. En este caso, bastante más común de lo deseable, estaríamos ante el
5 www.iplacex.cl
típico cliente que quiere resultados y valor, como es lo normal, pero que no le importa nada más.
Bueno, eso no es definitivo, pero es preferible que nos conozcamos todos, como un equipo al
completo y juguemos cada uno nuestro papel como tal.
Por ejemplo, supongamos que tenemos un proyecto con un cliente externo, que se comunica
con el equipo interno de una organización por medio del Product Owner 1. -Nótese esta
aclaración porque podría haber casos donde el propio cliente interno desempeña la labor de
Product Owner-. Como bien hemos mencionado antes, el cliente es una pieza fundamental en el
transcurso y futuro de nuestro proyecto. Así que tenemos que ayudarle a ser ágil, hacerle
sentirse ágil. Debemos educarle desde el comienzo del proyecto, desde el origen de este, donde
es clave su negociación con el Product Owner, en esa captura de requisitos, en esa construcción
del Product Roadmap o en esa definición del Release Planning2.
Vayamos a un escenario más concreto. Si estuviéramos utilizando Scrum o XP para un proyecto
de software, el cliente ya debería tener claro antes del comienzo de la primera iteración que:
Para cualquier cuestión, debe dirigirse al Product Owner y no al equipo de desarrollo.
Debe conocer y asumir que sus solicitudes de cambio y nuevas peticiones se aceptan, pero se
ejecutarán en próximas iteraciones, nunca en el transcurso de la presente y siempre teniendo en
cuenta la prioridad del Product Backlog.
Debe revisar continuamente, tener claras estas prioridades del proyecto y comunicarlo al
Product Owner, para que éste pueda ordenar el Backlog, que el equipo irá trabajando y
finalmente entregando en forma de valor.
1El Product Owner es el cliente o el representante del cliente en el proyecto.
2Se refiere al plan de entrega de los incrementos en el proyecto.
6 www.iplacex.cl
Será en la Demo o Review, una vez terminada la iteración, cuando podrá participar, dar su
opinión y solicitar sus nuevas peticiones, que el Product Owner traducirá en forma de historias
de usuario priorizadas para siguientes iteraciones.
En general, debe conocer y creer en el funcionamiento del equipo, su velocidad, y lo que es más
importante, y repetimos, respetar la metodología.
Y permítanme otro pequeño inciso sobre este “respetar la metodología” puesto que aquí
radica la verdadera dificultad. Este puede ser otro ejemplo en el que se afirma: “Sí, claro que
somos ágiles” o “Estamos usando Scrum, XP, Kanban…” pero no es nada más que un intento
que no se está llevando (correctamente) a cabo. Si el cliente no entiende, no quiere, no cree o
no hace uso de la metodología ágil, entendiendo sus valores y principios y llevándola a cabo,
estamos en uno de esos escenarios en el que nos planteamos: “¿Pero realmente somos ágiles?”
o algo así como “Pues yo hago Scrum y no funciona”. Por descontado que Scrum, no es sólo
poner papelitos en la pared. Ser ágil no significa únicamente celebrar diariamente las reuniones
stand up y poco más. De hecho, es completamente imposible aplicar Agile con un cliente que no
está verdaderamente comprometido, sin que participe en el proceso como se le debe exigir.
También es necesario tener en cuenta el tipo de cliente como profesional con el que estamos
tratando: más o menos técnico, más cercano o más distante, más o menos paciente. No tiene
nada que ver un experto tecnológicamente hablando, con un gestor financiero o un comercial.
En cualquier caso, lo realmente importante es conocerlo y hablar en su mismo idioma, y no me
refiero precisamente al lenguaje.
7 www.iplacex.cl
Este compromiso, negociación y trato prácticamente diario con nuestro cliente, dista mucho del
que tiene lugar en el tradicional Waterfall3, donde nos basamos en las fechas y en nuestros
diagramas a largo plazo, cuyo cumplimiento de hitos es realmente complicado en el tiempo,
sobre todo en el cambiante mundo del software. En Agile estamos potenciando esta relación
entre el cliente y equipo, haciéndola más cercana y humana. Es por ello, por lo que hacemos
especial énfasis en su fortalecimiento. Y aquí podríamos volver a pensar en el manifiesto ágil y
sus cuatro valores. Incluso sería preferible que esta relación fuese más allá de lo profesional,
conociendo así los gustos del cliente; hasta aficiones y forma de afrontar la vida, los problemas,
etc.
Sin embargo, sucede a menudo que lo vemos como un enemigo, y nada más lejos de la
realidad, tener al cliente como amigo es una garantía de éxito. Entrar en disputas, discusiones y
demás problemas nos lleva precisamente a desperdicio, desconfianza o falta de concentración y
esto no hace sino crear precedente en el futuro. Todos debemos remar en la misma dirección,
aplicando ineludiblemente la teoría y, como tal, debemos mimar el trato, no sólo con el equipo,
sino empezando por el cliente; pensando también en los usuarios de nuestro producto y, en
general, en todos los interesados de nuestro proyecto.
Como conclusión, espero humildemente haber hecho reflexionar a más de uno sobre los clientes
que conoce, tiene o ha tenido y cómo se ha comportado o tratado con ellos. Del mismo modo, a
mis queridos clientes, siempre ansiados al principio y algo más cuestionados después y, por
supuesto, a toda la comunidad ágil a la que me enorgullezco de pertenecer” (Telleria, 2019).
Entrega incremental
3Se refiere al primer modelo de desarrollo de software que se basa en la lógica de requerimientos
estables y definidos al inicio de proyecto.
8 www.iplacex.cl
Al trabajar directamente con el cliente, este espera recibir algo útil rápidamente. Cada una de
estas entregas funcionales se denomina incremento y corresponde a una parte de la solución
construida, probada, documentada e instalada que puede ser utilizada por el cliente de manera
inmediata. De ahí la importancia de priorizar los requerimientos para entregarle al cliente algo
que realmente le sirva.
El concepto es resumido en la siguiente imagen (Proyectosagiles.org, 2019):
Personas, no procesos
Como ya se mencionó la agilidad se apoya fuertemente en el equipo de desarrollo, mismo que
está formado por personas. Por esta razón se busca que ellos se apoyen y complementen,
logrando de esta manera aumentar la productividad y la calidad de lo que se construye. Al
respecto Darío Palminio indica que:
9 www.iplacex.cl
“En la planificación tradicional las personas son gestionadas como recursos, hasta cierto punto
intercambiables, individuales y especializados que siguen planes. Sin embargo, la productividad,
la calidad y la creatividad es mucho mayor si la gente que hace el trabajo también lo planea (Ken
Schwaber4). La alta rotación de personal que no deja madurar equipos, el foco en procesos y no
en ambientes de trabajo, la evaluación de desempeño individual y no grupal, la priorización de
procesos de calidad y herramientas por sobre las personas y relaciones se pueden transformar
en un problema” (Palminio, 2018).
Adoptar el cambio
La agilidad busca adaptarse rápidamente y por tanto el cambio no lo ve como un problema, sino
como una oportunidad. De hecho, se asume que no es posible planificar a largo plazo ya que el
entorno cambiante hace que sea necesario realizar demasiados ajustes transformando en estéril
lo que se supuso. Darío Palminio indica que en la gestión tradicional de proyecto “Los cambios
que surjan en la fase de ejecución son manejados por un sistema formal de Gestión del Cambio,
pero estos cambios suelen tratar de evitarse. No suele ser bien visto la introducción de cambios
en la etapa de ejecución y la misma, que involucra la construcción del producto, suele abarcar
un período de tiempo grande. Esto hace que se comprometan entregables a largo plazo y en
forma contractual. Y el compromiso contractual efectuado al inicio del proyecto es difícil de
cumplir cuando la realidad del desarrollo no se ajusta a lo planificado debido a la alta tasa de
cambios resultado de la incertidumbre y a la variabilidad de las necesidades del cliente en
proyectos de software o de dominio complejo” (Palminio, 2018).
Por el contrario, en la agilidad los cambios no solo se tratan de evitar, sino que se aprovechan
para crear una aplicación de mejor calidad y que aporte valor al negocio.
Mantener simplicidad
Se refiere al “arte de maximizar la cantidad de trabajo no realizado, es esencial (alineado al
principio de simplicidad). Este estilo de prácticas es parte de algo que, en metodologías ágiles,
se conoce como: "hacer todo lo posible por hacer lo menos posible". Por ejemplo, en
4Es uno de los creadores, junto a Jeff Sutherland, del marco de desarrollo ágil llamado Scrum.
10 www.iplacex.cl
Arquitectura se puede considerar mantener una lo más simple posible. Si la simpleza se traduce
en facilidad de uso de la arquitectura, facilidad para entender los conceptos involucrados y
documentación necesaria, es muy probable que el nivel de productividad aumente. En este
sentido la simpleza de la arquitectura es un requerimiento de calidad alineado a la filosofía ágil”
(Palminio, 2018).
Habiendo explicado en detalle estos principios es posible pasar al desarrollo dirigido por la
agilidad.
Desarrollo dirigido por agilidad
Conceptos iniciales
En la agilidad el desarrollo de software considera al diseño y la implementación como las
actividades centrales en el proceso. Las salidas de una etapa se usan como base para planear
la siguiente actividad del proceso tal como se puede ver en la siguiente figura (Sommerville,
2011):
Este enfoque permite a la agilidad adaptarse rápidamente a los cambios en el proyecto e
incorporar fácilmente nuevos requerimientos. Un enfoque basado en un plan es más formal en la
petición de cambios en los requerimientos. De todas maneras, Sommerville (2011) plantea que
“es irrelevante el conflicto sobre si un proyecto puede considerarse dirigido por un plan o ágil. A
final de cuentas, la principal inquietud de los compradores de un sistema de software es si
11 www.iplacex.cl
cuentan o no con un sistema de software ejecutable, que cubra sus necesidades y realice
funciones útiles para el usuario de manera individual o dentro de una organización. En la
práctica, muchas compañías que afirman haber usado métodos ágiles adoptaron algunas
habilidades ágiles y las integraron con sus procesos dirigidos por un plan”.
2.Administración de un proyecto ágil
El mismo Sommerville (2011) proporciona varias guías para entender la administración de un
proyecto ágil: “La responsabilidad principal de los administradores del proyecto de software es
dirigir el proyecto, de modo que el software se entregue a tiempo y con el presupuesto planeado
para ello. Supervisan el trabajo de los ingenieros de software y monitorizan el avance en el
desarrollo del software”.
También insiste en la diferencia con la gestión basada en planes al indicar que “Un enfoque
basado en un plan requiere en realidad que un administrador tenga una visión equilibrada de
todo lo que debe diseñarse y de los procesos de desarrollo. Sin embargo, no funciona bien con
los métodos ágiles, donde los requerimientos se desarrollan incrementalmente, donde el
software se entrega en rápidos incrementos cortos, y donde los cambios a los requerimientos y
el software son la norma. Como cualquier otro proceso de diseño de software profesional, el
desarrollo ágil tiene que administrarse de tal modo que se busque el mejor uso del tiempo y de
los recursos disponibles para el equipo. Esto requiere un enfoque diferente a la administración
del proyecto, que se adapte al desarrollo incremental y a las fortalezas particulares de los
métodos ágiles” (Sommerville, 2011, p. 72).
Por su parte Rally Software en su “Manual de Supervivencia del Gerente de Proyectos para la
Adopción Ágil” (2012) considera los siguientes puntos que permiten tener una visión más clara
de este tipo de administración: gestión de la integración, gestión del alcance y del tiempo,
gestión de la calidad y gestión de los recursos humanos. Esta secuencia de temas es relevante
ya que la agilidad se compromete con la entrega e integración sucesiva de incrementos.
También gestiona de manera especial el alcance del proyecto y del tiempo de desarrollo, así
como la calidad de lo construido y de los recursos humanos involucrados.
12 www.iplacex.cl
El detalle de estos temas es el siguiente (Rally Software Development, 2012):
Gestión de la integración
En la Gestión de Integración, uno de los entregables principales es el plan de proyecto el cual es
responsabilidad del gerente del proyecto.
En el Desarrollo Ágil de Software, con su énfasis en el diseño just-in-time y la toma de
decisiones en forma participativa, esta actividad se traduce en varios y diferentes ejercicios de
proyecciones y planificación, realizados en forma iterativa. En lugar de definir todos los
elementos de un plan de proyecto en el inicio del proyecto (alcance, estructura del equipo de
trabajo, programación, premisas, controles) el gerente de proyecto Ágil se enfoca en planificar
para el horizonte y en preparar la documentación de low-end ceremony apropiada para el tipo y
número de nodos de comunicación involucrados. La documentación delow-end ceremony del
release5 Ágil y los planes de iteración pueden consistir en varios paneles blancos (white-boards)
en una sala de control conteniendo marcaciones codificadas en diferentes colores, o en
cartulinas pegadas en la pared con notas de diferentes colores.
(Para mayor conocimiento, tome una hora de su tiempo y participe del seminario on-line,
gratuito, de Jim Highsmith sobre gestión de proyectos Ágiles, en:
http://www.rallydev.com/register_for_webinar_series.jsp#jimPresentation)
Estos planes de release indican la fecha de lanzamiento esperada y la funcionalidad requerida
en cada iteración indicando el nivel de esfuerzo para la implementación en conjunto dentro del
tiempo establecido, son definidos en las reuniones de planificación con todo el equipo.
El equipo debe crear el plan, asumir la responsabilidad del mismo, y comprometerse con el plan;
ellos no deben ser obligados a cumplir las especificaciones definidas por un individuo que esté
5Se refiere a la entrega de los incrementos que se van construyendo.
13 www.iplacex.cl
administrando el proyecto. Planes de release, planes de iteración y otros resultados de
planificación de las fases de Visión y Especulación son entonces compartidos con todos los
involucrados de forma más transparente. Para equipos que trabajan en un mismo local, esto
puede significar algo tan simple como colocar el plan en una pared; en caso de equipos
geográficamente dispersos, se requerirán herramientas para mantener la comunicación.
SharePoint6, wikis u otras herramientas de terceros, incluyendo Rally, están debidamente
capacitados para resolver este reto. La función de los gerentes de proyecto va desde escribir un
extenso documento detallado que define el plan para todo el proyecto hasta facilitar las tareas
del equipo en cada una de las iteraciones y compartir estas informaciones de la manera más
visible.
El control de cambios integrado también se modifica radicalmente en las metodologías Ágiles.
De acuerdo con la filosofía de la complejidad mínima para para obtener el máximo valor, el
proceso de control de cambios es dinámico e integrado a la rutina diaria de los equipos Ágiles. El
cambio en los productos es gestionado a través del backlog que clasifica cada una de las
funcionalidades. Este backlog de productos es gestionado por el cliente o por su proxy (gerente
de productos, experto en la materia, arquitecto) que es responsable de mantener la lista de
ítems a ser desarrollados, siendo aquellas funcionalidades que ofrecen mayor valor al negocio
las que tienen la mayor clasificación o puntuación. Este backlog no solo es un registro de la
funcionalidad requerida, si no otros ítems como el soporte técnico requerido y una relación delos
defectos. Durante la planificación del release y de la iteración, los ítems con la clasificación más
alta pasan del backlog a las iteraciones, para ser codificadas, probadas, y aceptadas por el
cliente. Durante la iteración, se realizan reuniones de stand-up diarias de 15 minutos7 para que
cada miembro del equipo notifique al resto del equipo sobre el status de sus responsabilidades
6Se refiere a una plataforma de colaboración empresarial, formada por productos y elementos de
software que incluye, entre una selección cada vez mayor de componentes, funciones de colaboración,
basado en el navegador web, módulos de administración de procesos, módulos de búsqueda y una
plataforma de administración de documentos (https://es.wikipedia.org/wiki/Microsoft_SharePoint)
7En estas reuniones breves cada integrante del equipo informa lo que hizo ayer, lo que va a hacer en el
día que se inicia y los problemas que ha tenido.
14 www.iplacex.cl
esta comunicación es un elemento clave para mantener la armonía del equipo – y así afrontar
cualquier obstáculo. Al final de cada iteración, se demuestra el código desarrollado en
funcionamiento, y se reúne el feedback de todos los involucrados, el cual pueden tener un
impacto en las futuras decisiones sobre los ítems en el backlog y su clasificación. Cambios en el
proceso también son realizados al final de las iteraciones, permitiendo que el equipo corrija el
producto, pero también la manera en que se trabaja. El equipo - cliente, desarrollador, control de
calidad, analista, redactor técnico, y gerente del proyecto - se convierte en el equivalente a un
directorio, para agilizar el proceso de forma que las decisiones sean tomadas rápidamente, en
colaboración y con poco o ningún protocolo.
Gestión del alcance y del tiempo
El “scope creep” (aumento / desvío gradual del alcance) siempre ha sido la perdición de los
gerentes de proyecto que utilizan el método cascada o Waterfall, ya que los requisitos siguen
cambiando en respuesta a los cambios en el mercado, los cambios en la industria, cambios en la
tecnología y todo lo que se aprende durante el proceso de desarrollo. La planificación, la
definición, la verificación y el control del alcance son todas áreas de conocimiento que reciben
enorme atención en el PMBOK8. Los métodos Ágiles también creen que ellas merecen mucha
atención, pero su filosofía para la gestión del alcance es completamente diferente. Los métodos
basados en planes se enfocan mucho en evitar los cambios en el alcance, mientras que los
métodos Ágiles los prevén, asumen y no intentan evitarlos.
Recuerde – para la estrategia Ágil el costo de la programación es fija, y se enfoca en
implementar las funcionalidades de mayor valor para el cliente.
Ésta es el área que más tiende a incomodar los gerentes de proyecto. El marco que utilizamos
es todavía el tiempo; sin embargo, en lugar de agregar más y más funcionalidad de manera que
8Se refiere a la Guía de los fundamentos para la dirección de proyectos (del inglés A Guide to the Project
Management Body of Knowledge o PMBOK por sus siglas) es un libro en el que se presentan
estándares, pautas y normas para la gestión de proyectos. La 6ª fue publicada el 6 de septiembre de
2017 (https://es.wikipedia.org/wiki/Gu%C3%ADa_de_los_fundamentos_para_la_direcci%C3%B3n_de_proyectos ).
15 www.iplacex.cl
el marco esté a punto de ceder o que estalle, lo que hacemos es utilizar varios marcos, hechos
de acero, y solamente paramos de agregar funcionalidad cuando el marco esté a punto de
ceder. Después, nada se le agrega al marco bajo el cual se opera, ya está bajo llave para
aquella iteración y nos enfocamos en desarrollar las funcionalidades que sean aceptada por el
cliente. Debido a que se le agrega funcionalidad a c/u de estos marcos y luego se le pone bajo
llave, es difícil proyectas cuánto trabajo podrá ser concluido en un plazo más largo. De hecho, la
pregunta más común hecha por gerentes de proyecto al escuchar sobre la metodología Ágil para
la planificación y gestión de alcance es “¿Qué es lo que le debo decir a mi jefe y/o cliente
cuándo me pregunte cuándo vamos a terminar?” Independientemente de la metodología que se
utilice, cuando se le solicita al gerente de proyecto mirar a futuro para dar respuestas, el papel
del gerente de proyecto se convierte en el papel de vidente y adivino. Un gerente de proyecto no
podría realmente contestar esta pregunta concretamente incluso si emplease métodos
tradicionales de gestión de proyectos - sería solamente una estimado basado en experiencia y
en un análisis histórico.
En el Desarrollo Ágil de Software, la planificación del alcance se realiza como parte de la
planificación del release. La definición del alcance y muchas de las prácticas definidas en el área
de Project Time Management del PMBOK son ejecutadas como parte de la planificación de las
iteraciones, en la cual las funcionalidades son definidas, encargadas, estimadas y designadas.
La gran diferencia es que el trabajo de planificación y diseño es hecho solamente en las partes
que están siendo preparadas para su codificación y no para el sistema en su totalidad. La
verificación de alcance se realiza dentro de la iteración, cuando los dueños y clientes de los
productos logran analizar, probar y aceptar las funcionalidades implementadas. Y el control de
cambios en el alcance es hecho por la gerencia del backlog de productos9, tal como fue descrito
en la sección anterior.
9Se refiere a la lista de requerimientos, ordenados según el valor de negocio que establece el cliente
representado por el dueño del producto (Product Owner).
16 www.iplacex.cl
3.Gestión de la calidad
Otro grupo de individuos forzados a cambiar su modo de pensar es el personal de control de
calidad. Habituados a tener un rol secundario, acostumbrados a trabajar en plazos reducidos,
especificaciones que no corresponden al producto recibido y poco interés en sus opiniones hasta
las últimas semanas del proyecto. El Desarrollo Ágil de Software incluye al Control de Calidad
(QA10) en el análisis y diseño del producto, manteniéndolo profundamente involucrado en la
toma de decisiones a lo largo del ciclo de vida del producto. Como el código desarrollado
aumenta en cada iteración, el QA ahora hace pruebas desde el inicio del proyecto, en lugar de
esperar que a un “monstruo “en la fase final del proyecto. Y, como el rendimiento es superior, el
QA tiene el reto de ser más técnico, pues se ven obligados a automatizar los procesos de a
todos los niveles, y no limitarse a pruebas a través de macros ejecutados vía GUI.
De hecho, en el nirvana11 de los métodos Ágiles, QA es el que conduce el proceso de desarrollo
de software, en algo denominado “Desarrollo Basado en Pruebas” o Test-Driven Development.
Bajo este método, las pruebas son definidas y automatizadas primero, inclusive antes de que se
comience a crear código operativo. Una vez concluidos todos los casos de test y los testeos
unitarios, comienza la codificación - y termina cuando todos los casos de test son aprobados
(con suerte al final de la iteración). Esto es lo más avanzado en términos de planificación y
control de calidad.
Normalmente, la planificación de calidad exige que se defina un plan que indique como ejecutar
las actividades de control de calidad que correspondan con las políticas y procedimientos de la
institución. Los miembros del equipo de QA Ágil deben de trabajar con el equipo de proyectos
para determinar cuáles herramientas y tecnología se irán a utilizar para definir, ejecutar y emitir
informes de las pruebas y sus resultados. Es importante involucrar a los desarrolladores en esta
definición, pues ellos irán a contribuir escribiendo pruebas unitarias y colaborando para definirla
estructura de cómo automatizar pruebas de regresión y de aceptación. Los Product Owners
10Quality Control o Control de Calidad. Se indica como QA por su sigla en inglés.
11Paraíso.
17 www.iplacex.cl
también deben estar involucrados, ya que deben contribuir a definir y ejecutar las pruebas de
aceptación. En prácticas Ágiles, todo el mundo contribuye para definir, mantener y mejorar la
calidad del producto.
La garantía de calidad, con su foco en la prevención de defectos, se traduce en la práctica Ágil
de manera que existe el compromiso de asignar recursos de QA al equipo de desarrollo de
forma que participe diariamente en la toma de decisiones, durante el ciclo de vida del proyecto.
Su aporte durante la elaboración y diseño contribuyen a que los desarrolladores produzcan
productos con menos defectos. El resultado es que se consideren más alternativas a ser
probadas (“what-if”12) debido a la colaboración entre los codificadores y los del personal de QA.
Los primeros toman en consideración como y porque se van a probar los nuevos desarrollos. A
su vez, los probadores tienen más conocimiento de la funcionalidad requerida por el Product
Owner de tal manera que pueda definir pruebas que más se acercan a la realidad.
Control de calidad pone énfasis en descubrir los defectos que ya pasaron desapercibidos en el
sistema y en trabajar con los desarrolladores para eliminarlos. Esta verificación de defectos se
hace dentro de la iteración, usando técnicas como compilaciones y smoke tests 13, pruebas de
regresión automatizada, pruebas unitarias, pruebas funcionales y exploratorias, y pruebas de
aceptación. Todos participan de estas pruebas - nadie está exento de las tareas de asegurar que
la funcionalidad codificada cumpla con las expectativas del cliente.
Gestión de los recursos humanos
Una vez realizada la asignación del personal, el PMBOK registra los procesos de Planificación
Organizacional y Desarrollo de Equipo. El PMBOK define el Plan Organizacional como el
proceso en el que se designan funciones y responsabilidades. El PMBOK define también el
desarrollo del equipo como el desarrollo de las habilidades requeridas por cada uno de los
12Se refiere al análisis del tipo “que pasaría si”.
13Se refiere a aquellas pruebas que pretenden evaluar la calidad de un producto de software previo a una
recepción formal, ya sea al equipo de pruebas o al usuario final
(https://es.wikipedia.org/wiki/Pruebas_de_humo).
18 www.iplacex.cl
miembros del mismo. El método Ágil tiene como objetivo establecer equipos interdisciplinarios, y
darles la potestad para que se auto organicen.
Establecer un equipo interdisciplinario significa que el equipo de desarrollo no será compuesto
únicamente por programadores. En lugar de esto, el equipo de desarrollo Ágil consiste de todos
los roles requeridos para que, al concluir la iteración, se tenga un producto, un desarrollo,
operativos. En otras se requiere de: control de calidad, analistas, arquitectos, redactores
técnicos, expertos en la materia, el cliente o Product Owner y el jefe del equipo (gerente de
proyecto, instructor de XP, Scrum Master). Estos individuos traen consigo un conjunto de
habilidades particulares, pero a la medida que el equipo madura, cada individuo va aprendiendo
más sobre las tareas y los esfuerzos de los otros miembros del equipo y gradualmente tienen
mayor predisposición y capacidad de ayudar para ayudar en áreas en las cuales no tienen tanta
experiencia. A fin de cuentas, contar con un equipo interdisciplinario significa que Ud. tiene un
grupo de individuos comprometidos con la entrega de las funcionalidades prometidas de manera
que están dispuestos a colaborar y/o hacer lo que sea necesario para concluir la iteración con
éxito.
El equipo se auto-organiza como resultado de la auto-fiscalización diaria tanto del producto y
como del proceso, de tal manera que el equipo en forma autónoma examina los logros y decide
como continuar trabajando. Este control por parte del equipo de la planificación, ejecución y
análisis tanto del producto como del proceso conduce al equipo a un nivel de desempeño más
alto y, sustentado por la exhortación al análisis y el deseo de una mejora continua.
Este nuevo concepto, que también es difícil que los gerentes de proyecto lo pueden visualizar, y
comúnmente provoca mucho nerviosismo cuando empiezan a querer saber cuál será su nuevo
rol, ya que no van a administrar a un equipo. Aquí es donde el cambio de supervisor-supervisado
debe cambiar a lo que Robert Greenleaf describió en los años ochenta como “líder sirviente”.
La dinámica de los equipos no cambia de la noche a la mañana y los equipos que todavía no se
acostumbraran a los nuevos métodos Ágiles necesitan de liderazgo para ayudarlos a aprender a
tomar decisiones en grupo. Para volverse un líder sirviente es necesario aprender a promover la
19 www.iplacex.cl
colaboración y la reflexión como medios para permitir que los equipos rindan de acuerdo a todo
su potencial. Las características de equipos experimentados con un liderazgo servidor son la
dirección, orientación, habilitación, y la eliminación de barreras y obstáculos.
4.Agilidad moderna
La agilidad ha sido un área que ha crecido y madurado muy rápidamente provocando que haya
autores que se refieran a una “Agilidad Moderna”, la que fue propuesta por Joshua Kerievsky
como algo “más ligero”. Esta propuesta se resume en la siguiente figura (publicada en
http://managementplaza.es/blog/los-cuatro-principios-del-modern-agile-agilidad-moderna/):
Brevemente cada cuadrante se describe de la siguiente manera:
1. Haz a la gente impresionante: se refiere a que todas las personas involucradas deberían
trabajar firmemente para que el cliente se transforme en alguien impresionante. Es decir,
al ponerlo en primer lugar, el equipo realmente se compromete en que el proyecto sea un
éxito para él.
20 www.iplacex.cl
2. Entrega valor continuamente: se refiere a buscar la entrega de valor para el cliente lo más
rápido posible. Para esto se propone “trozar” el gran aporte de valor en “trocitos” que
permitan lograr esta entrega continua. Esto se resume diciendo “cuanto más demores la
entrega a tus clientes, más tiempo tardarás en saber aquello que necesitan o los hace
felices”.
3. Haz de la seguridad un pre requisito: se trata de evitar el miedo a equivocarse porque
este mata el rendimiento de los equipos de trabajo. Es importante tomar las medidas para
evitar que un problema o amenaza para el trabajo en equipo vuelva a ocurrir.
4. Experimenta y aprende rápidamente: esto quiere decir que el equipo no debe atascarse
en el error que inevitablemente aparece cuando se está logrando aprendizaje. Este
aprendizaje debe poner en marcha más y nuevos experimentos. Aquí la velocidad es
clave: se trata de experimentar y de aprender rápidamente. Se trata de lograrlo
experimentando con frecuencia, perdiendo el miedo al fracaso ya que cuando algo no
resulta se analiza para saber por qué falló y eso hace crecer al equipo dándole más
confianza.
21 www.iplacex.cl
Conclusión
Como se ha visto la agilidad surge como una respuesta al desarrollo de software en un entorno
que necesita aplicaciones de calidad construidas en periodos de tiempo breves. Para esto el
Desarrollo Ágil privilegia el trabajo en equipo con una fuerte interacción con los clientes.
Lo anterior se puede comprobar en el marco de desarrollo Scrum que incorpora incrementos
cada dos, tres o a lo sumo cuatro semanas dándole un rol protagónico al cliente representado
por el Product Owner. Este personaje es el responsable de validar los requerimientos,
priorizarlos y luego aceptar los incrementos que van siendo integrados periódicamente a las
entregas previas.
Esta lógica de trabajo permite que lo que se construya sea realmente un aporte de valor al
negocio y además lograr un alto retorno de la inversión en el proyecto.
Para lograr todo lo anterior el Desarrollo Ágil se basa en cinco principios: una fuerte y
permanente participación del cliente, la entrega de incrementos sucesivos, enfocarse en las
personas que participan más que en los procesos, aceptar el cambio como algo inevitable y
beneficioso y mantener una simplicidad tanto en el desarrollo como en la documentación que se
genere.
A través de una iteración continua entre la ingeniería de requerimientos y el diseño e
implementación el Desarrollo Ágil logra adaptarse rápidamente a los cambios que van surgiendo
durante el desarrollo del proyecto cumpliendo así con las entregas comprometidas a un nivel de
calidad suficiente.
Por último, cabe destacar que la agilidad enfoca la mayoría de los esfuerzos y recursos en crear
verdaderos equipos de trabajo, es decir grupos de gente a las que les agrada trabajar en equipo
y que tienen una alta productividad.
22 www.iplacex.cl
Bibliografía
Palminio, D. (2018). Scrum en Ingeniería de Software. Santiago de Chile: Autores
Editores S.A.S.
Proyectosagiles.org. (08 de 01 de 2019). Desarrollo iterativo e incremental. Obtenido de
https://proyectosagiles.org/desarrollo-iterativo-incremental/
Rally Software Development. (2012). Manual de Supervivencia del Gerente de
Proyectos para la Adopción Ágil. www.rallydev.com.
Sommerville, I. (2011). Ingeniería del Software. México: Pearson.
Telleria, R. (08 de 01 de 2019). El Importante Papel del Cliente en un Proyecto Ágil de
Software. Obtenido de https://sg.com.mx/revista/43/el-importante-papel-del-
cliente-un-proyecto-agil-software
23 www.iplacex.cl
24 www.iplacex.cl
