Si ha estado trabajando en la industria del software durante más de unos pocos años, posiblemente haya experimentado agotamiento. Hay muchas razones para el agotamiento, pero puede describirse simplemente como el resultado de trabajar demasiado, bajo mucho estrés, durante demasiado tiempo.

Comienza con un proyecto. Ese proyecto tiene una especificación detallada y una fecha límite. Cuando la especificación cambia, la fecha límite no lo hace. Finalmente, la fecha límite llega y se va y la especificación se ha convertido en algo diferente de donde comenzó. Por supuesto, esto se considera su culpa y se le pide que se quede tarde o que se comprometa a “cumplir los objetivos”. Eventualmente, llegará todos los fines de semana y no importa cuánto trabaje, su gerente nunca está contento y el proyecto está perpetuamente “atrasado”.

Querer tiempo libre o vacaciones te hace parecer un vago. Te hace parecer como si fueras quien sostiene a tu equipo. Quizás trabajas en un entorno de oficina abierta; todos saben cuándo llegas allí, todos saben cuándo te vas y todos firman un contrato tácito para no ser la persona que no está trabajando más duro. Así que la gente se ve bien ocupada, y cada vez que alguien te pregunta cómo te va, simplemente respondes: “¡Ocupado! ¡Estoy tan ocupado!”

Pero al final algo da. Quizás cambie de trabajo, pero es más de lo mismo en otras compañías en la industria del software. Tal vez lo mantengas hasta que no quede nada y luego la compañía te deje ir porque simplemente “no encajas en cultura”. Tal vez renuncies y tomes un trabajo vendiendo autos porque la programación es demasiado frustrante. Como dicen, si quieres matar la alegría en un pasatiempo, trata de hacerlo para vivir.

Estoy proponiendo una solución. Es una forma de ágil que está diseñada explícitamente para ayudar a evitar el agotamiento. Yo lo llamo Agile Lite.

  • La regla más básica es esta: cada mes incluye un sprint de 3 semanas y una semana “off” donde se realiza la planificación del sprint. 3 semanas de desarrollo / 1 semana de descanso.
  • Un sprint contiene Issues y los ingenieros resuelven Issues, registran las preguntas pertinentes y actualizan el Rastreador de Problemas(Issue Tracker).
  • Una vez que el sprint ha comenzado, los Issues no se pueden agregar al sprint, pero se pueden eliminar. Esto reduce el cambio de contexto y eso es algo bueno.
  • Un Issue es cualquier unidad de trabajo que deba tomar entre 4 y 8 horas de esfuerzo de ingeniería. Un Issue está en el sprint actual o en el backlog.
  • Cualquier Issues en el sprint actual que no se haya completado al final del sprint se revisará durante la semana de planificación del sprint.
  • No hay horas extras de trabajo. No puede haber marchas de la muerte. A los ingenieros se les asigna una cadencia mensual de trabajo y se les da tiempo suficiente para recargar sus cerebros. La sobrecarga de gestión es mínima.

Eso es prácticamente todo el sistema. Puede ser modificado para adaptarse a sus propósitos. Pero si hay un diferenciador de Agile Lite que me gustaría señalar, es que estamos diciendo explícitamente: “Oye, los equipos ágiles se están agotando tanto como otras metodologías de desarrollo, tal vez necesitamos construir reglas explícitas para evitar el sobrecalentamiento. El motor que es el equipo de ingeniería “.

Dejemos de sobrecalentar nuestros motores. Hay mucho trabajo que hacer por ahí. Un pozo sin fondo, de hecho. Pero la vida es demasiado corta para gastarla trabajando, estresada y, finalmente, agotada.

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

En fin

Les recomiendo que usen la herramienta Issues/Boards de gitlab en la que pueden organizar las tareas de manera rápida e integrarla al proceso de desarrollo pudiendo mencionar y manejar los issues desde los commit.

 

Alguna documentación: https://about.gitlab.com/2018/08/02/4-ways-to-use-gitlab-issue-boards/

Espero que 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.