Como podemos tornar a agilidade agradável para os desenvolvedores que gostam de possuir pessoalmente grandes blocos do início ao fim?

Eu direi que existem muito poucas lojas de software que têm a sorte de ter a rara distinção onde o Agile realmente não faz sentido como uma metodologia. Se toda a sua equipe for composta por desenvolvedores de software verdadeiramente excepcionais, com profundo conhecimento dos aspectos do negócio e da longevidade da empresa e entre si, e se suas necessidades de negócios e necessidades do cliente forem sempre semelhantes e raramente sujeitas a alterações no meio de uma empresa liberação, então você tem a sorte de trabalhar em um ambiente tão raro, onde Agile provavelmente pode realmente ferir.

Ele é projetado para ser a abordagem mais eficaz em meio a exigências de negócios caóticas e em constante mudança e necessidades do cliente, evoluindo ou alterando os recursos do projeto e prazos apertados ou variáveis. Esse ambiente significa certa desgraça para o típico desenvolvimento em cascata, pois é vulnerável a mudanças de equipe no meio do projeto, vulnerável a mudanças de requisitos e extremamente vulnerável a mudanças de data.

Sinto por seus valiosos membros da equipe que não encontram mais alegria em seu trabalho. Eles podem muito bem ser pessoas excepcionalmente talentosas que se dedicam ao seu trabalho, mas no final, vários fatores fora de seu melhor controle ainda podem matar o projeto. A melhor maneira de abordar o desenvolvimento de recursos é perder a atitude e a expressão individual e pensar em termos da abordagem de equipe.

Se você achar que isso não funcionará para eles, poderá encontrar um uso especial para eles. Se eles são excepcionalmente talentosos e experientes, veja se eles estariam interessados em um papel arquitetônico, estabelecendo projetos de alto nível, abordagens, experimentando novas tecnologias e evoluindo as melhores práticas. Peça a essas pessoas que controlem e revisem a documentação de design.

Se isso não lhes convém, então talvez trabalhem separadamente em refatorações técnicas extremamente complexas em um ramo separado, protótipos imensamente envolvidos e prova de conceitos, ou outro trabalho pioneiro que às vezes precisa ser feito, mas não se encaixa. bem no escopo de um único projeto ou lançamento.

They just don’t find joy in work like they used to.

Correto.

Esse é um grande sintoma de que você está fazendo errado.

O Agile não deve impor uma nova ordem ruim às pessoas.

O Agile deve permitir que a equipe se organize automaticamente de uma forma que o torne mais eficaz.

Auto-organização significa que o gerenciamento não impõe regras estranhas. Não impõe horários ruins e não impõe interação desnecessária.

Some developers are primarily motivated by the joy of taking a piece of difficult work, thinking through a design, thinking through potential issues, then solving the problem piece by piece, with only minimal interaction with others, over an extended period of time

Por que eles não podem continuar fazendo isso?

Por que mudá-los?

Por favor, leia o Manifesto Ágil algumas vezes.

O Manifesto Ágil diz

Individuals and interactions over processes and tools

Não diz forçar as pessoas a trabalhar de uma maneira que seja desconfortável e improdutiva.

Se você forçar as pessoas a fazerem "interação" com muito pouco valor, você já foi longe demais.

Working software over comprehensive documentation.

Eles estão fazendo isso? Então, deixe-os em paz.

Customer collaboration over contract negotiation.

Você já está fazendo isso? Então não mude.

Responding to change over following a plan.

Onde essas pessoas já podem responder a mudanças? Se sim, então eles já eram ágeis. Eles não precisaram mudar.

minha empresa tentou (e ainda tentou, depois de anos tentando) fazer a mesma transição e, até agora, pessoalmente, não vi muito sucesso com isso. Durante esta transição, eu fiz um monte de leitura sobre desenvolvimento ágil e diferentes formas / aspectos / preocupações / técnicas e uma coisa que eu concordo strongmente é que o desenvolvimento ágil puro é mais adequado quando a equipe inteira é composta por pessoas de alta qualidade. (ou pelo menos todas as pessoas do mesmo nível).

