Metodologia_agil.txt

==============================
Guía de Metodología ágil by dM
==============================

Breve historia de la gestión ágil de proyectos
==============================================

Partiendo del concepto de fabricación ajustada de Toyota de la década de 1940,
los equipos de desarrollo de software han adoptado metodologías ágiles para
reducir los residuos y aumentar la transparencia, al tiempo que abordan
rápidamente las necesidades cambiantes de sus clientes. Un cambio radical con
respecto a la gestión de proyectos en cascada, que se centra en los lanzamientos
de "Big Bang", la agilidad ayuda a los equipos de software a colaborar mejor e
innovar más rápido que nunca. 

La gestión de proyectos ágil tradicional se puede clasificar en dos marcos:
scrum y kanban. Si bien scrum se centra en las iteraciones de proyectos de
duración fija, el kanban se centra en los lanzamientos continuos. Al terminar,
el equipo pasa inmediatamente al siguiente. 

¿Qué es la metodología ágil?
============================

La metodología ágil es un conjunto de técnicas aplicadas en ciclos de trabajo
cortos, con el objetivo de que el proceso de entrega de un proyecto sea más
eficiente. Así, con cada etapa completada, ya se pueden entregar avances y se
deja de lado la necesidad de esperar hasta el término del proyecto.

Creada en 2001 por un grupo de programadores de TI (Tecnología de la
Información) a través del “Manifiesto por el Desarrollo Ágil de Software”
> https://agilemanifesto.org/iso/es/manifesto.html la metodología ágil se
propone entregar valor al cliente de manera más rápida y puede proporcionar
numerosos beneficios a tu empresa, como:

-Optimización del flujo de trabajo

-Aumento de la productividad de tu equipo.

-Mayor satisfacción del cliente.

El manifiesto ágil original no establece iteraciones cada dos semanas o un
tamaño de equipo preferente. Solo define una serie de valores principales que
se centran en las personas. La forma en la que tú y tu equipo ponen en práctica
esos valores en la actualidad, ya sea siguiendo las instrucciones de scrum a
rajatabla o mezclando elementos de kanban y XP.

Manifiesto actualmente
======================

Manifiesto por el Desarrollo Ágil de Software

Estamos descubriendo formas mejores de desarrollar
software tanto por nuestra propia experiencia como
ayudando a terceros. A través de este trabajo hemos
aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha,
valoramos más los de la izquierda.

¿Por qué elegir la metodología ágil?
====================================

Los equipos que eligen la metodología ágil pueden responder ante los cambios en
el mercado o ante el feedback de los clientes rápidamente sin arruinar la
planificación de un año entero. La planificación justa y necesaria y el
lanzamiento de incrementos pequeños de forma frecuente permiten que tu equipo
recopile feedback sobre cada cambio y los integre en los planes futuros con unos
costes mínimos.

Pero aquí, los protagonistas no son los números: lo primero y más importante son
las personas. Tal y como se describe en el manifiesto ágil, las verdaderas
interacciones humanas son más importantes que los procesos rígidos. Colaborar
con clientes y compañeros de equipo es mucho más importante que las
disposiciones predefinidas, así como entregar una solución que resuelva el
problema del cliente es más importante que una documentación minuciosamente detallada.

Un equipo ágil comparte una visión y la hace realidad de la forma en la que
consideran que es mejor. Cada equipo fija sus propios estándares de calidad,
usabilidad e integridad. Su definición de "terminado" les permitirá determinar
la rapidez con la que completarán el trabajo. Aunque al principio puede resultar
intimidante, los líderes de las empresas comprueban que, cuando confían en un
equipo ágil, el equipo cuenta con un mayor sentido del compromiso y se esfuerza
para cumplir (o superar) las expectativas de la gestión.

¿Para qué tipos de proyectos son más adecuadas las metodologías ágiles?
=======================================================================

Algunos ejemplos:

-Proyectos cuya solución técnica se desconoce, suele pasar con aquellas tareas
que los equipos no han emprendido antes o cuando se trata de innovaciones.

-Proyectos de alta complejidad y que requieren del trabajo cooperativo de varias
personas o departamentos.

-Proyectos urgentes y que necesitan de un flujo de trabajo dinámico y donde los
cambios constantes sean bienvenidos.

¿Cuál es la diferencia entre la metodología ágil y una tradicional?
===================================================================

Para entender con precisión qué es la metodología ágil, es muy importante
conocer las diferencias entre esta metodología y una tradicional:

-Con la metodología ágil es posible controlar mejor el presupuesto, ya que
permite la entrega de pequeños resultados que ayudan a alinear los costos al
objetivo final del proyecto.

-En la metodología tradicional hay una planificación inicial que se debe seguir
hasta el final. Gracias a los sprints o ciclos de trabajo característicos de la
ágil, esto se vuelve más flexible, contribuyendo a una mejor gestión de riesgos.

-La colaboración con el cliente es más efectiva en la metodología ágil, ya que
recibe varios resultados durante todo el proceso y puede participar de forma
activa en su mejora.

Tipos de metodologías ágiles y su beneficio en la gobernanza de TI
==================================================================

Los métodos ágiles son modelos de gestión que se pueden aplicar dentro de la
estrategia de gerencia empresarial. Ya sea en la gobernanza de TI o en otros
segmentos, el beneficio de los métodos ágiles es que ayudan a reducir el tiempo
necesario para completar un proyecto y entregar más valor para el cliente, sin
perder calidad.

Entre los métodos ágiles que se pueden aplicar se encuentran:

Kanban
======

