domingo, 24 de abril de 2016

5 Claves prácticas para hacer planeación ágil sin morir en el intento


“El hombre que se prepara, tiene media batalla ganada".

Benjamín Franklin

A pesar que los métodos agiles están basados en no apegarse demasiado a un plan, sino más bien en una pila de trabajo, es recomendable tener una planeación inicial sobre la cual arrancar las labores de construcción del software. A continuación enlisto 5 claves prácticas que se pueden aplicar durante la planeación de un proyecto basado en un marco ágil:

1.-Tener una visión del proyecto

A pesar de que se puede tener la flexibilidad de ir clarificando los requerimientos del proyecto de forma evolutiva e ir adaptándose a los posibles cambios, es esencial iniciar con una visión de que se va a construir y por qué, no importa que se tenga a alto nivel, pero si es importante que todos los esfuerzos y requerimientos que se vayan identificando sobre el camino, estén apegados a dicha visión.

Tener una visión del proyecto evitara muchos dolores de cabeza y nos ayudara a no estar mezclando peras con manzanas.

Entregable resultante: un Documento de Visión o un documento que nos sirva como especificación de la visión del proyecto.



2.-Conoce a los involucrados y los resultados esperados

Es de suma importancia conocer los involucrados en el proyecto desde la perspectiva de cuáles son sus intereses y sus ámbitos de competencia, como podemos convertirlos en aliados para la ejecución del proyecto así como cuales son las vías de comunicación para trabajar con ellos. Es relevante también, determinar qué expectativas tienen del producto a construir; así como el rol que juegan dentro de la organización.

Teniendo definido los involucrados del proyecto y sus características, solo queda como punto final tener claro quien jugara el rol de promotor o Product Owner, el cual será nuestro enlace humano con los usuarios finales, quien validara los requerimientos y priorizara los intereses de la organización en relación con el proyecto.

Entregable resultante: Un documento de registro donde se especifiquen características de los involucrados.



3.-Conoce o define el core (núcleo) de la solución

Con la especificación de la visión del proyecto tendremos elementos para identificar cual será la columna vertebral del sistema, el core o núcleo de la solución, esto es muy importante porque a partir de este punto se sientan los cimientos de la solución.

Teniendo claro cuál es el core de la aplicación, una vez construido, será más fácil ir agregando capas de funcionalidad al software, de tal forma que la mayor parte de los cambios estarán en las funcionalidades que se cuelgan del núcleo.

Por las razones ya mencionadas es relevante que se dé especial atención al tiempo de análisis y desarrollo de las funcionalidades núcleo, con el objetivo de que en las primeras iteraciones quede lo más fortalecido, recordemos que es más fácil hacer modificaciones en las paredes y en el techo que en los cimientos de un edificio.



4.-Definir un mapa de funcionalidades

Es importante definir un mapa de funcionalidades en el cual se distribuyan de manera secuencial los requerimientos identificados en las sesiones previas de análisis, si los tenemos en historias de usuario mejor, mediante la definición de una secuencia lógica, como si fuera un proceso o una cadena de valor en la cual se presentan las características como si se tratara de un flujo de actividades.

Mediante esta actividad tendremos un mapa inicial de nuestra solución, e identificar posibles dependencias entre funcionalidades o requerimientos. Como se mencionó en la clave anterior ubicar también el core o núcleo de la solución como un elemento central de nuestro mapa.

Entregable resultante: Mapa de módulos de la solución, flujograma de proceso o un Story Mapping (Mapa de Historias).



5.-Definir tiempos tentativos para construcción y raleases (Lanzamientos)

Con el mapa de funcionalidades resultante, se puede iniciar con la definición de posibles iteraciones en las cuales se pueden estar construyendo los requerimientos; así mismo determinar en cual número de sprints podrían estar listos los releases para que los usuarios finales puedan usar la solución.

Entregable resultante: Product Backlog clasificado con los requerimientos clasificados por sprint y a su vez estos clasificados por release.




Es recomendable que durante la planeación se involucre a todo el equipo de trabajo, para dar diferentes puntos de vista y ayudar en la identificación de riesgos iniciales (tanto administrativos como técnicos) que muy difícilmente el Líder de proyecto podría visualizar solo.