Última versão Eu estava em uma equipe "ágil" que tinha IMHO muitos desenvolvedores com níveis de habilidade em todo o lugar e nós tentamos envolver todos no mesmo projeto. Foi um desastre. Fizemos mais conversas / discussões do que trabalho e, no final, o que a equipe produziu foi um trabalho mediano (leia Peopleware ou Mythical Man Month sobre como tirar a média). Esqueça os padrões de projeto, esqueça o baixo acoplamento ou quebre o código em pequenas classes e métodos. Esqueça tentar fazer algo interessante porque a) que não poderia ser explicado e entendido por todos os membros da equipe (pelo menos não em tempo hábil) eb) desde que nós éramos ágeis, o que eu comecei essa iteração, alguém com absolutamente nenhum entendimento continuaria na próxima iteração. Pessoalmente, eu simplesmente desisti e simplesmente esperei pelo scrum ou quem quer que me designasse tarefas, as fiz, fui para casa e codifiquei meus próprios projetos pessoais.

Eu absolutamente odiei o fato de que eu não poderia fazer nada com modelos C ++, ou escrever algumas bibliotecas de framework de baixo nível legais (mas um pouco complexas) que tornariam nossas vidas muito mais fáceis. Como algo assim pode ser feito quando ninguém na equipe é capaz de ler arquivos de cabeçalho STL, mas todos nós devemos estar trabalhando em uma coisa de cada vez. Todo o projeto acabou sendo recurso forçado por recurso bruto, porque é isso que o agile parece enfatizar.

Ao mesmo tempo, há poucas pessoas (muito poucas) na minha empresa que eu adoraria trabalhar lado a lado e compartilhar todo o meu código.

Mas agora você enfrenta uma escolha. A) Pegue todos os seus bons desenvolvedores seniores que produzem código de alta qualidade e os colocam em sua própria equipe e colocam o restante em uma equipe separada. Ou B) tentar equilibrar as equipes e colocar as boas com as menos boas. Em (A), o problema é que uma de suas equipes terá um desempenho muito baixo e não obterá boas habilidades / hábitos dos mocinhos. Em (B) seus mocinhos (em ambiente puro e ágil) se sentirão frustrados e começarão a trabalhar em seus currículos. O meu está atualizado.

Então, o que você vai fazer?

Eu não sei se esta é a solução correta. Pergunte-me novamente daqui a cerca de um ano. Mas e se, em vez de "pura e ágil", você formar uma equipe, mas identificar claramente qual (is) pessoa (s) tem mais influência (design, revisão de código ...) e garantir que essa pessoa compreenda isso e seja recompensada por uma responsabilidade extra. À medida que os membros da equipe começarem a trabalhar juntos, identifique aqueles que estão adotando bons hábitos / práticas e elevá-los ao mesmo nível que suas boas pessoas. Espero que, enquanto as pessoas gastarem um release ou dois trabalhando juntas, elas aprendam o que a outra pessoa está pensando e como ela funciona, para que seja mais compatível trabalhar no mesmo código ao mesmo tempo. Mas até que isso aconteça, se você simplesmente jogar as pessoas em um projeto, não será nada além de frustração (novamente, apenas minha opinião). Desta forma, se os seniores tiverem que trabalhar com os menos experientes, pelo menos eles terão mais peso (não ditadura, apenas mais peso) na tomada de decisões.

Alguns dos meus pensamentos são baseados em como comecei profissionalmente em software. Quando eu era cooperativo, trabalhei com um cara que era meu mentor. Ele me ensinou tudo, desde codificação de ética a um bom design, até a leitura de milhares e milhares de linhas de código que você não escreveu. No começo, não estávamos nem perto do mesmo nível e seria risível se fôssemos colocados em uma equipe ágil e disséssemos que podemos trabalhar no código uns dos outros. Mas ao longo do tempo (alguns anos), começamos a pensar muito parecidos. Eu pude entender seu código com um simples olhar e ele me disse várias vezes que ele não tinha absolutamente nenhum problema (e ficou surpreso com isso) navegando pelo meu código que ele nunca viu antes. Isso levou anos, não algo que aconteceu durante a noite. Depois de experimentar um desastre após desastre em um ambiente ágil nos últimos anos, eu pulava em um piscar de olhos com a chance de trabalhar junto com esse cara em um time ágil