El método ágil Kanban consiste en un seguimiento visual del progreso del
proyecto en un panel de tareas. Mediante tarjetas de señalización (Post-It® o
plataformas online) es posible identificar de forma clara y rápida el estado
actual de las tareas, lo que se debe hacer y lo que ya se ha terminado.

Vale la pena destacar que Kanban no propone un cambio en los procesos o
estrategias que el negocio está acostumbrado a desempeñar. La organización de
todas las tareas y subtareas del proyecto, de forma visual, ayuda a que todos
tengan claro cuál es el flujo de trabajo a seguir y que cada proceso se realice
en el orden correcto.

Scrum
=====

La metodología ágil Scrum se basa en ciclos de trabajo o sprints –que pueden
durar desde semanas hasta meses– en los que se entrega alguna parte del
proyecto. En cada nuevo sprint se genera una versión del producto que supera a
la anterior. El pilar fundamental de la metodología ágil Scrum es que todas las
decisiones se toman en función de la información existente y de la propia
experiencia de los integrantes del equipo.

Este método, además, incluye la realización de reuniones periódicas para motivar
al equipo, así como para realizar los ajustes necesarios.

Extreme Programming
===================

La metodología ágil de Extreme Programming o XP fue concebida específicamente
para desarrollar software. Para este fin, todo proyecto que funcione con base en
XP cuenta con los roles de líder ágil, cliente, programador y tester; cada uno
de ellos con papeles indispensables.

XP se asemeja a Scrum en que plantea cambios frecuentes y ciclos breves en los
cuales se entregan nuevas versiones de un proyecto.

Lean
====

El objetivo de la metodología ágil Lean es utilizar únicamente las herramientas
que sean necesarias para la evolución del proyecto. ¿Para qué? Para maximizar el
valor para el cliente y minimizar el desperdicio de tiempo y recursos de la
organización.

Scaled Agile Framework
======================

El Scaled Agile Framework (SAFe) combina elementos tanto de Lean como Scrum.
Consiste en un acompañamiento visual que divide todos los procesos y flujos de
un negocio. Esto permite crear una estructura organizacional constituida por
tres pilares:

-El desarrollo de software ágil

-El desarrollo de productos lean;

-Un pensamiento sistémico.

Scaled Agile Framework está hecho para proporcionar a las empresas una
estrategia estructurada que les permita escalar de forma ágil. Suele utilizarse
en proyectos de alta complejidad, ya que esta metodología plantea numerosos
roles, eventos y prácticas que deben intervenir en el proceso bajo reglas bien
definidas. Para empresas muy grandes, o planes donde más de 150 personas estén
involucradas, el nivel de prescriptividad de SAFe puede resultar útil.

Nexus
=====

Nexus es una metodología ágil complementaria que contribuye a la implementación
de Scrum. Está orientada al desarrollo de software y soporte de productos
escalables que necesitan que un personal amplio se involucre. A través de Nexus,
es posible entrelazar múltiples equipos Scrum que trabajan de forma colaborativa
sobre un solo portafolio de productos.

Cabe destacar que, una vez domines las metodologías ágiles y entiendas su
correcta aplicación, no tienes por qué limitarte a solo una de ellas. Es normal
que las empresas opten por híbridos donde se combinen elementos de diferentes
metodologías. Sigue leyendo y descubrirás cuál es el porcentaje de negocios a
nivel mundial que lo hace, y cuáles son los híbridos más usados.

¿Cómo se aplica la metodología ágil por primera vez?
====================================================

Asegúrate de que todos se suban a bordo: La metodología ágil promueve la
colaboración entre todos los participantes —colaboradores, clientes,
proveedores, etc. Si quieres asegurar que todas las partes interesadas
desempeñen el papel que les corresponde en la aplicación de la metodología, es
necesario que les informes al respecto y que se sumen al plan.

Para convencer a los involucrados de que la metodología ágil es el camino a
seguir, explícales sus beneficios y comparte ejemplos persuasivos. Si el
proyecto al que se van a enfrentar no está muy bien definido y puede
experimentar numerosos cambios en el recorrido, por ejemplo, háblales sobre cómo
la metodología ágil permitirá ajustarse de forma más eficiente a esa dinámica,
lo cual ayudará a reforzar la confianza en el proceso.

Empieza con un proyecto piloto: La idea es que apliques la metodología ágil en
todos los proyectos que lleva adelante tu negocio. Sin embargo, es mejor iniciar
primero por algún proceso pequeño en el cual puedas implementar la metodología y
evaluar sus resultados.

Si consigues el éxito, ya cuentas con una base sobre la cual trabajar y aplicar
la metodología en otros proyectos. En caso de que no sea así, puedes enfocar tus
esfuerzos en mejorarla donde haga falta hasta que la perfecciones, y de ahí
prosigues con otros proyectos.

Mantén a tu equipo motivado: Ya sabes que la metodología ágil depende de la
colaboración de todas las partes involucradas. Para que cada quien desempeñe su
rol de forma efectiva, es necesario mantener al equipo motivado.

¿Cómo puedes hacer esto? Algunos consejos:

-Comunica de forma transparente y clara cuáles son los objetivos a perseguir con
la metodología ágil y qué se espera de cada integrante. Si tu equipo cuenta con
toda la información, pueden trabajar de manera enfocada para alcanzar las metas.

-Demuéstrales a tus colaboradores que confías en sus habilidades para lograr los
objetivos. En lugar de supervisarlos constantemente, hazles saber que cuentas
con ellos y que, si necesitan cualquier soporte, tú se los brindarás.

Cíñete a una sola estructura: Existen muchos tipos de metodologías ágiles, cada
una con sus particularidades y pasos a seguir. Aunque no tiene nada de malo
utilizar híbridos de varias metodologías, al ser tu prueba piloto es mejor que
tú y tu equipo sigan el paso a paso de la estructura escogida, sin mezclar con
otras. Eso evitará que se compliquen las cosas.

