El “desarrollo de software ágil” es una gran idea que ha sido complicada por las industrias de publicación y consultoría. Agile Lite es un intento de simplificar la situación. No necesita un libro o un taller para explicar Agile Lite. Solo necesitas un archivo de texto con varios párrafos. Este es ese archivo de texto.

Agile Lite es bastante simple. Se puede aplicar a cualquier proyecto con personas que trabajan en él, asumiendo que el trabajo se puede dividir en tareas de componentes más pequeños que solo llamaremos Issues. Al igual que otras metodologías ágiles, utiliza ciclos de desarrollo cortos llamados Sprints. De manera un tanto única, Agile Lite reconoce explícitamente la prevalencia de agotamiento en la industria de desarrollo de software e intenta mitigarla directamente a través de un ciclo de desarrollo de 3 semanas / 1 semana fuera.

La configuración básica es esta:

  • La primera semana de cada mes se pasa con los líderes del proyecto y las partes interesadas que definen el próximo sprint. A pesar de que se asigna una semana, una sesión de planificación de sprint no debe tomar más de 2 horas y probablemente unos 45 minutos si se realiza correctamente. Es una semana intencionalmente ligera y muchas personas simplemente pueden tomarse el tiempo para pintar o surfear o lo que sea.
  • El sprint tiene lugar durante las 3 semanas restantes del mes. Durante este período, los ingenieros trabajarán en los Issues que se les asignaron durante las sesiones de planificación de sprint. Debido a que el equipo puede estar totalmente remoto y distribuido en zonas horarias, las reuniones “en vivo” ocurren con poca frecuencia y la mayoría de las comunicaciones se realizan a través del issue tracking system (que es más rápido para trabajar que el correo electrónico). Un tablero kanban compartido como Trello es un sistema de seguimiento de problemas suficiente, pero probablemente no lo sea una hoja de cálculo. Se desalientan las reuniones diarias; se puede obtener un impulso básico en el proyecto revisando las actualizaciones del sistema de seguimiento de problemas.
  • Una vez que ha comenzado un sprint, los Issues no se pueden agregar al sprint, pero se pueden eliminar. Esto reduce el cambio de contexto y eso es algo bueno.
  • Los Issues que no se completaron durante el sprint se revisan en la próxima sesión de planificación del sprint y se decide si se avanza el Issue al próximo sprint, se vuelve a poner en el Backlog o se vuelve a asignar a un desarrollador diferente.
  • Un problema está en el backlog o en el sprint actual.
  • Como se mencionó, se recomienda a los desarrolladores que tomen la semana de planificación para permitir que su cerebro se recupere del sprint anterior. No hay marchas de la muerte. Los desarrolladores no trabajan los fines de semana. Todo esto ayuda a evitar el agotamiento. Evitar el agotamiento es bueno para todos.

Eso es practicamente todo. El sistema no prescribe realmente prácticas de ingeniería y creo que eso está bien. Las prácticas de ingeniería se pueden definir a nivel de proyecto.

El trabajo de soporte se realiza de forma rotativa porque a veces las cosas suceden de forma inesperada y deben tratarse, pero un número sorprendente de problemas puede esperar hasta más tarde..

Agile Lite es una forma mejor y más sostenible de desarrollar software. Empodera a los desarrolladores de software al tiempo que ofrece un nivel de productividad consistente y sólido a los interesados en el proyecto.

En fin

Espero que esta simplificada introducción les sea útil y les ayude a encaminar sus proyectos a este marco de trabajo. Dejen en los comentarios su criterio sobre esta u otra forma eficiente de trabajar en equipos no tan grandes.

Tomado de: https://github.com/davebs/AgileLite