Esta não é realmente uma resposta, mas resume minha experiência / observações. Eu quero ver o que os outros diriam sobre isso.

O que é o Agile?

É:

• um conjunto de regras que você deve seguir para alcançar o que os definidores de regras pretendiam?

• uma abordagem best-adivinha para fazer as coisas dentro de seus pontos strongs, requisitos e limitações?

Se você acha que o Agile é o primeiro, e você sempre segue todas e cada uma das regras do Scrum e se preocupa constantemente, esteja você certo ou não, talvez este link esclarecerá um pouco para você.

Se você acha que é mais sobre o segundo, então parabéns - você 'get' Agile. Qualquer metodologia Agile só pode ser uma sugestão de como fazer as coisas. Se qualquer aspecto do seu método ágil escolhido não lhe parecer certo, então você tem o dever de parar de usá-lo, alterá-lo ou ser de alguma forma ágil sobre ele. O importante é que você consiga algo, que não seja retido por restrições artificiais - não apenas aquelas que todos nós conhecemos e amamos em nossos velhos dias de queda d'água, onde o PM o incomodava por diagramas completos documentados que ninguém jamais faria. leia apenas porque "é o que o processo diz para fazer", mas também das restrições de como você está usando. Se um scrum diário parecer uma restrição, não os pisque! Para cegamente tê-los porque as regras dizem que não é mais ágil do que os velhos modos.

Agora, se você tem alguns caras que fazem as coisas sendo trancados em um cômodo com apenas um litro de cola e uma escotilha para pizza, então utilize esse fato. Dê a eles alguma parte do sistema que seja mais autossuficiente e bloqueie-os. Quando terminarem, você deve fazê-los integrar esse trabalho (ou fazer com que outra pessoa faça isso, se preferir) com o restante do sistema.

Alistair Cockburn descreveu isso em seus métodos. Se você tem "praticantes de nível 3", então um método ágil perfeitamente válido é o seguinte:

“Put 4-6 people in a room with workstations and whiteboards and access to the users. Have them deliver running, tested software to the users every one or two months, and otherwise leave them alone.”

Como você tem um mix de pessoas, você precisa encontrar uma maneira de fazê-las trabalhar juntas de maneira construtiva, e isso significa que uma abordagem de tamanho único não será muito eficiente. Então, você precisa dividir as tarefas, garantindo, ao mesmo tempo, que o objetivo comum seja enfatizado. É ok enviar esses caras para o código, mas eles precisam estar cientes de como o material deles será parte integrante do resto do trabalho da equipe e que não conseguir isso é uma falha de qualquer coisa que eles estejam produzindo . Uma vez que eles entendam isso (ou seja, eles não podem simplesmente fazer o que quiserem e entregar algo inutilizável), então seu trabalho está feito.

Digamos que o ágil não é para todos e que o ágil não é para todos os projetos. No mesmo tempo ágil é um termo muito amplo e o Scrum é apenas uma implementação de um processo ágil - eu posso de alguma forma dizer a implementação com provavelmente a maioria das restrições que tentam configurar processos padronizados com passos bem conhecidos.

Outra área para pensar é qual é o propósito da agilidade? É ágil sobre a maneira como os desenvolvedores trabalham? Talvez - algumas metodologias realmente sigam essa direção. Mas o ágil em si abrange áreas fora do desenvolvimento. O Agile tem mais a ver com a condução de todo o processo, a maneira como uma interação funciona, a maneira como você entrega o produto com os recursos mais importantes no prazo e como você controla os recursos, como vê onde está no projeto etc.