Por otro lado, es importante que intenten cumplir con todos los requisitos de la
metodología y que no duden de su efectividad sino hasta llevarla a término. Los
proyectos que siguen estas estrategias tienen un éxito comprobado del 64%. Las
metodologías ágiles fueron planteadas de forma inteligente, por lo que vale la
pena darles una oportunidad y acoplarse a ellas.

Analiza los resultados y ajusta según haga falta: Una vez finalices la
aplicación de la metodología ágil, haz un análisis profundo sobre los resultados
del proyecto y compáralos con los de aquellas ocasiones en las cuales no se
emplearon esta serie de técnicas.

Con un análisis completo, será posible determinar en qué áreas la metodología
ágil produjo buenos resultados y en cuáles no. Esa información te servirá para
adaptarla y aplicarla de formas aún más acertadas en próximos proyectos.

3 preguntas clave sobre metodologías ágiles
===========================================

¿Qué es la metodología ágil en la gestión de proyectos?

La metodología ágil en la gestión de proyectos consiste en aplicar técnicas que
optimicen la entrega de resultados al cliente, sin perder la calidad de estas
entregas. Estas prácticas contribuyen, por ejemplo, a que el proyecto sea más
flexible y adaptable a los cambios que puedan surgir durante su realización.

Al consistir en una estructura basada en pequeños ciclos, la metodología ágil
también ayuda a:

-Mejorar la productividad;

-Impulsar el compromiso del equipo;

-Facilitar la formación de equipos más efectivos, autogestionados y
multidisciplinares.

¿Cuáles son las metodologías ágiles más utilizadas en las empresas?
===================================================================

¿Sabías que la aplicación de una metodología ágil en la empresa es capaz de
reducir los costos hasta en un 60%? Probablemente te interese adoptar alguna de
ellas en tu negocio, aunque quizás te preguntes cuál es la mejor.

En ese sentido, conocer cuáles son las metodologías ágiles más utilizadas a
nivel mundial podría ayudarte a elegir la más adecuada para tu empresa,
ajustándola a tus necesidades.

Según un reporte:

-Un 56% de las empresas utilizan Scrum, considerada la metodología ágil más
popular.

-14% hace empleo de más de 2 metodologías ágiles.

-8% recurre a una combinación entre Scrum y Kanban.

-6% opta por híbridos entre Scrum y XP>

-Por último, 5% de las empresas utilizan la metodología ágil Kanban para la
optimización de procesos.

¿Qué empresas utilizan Scrum?
=============================

Para complementar el conocimiento sobre qué es la metodología ágil, es
importante que reconozcas a algunas de las empresas que utilizan el método
Scrum y cómo lo hacen, considerando que esta es una de las más aplicadas:

En Google, Scrum es el método ágil que se ha utilizado para desarrollar variedad
servicios y programas. Uno de ellos es Google Ads.

Los equipos de Yahoo utilizan el método ágil Scrum para crear, desarrollar y
probar sus productos y servicios durante algunos días.

Gracias a la metodología ágil Scrum, Amazon logró que sus equipos trabajen con
gran autonomía y puedan obtener más resultados en menos tiempo.

Metodología ágil en el pasado, el presente y el futuro
======================================================

La publicación del manifiesto ágil en 2001 marcó el inicio de la metodología
ágil en sí. Desde entonces, han surgido muchos marcos ágiles, como scrum,
kanban, lean y la programación extrema (XP). Todos ellos se basan en los
principios de iteración frecuente, aprendizaje continuo y alta calidad a su
manera. Scrum y XP son los métodos preferidos de los equipos de desarrollo de
software, mientras que kanban es el favorito de los equipos orientados a los
servicios, como los departamentos de TI o de recursos humanos.

En la actualidad, muchos equipos ágiles combinan prácticas de varios marcos
diferentes con una serie de prácticas únicas del equipo. Algunos equipos adoptan
determinadas estrategias ágiles (como reuniones rápidas, retrospectivas,
backlogs, etc.), mientras que otros crean una nueva práctica de la metodología
ágil (equipos de marketing ágiles que siguen el manifiesto de marketing ágil).

Los equipos ágiles del futuro valorarán su propia eficacia por encima de su
adhesión a la doctrina. La actitud abierta, la confianza y la autonomía se
postulan como la divisa cultural de las empresas que quieren atraer a los
mejores y sacarles el mayor partido.

¿Por qué las empresas del sXXI necesitan ser ágiles?
====================================================

Las empresas estamos usando los métodos ágiles, sencillamente porque funcionan.

Tres razones:

-Adaptación constante: No tienes que seguir un plan fijo cuando el entorno
cambia. Las metodologías ágiles te permiten ajustar tu estrategia sobre la
marcha, respondiendo a las necesidades reales del proyecto.

Entrega continua: No necesitas esperar hasta el final para ver los resultados.
Con un enfoque ágil, entregas versiones funcionales regularmente, lo que te
permite hacer ajustes con base en la retroalimentación.

Mejora la colaboración: En las metodologías ágiles, todos tienen un rol
importante. El equipo trabaja unido, lo que reduce errores y fomenta un sentido
de pertenencia y compromiso.

Cómo empezar
============

Introducir tu empresa en el mundo de los métodos ágiles es mucho más fácil de lo
que piensas, así que solo tienes que decidir empezar y ponerte a ello. Para que
no cometas errores de principiante, léete estos consejillos:

-Forma tu equipo: No empieces a utilizar los métodos ágiles sin asegurarte de
que todo el equipo comprende su uso y sabe aplicarlas. Herramientas como Jira o
Trello te ayudarán a organizar y visualizar el progreso.

