Algumas equipes de desenvolvimento da minha empresa estão mudando para práticas de desenvolvimento Agile e o trabalho de seus desenvolvedores parece estar diminuindo para discutir e programar minúcias sobre recursos triviais de software devido a ciclos de iteração de duas semanas. E também por causa da mentalidade de "qualquer desenvolvedor pode corrigir qualquer bug". Entrei recentemente para uma dessas equipes, transferindo-me de outra equipe na mesma empresa ...
Sinto fortemente que os desenvolvedores devem possuir seus recursos de software desde o início (design) até o final (implementação e teste de unidade). O Agile parece estar indo contra esse pensamento. Existe alguma verdade na minha percepção ou estou apenas vivendo uma implementação ruim do Agile?
Durante as duas iterações de duas semanas, as pessoas recebem de maneira arbitrária novos pequenos recursos e correções de erros, dependendo da carga de trabalho durante esse ciclo. Ninguém parece possuir a responsabilidade dos principais recursos do software. Passamos uma quantidade estúpida de vezes em coisas triviais, como adicionar um único botão a uma caixa de diálogo durante uma iteração de duas semanas, com uma história, revisões diárias, revisão de código etc.
Então, em projetos Agile, como gerenciar recursos maiores? Quem possui a responsabilidade: desenvolvedores individuais ou toda a equipe? Como alguém se extrai das minúcias e se concentra em objetivos de longo prazo? Qualquer feedback seria valioso.
Respostas:
Se você acha que isso ajudaria os esforços da equipe, não hesite em amenizar a mentalidade de "qualquer desenvolvedor pode corrigir qualquer bug" que você vê como criando problemas.
A prática
Collective Code Ownership, às vezes também chamadaShared Code, é um princípio fundamental em muitos tipos de desenvolvimento Agile, e provavelmente é o que você está experimentando:Em extremeprogramming.org :
De c2.com :
Existem alguns benefícios definitivos para
Collective Code Ownership. No entanto, você não é a primeira pessoa a observar deficiências nessa abordagem . Nada além de Martin Fowler descreve uma abordagem que se encontra entre os extremos deStrong Code Ownership(onde os indivíduos "possuem" seus módulos) eCollective Code Ownership. Ele descreve isso como propriedade de código fraco :No mesmo artigo, ele continua dizendo:
O ponto principal é que, para realmente aderir aos princípios do Agile, a equipe deve fazer o que leva a um código de trabalho de boa qualidade. Se isso significa afrouxar o controle
Collective Code Ownership, não há nada de errado (ou anti-ágil) nisso.fonte
Para responder sua pergunta, tentarei fornecer uma descrição de como lidamos com as situações mencionadas em sua pergunta:
Usamos a estrutura Scrum no Agile. As sessões de planejamento da Sprint e preparação de pedidos em atraso ajudam nossa equipe a dividir histórias relativamente definidas adequadamente.
No geral, uma equipe como um todo é responsável pelo resultado dos compromissos de um sprint (todas as histórias). Eles conseguem ou falham em equipe. Assim, a equipe como um todo influenciaria como o trabalho deve ser gerenciado para que o trabalho seja realizado no sprint.
Cartas de histórias tiradas por um desenvolvedor (nas paradas) tornam-se responsabilidade do desenvolvedor fazer e assinar, pronto para ser lançado no final do sprint. No entanto, a equipe deve usar as exibições diárias para ver se alguém parece estar lutando com a história e, em seguida, prosseguir para ajudar o desenvolvedor a concluir suas tarefas pendentes.
No nosso caso, com o Scrum, se algo nos for dado que não fazia parte do compromisso original do sprint, nós o adicionamos como 'trabalho não planejado' e nossos proprietários de produtos sabem que o esforço não planejado adicionado pode resultar no não cumprimento de nossos compromissos originais. Também temos uma estrutura plana na equipe, para que ninguém desempenhe um papel de gerente e todos sejam motivados a não deixar a equipe falhar, pois todos são igualmente responsáveis pelo trabalho.
fonte
O proprietário do produto possui a parte que . Ele é responsável por decidir quais itens do Backlog do produto são mais anteriores a outros itens e é responsável por entregar o produto com base nos recursos disponíveis no prazo .
Equipe Scrum (incluindo proprietário do produto, e Scrum Master) são responsáveis por como parte. Eles devem decidir como gerenciar a equipe, compartilhar conhecimentos, se auto-organizar, reunir-se diariamente (stand-up diário), revisar-se (reunião retrospectiva), ter recursos multifuncionais, etc.
Essa ideia está longe de possuir um recurso, já que as partes interessadas possuem esses recursos, não eu e você.
fonte
A maneira como faço isso, com um baixo nível de dor, é que cada desenvolvedor seja responsável por um cartão no tabuleiro, desde quando é retirado da lista TODO até passar para DONE. O proprietário do recurso, na medida em que funcionalidade entra nele, é o Líder da equipe, PME e BA. Cada equipe possui um líder de equipe (especialista técnico e advogado), um especialista no assunto e um analista de negócios.
Normalmente, o BA é o cara / garota que responde às perguntas do desenvolvedor que atualmente trabalha em um cartão. Todos trabalhamos na mesma sala, portanto, se o líder da equipe (eu), o BA ou a PME ouvir algo de que não concordamos, entraremos em contato e levaremos o desenvolvedor a uma sala de discussão para discutir mais. Normalmente, nós três traremos os membros dos outros três se acharmos que eles podem ser de valor para a discussão.
É certo que às vezes leva a perder tempo enquanto discutimos um problema, mas geralmente chegamos a uma boa solução rapidamente.
Por fim, é o líder da equipe que assina os itens da lista de pendências como estando prontos para o desenvolvimento e é o líder da equipe que tem a palavra final quando uma decisão precisa ser tomada e é responsável se a implementação estiver "errada". (Não pergunte sobre o jogo da culpa "errado": /).
Todos os outros desenvolvedores que ouvem a conversa são incentivados a oferecer sugestões e todos os membros da equipe têm sugestões durante a apresentação no final do sprint, quando novos recursos são demonstrados.
tl; dr (para nós): o líder da equipe possui os recursos e um desenvolvedor individual trabalha em um cartão de recurso (ou bug, melhoria, dívida técnica etc.) do início à aceitação pela equipe de teste).
fonte
O primeiro problema que vejo é que o processo de estimativa está indo um pouco amplo. Sim, os desenvolvedores devem ter uma palavra a dizer quanto trabalho eles devem desempenhar. Não, isso não significa que adicionar um único botão a um formulário da Web agora é uma história de duas semanas do desenvolvedor (no entanto, muitos pontos equivalem ao processo de estimativa da sua empresa). Se esse é o estado atual, então você, como gerente de projeto, deve estar tentando adivinhar.
Segundo, ouço "do início (design) ao fim (implementação e teste de unidade)" e o primeiro pensamento que vem à mente é "você está fazendo errado". Seus testes de unidade fazem parte do seu trabalho de design como um desenvolvedor / equipe de desenvolvimento e devem ocorrer primeiro; você pega os requisitos básicos, destila-os em uma simples "lista de verificação" de "Se ... Quando ... Então ..." - digite sentenças e depois converta essas sentenças em uma série de testes básicos que afirmam que o programa atende àqueles afirmações e, portanto, os requisitos. Isso acontece antes de você escrever uma linha do código de produção que atenda às asserções dos testes. Se os testes de unidade chegarem por último, depois de já ter implementado o software, você perderá vários aspectos principais dos testes de unidade; em geral, seus desenvolvedores não podem "programar para verde",
Quanto aos desenvolvedores que "possuem" seus recursos, há um sim e um não. Primeiro, uma mudança bastante comum das "equipes auto-organizadas" é uma tendência para os desenvolvedores saírem em pares ou três e trabalharem nas coisas que sabem melhor. Supondo que você tenha um bom conjunto abrangente de conhecimentos de desenvolvedor, de modo que a equipe possa cobrir todo o trabalho a ser realizado em cada iteração dessa maneira, você pode simplesmente deixar isso acontecer; é uma coisa boa para a velocidade, pois os desenvolvedores permanecem focados e familiarizados com as áreas da base de código em que estão trabalhando, de iteração para iteração.
No entanto, um desenvolvedor que possui um recurso para toda a vida é uma mentalidade perigosa, porque reduz o "número de caminhões" da sua equipe (definido francamente como "quantas pessoas poderiam ser atingidas por um caminhão antes que a equipe não pudesse funcionar", dada a pior cenário possível de pessoas específicas atingidas e perda de conhecimento resultante.) Se o cara que você atribuiu ao recurso "Importação de arquivos" do seu software e o possuiu por 2 anos sai de férias por três semanas, tira licença prolongada do FMLA, muda empregos, ou ao extremo, realmente é atropelado por um caminhão e morre, agora você não tem mais ninguém que conheça esse recurso, porque essa área da base de código tem sido o alcance exclusivo de um cara há anos. com esta parte específica da base de código,você perderá velocidade significativa e também se abrirá para problemas adicionais com defeitos, pois o novo cara que está pouco familiarizado com o funcionamento da base de código agora pode permanecer lamentavelmente ignorante das coisas que pode e não pode mudar dentro dela. .
Em vez disso, você deve cultivar uma divisão do trabalho que mantenha o número de seu caminhão no mínimo 2 ou acima e em uma equipe maior (uma dúzia ou mais) mais próxima de 3 ou 4. Dessa forma, se um indivíduo não puder fazer o trabalho , por qualquer motivo, há várias outras pessoas que podem participar. Às vezes, as equipes naturalmente se agitam dessa maneira, especialmente se você introduzir algumas técnicas de XP, como programação em pares ou no estilo dojo (um cara escreve em uma nova asserção com base em nos requisitos que o código não atende; o próximo sujeito codifica para passar no teste e depois adiciona outra asserção de requisito que falha e passa adiante). Por definição, nessas situações, você tem vários olhos olhando para o código, desenvolvendo-o e familiarizando-se com ele.
No geral, a idéia do Agile é promover o desenvolvimento "leve". Sua equipe parece estar atolada em minúcias de processos e documentação, quando o foco principal, conforme o Manifesto Ágil, deve estar nos membros da equipe e em suas interações, e, é claro, no código funcional e de trabalho. Os processos inerentes ao Agile são um meio para atingir um fim e não há uma maneira única de seguir o Agile; até mesmo as estruturas principais do Agile, como o SCRUM, são maleáveis com base nas suas necessidades como empresa, equipe e até mesmo dia a dia (apenas mantenha as idéias básicas dos valores fornecidos por esses processos no coração ao fazer essas alterações).
fonte
O processo Agile é definido pela equipe para a equipe seguindo as diretrizes e pode diferir de equipe para equipe. Na maioria dos casos, não vi duas equipes diferentes que espelhem o mesmo processo em minha experiência profissional. Basicamente, a idéia é ter o desenvolvimento mais eficiente, o que, em alguns casos, significa que pessoas diferentes trabalham em recursos na mesma base de código e, em outros casos, uma pessoa é o proprietário do recurso desde o início até a conclusão do recurso.
Recursos basicamente maiores (vamos chamá-los de histórias de usuário) podem ser divididos em histórias de usuário menores e, ainda assim, uma única pessoa pode ser o proprietário do recurso, espalhando essas histórias de usuário por vários sprints. Da mesma forma, a pessoa pode ser proprietária do recurso e não fazer todo o trabalho para o recurso. Por exemplo
Cenário:
A equipe é tecnicamente o proprietário do recurso, mas um desenvolvedor pode agir como um.
Nesse cenário, há pelo menos três pessoas (podemos ter mais de um QE de serviço) responsável pela entrega do recurso, mas o desenvolvedor é proprietário e, de certo modo, dirige o recurso. É claro que isso exige mais dedicação a esse recurso específico por parte do desenvolvedor, mas não está fora do escopo do Agile e, ao mesmo tempo, temos um único proprietário de recurso.
fonte