Estoy comenzando una compañía de software financiero y en el proceso he estado estudiando los principios y métodos ágiles y el aspecto del desarrollo que aún no he visto abordado es dónde encajar la necesidad continua de que los desarrolladores aprendan nuevas habilidades y tecnologías en el desarrollo proceso.

Antes de trabajar en software financiero durante los últimos años, pasé la mayor parte de mi carrera como programador de gráficos en 3D trabajando en videojuegos y software SIG y biométrico y siempre tuve que zambullirme en un precipicio y descubrir cómo para volar. Si bien siempre tuve éxito, estoy seguro de que no voy a vivir tanto como lo hubiera hecho si no me hubiera matado trabajando tantas horas, 100 semanas y meses a la vez.

Ahora que estoy comenzando una compañía de software que no tiene las intensas demandas innovadoras de los gráficos en 3D, quiero establecer un enfoque más holístico para el desarrollo.

Tal vez ágil simplemente no aborde esto, pero si lo hace, no he encontrado dónde y agradecería cualquier conocimiento o experiencia o experiencia que alguien tenga con esto.

Esto realmente no tiene mucho que ver con Agile, o incluso con Ingeniería de Software. Simplemente es cierto para cualquier empresa en cualquier negocio: debe reservar un tiempo para la capacitación. Período.

Agile tiene esta idea de "ritmo sostenible", lo que significa que, en ningún momento, el equipo debe trabajar más duro de lo que podría soportar por un tiempo indefinido. Es decir, no hay "tiempo de crisis". Esto también debe ser respetado por la capacitación. Por lo tanto, un ritmo sostenible para su equipo es "no más de 5 horas seguidas sin descanso, no más de 9 horas por día, no más de 40 horas por semana", y desea proporcionar un 10% de tiempo para el entrenamiento, entonces usted necesita planificar sus proyectos durante 36 horas semanales.

Pero, de nuevo, esto no tiene nada que ver con Agile, eso es solo sentido común y matemáticas de primaria.

Personalmente, pensaría que algo como permitir media hora por día, medio día por semana y una semana completa por trimestre permitiría al equipo adquirir fragmentos de conocimiento de diferentes tamaños rápidamente y a un ritmo constante.

También hay algunas prácticas ágiles que ayudan con la transferencia de conocimiento, es decir, para suavizar las diferencias en el nivel de conocimiento entre los equipos:

• retrospectivas diarias
• retrospectivas por sprint
• retrospectivas por proyecto
• programación en pareja
• emparejamiento de ping-pong (intercambiando el controlador y el navegador después de cada paso del ciclo rojo-verde-refactorizador)
• emparejamiento promiscuo (sin pares fijos, los pares se asignan al azar y se cambian cada mañana y almuerzo)
• número impar de miembros del equipo (si realiza programación de pares, deja a un miembro del equipo libre para aprender)
• programación de la mafia (una variante en la programación de pares donde todo el equipo usa una sola computadora y pantalla, un miembro designado del equipo es simplemente un "mecanógrafo" y los otros le dicen qué escribir)
• equipos promiscuos (los desarrolladores se asignan aleatoriamente a equipos todos los días / cada sprint)

La programación de pares y la programación de la mafia no solo proporciona una revisión continua del código sino también un intercambio continuo de conocimientos. El emparejamiento de ping-pong evita que una persona "acapare el teclado". El emparejamiento promiscuo difunde el conocimiento a través de todo el equipo, los equipos promiscuos difunden el conocimiento a través de toda la compañía y aseguran que cada desarrollador conozca cada proyecto y cada base de código; También conducirá a un alto grado de estandarización en la (s) base (s) de código. Si bien el enfoque principal de las retrospectivas es proporcionar retroalimentación sobre el proceso de desarrollo y adaptarse en consecuencia, también se puede utilizar para comunicar un problema poco común y cómo resolverlo.

No hay que decir que el empleador debe proporcionar una biblioteca extensa, suscripciones pagas a ACM, Springer, IEEE, etc., así como habitaciones silenciosas para estudiar y habitaciones más grandes para enseñar. Muchas pizarras y flipboards, así como los proyectores en todas partes son, por supuesto, sensibles en general, no solo para capacitación.

Voy a estar de acuerdo con la mayoría de lo que dijo Jörg W Mittag , pero no con la afirmación de que "esto realmente no tiene mucho que ver con Agile". Una serie de técnicas ágiles apoyan el aprendizaje y el desarrollo de individuos y equipos.

Los métodos ágiles tienden a basarse en incrementos o flujo continuo. En cualquier caso, el trabajo se ordena en función de factores como la prioridad, el valor y las dependencias. Dado que la atención se centra en el trabajo a corto plazo, el equipo puede identificar el conocimiento que se necesita para entregar y, si la falta de conocimiento es un problema, planificar para obtener ese conocimiento justo a tiempo. La visibilidad y la transparencia también tienden a ser aspectos clave de varios métodos ágiles, por lo que las partes interesadas pueden ver en qué está trabajando el equipo y cómo están trabajando para mejorar sus habilidades para entregar valor. Cuando es necesario un aprendizaje extensivo, se puede planificar en el futuro cercano o en la iteración actual.

Una vez que las personas en un equipo han adquirido conocimiento, existen técnicas en torno al emparejamiento y el mobbing. La programación en pareja es una práctica clave en la programación extrema que también se ha aplicado a otros métodos y está diseñada para, entre otras cosas, facilitar el aprendizaje. Mobbing es aplicar esto a más de solo dos personas. La estrecha colaboración y la funcionalidad cruzada de los equipos significa que no hay silos y esta información se difunde.