-Elige el enfoque adecuado: Si necesitas estructura, Scrum es ideal. Si
prefieres algo más visual y flexible, Kanban es ideal y si como nosotros lo
aplicas por libre Scrumban es tu opción.

-Crea una cultura ágil: No se trata solo de implementar un método; es un cambio
de mentalidad en tu organización profundo. Fomenta la retroalimentación y deja
que tu equipo descubra que funcionan poco a poco, sin presionar.

El Agile aplicado al software
=============================

Las métodos ágiles han cambiado la forma en la que se desarrolla el software.
Gracias a los sprints y la entrega continua, los equipos pueden hacer ajustes
rápidamente, mejorando la calidad del producto y reduciendo errores. Ya no se
trata de esperar meses para tener un resultado; con el enfoque ágil, te adaptas
constantemente a los cambios y mejoras el producto en cada etapa.

Los 12 principios del Agile Manifiesto
======================================

Estos principios refuerzan el mensaje del Manifiesto Agil o Agile Manifiesto,
documento fundacional bajo el que se desarrollo el framework de Agile Project
Management.

Con el objetivo de facilitar tu comprensión, hemos dividido los 12 principios de
Agile en 4 categorías o temas:

-Entrega de valor: ¿Cómo entregan los equipos Agile productos de alto valor a
sus clientes?

Colaboración de negocio: ¿Cómo colaboran los miembros de los equipos de agile
con sus compañeros de negocio y con los stakeholders para crear valor en la
organización?

Dinámica del equipo y cultura: ¿Cómo un equipo de Agile mantiene las dinámicas
interpersonales y de equipo correctas para entregar valor tanto al cliente como
a la organización?

Retrospectivas y aprendizaje continuo: ¿Cómo aprende continuamente el equipo a
incrementar el rendimiento de la organización?

Entrega de valor
================

En esta categoría vamos a incluir aquellos principios que permitan entregar el
trabajo lo más rápido posible para conseguir feedback de los usuarios y mitigar
el riesgo de gastar demasiado tiempo creando un producto que no quieran los
usuarios.

Los principios de esta categoría son:

-La prioridad principal del equipo es satisfacer al cliente a través de una
entrega recurrente de valor a modo de entregables.

-Entregar software (o el producto que sea) funcional frecuentemente, mínimo cada
2 semanas y siempre tratando de usar el intervalo de tiempo más bajo.

-El producto funcional construido es la principal métrica de progresión.

-La simplicidad (el arte de maximizar la cantidad de trabajo hecho reduciendo lo
no esencial) es un principio importantísimo en esta metodología.

-Atencion continuada a la excelencia técnica y el buen diseño mejora la agilidad.

Colaboración de negocio
=======================

Colaborar con tus clientes ayuda al equipo a conseguir información crítica para
el negocio lo antes posible (validar o descartar hipótesis) permitiendo así a
los equipos de desarrollo de producto (sea software o no) poder ajustar y
adaptar sus planes a esta nueva realidad de forma instantánea.

Los principios de esta categoría son:

-El equipo de desarrollo debe estar abierto a cambios en las peticiones del
producto incluso en etapas tardías del desarrollo. La metodologías agiles
aprovechan el cambio para mejorar la ventaja competitiva del cliente.

-Los desarrolladores del producto y el resto del personal involucrado en la
cadena de valor de la empresa deben colaborar diariamente para el cumplimiento
del proyecto.

Dinámicas del equipo y cultura
==============================

El objetivo de estos principios es crear una cultura de equipo efectiva que sea
inclusiva, empoderadora y de apoyo mutuo.

Los principios de estas categorías son:

-Construir proyectos en torno a individuos motivados y comprometidos. Hay que
darles el ambiente de trabajo necesario, cubrir sus necesidades y confiar en que
harán el trabajo adecuado.

-El método más eficiente y efectivo de transmitir información entre miembros del
equipo es a través de conversaciones cara a cara (o videollamada en su defecto)
y no por canales asíncronos.

-El desarrollo ágil proporciona y promociona un desarrollo de la organización
sostenible en el tiempo.

-Los mejores productos, mockups, planos, requerimientos y diseños proceden de
equipos autónomos.

Retrospectivas y aprendizaje continuo
=====================================

Recordemos que los equipos de desarrollo ágil aceptan el cambio como parte
habitual y recurrente. Es por eso que el principio fundamental de esta temática
es:

-De forma regular, el equipo reflexiona a través de las reuniones de
retrospectiva, cómo poder ser más eficiente y ajustar su comportamiento en
consecuencia.

Responsabilidades de los gestores de proyectos ágiles
=====================================================

Sea cual sea la metodología ágil que elijas para organizar la fase de desarrollo
de un software, necesitarás un modo de comprobar el progreso de tu equipo con el
que puedas planificar los futuros trabajos o sprints. Las estimaciones de
proyectos ágiles ayudan a los equipos que usen scrum y kanban a conocer bien sus
capacidades. Los informes ágiles permiten consultar el progreso del equipo a lo
largo del proyecto. Los diagramas de Gantt y la limpieza del backlog ayudarán a
los gestores de proyectos a llevar un control de la lista de tareas pendientes y
listas para que el equipo las acometa.

Estimación de proyectos ágiles
==============================