Existem metodologias que não tentam mudar nada do seu processo de desenvolvimento - o Scrum não é o único. Todas as metodologias ágeis enfatizam a melhoria contínua. Você detectará alguma etapa ineficiente em seu processo e tentará melhorá-lo / alterá-lo - essa é a maneira ágil. Verifique outra metodologia ágil popular - Kanban.

Você / Sua empresa decidiu usar o Scrum e isso pode levar ao fato de que algumas pessoas não gostarão dele e sairão. Você deve lidar com cada um dos seus desenvolvedores separadamente. Você deve falar sobre isso com cada um e você deve tentar encontrar alguns interesses que lhes permitam desfrutar do trabalho novamente.

Eles podem ter o papel de mentores, podem ensinar aos outros, mostrar a eles como refatorar o código para melhorar a arquitetura ao trabalhar iterativamente. Eles podem formar juntos alguns esquemas de arquitetura global usados nos projetos. Eles também podem trabalhar em provas de conceitos, participar de RFI (solicitação de informações) quando os clientes fazem perguntas para pensar sobre a viabilidade de requisitos. Eles podem trabalhar em pares com desenvolvedores menos qualificados e fazer a complexa tarefa juntos, etc. Seu principal valor deve ser usar suas habilidades e permitir que outros aprendam com eles.

Scrum e agilidade global de fato, de alguma forma, mantêm os indivíduos e priorizam as equipes - as equipes entregam aplicativos, não indivíduos. Essa ideia é baseada no fato de que você nunca terá uma equipe em que todos tenham o mesmo conjunto de habilidades e experiência.

Se a sua transição para o Scrum for bem-sucedida, eles deverão ver que o processo geral melhorou, os prazos de entrega foram reduzidos, a qualidade melhorou e os clientes ficaram mais satisfeitos. Eles ainda podem acreditar que os aplicativos desenvolvidos em si são muito piores do que poderiam ser, mas esse é o ponto - o cliente não quer o melhor código já escrito. Os clientes querem o código de trabalho mínimo / mais barato / mais rápido que satisfaça suas necessidades. Se a força bruta é suficiente para isso, então seja. Isso é algo que pode causar problemas a desenvolvedores altamente qualificados, mas não é falha de agilidade, é o lugar onde as demandas de negócios e o perfeccionismo vão um contra o outro.

Isso beneficiará toda a equipe se você resolver alguns dos principais problemas e entregá-los a um grande desenvolvedor. Todos podem se atualizar e aprender algo no processo. Apenas não construa uma aplicação inteira dessa maneira.

Você não reduz o código ao menor denominador comum. Você faz o inexperiente alcançar os melhores desenvolvedores.

Tem havido muita discussão sobre o que é ou não é "ágil" e muitos sentimentos pessoais, experiências e dúvidas sobre o processo ágil compartilhado aqui, mas eu realmente não vi uma resposta real para a pergunta. A questão original era como manter seus principais desenvolvedores motivados quando eles vêem o código que eles escreveram no nível da forma de arte pura, e investiram seu suor e sangue, hackeados por outra pessoa e "corrompidos". Note que, ágil ou não, isso vai acontecer em algum momento, é apenas mais visível agora porque eles ainda estão trabalhando no código ao mesmo tempo que outros, em vez de haver o handoff típico para suportar, em que ponto eles simplesmente não veriam essas alterações sendo feitas.

O que eu veria como a chave aqui é expandir a responsabilidade desses desenvolvedores e ajudá-los a mudar seu foco para o quadro maior. Talvez isso signifique um novo título, como o Arquiteto de Software, ou Líder de Equipe ou Engenheiro de Software Sênior. Em seguida, mostre a eles que essa é uma oportunidade de ter um impacto maior, não apenas em um único projeto por vez, mas em vários projetos. O senso de propriedade ainda pode estar lá, mas seu foco não deve mais ser entregar um único grande projeto, mas ajudar a definir o padrão para projetos ALL . Ajude-os a se concentrar em seu strong desejo de construir algo grandioso, mas mude o foco para desenvolver as práticas de engenharia de software de sua empresa e os outros desenvolvedores. Em vez de se encolher com o pensamento de seus colegas de trabalho hacking seu código em pedaços, isso pode ser uma chance para eles subir para o próximo nível e orientar seus companheiros de equipe e trazê-los ao seu nível.