martes, 19 de abril de 2016

Una historia dice más que mil palabras (Cont. 1)


Gestión de requerimientos y compromisos.-Haciendo mejores requerimientos mediante historias de usuario.



Como se ha podido ver en la entrada anterior, las historias de usuario pueden ser una técnica muy práctica al momento de identificar y concretar requisitos, tratando siempre de especificar detalles muy claros de lo que necesita y como lo requiere el usuario aplicado en el software.

Para determinar si estamos haciendo buenas historias de usuario que nos ayuden a tener información obtenida realmente útil para la construcción de las funcionalidades en el sistema, es importante recordar que las historias de usuario nos sirven para a iniciar una conversación centrada en requisitos muy particulares y las características de los mismos; así mismo permiten facilitar el camino de la exploración de requisitos, ayudando a que el usuario especifique los que requiere y como lo quiere (Criterios de Aceptación), pero solo el uso frecuente de esta técnica nos permitirá ir puliendo la forma de llevar una conversación más provechosa en la obtención de mejores requerimientos.

Para evaluar de forma inicial si nuestra historia de usuario es hasta cierto modo factible o correcta, es importante conocer sus características desde la visión del modelo INVEST: Independet, Negotiable, Valuable, Estimable, Small y Testable (En Inglés), que  transformado al español quedaría de la siguiente manera:

*Independiente: La historia de usuario no debe ser dependiente de otra, aunque para esta característica podemos hacer ciertas excepciones.

*Negociable: Puede ser negociable en el caso de que puede ser ejecutada durante una iteración; así como ser reemplazada por otra del mismo tamaño para su construcción.

*Valiosa: Debe generar valor al proyecto, negocio o los usuarios finales.

*Estimable: Puede ser estimada en tiempo y esfuerzo, dejando el mínimo de incertidumbre al programador para su construcción.

*Pequeña (Small): Debe ser lo más pequeña que se pueda, para poder cumplir con la característica anteriormente señalada.

*Testeable: Debe tener las características de presentación o comportamiento para ser testeada o en consecuencia que tenga criterios que determine que está terminada.



Ahora bien para detallar de forma un poco más completa la manera de mejorar nuestras historias de usuario, veamos como las características basadas en el modelo INVEST nos permiten ir filtrando los buenos requisitos de los ambiguos. Las características fueron ordenadas mediante una secuencia lógica de construcción y agregación de valor a la historia de usuario:

1.-Valiosa: La historia de usuario tiene que ser de utilidad y para saber esto recordemos que en la misma estructura de la historia, se especifica el “para que” es requerida. Mediante este sencillo prefijo conoceremos si genera valor para el usuario o está fuera del alcance.

2.-Pequeña: La historia de usuario debe ser lo más compacta posible, al referirnos a esto debemos buscar que siempre auto contenga solo una funcionalidad o satisfaga una sola necesidad a la vez; por ejemplo: Como responsable de ventas quiero realizar la consulta del índice de ventas semanal por región comercial para conocer cual tiene el mayor y menor índice de ventas, como se observa la especificación es muy concreta en lo que se requiere hacer y por lo tanto pequeña. No se entra en ambigüedades de alguna funcionalidad adicional.

3.-Independiente: Debemos procurar que nuestras historias sean independientes unas de otras de tal forma que puedan ser construidas sin impactar en labores de construcción de otra. Como vimos en la característica anterior, entre más auto contenidas sean las funcionalidades más independencia le daremos a la historia de usuario, pero en ocasiones para esta característica es conveniente hacer ciertas excepciones, puesto que en algún momento tendremos historias de usuario que inevitablemente tendrán relación con otra (dependencia), ejemplo:

·     Historia de usuario inicial: Como responsable de ventas quiero realizar la consulta del índice de ventas semanal por región comercial para conocer cual tiene el mayor y menor índice de ventas.

·         Historia de usuario dependiente: Como responsable de ventas quiero enviar comentarios o sugerencias vía correo electrónico a la región comercial con el menor índice de ventas.



4.-Estimable: Al tener en nuestra historia de usuario las características de ser pequeña e independiente, es más fácil dar al equipo de trabajo, y en un caso muy especial al programador, los elementos necesarios para que pueda determinar el esfuerzo (días de trabajo) que tiene que hacer para la construcción de ese requerimiento.