La estimación del proyecto es una fase imprescindible en los métodos kanban y
scrum utilizados en la gestión de proyectos. En el caso del método kanban,
muchos equipos fijan el límite del trabajo en curso para cada fase en función de
sus experiencias pasadas y el tamaño del equipo. Los equipos de scrum hacen una
estimación del proyecto para detectar cuánto trabajo se puede realizar en un
sprint concreto. Muchos equipos ágiles usan técnicas exclusivas de estimación,
como la planificación iterativa mediante tarjetas ("planning poker"), la
organización de los horarios más adecuados o el uso de puntos de historia para
determinar el valor numérico de la tarea disponible. Estos tipos de estimaciones
ofrecen a los equipos ágiles un punto de referencia al que acudir durante la
revisión retrospectiva del sprint y con el que comprobar el rendimiento del
equipo.

Nota
====

En la actualidad, muchos equipos ágiles combinan prácticas de varios marcos
diferentes con una serie de prácticas únicas del equipo. Algunos equipos adoptan
determinadas estrategias ágiles (como reuniones rápidas, retrospectivas,
backlogs, etc.), mientras que otros crean una nueva práctica de la metodología
ágil (equipos de marketing ágiles que siguen el manifiesto de marketing ágil).

Mejores prácticas de pruebas de metodología ágil y por qué son importantes
==========================================================================

Todavía hacen falta pruebas manuales, ¡pero no de la forma que estás pensando!

La gestión de proyectos en cascada divide el desarrollo y las pruebas en dos
pasos distintos: los desarrolladores crean una funcionalidad y luego se la
"lanzan" al equipo de control de calidad (QA, por sus siglas en inglés) para que
realicen las pruebas. El equipo de control de calidad escribe y ejecuta los
planes de pruebas en detalle. También liman los defectos al verificar
minuciosamente si hay regresiones en las funcionalidades existentes que el nuevo
trabajo podría haber provocado.

Muchos equipos que utilizan estas cascadas u otros modelos tradicionales de
pruebas observan que, según crece el producto, la cantidad de pruebas aumenta
exponencialmente, y el control de calidad lucha invariablemente por seguir el
ritmo. Los propietarios de proyectos se enfrentan a una inoportuna elección:
retrasar la publicación o escatimar en pruebas. (Adivina cuál de las dos
opciones gana el 99 % de las veces). Mientras tanto, el desarrollo ha pasado a
otra cosa. Así pues, no solo aumenta la deuda técnica, sino que tratar cada
defecto requiere un costoso cambio de contexto entre dos partes de la base de
código. El colmo.

Para empeorar aún más las cosas, normalmente se recompensa a los equipos de
control de calidad por los errores que hayan encontrado, con lo que los
desarrolladores se ponen a la defensiva. ¿Y si hubiera una forma mejor para que
tanto el equipo de desarrollo como el de control de calidad redujeran el número
de errores de código, a la vez que se eliminan esas amargas concesiones que
tienen que hacer los propietarios del proyecto? ¿No se crearía un software
completo mejor?

Pasar de métodos de prueba tradicionales a ágiles
=================================================

Los equipos ágiles y de DevOps tienen como objetivo entregar funciones nuevas de
calidad de forma sostenible. Sin embargo, las metodologías de pruebas
tradicionales no encajan en un marco ágil o DevOps. El ritmo de desarrollo
requiere otro enfoque para garantizar la calidad de las compilaciones. En
Atlassian, realizamos pruebas siguiendo la metodología ágil. Analiza
detenidamente nuestro método de pruebas con Penny Wyatt, responsable sénior del
equipo de control de calidad de Jira Software.

De forma muy similar al cálculo de la deuda de una tarjeta de crédito, comienza
con cierto dolor, pero rápidamente se agrava... y debilita la agilidad analítica
del equipo. Para hacer frente a la multiplicación de la deuda técnica, en
Atlassian capacitamos a nuestros desarrolladores para que sean unos campeones en
materia de calidad (bueno, no: esperamos que lo sean). Creemos que los
desarrolladores aportan habilidades fundamentales para fomentar la calidad del
producto:

Los desarrolladores son muy buenos en resolver problemas de código.

Los desarrolladores que escriben sus propias pruebas están más comprometidos con
solucionarlos cuando fracasan.

Los desarrolladores que entienden los requisitos de la funcionalidad y sus
implicaciones de pruebas suelen escribir mejor código.

Creemos que cada historia de usuario del backlog requiere tanto código de la
funcionalidad como código de la prueba automatizada. Aunque algunos equipos
asignan el código de la funcionalidad a los desarrolladores mientras el equipo
de pruebas se encarga de las pruebas automatizadas, pensamos que es más efectivo
que un solo técnico entregue todo el conjunto.

Consejo de experto: Trata los bugs de funcionalidades nuevas y las regresiones
de funcionalidades existentes de forma distinta. Si surge un error durante el
desarrollo, dedica un momento a comprender el fallo, arréglalo y sigue adelante.
Si aparece una regresión (es decir, algo que antes funcionaba ha dejado de
funcionar), es probable que vuelva a aparecer. Crea una prueba automatizada para
impedir que la regresión reaparezca en el futuro.

Este modelo no quiere decir que los desarrolladores trabajen solos. Es
importante contar también con técnicos de control de calidad en el equipo. El
control de calidad ofrece una perspectiva importante del desarrollo de una
funcionalidad, y los buenos técnicos de control de calidad saben dónde se suelen
esconder los errores y pueden advertir a los desarrolladores de probables
"te pillé".

Pruebas exploratorias con un toque humano
=========================================

En nuestros equipos de desarrollo, los miembros de control de calidad se unen a
los desarrolladores para llevar a cabo las pruebas exploratorias, una valiosa
práctica durante el desarrollo para defenderse de más errores graves. De forma
muy similar a la revisión del código, hemos visto cómo se transmiten los
conocimientos de pruebas al equipo de desarrollo por ese motivo. Cuando los
desarrolladores se convierten en mejores evaluadores, se entrega mejor código la
primera vez.

