Estou iniciando uma empresa de software financeiro e, no processo, estudei princípios e métodos ágeis, e o único aspecto do desenvolvimento que ainda não vi abordado é onde ajustar a necessidade contínua de desenvolvedores de aprender novas habilidades e tecnologias no desenvolvimento. processo.

Antes de trabalhar em software financeiro nos últimos dois anos, passei a maior parte da minha carreira como programador de gráficos 3D trabalhando em videogames e software de SIG e biometria, e sempre tive que mergulhar de um penhasco nas coisas e descobrir como voar. Embora eu sempre tenha conseguido, tenho certeza de que não vou viver o tempo que teria se não tivesse me matado trabalhando tantas 100 horas por semana e meses por vez.

Agora que estou iniciando uma empresa de software que não possui as intensas demandas inovadoras dos gráficos 3D, quero estabelecer uma abordagem mais holística ao desenvolvimento.

Talvez o ágil simplesmente não resolva isso, mas, se o fizer, não encontrei onde e agradeceria qualquer conhecimento, experiência ou experiência que alguém tenha com isso.

Isso realmente não tem muito a ver com Agile, ou mesmo com Engenharia de Software. É simplesmente verdade para qualquer empresa em qualquer negócio: você precisa reservar um tempo para o treinamento. Período.

O Agile tem essa ideia de "ritmo sustentável", o que significa que, em nenhum momento, a equipe deve trabalhar mais do que aquilo que poderia sustentar por um período indeterminado de tempo. Ou seja, não "tempo de crise". Isso precisa ser respeitado pelo treinamento também. Portanto, um ritmo sustentável para sua equipe é "não mais que 5 horas seguidas sem interrupção, não mais que 9 horas por dia, não mais que 40 horas por semana" e você deseja fornecer 10% de tempo para o treinamento, então você precisa planejar seus projetos por 36 horas semanais.

Mas, novamente, isso não tem nada a ver com o Agile, isso é apenas senso comum e matemática da escola primária.

Pessoalmente, eu pensaria que algo como permitir meia hora por dia, meio dia por semana e uma semana inteira por trimestre permitiria à equipe adquirir conhecimento de diferentes tamanhos rapidamente e em ritmo constante.

Existem também algumas práticas ágeis que ajudam na transferência de conhecimento, ou seja, para suavizar as diferenças no nível de conhecimento entre as equipes:

• retrospectivas diárias
• retrospectivas por sprint
• retrospectivas por projeto
• programação em par
• emparelhamento de pingue-pongue (troca de driver e navegador após cada etapa do ciclo de refatoração de vermelho-verde)
• emparelhamento promíscuo (sem pares fixos, os pares são atribuídos aleatoriamente e trocados todas as manhãs e almoços)
• número ímpar de membros da equipe (se você emparelhar a programação, deixa um membro da equipe livre para aprender)
• programação mob (uma variante da programação em pares, em que toda a equipe usa um único computador e tela, um membro designado da equipe é simplesmente um "datilógrafo" e os outros dizem a ele o que escrever)
• equipes promíscuas (os desenvolvedores são designados aleatoriamente para equipes todos os dias / cada sprint)

A programação em pares e a programação mob não apenas fornecem revisão contínua de código, mas também compartilhamento contínuo de conhecimento. O emparelhamento de pingue-pongue evita que uma pessoa "monopolize o teclado". O emparelhamento promíscuo espalha o conhecimento por toda a equipe, as equipes promíscuas espalham o conhecimento por toda a empresa e garantem que todo desenvolvedor conheça todos os projetos e todas as bases de código; isso também levará a um alto grau de padronização na (s) base (s) de código. Embora o foco principal das retrospectivas seja fornecer feedback sobre o processo de desenvolvimento e se adaptar adequadamente, ele também pode ser usado para comunicar um problema incomum e como resolvê-lo.

Não é preciso dizer que o empregador deve fornecer uma biblioteca extensa, assinaturas pagas à ACM, Springer, IEEE etc., além de salas silenciosas para estudar e salas maiores para ensinar. Muitos quadros brancos e flipboards, além de projetores em todos os lugares são naturalmente sensatos em geral, não apenas para treinamento.

Vou concordar com a maior parte do que Jörg W Mittag disse , mas não com a afirmação de que "isso realmente não tem muito a ver com Agile". Várias técnicas ágeis suportam o aprendizado e o desenvolvimento de indivíduos e equipes.

Os métodos ágeis tendem a se basear em incrementos ou fluxo contínuo. Nos dois casos, o trabalho é ordenado com base em fatores como prioridade, valor e dependências. Como o foco está no trabalho de curto prazo, a equipe pode identificar o conhecimento necessário para fornecer e, se a falta de conhecimento for um problema, planejar a aquisição desse conhecimento na hora certa. Visibilidade e transparência também tendem a ser os principais aspectos de vários métodos ágeis, para que as partes interessadas possam ver no que a equipe está trabalhando e como estão trabalhando para melhorar suas habilidades de agregar valor. Quando um aprendizado extensivo é necessário, ele pode ser planejado no futuro próximo ou na iteração atual.

Depois que os indivíduos de uma equipe adquirem conhecimento, existem técnicas para emparelhar e mobbing. A programação em pares é uma prática fundamental na programação extrema que também foi aplicada a outros métodos e foi projetada para, entre outras coisas, facilitar o aprendizado. Mobbing está aplicando isso a mais do que apenas duas pessoas. A estreita colaboração e funcionalidade cruzada das equipes significa que não há silos e essas informações são disseminadas.