Para lograr una estimación más certera es conveniente que se divida la historia de usuario en tareas técnicas, las cuales nos especifican que se tiene que hacer para construir la funcionalidad, ejemplo: adecuación a una tabla en base de datos, codificación de una vista o procedimiento almacenado, configuración de un archivo o clase, diseño de formularios, etc.

5.-Negociable: Cuando una historia de usuario tiene una estimación razonable del esfuerzo requerido para su construcción, es más fácil tener argumentos para poder negociar ante los usuarios o el product owner (promotor del proyecto), para aquellos casos cuando se quiera cambiar el enfoque del requerimiento o se pretenda sustituir por otro durante una iteración que ya se tiene en ejecución.

6.-Testeable: La historia de usuario debe tener una serie de especificaciones que permitan determinar cómo debe ser testeada, tanto en su funcionalidad como en completitud, esto se logra mediante la especificación de criterios de aceptación, concepto el cual mencionamos en la entrada anterior. Al ser una funcionalidad auto contenida debe dar cierta facilidad ejecutar las pruebas, basado tanto en lo visual como en lo funcional.




Como podemos observar profundizar y armar las características de la historia de usuario bajo la secuencia de pasos anterior, del modelo INVEST, nos permite tener una guía para comprender que puntos debemos considerar al momento de obtener y armar mejores requerimientos basados en esta técnica.

miércoles, 13 de abril de 2016

Una historia dice más que mil palabras


Potenciando el desarrollo de software mediante el uso de historias de usuario.

Las historias de usuario son una técnica para representar una necesidad o requisito por parte de un usuario, y si es utilizado de manera ingeniosa puede servir también, para que el levantamiento de requerimientos sea de mayor provecho al arrojar detalles que durante una entrevista no tan fácil lograría satisfacer.
Antes de entrar en materia sobre sus posibles usos es conveniente conocer un poco más sobre las historias de usuario. Las historias de usuario como tal deben ser pequeñas y prácticas de tal manera que cuentan, de manera muy corta, una necesidad y su valor que aportan al negocio. Una historia de usuario debe permitirnos ser escrita en una pequeña tarjeta, nota o post-it de tal forma que evita la tediosa actividad de escribir una gran especificación de requisitos.



La sintaxis para escribir una historia de usuario puede ser la siguiente:

As a (User Role) Iwant to (Do this) so that (Achive that), que en español sería: Como (Rol de Usuario) Quiero (Hacer esto) Para (Alcanzar o lograr esto).

En términos más prácticos si nuestro proyecto estuviera orientado en el desarrollo de un sitio web para la venta de productos electrónicos, en lugar de hacer especificaciones completas como casos de uso tendríamos los siguientes ejemplos de historias de usuario.

1.-Busqueda por Nombre

Como Cliente quiero poder hacer una búsqueda de artículos por nombre para encontrar más rápidamente el producto que deseo comprar.

2.-Selección de varios artículos para agregarlos  al carrito de compra

Como Cliente quiero realizar una selección de diferentes artículos para agregarlos a mi carrito de compra.

3.-Realizar pago en línea de la compra

Como Cliente quiero realizar el pago en línea de mis artículos para concluir con mi compra.

Como nos damos cuenta, la forma de redactar una historia de usuario es completamente sencilla y especifica una necesidad usando el lenguaje de los usuarios, evitando la necesidad de especificar a gran detalle elementos de software.

Ahora para aquellos quienes tienen experiencia realizando análisis de sistemas mediante Casos de Uso o especificaciones de requerimientos, se preguntaran ¿Bueno y con esto puedo empezar a construir algo? , la respuesta es que no del todo, con la especificación de la historia de usuario acotamos el alcance de una necesidad. El detalle lo especificamos con los llamados “Criterios de Aceptación”.

Los Criterios de Aceptación no son otra cosa que aquellas especificaciones mediante las cuales podemos determinar que un requerimiento está completamente terminado, aporta detalles para la programación del mismo, define las fronteras de lo que se va a construir y también ayuda a los testers a verificar que puntos de la implementación tiene que probar.