Las pruebas exploratorias hacen que el código, y el equipo, sean más fuertes.

¿Pero las pruebas exploratorias no son manuales? Pues no. Al menos no en el
mismo sentido que las pruebas manuales de regresiones. Las pruebas exploratorias
son un método de prueba basado en los riesgos y de pensamiento crítico en el que
el evaluador emplea sus conocimientos de riesgos, detalles de implementación y
necesidades del cliente. Saber estas cosas con anterioridad en los procesos de
prueba permite que el desarrollador o el técnico de control de calidad encuentre
las incidencias rápidamente y de forma exhaustiva, sin necesidad de disponer de
casos de pruebas con guion, planes de prueba detallados ni requisitos. Pensamos
que son mucho más efectivas que las pruebas manuales tradicionales, ya que
podemos devolver las ideas de las sesiones de pruebas exploratorias al código
original y las pruebas automatizadas. Las pruebas exploratorias también nos
enseñan la experiencia de utilizar una funcionalidad de un modo que no consiguen
las pruebas con guion.

Mantener la calidad entraña una mezcla de pruebas exploratorias y automatizadas.
A medida que se desarrollan nuevas funciones, las pruebas exploratorias
garantizan que el código nuevo cumpla las normas de calidad en un sentido más
amplio que solo con las pruebas automatizadas. Esto incluye la facilidad de uso,
un diseño agradable a la vista y una utilidad general de la función, aparte de
las sólidas protecciones contra regresiones que proporcionan las pruebas
automatizadas.

Cambiar cuesta, cuesta mucho
============================

Os dejo con una anécdota personal que resume perfectamente mi trayectoria con
las pruebas ágiles. Recuerdo que al principio de mi carrera estuve gestionando
un equipo técnico que se resistía firmemente a escribir pruebas automatizadas,
porque era "trabajo de control de calidad". Después de varias iteraciones de
código erróneo y de oír todos los motivos por los que las pruebas automatizadas
retrasarían al equipo, me puse firme: había que realizar pruebas automatizadas
en todo el código nuevo.

Tras una sola iteración, el código empezó a mejorar. Y resulta que el
desarrollador que estaba más rotundamente en contra de escribir pruebas fue el
que se empezó a poner en marcha cuando una prueba fallaba. Durante las
iteraciones siguientes, las pruebas automatizadas se incrementaron, escalaron
entre navegadores y mejoraron el espíritu de desarrollo. Las funcionalidades
tardaban más en salir, claro. Pero los errores y los repasos disminuyeron
drásticamente, con lo que al final nos ahorraba muchísimo tiempo.

Los cambios no suelen ser fáciles. Pero, como la mayoría de cosas que valen la
pena, si te arremangas y creas patrones nuevos para ti mismo, solo te quedará
esta pregunta: "¿Por qué no lo había hecho antes?"

========================================
Cómo ser un excelente desarrollador ágil
========================================

El desarrollo de software ágil se basa por completo en el desarrollo sostenible.

El desarrollo de software ágil no se centra únicamente en los desarrolladores.

Nadie quiere lanzar software con muchos errores, problemas de rendimiento y poca
satisfacción del cliente. La integración continua y las revisiones del código
ayudan a evitar estas situaciones, pero ¿quién tiene tiempo para ello? Pues
bien, los equipos ágiles y DevOps encuentran tiempo.

Los desarrolladores ágiles se centran en un desarrollo sostenible, no en actos
heroicos. La sostenibilidad tiene que ver con buenas estimaciones, estrategias
eficaces de creación de ramas para gestionar el código, pruebas automatizadas
para proteger la calidad y una implementación continua para obtener feedback
rápidamente de los usuarios.

Adoptar prácticas de desarrollo sostenible requiere una disciplina a la que
aspiramos la mayoría de nosotros, pero que a menudo no logramos alcanzar. Esto
se debe a que no se puede adoptar la metodología ágil o DevOps sin una base. La
cultura de toda la organización debe respaldarlo y, a veces, se necesita un
motor para el cambio, como un ingeniero de DevOps. Por ello, los líderes del
proyecto deben entender que la calidad es más importante que el alcance o la
planificación, lo cual es a menudo la parte más difícil de adoptar una
metodología ágil.

¡Pero merece la pena! Los desarrolladores tienen la libertad y la
responsabilidad de desarrollar software de forma sostenible, a la vez que
mantienen una buena relación con la empresa. Además, la empresa se beneficia de
una mayor calidad del producto en el mercado, lo que refuerza aún más esa
relación con los ingenieros. Y lo que es mejor, los desarrolladores ágiles pocas
veces tienen que ir a marchas forzadas. Cuando el desarrollo se retrasa porque
para mantener una buena calidad hay que esforzarse más de lo previsto, el lado
del triángulo que representa el alcance puede ajustarse a la situación; así
nadie tiene que sacrificar el fin de semana.

Todos los desarrolladores de software conocen el triángulo de la gestión de
proyectos: alcance, plazos y calidad. La mayoría de nosotros ha participado en
proyectos donde el alcance no era flexible, los plazos se venían abajo y el
desarrollo se veía superado por una deuda técnica creciente. En ocasiones (por
si acaso esto fuera poco), el producto final ni siquiera era lo que exigía el
mercado. Es una situación frustrante y desgraciadamente familiar.

Pero no hay que tener miedo: hay buenas noticias.

Gracias al desarrollo de software ágil, el alcance se convierte en una variable
dinámica para que los equipos puedan proteger la calidad, crear una cultura de
desarrollo activa y trabajar estrechamente con la empresa. En Atlassian, la
metodología ágil es el núcleo de todos los equipos de desarrollo (y de otros
equipos también). Esto es así por un buen motivo.

