“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.