Tomemos uno de los ejemplos anteriores:

1.-Busqueda por Nombre

Como Cliente quiero poder hacer una búsqueda de artículos por nombre para encontrar más rápidamente el producto que deseo comprar.

Y sus criterios de aceptación podrían quedar de la siguiente manera:

  •     Verificar que el texto introducido se pueda encontrar en cualquier parte del nombre del producto a buscar.
  •       Verificar que la lista de artículos encontrados los ordene de menor al de mayor precio.
  •          Verificar que los artículos presentados, por artículo, tengan los siguientes datos:


o   Imagen del artículo
o   Nombre Completo
o   Descripción
o   Precio

Como podemos observar los criterios de aceptación dan un poco más de luz al programador para que conozca exactamente que tiene que construir y también ayudan tanto a los usuarios, como al equipo de trabajo a delimitar el esfuerzo y complejidad del requerimiento.

Como se mencionó anteriormente la historia de usuario puede ser escrita en una pequeña tarjeta, nota o post-it, de acuerdo al tamaño de nuestra historia y sus criterios de aceptación, decidiremos el material que usaremos:

1.-Uso de post-it



2.-Uso de tarjetas



También para dar mayor soporte a las historias de usuario se puede reforzar con información adicional que los usuarios nos proporcionen para darle solides al requerimiento, como se muestra en el siguiente ejemplo:



Todo aquello de vaya relacionado con el requerimiento como prototipos en papel, información en archivos de Excel, reglas, cálculos, etc. puede ser entregado al programador como un paquete del requerimiento para su construcción.


Es conveniente que las historias de usuario sean escritas durante las entrevistas con los usuarios o durante un taller para la obtención de requerimientos e involucrar a los mismos sobre la importancia y el porqué de esta técnica, para apoyar en la mejor comprensión de la problemática ya que nos enfoca en conocer que parte del sistema aporta el mayor valor al negocio.

viernes, 1 de abril de 2016

Por qué RUP también puede ágil…


Agilidad es una de las tendencias en boga durante los últimos años dentro de los entornos de desarrollo de software como una  propuesta innovadora ante el eterno problema para generar valor a los usuarios, poder hacer ajustes ante ambientes cambiantes y controlar riesgos en los proyectos; muchos son los equipos que se han visto beneficiados ante el hecho de aplicar practicas agiles creando división entre las corrientes tradicionales y los agilistas, para lo cual marcos de trabajo como RUP han sido duramente atacados por promover procesos excesivamente pesados y burocráticos que se convierten más en obstáculos que medios para mejorar el trabajo.

Haciendo reflexión sobre las características de SCRUM así como las de RUP lleguo a la conclusión de que el problema no se encuentra en los métodos si no en las personas, desde el momento en que nos casamos con llevar un conjunto de buenas prácticas como técnicas que se tienen que llevar al pie de la letra y no como lo que son, “buenas prácticas”, nos convertimos en esclavos de las recomendaciones que alguien más definió o estableció y no como técnicas que pueden ser usadas en un contexto o en otro.

RUP se encuentra fundamentado en 6 principios clave los cuales son:
  • Adapt the process
  • Balance stakeholders priorities
  • Collaborate across teams
  • Demonstrate value iteratively
  • Elevate the level of abstraction
  • Focus continuously on quality
Si verificamos el primer principio: “Adapt the process – Adaptar el proceso”, se puede entender cómo adaptar el proceso al contexto del proyecto,  adaptarlo a las necesidades del cliente, ajustarlo a la naturaleza de los requerimientos y del negocio e identificar que sí puede ser aplicado y que no, tanto en roles, artefactos, herramientas así como en “buenas practicas, en resumen si el proyecto tiene un cierto nivel de incertidumbre y los requerimientos pueden ser cambiantes, ajustar RUP para que pueda ser ágil y efectivo ante este entorno podría ser adecuado, sin romper con la esencia del método.

Balance stakeholders priorities (Balancear las competencias entre los involucrados) y Collaborate across teams (Colaboración entre equipos), que se pueden interpretar o ligar al manifiesto ágil cuando se refiere a “Individuos e interacciones, por encima de los procesos y las herramientas” así como “Colaboración con el cliente por encima de negociación contractual”, balancear las necesidades, colaborar, comunicar, crear sinergias entre los individuos, etcétera; todo aquello que permita tener un adecuado flujo de interacción y comunicación dentro del proyecto.