Vou tentar ilustrar alguns aspectos que não foram abordados por outras respostas e que, IMO, são importantes.

The basic issue is this: Some developers are primarily motivated by the joy of taking a piece of difficult work, thinking through a design, thinking through potential issues, then solving the problem piece by piece, with only minimal interaction with others, over an extended period of time. They generally complete work to a high level of quality and in a timely way; their work is maintainable and fits with the overall architecture.

Esse tipo de desenvolvedores pode achar difícil adaptar-se a um ambiente ágil e sua atitude é freqüentemente descartada como "falta de vontade de mudar", possivelmente relacionada ao ego ou à antiquada.

Uma abordagem é que um desenvolvedor leva a especificação do problema, vai até o quarto dela e volta duas ou três semanas depois com uma solução. A qualquer momento (quando necessário), o desenvolvedor pode iniciar alguma interação com outros membros da equipe ou com partes interessadas (fazendo perguntas sobre questões específicas), mas a maioria do trabalho é feito pelo desenvolvedor que é atribuído a tarefa.

O que acontece em um cenário ágil? A equipe divide o problema em pequenos pedaços (histórias de usuário) após uma análise rápida (preparação). A esperança é que as histórias dos usuários sejam independentes umas das outras, mas freqüentemente isso não é o caso: para dividir um problema complexo em partes realmente independentes, você precisaria de um conhecimento que normalmente só é obtido depois de trabalhar nele por vários dias. Em outras palavras, se você é capaz de dividir um problema complexo em pequenas partes independentes, isso significa que você já o resolveu e que você só tem trabalho de diligência. Para um problema que requer, digamos, três semanas de trabalho, este provavelmente será o caso durante a segunda semana, não depois de algumas horas de preparação feitas no início do sprint.

Assim, depois que um sprint foi planejado, a equipe trabalha em diferentes partes de um problema que provavelmente tem dependências entre si. Isso gera muita sobrecarga de comunicação tentando integrar diferentes soluções que podem ser igualmente boas, mas que são diferentes entre si. Basicamente, o trabalho de tentativa e erro é distribuído por todos os membros da equipe envolvidos, com uma sobrecarga de comunicação adicional (aumentando de forma quadrática). Eu acho que alguns destes problemas são ilustrados muito bem em este artigo por Paul Graham, em particular o ponto 7.

Naturalmente, compartilhar o trabalho entre os membros da equipe reduz o risco relacionado a um membro da equipe deixar o projeto. Por outro lado, o conhecimento sobre o código pode ser comunicado de outras maneiras, e. usando revisões de código ou dando apresentações técnicas aos colegas. A esse respeito, não creio que exista um marcador de prata válido para todas as situações: a propriedade de código compartilhado e a programação em pares não são a única opção.

Além disso, "entrega de funcionalidade de trabalho em intervalos mais curtos" resulta em uma interrupção do fluxo de trabalho. Isso pode ser OK se o pedaço de funcionalidade é "adicionar um botão de cancelamento na página de login" que pode ser concluído até o final de um sprint, mas quando você está trabalhando em uma tarefa complexa você não quer tais interrupções: é como tentando dirigir um carro 100 km o mais rápido possível e parando a cada 5 minutos para verificar até onde você chegou. Isso só vai te atrapalhar.

É claro, ter pontos de verificação freqüentes é feito para tornar um projeto mais previsível, mas em alguns casos a interrupção pode ser muito frustrante: dificilmente se pode ganhar velocidade que já é hora de parar e apresentar algo.

Além disso, não acho que ter alguns membros da equipe trabalhando isoladamente em problemas específicos e difíceis seja contra valores ágeis. Afinal, as equipes devem se auto-organizar e usar o processo que eles descobriram ser o mais eficaz ao longo dos anos.

Apenas meus 2 centavos.

