No desenvolvimento Agile, quem é o proprietário dos “recursos” do software e como você gerencia o desenvolvimento?


8

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.


Se você quiser se livrar das minúcias, não se preocupe em atribuir um recurso para toda a vida a um desenvolvedor específico.
11133 JeffO

"pessoas arbitrariamente recebem novos pequenos recursos" parece o seu problema, que não é ágil. Os processos típicos do Agile devem permitir que você selecione seu próprio trabalho. Tente ler um livro sobre o Agile - eu recomendo o successedingwithagile.com para todos.
Dave Hillier

Respostas:


12

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 chamada Shared Code, é um princípio fundamental em muitos tipos de desenvolvimento Agile, e provavelmente é o que você está experimentando:

Em extremeprogramming.org :

A propriedade coletiva incentiva todos a contribuir com novas idéias para todos os segmentos do projeto. Qualquer desenvolvedor pode alterar qualquer linha de código para adicionar funcionalidade, corrigir bugs, melhorar projetos ou refatorar. Ninguém se torna um gargalo para mudanças.

De c2.com :

O ExtremeProgramming considera que o código pertence ao projeto, não a um engenheiro individual. À medida que os engenheiros desenvolvem a funcionalidade necessária, eles podem navegar e modificar qualquer classe. Eles são responsáveis ​​por manter todos os UnitTests em execução (e escrever novos para novas funcionalidades). Eles assumem as mesmas tarefas de preservação de integridade que o proprietário da classe em uma situação de CodeOwnership.

Trabalhar nesse modo permite que uma equipe responsável se mova rapidamente para adicionar novas funcionalidades, mantendo a responsabilidade nos objetos certos. CodeOwnership cria dependências e gargalos ao implementar UserStories. Evitamos a propriedade do código, porque ele entra em conflito com o compromisso do PlanningGame. ("Código não é nada, histórias são tudo!")

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 de Strong Code Ownership(onde os indivíduos "possuem" seus módulos) e Collective Code Ownership. Ele descreve isso como propriedade de código fraco :

A propriedade de código fraco é semelhante [à Strong Code Ownership] em que os módulos são atribuídos aos proprietários, mas diferente em que os desenvolvedores têm permissão para alterar os módulos pertencentes a outras pessoas. Espera-se que os proprietários dos módulos assumam a responsabilidade pelos módulos que possuem e acompanhem as alterações feitas por outras pessoas. Se você quiser fazer uma alteração substancial no módulo de outra pessoa, é educado conversar primeiro com o proprietário do módulo.

No mesmo artigo, ele continua dizendo:

A escolha entre propriedade fraca e propriedade coletiva tem mais a ver com a dinâmica social da equipe. Ambos parecem funcionar e fracassam igualmente bem. Pessoalmente, prefiro a dinâmica de uma equipe de propriedade de código coletivo - particularmente no contexto da Extreme Programming.

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.


Ótima resposta e boas citações! Eu diria que, em um mundo perfeito com a equipe perfeita, a Strong Code Ownership faz todo o sentido. Muitas empresas têm desenvolvedores de peso morto e, quando recebem a propriedade de uma tarefa, todo mundo sofre e, como resultado, a qualidade do software é reduzida ao nível mais baixo possível. A programação extrema e a propriedade coletiva são melhores nesse caso, porque os desenvolvedores ineficazes podem ser contornados.
maple_shaft

3
@ maple_shaft: Eu diria que, em um mundo perfeito, com a equipe perfeita, a propriedade do código coletivo faz todo sentido. Todos os desenvolvedores entenderiam completamente todo o código e seriam competentes para fazer alterações em qualquer lugar. Qualquer desenvolvedor poderia fazer todo o trabalho necessário para qualquer história de usuário. Não haveria gargalos, pois um ou outro proprietário estava sobrecarregado.
kevin Cline

@kevincline Bom ponto e uma perspectiva que eu não considero
maple_shaft

Ótima resposta. Acho que o que me deixa desconfortável com o Agile é a grande diferença entre as práticas da minha antiga e da nova equipe. Na minha equipe anterior, todos tinham mestrado e doutorado em engenharia. Eles eram primeiro um especialista em uma área que implementaria código especializado em seu domínio de especialização. Portanto, a propriedade do código compartilhado seria praticamente impossível. Enquanto na minha equipe atual, todos são essencialmente especialistas em ciência da computação com formação e experiência semelhantes, o que parece tornar mais viável a propriedade compartilhada.
Kavka

@Kavka: Acho que sua equipe anterior estava confiando na experiência no domínio como um substituto para requisitos explícitos no nível da unidade (ou seja, testes de unidade). É necessário ter conhecimento de domínio para definir requisitos. Não é necessário implementar requisitos depois de definidos. Na minha experiência, o código escrito por especialistas em domínio tende a ser difícil de manter, porque os especialistas em domínio raramente são também programadores especializados.
kevin Cline

4

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.


3

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ê.


1

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).


0

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).


0

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:

  • Grande recurso estimado em 6 semanas (3 corridas).
  • O recurso é dividido em várias histórias de usuários, cada uma levando até dois dias.
  • As histórias de usuários incluem desenvolvimento de recursos, testes de unidade, testes de interação, integração (com outros recursos) e testes de integração

A equipe é tecnicamente o proprietário do recurso, mas um desenvolvedor pode agir como um.

  • O desenvolvedor escreve a funcionalidade
  • O desenvolvedor escreve os testes de unidade
  • Um engenheiro de qualidade escreve a automação
  • Outro desenvolvedor garante a integração

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.