Demonstrate value iteratively (Demostrar valor iterativamente), que al confrontarlo nuevamente con el manifiesto ágil encontramos  “Software que funciona, por encima de la documentación exhaustiva” entendiendo que valor al cliente en la filosofía ágil es el software funcional o productivo; así que en ambos lados de la moneda para los usuarios finales todo aquello que genere valor debe ser entregado al final de cada iteración o al final de cada sprint: software funcional, software funcional + documentación, documentación para cumplimiento contractual, etc.

En los 12 principios agiles tenemos el onceavo principio especificando lo siguiente: “La simplicidad como arte de maximizar la cantidad de trabajo que se hace, es esencial” y al contraponerlo con el quinto principio de RUP Elevate level of abstraction (Elevar el nivel de abstracción) se puede entender a este principio como enfocarse en lo esencial, lo más básico, lo más simple del problema, el proyecto o de los requerimientos; lo más mínimo funcional que satisfaga las necesidades de los usuarios finales; los detalles no prioritarios que refuercen al producto pueden venir después.

Focus continuously on quality (Enfoque continuo en la calidad) tomando en consideración que la agilidad y SCRUM proponen que el software entregado debe estar libre de errores para lo cual continuamente tendremos que estar haciendo entregas de calidad y el código debe estar en constante mantenimiento.

Creo fielmente que ambos marcos de trabajo tienen los mismos cimientos, pero al final el propósito de este pequeño recorrido comparativo es dar un poco de luz en donde considero convergen, se unen o fracasan las “buenas practicas” y es en el momento de querer implementarlas como un paso a paso y no como procesos adaptativos y ajustables en el momento de omitir los valores y principios que dan origen a una técnica u otra.  Considero que RUP se convirtió en excesivamente pesado desde el momento que fue llevado a la práctica como una maquinaria cerrada más que como una caja de herramientas adaptativa que se usa según la naturaleza de los problemas.

Las 6 habilidades que todo líder de proyecto debe desarrollar


Más que conocer las buenas prácticas en gestión de proyectos así como sus técnicas y herramientas, indistintamente de que metodología se use o se pretenda poner en práctica, todo administrador de proyecto debe desarrollar ciertos “Skills” que por lo general no vienen en las guías, manuales o tutoriales:

1.-Dominar el negocio

"Siempre es importante conocer el entorno y sus reglas en el más corto tiempo posible".

Es básico que dentro del proyecto se conozca en el más corto  tiempo todas las aristas que intervienen en el mismo (desde el marco teórico) pasando por las reglas de negocio, políticas y restricciones así como los actores y sus perfiles tanto personales como profesionales.

No se requiere forzosamente que convertirse en un experto del área, pero si es conveniente que asimilar en el más corto tiempo posible la mayor cantidad de detalles que permitan tomar decisiones más certeras identificando factores de éxito, restricciones, posibles riesgos y amenazas.

Un líder de proyecto que hable el mismo lenguaje de los usuarios y clientes inspira empatía y confianza anotándose puntos valiosos para que cuando sea necesario resolver conflictos o proponer mejoras.

2.-Se practico

"Se debe ser práctico en la toma de decisiones y resolución de conflictos".

Ser practico en la gestión de proyectos significa aprovechar de la mejor manera lo se tiene a la mano, incluso una circunstancia negativa puede ser un recurso valioso. Dentro del ciclo de vida del proyecto, en más de una ocasión; y para no evitar sobresaltos en etapas finales; es conveniente que las decisiones estén encaminadas en obtener los resultados más óptimos y rápidos para satisfacer las necesidades de los clientes.

Los recursos son limitados: tiempo, dinero, mano de obra, incluso el conocimiento; durante la ejecución es efectivo procurar que cada decisión tomada cumpla o satisfaga con el alcance del proyecto.

Es mortal usar recursos en prácticas que no generen mucho valor al alcance del proyecto como realizar reuniones con tiempos excesivos y para temas vánales, recursos destinados a cubrir requerimientos de poco valor o destinar presupuesto en actividades fuera del enfoque principal, etc. son solo algunos ejemplos.

