Pesquisar neste blog

1 de jun. de 2012

Série Scrum: lidando com estimativa e escopo com o cliente

Por: iMasters
Em: https://www.ibm.com/developerworks/mydeveloperworks/blogs/fd26864d-cb41-49cf-b719-d89c6b072893/entry/s_C3_A9rie_scrum_lidando_com_estimativa_e_escopo_com_o_cliente?lang=pt_br


Olá, pessoal! E hoje vamos continuar firmes e fortes na série Scrum! Neste artigo, vamos aprender como lidar com estimativa e escopo com o cliente. Praticamente todo mundo já deve ter escutado essa solicitação do cliente: “será que não dá para diminuir um pouco a estimativa?”. O problema é que nem sempre dá, mesmo que o cliente continue insistindo. Então, como resolver esse problema e ao mesmo tempo deixar o cliente satisfeito? É o que veremos a seguir.

Lidando com estimativa e escopo com o cliente situação comum e esperada  

Estimar não é uma tarefa fácil e envolve vários fatores (o quanto o time conhece as tecnologias, o produto, a experiência profissional). Os novatos da equipe normalmente terão dificuldade em estimar no começo - pelos fatores citados anteriormente -, sendo assim, o ScrumMaster deve auxiliar os novatos, dando um coach na estimativa. 
Acredito que muitos de vocês já passaram pela situação que vou relatar a seguir - e não só com clientes, mas com gerente de projetos, arquitetos etc.
O cliente diz: eu sei que você tem uma equipe técnica qualificada e com os melhores profissionais. Será que não dá para diminuir um pouco a estimativa?
Nesse caso, o cliente está usando a qualidade interna (aquilo que ele não vê) como fator para reduzirmos a estimativa - mas ele não quer diminuir o escopo. Claro que não permitiremos isso. Sacrificar a qualidade interna, na maioria das vezes (para não dizer sempre) é uma péssima idéia. Lembre-se disto: uma vez que se permite a deteriorização de uma base de código, é muito difícil recuperar a qualidade mais tarde. Não conte com refactoring, pois fazê-lo depois de tudo demanda custos e nem sempre o cliente vai querer pagar por isso. Mas como responder ao cliente a pergunta acima? 
Uma das formas de responder é tentar convencê-lo a reduzir o escopo para algo mais especifico e remover aquela parte avançada - que normalmente vai virar uma nova história e que pode entrar no próximo Sprint. Um exemplo: se o cliente quer que todas as mensagens iterativas sejam exibidas, por que não implementar as mais importantes e deixar as outras para o futuro? Aquelas que não causam impacto no entendimento ou funcionalidade da aplicação podem ficar para os próximos Sprints. 
Outra situação é que ele quer um WebService para a aplicação, mas o ScrumMaster viu junto com a equipe que não dá para entregar dentro do tempo. A missão agora é convencer o cliente a diminuir o escopo - caso ele queira ver algo de WebService pelo menos iniciado no Sprint corrente. 
Sei que não é uma tarefa fácil convencer o cliente disso, mas se ele está envolvido com o time e o Scrum, ele sabe dos problemas que pode ter se tentar ir além da capacidade de entrega da equipe (é por isso que o PO não dita o que deve entrar no Sprint). É a equipe que vai pegando os itens até chegar ao limite. Então qual a solução? Negociar e validar o escopo com o PO. Essa é a forma mais adequada para não afetar a qualidade interna do produto. Alguém, uma vez, disse que a qualidade não é negociável. 

Nenhum comentário:

Postar um comentário