BT

Executando Agile Após Demissões

por Mark Levison , traduzido por Paulo R. C. Siqueira em 09 Jan 2009 |

Adrian Carr escreveu sobre a adaptação da implementação de Scrum da sua equipe após demissões. Originalmente, a equipe era um grupo de quatro desenvolvedores, um testador, um Product Owner e o Scrum Master. Após os cortes, a equipe foi reduzida para quatro membros com Adrian como Scrum Master em meio período e nenhum Product Owner dedicado. A unidade de negócios teve o mesmo problema de pessoal que o grupo de desenvolvimento e portanto foi capaz de providenciar apenas um "ponto de contato senior que entende do negócio e está autorizado a tomar decisões sobre o projeto". Então a questão que ficou para ele foi: Quais partes do Scrum manter? A primeira tentativa de Adrian incluiu:

  • Manter apenas as partes do Scrum que fazem sentido em um grupo menor: reuniões em pé diárias, sprints curtos, revisões, retrospectivas, project burndowns visíveis.
  • Todo mundo na equipe faz parte do papel de Product Owner se reunindo com clientes, usuários finais etc, mas Adrian manteve o product backlog e tomava decisões finais etc.
  • Eliminar desperdício.
  • Manter as coisas o mais simples possível.
  • Creditar pontos de histórias apenas para funcionalidades colocadas em produção, a expectativa é que isso iria forçar a equipe a criar funcionalidades menores e mais fáceis de gerenciar. Isto deveria levar a uma redução no tempo das iterações e gerar mais feedback.
  • Trabalhar em blocos muito pequenos de trabalho – apenas dois ou três itens por vez.
  • Focar em entregar os itens de maior valor primeiro.
  • Conhecer para quem o software estava sendo desenvolvido. Conhecer seus nomes, seus papéis e porque eles faziam o que fazem.
  • Vigiar por fatores externos que freiem a equipe e tirá-los do caminho.

Robin Dymond, da Innovel, tem uma preocupação maior: a ausência de um Product Owner dedicado. Ele diz que para um desenvolvedor fazer esse papel ele irá ter que se tornar um expert no negócio, diminuindo o tempo que ele tem para desenvolver. Ao invés disso, ele recomenda:

Se o pessoal de negócios está pressionado por tempo então a equipe de desenvolvimento pode fazer reuniões pequenas e frequentes com eles, eles podem aprovar os critérios de aceitação ao invés de escrevê-los, e eles podem focar em prioridades. No entanto eles precisam estar no seu papel, e ter a responsabilidade. A equipe não pode fazer isso por eles, porque a equipe irá inevitavelmente interpretar as coisas de modo diferente, escolhendo prioridades diferentes e tomando decisões diferentes das que o pessoal de negócio iria.

Em uma opinião de Mary Poppendieck's (autor do Implementing Lean Software Development (implementando desenvolvimento de software enxuto)), o Product Owner não é sempre necessário ou até mesmo desejável, já que ela considera que se os desenvolvedores entendem o que o cliente quer o product owner adiciona uma nova camada e é provável que haja informação perdida devido a intermediações. Para Mary, a chave é ter uma medida boa e simples na qual todos concordem como o objetivo, então todas as funcionalidades podem ser medidas contra o valor entregue para esse objetivo.

Ron Jeffries avisa quanto a possível falta de clareza entre a equipe, como Product Owners, e a Unidade de Negócios. Se o produto acaba não sendo exatamento o que o cliente precisa, a unidade provavelmente irá culpar a equipe de desenvolvimento por suas decisões. Ron aponta que uma das vantagens do papel Product Owner/Customer tradicional é que a unidade de negócios então não tem quem culpar além de si mesmos, se o produto não realizar as expectativas dos usuários finais.

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião
Feedback geral
Bugs
Publicidade
Editorial
Marketing
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2016 C4Media Inc.
Política de privacidade
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.