3.-Visión, adelantarse a los hechos

"Anticípate a los golpes que te van a dar como a los que no has recibido".

Cualquier actividad desempeñada en el equipo como solicitudes de cambio o variantes en la temperatura del proyecto debe ser efectivamente detectada y analizada en frio, incluso antes de que se den los resultados ya ayuda a identificar por donde vendrán los golpes. Como administrador del proyecto encontraremos que esa intuición, conocimiento previo o sexto sentido, sobre lo que pudiese ocurrir, nos evitara de muchos dolores de cabeza y/o conflictos con los clientes o usuarios.

Debemos comprender que las circunstancias pueden tomar diversos flujos alternos y que en cada flujo puede generarse un impacto positivo o negativo para lo cual es razonable tener un plan B para cualquier acción preventiva así como correctiva y tomar la mejor decisión posible que se tenga a la mano.

4.-La Comunicación como un recurso estratégico

Para cumplir con los objetivos del proyecto es básico que se tenga un adecuado canal de comunicación con el cliente y los miembros del equipo. Uno de los recursos más valiosos y un aliado muy efectivo será la habilidad de comunicarse tanto como sea posible con el cliente, usuarios o el equipo de trabajo, sobre acuerdos, cambios solicitados, entregas o comunicados de interés para todos los involucrados.

5.-Promover y desarrollar la habilidad social

"Crear aliados estratégicos en todas las áreas del proyecto".

Al cliente no solo le interesan los resultados si no también que el ciclo de vida del proyecto sea lo más ameno posible y sin sobresaltos. Somos animales con habilidades sociales para lo cual podemos utilizarlas tanto para obtener la mayor cantidad de información posible como para la resolución de conflictos y/o diferencias.

Fomentar un ambiente ameno en la forma de trabajo en el cual se demuestre cierta flexibilidad y efectividad que permita al líder de proyecto y el equipo derribar barreras de comunicación o diferencias interpersonales; así como sortear obstáculos cuando se trate de trabajar en entornos socialmente complejos o con clientes muy difíciles.

Es fundamental tomar en consideración el hecho de no confundir amistad con el trabajo, lo principal siempre será entregar resultados en el más corto tiempo posible y en forma.

6.-Desarrollar la habilidad de decir “No”, pero con sutileza.

“El fracaso de la política consiste en tratar de quedar bien siempre con todos.”

François Mitterrand.

Aunque estemos en la posición de que somos un  producto que brinda un servicio para satisfacer una necesidad, no significa que todo lo que se solicite o se crea posible, es posible en el proyecto. Siempre, siempre se debe tratar de que nuestro cliente o usuarios tengan presente el alcance y objetivo del proyecto. Es común que conforme el equipo avanza y entrega resultados los involucrados solicitan mejoras emergentes las cuales pueden ser alcanzables, pueden ser requerimientos no identificados inicialmente o solicitudes que le dan valor al proyecto pero que no son un factor de éxito.

Es conveniente no movernos demasiado a los caprichos del cliente, aquí es conveniente mucha habilidad de negociación para que de manera muy sutil, en algunos casos, se les dé un sí, pero en otros casos se les dé un “No” y se justifique el porqué de forma razonable.
Toda solicitud nueva tiene que evaluarse desde la perspectiva de que estamos bajo cinco ejes de restricción: tiempo, alcance, presupuesto, recursos humanos y calidad. Involucrar al promotor del proyecto o al rol que aprueba los nuevos requerimientos o solicitudes de cambio es muy positivo y hacer de su conocimiento que todo evento en el proyecto tiene un impacto tanto para bien como para mal.

Al final de proyecto si algo sale bien o sale mal una gran parte, si no la mayoría, será responsabilidad del administrador del proyecto. La manera de negociar de forma transparente y con honestidad la ejecución de cambios drásticos de alcance, así como también hacer responsables a los clientes de sus peticiones necesidades, será de gran utilidad para no desviar el alcance del producto final.

