Na minha coluna MundoOO da revista MundoJava, publiquei um artigo que dismistifica muito sobre User Stories e responde a algumas perguntas comuns sobre o assunto que observei no mercado em muitas equipes: Como escrever? Quem faz o que? Pra que usar cartões? Aonde está a especificação? e etc…
Essas dúvidas geralmente surgem no nosso curso Scrum, onde temos uma atividade prática muito legal sobre captura de User Stories dentro de uma concepção ágil (veja cases do blog).
Este artigo é parte de uma série sobre Agilidade que estou mantendo na coluna. Ultimamente escreví sobre modelagem ágil, TDD, requisitos/especificações executáveis e etc…
Segue o trechinho grátis:
É fato que a maior parte do mercado brasileiro hoje usa contratos de escopo fechado, principalmente nos grandes projetos (governo, bancos, Telecom, indústrias e etc…). O contrato de escopo fechado promete “previsibilidade” no desenvolvimento de software, porém, esta forma de contratação parte de duas premissas muito duvidosas: 1 – o cliente sabe exatamente o que quer; e 2 – a equipe sabe estimar exatamente o esforço de construção.
Se você já trabalhou em dois ou três projetos de software você sabe perfeitamente que essas premissas são folclore. Nem o cliente sabe exatamente o que quer e nós sempre temos um grau de confiança inaceitável nas nossas estimativas de longo prazo. Essa é a maior razão para o seu gerente colocar 50%, 100% e até 150% de “gordura” ou “pulmão” no valor da proposta para o cliente. E esse é o resultado: tentar forçar a “previsibilidade” num contrato de escopo fechado gera projetos mais caros e clientes muito insatisfeitos. Na maioria das vezes isso acontece porque o cliente se envolve timidamente no projeto, tomam suas especificações funcionais como verdade absoluta e dizem: “- Eu quero tudo!!!”, não se importando se a solução vai resolver os problemas ou não.
Na verdade, um projeto de software tem uma peculiar característica de “constante investigação”. Ken Schwaber chama isso de “inspeção e adaptação”. Em termos mais práticos, o dia-a-dia de uma equipe de desenvolvimento de software é “checar se estamos no caminho certo e ajustar o rumo sempre que necessário”. Desenvolvimento de software é um processo criativo de pesquisa, então, especificações pactuais gordas que apodrecem no nosso controle de versão nos ajudam muito pouco para o sucesso do projeto. Em projetos de software bem sucedidos é comum o produto final ser bem diferente da idéia concebida inicialmente. Durante o desenvolvimento do projeto, uma sugestão de solução nos leva a novos problemas ocultos que não podem ser ignorados e a outras possibilidades de solução ou “atalhos” que devemos aproveitar. Dentro do desenvolvimento iterativo esses problemas e atalhos se tornam muito claros.
[photopress:Figura7_1.gif,full,pp_image]
Quer ler mais? Já nas bancas…
Olá Rodrigo!
Legal, mas no site da mundojava a última edição é a 31. Nesta sua coluna fala sobre “Requisitos Executáveis com FIT”. É esta edição mesmo? Obrigado e continue o excelente trabalho.
Então… a MundoJava demora um pouquinho para atualizar o site… mas meu artigo está na edição 32. Deve estar nas bancas em breve.
Pingback:3 dicas para melhorar tuas estorias
Quem disse que projetos vendidos a escopo fechado devem terminar com o escopo inicial? Conhece o conceito de Gerência de Mudanças? Venda de projetos em escopo fechado tem vários benefícios em tempo de contratação, incluíndo tempo previsto, tamanho, recursos, etc, e que são exigências de diversos compradores. Quem não tem sucesso em execução de projetos fechados é porque não tem experiência em negociação de requisitos durante a execução, ou pq preveu muuuito errado e não deixou o comprador ciente que mudanças ocorrem, e sempre ocorrerão.
Robson, você não consegue ver as inconsistências no seu próprio comentário? Se é um dos “benefícios” ter o tempo de contratação, tempo previsto, tamanho e etc, aonde entra a Gestão de Mudanças?
Sucesso na “execução” do projeto não é um bom parâmetro de sucesso. Mais importante é o sucesso do cliente com a aplicação.
Você colocou as coisas no comentário como se muitas empresas estivessem tendo muito sucesso e muitos clientes satisfeitos com esse modelo. Infelizmente não é bem isso que vejo no mercado de norte a sul do Brasil.
Temos centenas de literaturas e artigos defendendo o ponto de vista que escreví no artigo. Se você tem uma formula que através de experiência em negociação de requisitos, acertabilidade na previsão e deixar o comprador ciente das mudanças faz esse modelo funcionar você deveria escrever um artigo defendendo isso, e deixe que os outros julguem.