La metodología ágil no es únicamente un conjunto de protocolos. Es una filosofía
técnica y cultural.

Permite adquirir prácticas que creen un fundamento técnico sólido del producto e
insuflar una cultura de colaboración en el equipo. Los desarrolladores de los
equipos ágiles están más comprometidos, programan mejor y se divierten más.

Las relaciones sólidas implican un producto más sólido
======================================================

La metodología ágil tiene que ver con el trabajo en equipo, lo cual no es
ninguna sorpresa dado que la mayor parte del software de hoy en día lo crean
equipos. Los desarrolladores crean relaciones sólidas con los gestores de
productos, diseñadores, publicistas y encargados de operaciones debido a que la
creación de código sostenible significa estar conectado en todas las facetas del
proyecto. Atlassian ha visto enormes mejoras en la calidad del código y en la
satisfacción de los desarrolladores al permitirles trabajar directamente con
otras áreas de la empresa. Mejor código, menos "basura" (es decir, menos trabajo
duplicado o flujos conflictivos) y más eficacia entre funcionalidades son
algunas de las ventajas.

Los mentores también son muy importantes. Los equipos ágiles se forman entre sí
para asegurar que el conocimiento de la base de código se extiende por todo el
equipo. Una manera de lograrlo es mediante las revisiones del código, lo cual no
solo protege la calidad, sino que también extiende la familiaridad con el código
en todo el equipo. Independientemente de cómo se propague el conocimiento, en
los equipos ágiles no participan desarrolladores esenciales que no pueden irse
de vacaciones porque son los únicos que entienden una parte concreta del código.
Porque nadie quiere ser ese desarrollador.

Los desarrolladores ágiles también trabajan a fondo con los recursos
tecnológicos del proyecto con mayor facilidad que sus homólogos de cascada
debido a que los equipos ágiles se autorganizan, dando a los miembros la
oportunidad de adquirir nuevas habilidades. Es un hecho que los desarrolladores
que entregan funcionalidades enteras (desde una interfaz de usuario a una base
de datos) asumen mayor propiedad de su código. En Atlassian cultivamos
desarrolladores completos porque creemos en compartir el conocimiento por todo
el equipo y toda la empresa.

Programación, cultura y disfrutar del desarrollo de software ágil
=================================================================

Adoptar una metodología ágil implica crear una gran cultura de desarrollo en tu
organización. Sigue leyendo para aprender más acerca de las estrategias de
creación de ramas eficaces, técnicas de pruebas automatizadas, integración
continua y la creación de relaciones fructíferas con otras partes de la empresa.

=============================================================
Planificación ágil trimestral: 8 pasos para ponerse en marcha
=============================================================

Aprende a crear un gran software mediante la planificación ágil a largo plazo

De camino a otra reunión de planificación trimestral ágil en el trabajo, me di
cuenta de que yo también estoy trabajando en un proyecto a largo plazo. Estoy
construyéndome una casa. La creación de software y la construcción de una casa
no son cosas tan distintas: ambos son proyectos a largo plazo donde varios
equipos deben coordinarse y, como podría confirmar cualquiera que se haya
embarcado en la construcción de una casa, nunca terminan del todo. Siempre
pueden hacerse mejoras, siempre hay algo que se rompe y las tendencias del
mercado siempre cambian. Sin un plan, corres el riesgo de que surjan
impedimentos o que se aplace la eterna mudanza que siempre está programada para
dentro de dos meses.

Donde el desarrollo de software difiere y la construcción de una casa podría
salir totalmente beneficiada, es en el uso de la metodología ágil. Esta
metodología permite que varios equipos puedan responder a los cambios
rápidamente. Así que ¿cómo puede la metodología ágil, un método basado en una
entrega frecuente y continua, combinarse con una planificación general y a
largo plazo? ¿Es posible crear un pronóstico realista durante un periodo
prolongado, sabiendo que la única constante es el cambio?

Cómo funcionan conjuntamente la planificación a largo plazo y la metodología
ágil
============================================================================

Con independencia de tu progreso actual hacia la metodología ágil, y tanto si
utilizas kanban, scrum o estás empezando a probar la agilidad a gran escala, es
necesario gestionar personas, trabajo y tiempo al planificar la visión
estratégica a largo plazo. A la hora de gestionar el desarrollo de software,
resulta difícil pensar en un enfoque con herramientas desconectadas, como los
diagramas de Gantt, las hojas de cálculo y mezclas personalizadas de
herramientas de gestión de carteras de proyectos. O, en el caso de mi
contratista, su combinación de hojas de cálculo, correos electrónicos y
mensajes de texto pasa a ser al instante algo poco práctico.

La clave de la planificación ágil a largo plazo es mantener los detalles y las
estimaciones de tareas en sintonía con la hoja de ruta.

Antes de tratar el tema de las soluciones de pronóstico dinámico, veamos los
pasos que debes seguir para crear un plan ágil a largo plazo con la metáfora de
construir una casa:

Paso 1. Comienza con una imagen global.

Ya sea una casa o un producto, tienes que definir la visión y perfilar los temas
estratégicos. Piensa en los temas como áreas prioritarias para toda la
organización. ¿En qué quieres centrarte el próximo trimestre, los próximos 6
meses y el próximo año? ¿Dónde quieres dedicar tiempo y emplear recursos?
¿Rendimiento, experiencia del usuario, seguridad, nuevas funciones competitivas
(¿un jacuzzi, por ejemplo?) o una combinación de todo ello?

