Una metodología de desarrollo flexible es una gran idea que es demasiado complicada. Agile Lite es un intento de simplificar la situación. No necesita libros o seminarios para explicar Agile Lite. Solo se necesita un pequeño texto con algunos puntos. Aquí está el texto.

Agile Lite es bastante simple. Se puede aplicar a cualquier proyecto, siempre que el trabajo se divida en tareas más pequeñas (problema). Al igual que otras metodologías ágiles, utiliza ciclos de desarrollo cortos: sprints. Pero a diferencia de ellos, Agile Lite reconoce claramente la prevalencia del agotamiento en la industria del desarrollo de software y trata de mitigarlo directamente mediante la introducción de un ciclo de desarrollo de tres semanas / una semana de descanso.

Reglas básicas:

• La primera semana de cada ciclo, los gerentes de proyecto, los desarrolladores y otras partes interesadas determinan el próximo sprint. Aunque se ha reservado una semana, la planificación del sprint no tomará más de dos horas, y con la organización correcta, tomará aproximadamente 45 minutos. Esta es una semana intencionalmente fácil: muchos simplemente pueden tomarse unas vacaciones para surfear, pintar u otra cosa.
  
• Sprint corre durante las tres semanas restantes. Durante este período, los ingenieros trabajan en las tareas que se les asignan durante la planificación. Dado que los empleados pueden ser remotos y distribuidos en zonas horarias, las reuniones en vivo no son frecuentes, y la mayoría de la comunicación se realiza a través de un rastreador (que funciona más rápido que el correo electrónico). Un tablero kanban común como Trello está bien, y una hoja de cálculo es poco probable. No se recomiendan los planeadores diarios: el pulso general del proyecto se rastrea completamente mediante actualizaciones de rastreadores.
  
• Una vez que comienza el sprint, no puede agregar tareas al sprint, pero puede eliminarlas. Esto reduce el cambio de contexto, lo cual es bueno.
  
• Las tareas no finalizadas se consideran en la próxima sesión de planificación del sprint, y se decide mover la tarea al siguiente sprint, devolverla a la lista de deseos o reasignarla a otro desarrollador.
  
• Cada tarea está en la lista de deseos o en el sprint actual. Cada tarea debe tomar de 4 a 8 horas en completarse.
  
• Como ya se mencionó, se aconseja a los desarrolladores que descansen durante la semana de planificación para que el cerebro se recupere del sprint anterior. Esto no es una cruzada. Los desarrolladores no trabajan los fines de semana. Todo esto ayuda a evitar el agotamiento, lo cual es útil para todos.

Aunque el trabajo principal en el sprint se puede planificar, a veces sucede algo inesperado. Estos problemas inesperados se denominan problemas de soporte.

Durante la planificación del sprint, sugerimos asignar tiempo para resolver tareas de soporte que no son susceptibles de planificación. Por ejemplo, "durante el próximo sprint, Dave tiene 12 horas para resolver tareas de soporte (cuyos detalles se determinarán más adelante)". A menudo es útil mantener la rotación, donde los desarrolladores responsables de los problemas de soporte cambian en cada sprint.

Para mejorar la precisión del pronóstico, en cada sesión de planificación del sprint, se analiza la cantidad de trabajo de apoyo realmente realizado en el sprint anterior, y se toma una decisión sobre si lleva más o menos tiempo apoyar el siguiente sprint.

En la práctica, diferentes grupos tienen diferentes definiciones para las tareas de soporte. Quizás esto significa atención al cliente / cliente. Quizás el apoyo de otros desarrolladores. Depende de usted decidir qué elementos de esta metodología general son los mejores para su equipo.

Al eliminar la complejidad innecesaria, Agile Lite es la mejor y más sostenible forma de desarrollar software. Ayuda en el desarrollo, al tiempo que garantiza un alto nivel de productividad constante.

Lite ágil para desarrolladores

Si no eres nuevo en la industria, es posible que hayas experimentado agotamiento. Tiene muchas razones, pero la forma más fácil de describir el agotamiento es el resultado de trabajar demasiado bajo demasiado estrés durante demasiado tiempo.

