Curso básico de agile: Los principios del manifiesto (Parte 3)

Esta es la continuación de la publicación Los cuatro valores del manifiesto. Desde su sitio oficial pueden leer aquí en Español los 12 principios del manifiesto agile.

Mencionare algunos marcos de trabajo, Scrum y kanban. Además de una palabra de Scrum: Sprint. No se preocupen, los marcos de trabajo los veremos a detalle después de terminar de revisar los 12 principios.

Mi mentor de agile Naveed Khawaja, menciona que los valores son algo confusos o a muy alto nivel, fluffy stuff. Pero los principios nos ayudaran a darle un mejor significado a la forma de trabajo agile y ver la relación que tienen entre ellos mismos:

1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.

La prioridad siempre es el cliente, sea agile o metodologías tradicionales, lo que cambia es la dinámica que nos exige agile para llevar esto acabo. Veamos dos partes importantes en este principio:

  • mediante la entrega temprana …: Es necesario recibir comentarios de nuestros clientes cuanto antes posible y así fallar rápido. Si, es esperado que nada funcione correctamente en un inicio. Tradicionalmente al tener largas fases y un periodo de desarrollo relativamente largo, todo parece marchar muy bien en un inicio pero comúnmente termina muy mal: Cambios de último momento, al cliente no le gusto el diseño/color, esta función no era de la forma como se asumió, etc. Es por ello que marcos de trabajo como Scrum tienen entregables pequeños en periodos cortos.
  • software con valor: Entregar constantemente pero sin que funcione no es lo que nos pide este punto. Cada que entreguemos, tiene que ser una pequeña parte funcional. Por ejemplo, si se añade un botón, este tiene que funcionar. De aquí vienen temas como User stories y cake slice. No debemos separar las tareas de front-end y back-end. Una tarea debe ser estimada pensada en todo.

Expresar lo que realmente necesitamos es complicado, entender lo que otros necesitan es mucho más complicado. Si permitimos que nuestros clientes usen la aplicación constantemente mientras se encuentra en desarrollo, ayudara a desarrollar y entregar algo que realmente les generará mucho más valor en su día a día. Capaciten a su cliente para que comprenda que es normal que falle mientras se esta en desarrollo o pre-producción.

2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

Aquí hay un gran dilema con practicantes de agile: «Me piden cambios en cada momento y estos nunca terminan», «¡cada día cambian los requerimientos!». Existen industrias que cambian constantemente durante periodos cortos de tiempo o clientes que cuentan con una idea en un inicio y conforme usan nuestra aplicación deciden otras cosas o les vienen nuevas ideas, esto es normal y se debe aceptar.

  • … incluso en etapas tardías del desarrollo.: Claro que podemos cambiar pero debemos clarificar cuando serían estas ventanas de tiempo y en que momentos no es posible hacerlo.

Si llegan a utilizar un marco de trabajo como Scrum, una vez iniciado el compromiso del sprint (periodo o iteración de desarrollo corto), el equipo desarrollará y se comprometerá a terminar todas las tareas en ese dicho periodo (1, 2, 4 semanas, etc.). Si algo cambia o algo nuevo se pide, se agregará como tarea con su respectiva prioridad: para el siguiente periodo (itearación/sprint) una vez que el periodo actual (itearación/sprint) termine. No se puede ni se debe cambiar el alcance de un periodo (itearación/sprint) en curso.

Dependiendo que tan cambiante sea la industria, este periodo (sprint) puede cambiar, no es fijo, de esta manera se podrá terminar de desarrollar cierta funcionalidad y después continuar con los cambios nuevos.

Si los cambios son tan repentinos, existe otro marco de trabajo llamado kanban, es mucho más flexible y útil para estas situaciones, donde no hay forma de planear contingencias: ambientes caídos, problemas en producción y proyectos con un alto grado de incertidumbre. Es muy necesario capacitar al cliente en agile con el concepto: El alcance no esta comprometido. Solo el tiempo y el costo. Ejemplo: el costo de tu proyecto es de $30,000 en un periodo de 2 meses y no más. Pero no entregaremos las 100 cosas que pides, solo las más importantes para ti, quedarán cosas sin terminar, debido a cambios que surjan de tu parte (del cliente) o por la complejidad técnica, etc.

En cualquier situación, establezcan y dejen claro un modelo donde se acuerde el proceso a llevar para cambios tardíos.

3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.

La frecuencia en la que se entreguen nuevas versiones dependerá de la capacidad del equipo y de las necesidades. Sean disciplinados para entregar de manera constante en ese periodo acordado. Se debe considerar el periodo de sprint que estén manejando, en caso de trabajar con Scrum. Además de considerar el tiempo que les demora crear y desplegar una nueva versión, hasta qué ambiente se desplegará la versión (¿desde Dev a Test?, ¿a PreProd? o ¿hasta producción?).

A muchos les hará sentido un periodo de un mes, dos semanas, o por semana. Lo importante es tener un acuerdo y que este sea el menor tiempo posible. Donde ningún miembro del equipo tenga que hacer horas extras.

4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.

Romper con los silos es parte de la cultura agile. Asumir es el peor crimen que alguien puede cometer, es por ello que la comunicación y colaboración son clave para cualquier tipo de desarrollo y son prácticas muy valoradas.

En los casos, que los clientes se encuentren en otras ciudades o países. Donde no es posible tener a todo el equipo en la misma área geográfica (si, el negocio también debe ser considerado parte del equipo), se debe establecer desde el contrato, la necesidad de un representante del cliente o del negocio, para que este acuda a las reuniones del equipo de desarrollo, ayude con las dudas sobre los procesos de negocio y sobre todo, pueda decidir cual es la prioridad del trabajo a seguir. Este representante tendrá que conocer la visión y meta del proyecto.

Es difícil entender el lenguaje de los clientes desde nuestra perspectiva técnica, no puedo expresar mi duda o inquietud con facilidad, para estás situaciones contar con alguien en el equipo con el oficio del analista de negocios, que pueda fungir como ese proxy o puente entre el área de TI y del negocio, sería lo más ideal.

De no ser posible, mínimo, se debe tener al equipo de desarrollo en el mismo lugar (desarrolladores, testers, diseñadores, etc.) y así disminuir a menor medida problemas de comunicación o mal-interpretación.

Desde mi humilde opinión: de nada sirve separar por área o piso a los empleados dependiendo de su oficio u especialidad: desarrolladores, diseñadores, arquitectos, gerentes, administrativos, testers, calidad, etc. No existe tal cosa como el equipo de desarrollo, el equipo de pruebas, etc. todos somos un equipo.

Para discutir, compartan en los comentarios:

  1. ¿En su empresa, equipo o área de trabajo siguen estos principios?
  2. ¿Qué dudas tienen sobre los primeros principios?

Fuentes:

Gracias por compartir tu opinión en esta nota

Para que tu avatar aparezca en los comentarios de este y otros blogs debes ser usuario registrado en Gravatar, puedes registrarte en el siguiente enlace: http://en.gravatar.com/site/signup
Stay Geek!

Deja un comentario

Sitios Amigos
Únete en Facebook
Publicaciones Favoritas