Las habilidades anteriormente mencionadas seguramente no son las únicas, seguramente en el andar gestionando proyectos se podrán descubrir muchas más que se considere serán de utilidad para ser usadas como parte de la caja de herramientas en el día  a día.

Agilidad o Adaptación en el desarrollo de software



De todos es conocido, por lo menos para los que nos encontramos en la industria del desarrollo de software, que satisfacer las necesidades de los clientes no es una tarea sencilla y mucho menos cuando se trata de entregar resultados en lapsos de tiempo muy corto. Ya no existe tiempo para hacer un levantamiento exhaustivo de requerimientos, hacer uso del UML en todo su esplendor o elaborar especificaciones de casos de uso antes de digitar las primeras líneas de código, el tiempo hoy es un recurso limitado para lo cual el equipo de trabajo tiene como misión imposible comenzar la construcción de algo que apenas va teniendo forma por lo obtenido en sesiones cortas con el cliente y los usuarios finales.

La agilidad propone que el equipo de desarrollo de software se enfoque más con la premisa de entregar software funcional en iteraciones de tiempo relativamente cortas, por lo que los principios, técnicas y especificaciones de los métodos agiles se acoplan perfectamente a aquellos clientes que esperan tener una herramienta potencialmente usable en un lapso de pocas semanas. Construir software no es una tarea sencilla, el surgimiento de los métodos tradicionales como cascada o RUP surgieron para poner un poco de orden en el caos existente durante mucho tiempo en esta industria pero las reglas del juego han cambiado vivimos en un mundo donde los cambios ya no se dan en años si no en cuestión de meses, los mercados y las tendencias se mueven a una velocidad vertiginosa para lo cual la industria, las instituciones y las empresas de servicios tienen que renovarse constantemente para ser más competitivos, atraer más clientes o simplemente sobrevivir, los productos innovadores son requeridos en lapsos de tiempo muy tempranos y es aquí es donde la Agilidad hace su aparición como una opción para enfocarse en lo que realmente es importante.

Agilidad puede sonar como algo muy radical para construir software entendiendo que los métodos tradicionales surgieron para controlar las variaciones o incertidumbre mediante la ejecución de unas efectivas primeras etapas de compresión del dominio y diseño los requerimientos, pero cuando se trata de tener algo usable en tiempo record es cuando se requiere buscar otros medios. El concepto de Agilidad no pude tener mucho sentido si no hablamos que va tomado de la mano con la Adaptación. Agilidad y Adaptación son dos poderosas herramientas para crear software evolutivo e ir mitigando riesgos o la incertidumbre sobre los cambios drásticos de los requerimientos o alcance del proyecto.

Durante las primeras iteraciones del ciclo de desarrollo (preferentemente en lapsos no mayores de dos a tres semanas) es conveniente entregar el “core” de la solución, durante estas primeras entregas el cliente puede ir identificando si se ha entendido la esencia de la aplicación o existen requerimientos adicionales que se requieren incluir, dado el caso lo construido puede irse ajustando en las siguientes iteraciones, incrementado y dando forma de poco a poco al producto final, en otras palabras respondiendo rápidamente (Agilidad) y ajustando (Adaptabilidad) sobre la marcha.

Es importante recordar que agilidad no significa caos y desorden más bien ser práctico y veloz en la ejecución así como flexible en los ajustes, no solo del software sino también al proyecto y del equipo.

Enlisto a continuación a grandes rasgos como puedes usar la agilidad y adaptación en el día a día en tus proyectos:

1.-Inicialmente clarifica y aterriza la visión del producto final con el promotor del proyecto, mínimo a un alto nivel.

2.-Descubre, define, aclara y clasifica cuales son los requerimientos clave para que la solución pueda ser considerada exitosa.

3.-Planifica y ejecuta tus entregas en ciclos cortos. Trata de que en la primera iteración se construya el esqueleto de la arquitectura del software, sobre este esqueleto se irán agregando las capas de funcionalidad en las posteriores iteraciones.

4.-Durante la ejecución involucra activamente al promotor del proyecto para que en las entregas se tenga retroalimentación y se pueda evaluar si se están alcanzando las expectativas de los usuarios finales, de no ser así adapta el software, adapta el proyecto y adapta la forma de trabajar de tu equipo para obtener los mejores resultados posibles.