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.

No hay comentarios.:

Publicar un comentario