Claro que lo quería todo, pero siempre están esas dos molestas realidades: el
tiempo y el dinero. Establecer los temas de mayor prioridad te ayudará a centrar
tu tiempo y energía en hacer pocas cosas pero hacerlas verdaderamente bien.

Paso 2. Identifica los elementos de mayor valor.

Para respaldar, por ejemplo, el tema de la seguridad, tendremos que construir
nuevos cimientos, con muros verticales en la estructura, puertas de madera
maciza y ventanas de doble acristalamiento.

Paso 3. Desglósalos.

Así las cosas, ¿qué trabajo se necesita realmente para instalar ventanas nuevas
y seguras? Desglosa el trabajo de la iniciativa más ambiciosa en acciones más
asequibles, como epics que puedan ayudarte con la planificación trimestral ágil.
Así tendrás una visión detallada de todos los pasos necesarios para completar tu
iniciativa.

Por ejemplo, tienes que quitar las ventanas antiguas, comprar unas nuevas,
instalarlas, mejorar el rendimiento de las ventanas con cortinas o persianas,
etc. Estas pequeñas acciones formarían tu backlog.

Esto te ayudará en el siguiente paso del proceso de planificación, y el más
importante, la estimación.

Paso 4. Comienza con las estimaciones.

Una vez desglosado el trabajo, deberás realizar una estimación aproximada del
tiempo necesario para crear una hoja de ruta. Una hoja de ruta es un plan de
acción de cómo un producto o una solución evoluciona a lo largo del tiempo.
Necesitas esto para comprender cuándo ocurrirán los acontecimientos importantes
y en qué orden.

Aquí es donde entra verdaderamente en juego la experiencia de tu contratista (o
gestores de productos y jefes de desarrollo). Al observar esfuerzos similares en
el pasado, puedes hacerte una buena idea del tiempo necesario para completar
cada epic.

Dado que para estimar es preciso conocer los esfuerzos del pasado con epics
similares, es aún más importante almacenar la información en un único lugar. De
esa forma, resulta mucho más sencillo mirar atrás y lograr unas estimaciones más
exactas. Mi contratista confía en su experiencia, pero ¿qué sucede si se olvida
o si un contratista diferente tiene una experiencia distinta?

Más adelante, pasarás la hoja de ruta final al equipo (desarrolladores,
instaladores de ventanas, etc.) donde analizarán el alcance con más exactitud
si cabe.

Obtén estimaciones

Paso 5. Crea versiones inteligentes.

Al utilizar un desarrollo ágil, los equipos suelen entregar un fragmento de
software al final de cada sprint como una publicación (versión). No obstante,
cuando planificas y estableces una hoja de ruta a largo plazo, tienes que
definir algunos puntos de publicación aproximados en tu hoja de ruta, de modo
que puedas estimar las fechas de publicación del siguiente trimestre con la
planificación trimestral ágil. Por ejemplo, "Exterior de la casa completo", que
combinaría la iniciativa de ventanas de seguridad con la estructuración, la
pintura, el aislamiento, etc.

Agrupa los elementos de trabajo en tu backlog con funcionalidades similares,
aúna el mayor sentido común posible u ofrece valor en conjunto a los clientes.
Y, recuerda, las versiones están totalmente impulsadas por el alcance y no por
exigentes fechas límite.

Crea publicaciones inteligentes

Paso 6. Crea la hoja de ruta.

Ahora ya dispones de una estimación de backlog, publicaciones y equipos con una
velocidad. El tradicional triángulo de planificación indica que un plan cuenta
con tres variables: alcance (lo que quieres hacer), duración (cuánto tiempo te
llevará hacerlo) y recursos (quién puede hacerlo). Tienes todo lo que necesitas
para crear una hoja de ruta realista. Por último, el contratista puede darte una
idea de la fecha de traslado real.

Consejo de experto: Aquí es donde puedes utilizar una herramienta como los
cronogramas de Jira para crear una hoja de ruta realista para tus equipos, tomar
decisiones basadas en datos y mantener a las partes interesadas al tanto de cómo
llevan el seguimiento tus equipos.

Genera la hoja de ruta

Paso 7. Compártela con el equipo y valídala.

Entrega tu nueva y reluciente hoja de ruta al equipo y valídala. Deja que sea el
equipo quien desglose los epics en historias y dé sus mejores estimaciones de
cuánto tiempo tardará en completarse el trabajo. Es posible que los techadores
tengan algún problema de calendario o que la empresa de cimentación se haya
quedado sin cemento, para lo que se tardará seis semanas en hacer el pedido.
Utiliza estos factores externos para validar tus suposiciones y realizar tus
estimaciones, y los pasos necesarios para completar los epics de manera más
precisa. También debes poner en práctica tu hoja de ruta teniendo en cuenta a
las principales partes interesadas, especialmente, si se requiere su aprobación
para avanzar con determinadas fases del proceso.

Paso 8. Sigue mejorando.

Con la metodología ágil, al igual que con la construcción de una casa, ningún
proyecto se termina jamás. Seguir proporcionando valor a través de mejoras
paulatinas es lo que impulsa la innovación y una casa letal. Utiliza tu hoja de
ruta para informar y optimizar hojas de ruta futuras. Solicita feedback a tu
cliente o tu familia, y sigue probando y mejorando de forma frecuente y
periódica.

Fuentes
=======

https://www.atlassian.com/es/agile/software-development/testing

https://www.zendesk.com.mx/blog/metodologia-agil-que-es/#

https://www.atlassian.com/es/agile

https://www.iebschool.com/blog/que-son-metodologias-agiles-agile-scrum/

https://www.atlassian.com/es/agile/project-management

https://www.atlassian.com/es/agile/software-development/developer

https://www.atlassian.com/es/agile/agile-at-scale/long-term-agile-planning