Mesmo com a capacidade de planejar e executar, aprendendo o que é necessário para o trabalho imediato, é muito importante ter membros da equipe com conhecimento. Ter pessoas com algum nível de conhecimento existente sobre as ferramentas, tecnologia e domínio permitirá que elas sejam mais informadas ao assumir tarefas de aprendizado e sejam mais eficazes ao disseminar conhecimento para outros membros da equipe.

Planeje uma tarefa de prova de conceito para o sprint no qual você deseja orçar tempo para aprender uma habilidade. Mantenha-o focado em algo muito específico, como aprender a criar uma tabela HTML acessível. Continue agendando provas de conceito até que você tenha aprendido as habilidades necessárias para a história. Dê a cada tarefa do POC alguns pontos da história e uma data de vencimento para que você possa cronometrar adequadamente e mostrar o progresso no final do sprint.

Então, e se uma história tiver apenas 5 pontos para um desenvolvedor experiente? Talvez seja necessário 3-4 tarefas em 8 pontos cada. Após essas tarefas de POC, a história ainda pode ter apenas 5 pontos, mas pelo menos você reserva um tempo para aprender as novas habilidades, para que a história de 5 pontos não seja de 40 pontos - mesmo que as tarefas de história e POC totalizem 40 pontos.

Scrum tem a idéia de um 'pico'. Se a equipe está adotando uma nova tecnologia ou capacidade, um pico é uma história para encapsular esse trabalho. Portanto, enquanto uma história no ágil é um pouco de funcionalidade focada no usuário, a saída de um pico é a documentação do que foi aprendido e um detalhamento do trabalho para colocá-lo em prática no aplicativo real.

Na prática, descobri que é uma boa maneira de gerenciar pelo menos o treinamento em pequena escala - o suficiente para atualizar os desenvolvedores com um novo sistema ou estrutura e ainda prestar contas ao cronograma.

Eu não vi isso nas outras respostas, então eu gostaria de acrescentar que muitas organizações iniciam guildas, ou capítulos ou Centros de Excelência em áreas de habilidades. Podem ser tópicos amplos, como tecnologia, ou tópicos específicos, como React Native Development. Tudo depende se o interesse em participar existe na sua empresa.

Independentemente disso, esses grupos geralmente possuem a tarefa de ajudar as pessoas do grupo a crescer profissionalmente. Isso cria um espaço separado fora do trabalho para reforçar e expandir as habilidades das pessoas que as usam todos os dias e até das pessoas fora da disciplina que estão interessadas em treinamento cruzado. Essa não é a única solução para esse problema, mas parece estar se tornando cada vez mais comum.

Alguns outros já mencionaram aspectos, mas eu só queria compartilhar como me encaixo no desenvolvimento pessoal em um ambiente ágil.

1. Desenvolvimento contínuo

Essa é a mais fácil, reduza sua capacidade em cada sprint até ter tempo suficiente para o desenvolvimento contínuo. A parte mais difícil é manter o seu plano e também fazer o desenvolvimento se houver mais outras tarefas a serem realizadas. Se você tiver emergências, poderá sacrificar esse momento de vez em quando, mas, caso contrário, não.

Como você reduziu sua capacidade, tudo o que você faz nesta categoria está um pouco fora da preocupação direta de outros membros da equipe e eles provavelmente não têm muitos motivos para se preocupar com isso ou atualizar o planejamento especificamente em cada sprint individual.

2. Maiores esforços durante um sprint

O que descobri é que, se você planejou algo com um impacto maior (por exemplo, treinamento de 2 dias durante um sprint), atualize o sprint para refletir isso. Não sei ao certo qual é a solução teórica para isso, mas vi muitas vezes que as pessoas colocam a tarefa de treinamento no quadro para garantir que seja visível que alguém está ocupado com isso.

Como alternativa, você pode corrigir a capacidade do sprint específico, mas, a menos que as pessoas olhem com muito cuidado o seu desempenho / eficiência medidos, eu ficaria longe disso. Especialmente em uma equipe nova, a estabilidade é provavelmente mais valiosa que a precisão.

Agile é um conjunto de filosofias, dê uma olhada no manifesto, é TUDO Agile, então quando você diz como o Agile pode resolver meus problemas, recomendo aprender (muito) mais sobre o Agile. Vamos dar uma implementação concreta do Agile: SCRUM. No SCRUM, temos os conceitos de Sprint e Spikes. Por meio desses dois artefatos, é possível realizar a criação de um orçamento para o aprendizado.

Se você olhar um sprint como um gráfico de pizza, poderá dividir as prioridades com base no tópico, um desses tópicos pode ser ... aprendendo novas habilidades!

Um pico é uma tarefa de pesquisa em um sprint que envolve avaliar a viabilidade de algo geralmente através do aprendizado.

Por fim, o que você está fazendo ainda está em cima da mesa e você pode aprender ENQUANTO está fazendo o que está trabalhando, e nesse ponto você pode tentar aumentar os pontos da história / capacidade de lidar com o desafio técnico.

Para citar o próprio Manifesto Ágil :

Indivíduos e interações em processos e ferramentas
Software de trabalho em documentação abrangente
Colaboração do cliente em negociação de contratos
Respondendo a mudanças ao seguir um plano

A ênfase é minha, destacando as partes que provavelmente são mais aplicáveis ​​a você.

Fundamentalmente, desenvolvedores ágeis bem treinados podem responder a ambientes em mudança muito melhor do que aqueles que permitem petrificar suas habilidades.

Se posso adicionar minha própria definição de ágil, também podemos incluir "colaboração do cliente". Acho que a melhor definição de ágil é aquela baseada na idéia de agilidade - se o cliente (ou o ambiente) muda radicalmente, como você lida com isso? Se você estiver promovendo um ambiente de colaboração com o cliente, eles terão um grande interesse em sua equipe, sabendo o que estão fazendo.