Todo comienza con un proyecto. Cada proyecto tiene una especificación detallada y una fecha límite. Cuando la especificación cambia, la fecha límite no lo es. Al final, llega la fecha límite, y la especificación se ha convertido en algo diferente de donde comenzó. Por supuesto, esto es considerado como su culpa, y se le pide que se quede hasta tarde o que "estire el objetivo". Como resultado, usted trabaja todos los fines de semana, pero independientemente de sus esfuerzos, el gerente siempre está insatisfecho y el proyecto está constantemente "retrasado".

Queriendo ir de vacaciones o vacaciones, parecerá un holgazán que no apoya al equipo. Puede estar trabajando en una oficina abierta; todos saben cuándo alguien viene y se va, y todos firman un contrato tácito para no trabajar menos que otros. Por lo tanto, las personas saben cómo verse ocupadas. Cuando alguien pregunta cómo estás, simplemente respondes: “¡Ocupado! Estoy tan ocupado!

Pero al final, algo sucede. Puede cambiar de trabajo, pero generalmente son otras compañías en la industria del software. Tal vez le das todas tus fuerzas para completar la devastación, y luego la compañía te deja ir, porque ya "no encajas en la cultura". Quizás renuncies y comiences a intercambiar autos, porque la programación es demasiado frustrante. Como dice el refrán, si quieres perder el placer de un pasatiempo, trata de ganar dinero con él.

Te ofrezco una solución. Esta es una forma ágil que está claramente diseñada para evitar el agotamiento: Agile Lite. No hay horas extras de trabajo. El trabajo de ingeniería está en marcha, y los desarrolladores tienen tiempo suficiente para recargar sus cerebros. Los gastos generales de gestión son mínimos.

Casi todo el sistema se describe en los seis puntos anteriores. Se puede cambiar de acuerdo a sus objetivos. Pero me gustaría destacar una característica de Agile Lite. Aquí decimos explícitamente: “Oye, los equipos flexibles se agotan de la misma manera que en otras metodologías de desarrollo. Puede valer la pena escribir reglas explícitas para evitar el sobrecalentamiento del motor, que es el equipo de ingeniería ".

Dejemos de sobrecalentar los motores. Tenemos mucho trabajo De hecho, este es un pozo sin fondo. Pero la vida es demasiado corta para gastarla completamente en trabajo, estrés y, en última instancia, agotamiento.

Agile Lite para gerentes

¿Tu empresa tuvo problemas con los desarrolladores? ¿A menudo los proyectos no cumplían los plazos? ¿Has trabajado con desarrolladores que comienzan perfectamente, luego se degradan lentamente y luego desaparecen? Quizás este es un programador talentoso que ha experimentado agotamiento.

Burnout es extremadamente común en la industria del software y es una razón clave por la cual muchos proyectos de software fallan. El agotamiento se puede describir mejor como síntomas del trastorno de estrés postraumático asociado con un proyecto u organización dado. Por ejemplo, el cerebro parece apagarse y usted siente una ansiedad extrema ante la mera mención de cierto proyecto. Esto es agotamiento. Un desarrollador en este estado, muy probablemente, no podrá continuar trabajando en este proyecto, y en proyectos posteriores no podrá trabajar con toda su fuerza. Burnout puede paralizar una carrera.

Esto es similar a hacer funcionar un motor de automóvil a altas velocidades durante mucho tiempo sin agregar aceite o combustible. Al final, este motor se descompondrá y será difícil volver a armarlo.

Los principios básicos de Agile Lite se describen anteriormente y están sujetos a cambios de acuerdo con sus objetivos.

Preguntas frecuentes + declaraciones típicas

La única regla general en el mundo del desarrollo ágil es que todos lo hacen mal. @fwip

Entonces, ¿los ingenieros tienen 12 semanas de descanso al año para practicar surf y pintar? ¿Cómo funcionará esto en un mundo donde el trabajo de 9-00 a 21-00 seis días a la semana se convierte en la norma?

Creo que sus desarrolladores deberían descansar tanto como lo necesiten.

Observo que la semana laboral de 40 horas se consideró una idea radical. Google comenzó con el 80% del tiempo de trabajo para grandes proyectos, ahora tenemos el 75%, me gustaría reducirlo al 10% (método Ferris) para fines de la década de 2020.