Some developers are primarily motivated by the joy of taking a piece of difficult 
work, thinking through a design, thinking through potential issues, then solving
the problem piece by piece, with only minimal interaction with others, over an 
extended period of time

Parece que eles são "Lone Rangers". No Scrum canônico, essas pessoas simplesmente não podem se encaixar no Time (elas perdem o bit "interação").

Se eles não são "Lone Rangers", então há esperança. Se você estiver fazendo Scrum adequadamente, eles devem fazer parte do design do recurso no qual eles estarão trabalhando (durante o Planejamento da Sprint). Este é o único momento em que eles precisam interagir com os outros. Você pode até mesmo "atribuir" todas as histórias relacionadas a esse recurso para elas.

Durante o Sprint, eles só serão "incomodados" pelo Scrum diário ... até que você possa prová-los (por ações, não por palavras) que serão apenas 15 minutos de seu tempo, e apenas para garantir que tudo está correndo bem. Fique perto das três perguntas e a maioria das pessoas deixará de obedecer.

Em nossa equipe, temos um grupo especial apenas para aprimoramentos de desempenho. Nós não os vemos muito, apenas no início do sprint para falar sobre as mudanças a serem feitas e, ao final, na retrospectiva. Eles têm seu próprio "líder scrum", que reporta ao time Scrum of Scrum. Eu posso te dizer, eles estão se divertindo.

Se Joe (seu desenvolvedor do Hero) for um pouco flexível, não vejo problema:

Como dito acima, deixe a equipe se auto-organizar: Se alguns problemas são melhor enfrentados deixando-se o próprio Joe mastigar sozinho, então você esperaria que uma equipe auto-organizada de mente aberta chegasse a essa conclusão por conta própria. / p>

Os únicos desafios que permanecem dentro das poucas restrições que o Scrum impõe:

1. Entregando funcionalidade em intervalos regulares: se você deixar que o Joe mastigue um problema por meses, sem mostrar nada até o final, então Joe não é realmente ágil: ele está tomando o proprietário do produto como refém e não permitindo a ele uma oportunidade de reespecificar essa parte do produto. Com essa prática, há também o risco de que ele esteja atrasado e ninguém perceba isso. (Mas, de acordo com sua descrição, isso não é tão provável). Solução: seria muito pedir a Joe para se sentar junto com o PO, dividir a história do usuário e concordar com os resultados intermediários, de preferência (mas não necessariamente) com o valor do usuário?

2. Honrando as prioridades definidas pelo proprietário do produto: se partes de código pertencerem a especialistas, você corre o risco de uma situação em que a evolução do produto é determinada pela disponibilidade de cada especialista, e não pelas prioridades comerciais: O restante da equipe pode estar trabalhando em recursos menos importantes, enquanto os três principais recursos estão parados porque "somente Joe pode fazer isso". Isso é ruim. Nesse momento, a equipe deve (temporariamente) mudar seu hábito e dividir o trabalho de Joe por mais membros da equipe.

Em suma: Se Joe, o criador de heróis, concordar com a PO como ele mostrará o progresso em cada sprint, a equipe poderá atribuir certas histórias a ele e deixá-lo em paz. Mas se PO tem muito trabalho para Joe, e não o suficiente para a equipe (ou vice-versa), então Joe e a equipe precisam se adaptar, não o PO.

As regras para uma equipe ágil devem ser personalizadas para se adequarem à equipe - isso pode ser uma personalização realmente pessoal; Por exemplo, trabalhei em uma equipe em que a regra era:

All Code must be written by a pair, except David may write code alone.

David era um desenvolvedor / arquiteto sênior, que trabalhou principalmente em ferramentas que outros usariam em seu próprio código. Ele possuía muito o código que ele escreveu. Era sustentável e testado, e todos na equipe sabiam que ele era provavelmente o melhor codificador lá, e que a equipe seria melhor servida, permitindo que ele construísse certas peças da estrutura e as apresentasse como completas para a equipe. equipe.

Eu não tenho uma resposta para introvertidos de jardim, mas para introvertidos excepcionais, a equipe terá regras diferentes para obter o benefício.