Incluso con la capacidad de planificar y ejecutar el aprendizaje de lo que es necesario para el trabajo inmediato, es muy importante contar con miembros del equipo bien informados. Tener personas con cierto nivel de conocimiento existente de las herramientas, la tecnología y el dominio les permitirá estar más informados cuando asuman tareas de aprendizaje y serán más efectivos al difundir el conocimiento a otros miembros del equipo.

Planifique una tarea de prueba de concepto para el sprint en el que desea presupuestar tiempo para aprender una habilidad. Manténgalo enfocado en algo muy específico, como aprender a crear una tabla HTML accesible. Programe tareas de prueba de concepto hasta que haya aprendido las habilidades necesarias para la historia. Dé a cada tarea POC algunos puntos de la historia y una fecha de vencimiento para que pueda marcar el tiempo adecuadamente y mostrar el progreso al final del sprint.

Entonces, ¿qué pasa si una historia solo debe ser de 5 puntos para un desarrollador experimentado? Tal vez se necesitan 3-4 tareas en 8 puntos cada una. Después de esas tareas de POC, la historia aún puede ser de solo 5 puntos, pero al menos se reserva el tiempo para aprender las nuevas habilidades para que la historia de 5 puntos no sea de 40 puntos, incluso si las tareas de historia y POC suman 40 puntos.

Scrum tiene la idea de una 'espiga'. Si el equipo está asumiendo una nueva tecnología o capacidad, un pico es una historia para encapsular ese trabajo. Entonces, si bien una historia en ágil es una funcionalidad enfocada en el usuario, el resultado de un pico es la documentación de lo aprendido y un desglose del trabajo para ponerlo en práctica en la aplicación real.

En la práctica, descubrí que es una buena forma de administrar al menos una capacitación a pequeña escala, suficiente para que los desarrolladores se pongan al día con un nuevo sistema o marco mientras siguen dando cuenta del cronograma.

No vi esto en las otras respuestas, por lo que quería agregar que muchas organizaciones comienzan gremios, capítulos o centros de excelencia en torno a las áreas de habilidades. Estos pueden ser temas amplios como la tecnología o temas específicos como React Native Development. Todo depende de si existe el interés de participar en su empresa.

De todos modos, estos grupos a menudo poseen la tarea de ayudar a las personas en el grupo a crecer profesionalmente. Esto crea un espacio separado fuera del trabajo para reforzar y expandir las habilidades tanto para las personas que usan esas habilidades todos los días como para las personas fuera de esa disciplina que están interesadas en el entrenamiento cruzado. Esta no es la única solución a este problema, pero parece ser cada vez más común.

Algunos otros ya mencionaron aspectos, pero solo quería compartir cómo encajo el desarrollo personal en un entorno ágil.

1. Desarrollo continuo

Esta es la más fácil, reduce tu capacidad en cada sprint hasta que tengas tiempo suficiente para hacer un desarrollo continuo. La parte difícil generalmente es apegarse a su plan, y también hacer el desarrollo si hay más tareas por realizar. Si tiene emergencias, puede sacrificar esta vez de vez en cuando, pero de lo contrario no.

Debido a que redujo su capacidad, cualquier cosa que haga en esta categoría está fuera de la preocupación directa de otros miembros del equipo, y probablemente no tengan muchas razones para preocuparse o actualizar la planificación específicamente en cada sprint individual.

2. Grandes esfuerzos durante un sprint

Lo que he encontrado es que si ha planeado algo con un impacto mayor (por ejemplo, 2 días de entrenamiento durante un sprint), debe actualizar el sprint para reflejar esto. No estoy seguro de cuál es la solución teórica para esto, pero a menudo he visto que las personas simplemente colocan la tarea de capacitación en la pizarra para asegurarse de que sea visible que alguien está ocupado con esto.

Alternativamente, podría corregir la capacidad de sprint del sprint específico, pero a menos que las personas observen con mucho cuidado su rendimiento / eficiencia medido, me mantendría alejado de esto. Especialmente en un equipo nuevo, la estabilidad es probablemente más valiosa que la precisión.

Agile es un conjunto de filosofías, mira el manifiesto, eso es TODO lo que es Agile, así que cuando dices cómo Agile puede resolver mis problemas, recomiendo aprender (mucho) más sobre Agile. Tomemos una implementación concreta de Agile: SCRUM. En SCRUM tenemos los conceptos de Sprint y picos. A través de estos dos artefactos, es posible lograr crear un presupuesto para el aprendizaje.

Si miras un sprint como un gráfico circular, puedes dividir las prioridades en función del tema, uno de esos temas puede ser ... ¡aprender nuevas habilidades!

Un pico es una tarea de investigación en un sprint que implica evaluar la viabilidad de algo, generalmente a través del aprendizaje.

Por último, lo que has estado haciendo todavía está sobre la mesa y puedes aprender MIENTRAS haces lo que sea que estés trabajando, en ese momento puedes intentar aumentar los puntos / capacidad de la historia para hacer frente al desafío técnico.

Para citar del Manifiesto Ágil mismo:

Individuos e interacciones sobre procesos y herramientas
Software de trabajo sobre documentación integral
Colaboración del cliente sobre negociación de contratos
Responder al cambio sobre seguir un plan

El énfasis es mío, destacando las partes que probablemente sean más aplicables para usted.

Básicamente, los desarrolladores ágiles bien entrenados pueden responder a los entornos cambiantes mucho mejor que aquellos que dejan petrificar sus habilidades.

Si puedo agregar mi propia definición de ágil, también podemos incorporar la "colaboración del cliente" a la mezcla. Creo que la mejor definición de ágil es la basada en la idea de agilidad: si el cliente (o el entorno) cambia radicalmente, ¿qué tan bien lo hace? Si está fomentando un entorno de colaboración con el cliente, ellos tendrán un interés personal en que su equipo sepa lo que están haciendo.