El sistema 996 (de 9 a.m. a 9 p.m., 6 días a la semana) es el enfoque opuesto, que busca extender la semana laboral de 40 horas a una de 72 horas. Veo esto como una regresión y creo que deberíamos dejar de fetichizar las horas extras. De hecho, no aumenta la productividad.

Además, usted decide qué hacer durante la "semana de descanso": irse de vacaciones, asignar una carga de trabajo más ligera u otra cosa. La respuesta puede depender de la semana en particular.

Quizás la "semana fácil" sea más fácil para las personas que la "semana de descanso". Use lo que sea más conveniente para usted.

El surf y la pintura no son obligatorios, se dan simplemente como ejemplos. Yo mismo ni siquiera surfeo y pinto.

¿Se asignan tareas a las personas o ellas mismas predicen lo que obtendrán?

Ellos predicen. Está bien si tus estimaciones son incorrectas. Esto es parte del proceso, y todo en un solo equipo.

¿Podría llamarse iteraciones en lugar de sprints?

Por supuesto! Sprint es adecuado para mí.

¿Es posible hacer una iteración deslizante en el estilo kanban, donde las fechas de inicio y finalización varían y dependen de las circunstancias?

Realmente aprecio el concepto de un ciclo de trabajo con ciertas fechas de inicio y finalización, y definido por un bloque de tareas. Las iteraciones deslizantes que no están sincronizadas con un ciclo particular lo arruinarán.

¿Por qué exactamente tres semanas de sprints?

Porque el desarrollo más la recuperación se ubica en 13 espacios por año. Cuando se completa el ciclo, comienza uno nuevo. Una semana de "descanso" le permite reiniciar antes del inicio de un nuevo sprint. Se trata de lograr una cadencia e intervalos claros y consistentes.

¿Significa esto que las fechas de inicio y finalización de los sprints a menudo caen a mediados del mes calendario?

Si

¿Los desarrolladores están involucrados en la planificación del sprint?

Si No tienen prohibido asistir a la reunión. Simplemente no es necesario, especialmente si el rastreador de tareas funciona bien, y el equipo discutió algunos de los puntos para el próximo sprint durante el anterior.

Estoy por menos reuniones. A pocas personas les gustan. Si eres uno de esos, entonces no cuentes conmigo.

¿La planificación de un sprint lleva una semana?

No, ese es el punto. Esta es una semana fácil.

¿Son los stand-ups realmente un problema?

En mi experiencia, sí. Por lo general, todos están de pie en un círculo, escuchando a una persona durante 20 minutos. Por supuesto, este es el enfoque "incorrecto", pero nunca he visto a nadie hacerlo bien, y preferiría abandonar por completo los planeadores diarios. Aún más difícil (o al menos inconveniente) hacerlo cuando su equipo está distribuido geográficamente. Pero si son muy valiosos para ti, no dejes que te detenga.

¿Deberíamos hacerlo de esta manera?

No Nadie te obliga a nada. Estas son recomendaciones, no reglas.

Esto no es una religión.

Estas reglas son políticas solo en el sentido en que la propaganda de la semana laboral de 40 horas fue política.

Lo que funciona para usted puede no funcionar para otros. ¿Sabes sobre esto?

Estoy seguro de eso!

Reclamos frecuentes

No necesita hacer predicciones sobre el tiempo, porque las estimaciones son imposibles.

Los pronósticos se consideran pronósticos, no contratos firmados con sangre. Por lo tanto, si no se respetan, esto es normal. Haga todo lo posible y trate de hacer un pronóstico en incrementos de 4 horas.

No se puede confiar en los desarrolladores, y usted necesita hacer un seguimiento de todo su tiempo, porque así es como se hace el trabajo.

Realmente no estoy de acuerdo, pero no puedo explicar rápidamente por qué. Tenemos diferencias fundamentales en la cosmovisión.

Esto no es ágil.

Por supuesto, Agile, tiene razón en el título.

Esto no es realista.

Y aun así funciona.

Estás haciendo mal ágil.

Desafortunadamente, el problema con Agile es que no se puede hacer correctamente.