Determinação do custo de software em metodologias ágeis

Possível, sim. Necessário? Acho que não.

No nosso caso, usamos XP com iterações a cada 1 ou, no máximo, 2 semanas.
Com requisitos que cabem nesse prazo, e o acompanhamento correto do tempo de projeto, sabe quais as chances de se errar numa estimativa?
Quase zero.

Ainda assim, sabe qual é o custo de um erro? Provavelmente um ou dois dias naquela iteração (o que para a maioria dos clientes não é um problema, exceto em uma ou duas datas críticas).

O maior motivo você já deduziu: num período de tempo tão curto desses os requisitos programados para a iteração não mudam e a quantidade de requisitos para se estimar é muito pequena.

E, se mudarem, muitas vezes o cliente prefere esperar a próxima iteração.

tnaires:

Olá pessoal.

Na empresa onde trabalho, utilizamos análise de pontos por função para medir o tamanho do software, e estimar custos e prazo. Porém, um dos principais problemas que vejo nessa técnica é que, para a estimativa ter um nível razoável de precisão, os requisitos devem estar bastante amadurecidos - o que pode levar muito tempo, uma vez que os mesmos estão sempre mudando. E, sempre que olhamos para trás, percebemos que os custos quase sempre excedem as estimativas.

Sempre tive interesse por metodologias ágeis, como Scrum e XP, mas ainda não tive tempo de estudá-las a fundo. Acho interessante essa idéia de implementar o sistema aos poucos e ir refatorando, ao mesmo tempo que versões funcionais são entregues em períodos curtos. Mas como estimar o preço do software nessas condições?

Você percebeu que o problema não é o “como” você estima, e sim o que você faz com esta estimativa, certo? Fechar um contrato de software somente baseado somente em escopo ao meu ver é sempre negativo porque:

• Os requisitos sempre mudam;
• Você perde grandes oportunidades de aprender e melhorar seu software durante o projeto;
• As chances de você entregar funcionalidades que não agregam valor é muito grande;
• Para cobrir o escopo provavelmente você vai ter que abrir mão do custo, do prazo ou, o que mais acontece, da qualidade.

Neste ponto, a maioria das técnicas ágeis não dá uma “receita de bolo” para fugir do problema, mas apresenta algumas alternativas:

• Estimar o projeto baseando-se na priorização de requisitos de alto nível, usando técnicas como MoSCoW. O tamanho do projeto é estimado levando escopo em consideração(usando pontos por função ou qualquer outra medida), e se você for esperto permitirá que o escopo seja repriorizado frequentemente.
• Usar para um contrato de escopo variável

Ou seja, a idéia sempre é flexibilizar o escopo e compartilhar riscos e benefícios com o cliente.

tnaires:

Será que é viável aplicar a técnica de análise de pontos por função a cada iteração? Eu acho que sim, pois como os requisitos das versões menores são mais estáveis, a técnica se torna mais precisa. Mas gostaria de saber a opinião do pessoal que já trabalha com metodologias ágeis.

Aqui estamos tratando de períodos de 2-4 semanas. Normalmente após algumas iterações a equipe aprende sobre sua velocidade é capaz de estimar facilmente os requisitos usando métricas simples como Story Points. Neste caso eu não vejo necessidade de uma métrica tão complexa quanto pontos por função.

ViniGodoy:

Possível, sim. Necessário? Acho que não.

No nosso caso, usamos XP com iterações a cada 1 ou, no máximo, 2 semanas.
Com requisitos que cabem nesse prazo, e o acompanhamento correto do tempo de projeto, sabe quais as chances de se errar numa estimativa?
Quase zero.

Ainda assim, sabe qual é o custo de um erro? Provavelmente um ou dois dias naquela iteração (o que para a maioria dos clientes não é um problema, exceto em uma ou duas datas críticas).

O maior motivo você já deduziu: num período de tempo tão curto desses os requisitos programados para a iteração não mudam e a quantidade de requisitos para se estimar é muito pequena.

E, se mudarem, muitas vezes o cliente prefere esperar a próxima iteração.

Vini,

Gosto deste esquema de iterações pequenas, etc. que as metodologias agéis proporcionam. Mas continuamos tendo o mesmo problema de fazer uma estimativa inicial para o projeto como um todo. O cliente precisa saber em quanto tempo e a que custo ele terá o sistema pronto.

Como vocês fazem esta estimativa?

Nilson Costa:

Vini,

Gosto deste esquema de iterações pequenas, etc. que as metodologias agéis proporcionam. Mas continuamos tendo o mesmo problema de fazer uma estimativa inicial para o projeto como um todo. O cliente precisa saber em quanto tempo e a que custo ele terá o sistema pronto.

Como vocês fazem esta estimativa?

Era exatamente isso que eu ia perguntar 8)
Inclusive, o texto sobre contrato de escopo variável que o s4nchez passou fala o seguinte:

Abraços

Agora é hora de você ter um bom negociador. O cliente precisa entender o dinamismo do modelo de desenvolvimento de um software, e também precisa estar ciente de como funcionará o processo de desenvolvimento, que esse processo é longo, e saber que é praticamente impossível prever com precisão o que será prioritário daqui a vários meses.

Tente propor um modelo de contrato flexível, de curta duração. Infelizmente, se você ainda tiver que orçar para ele “o sistema como um todo”, já que a empresa dele provavelmente trabalha com uma previsão orçamentária rígida, faça no método tradicional, por pontos de função.Mas deixe-o ciente de que a estimativa é só para fins do planejamento da empresa dele, não para o real custo do desenvolvimento em si, porque nem ele e nem ninguém saberá quais serão as prioridades para e empresa dele (e portanto, para o sistema) daqui a um ou dois anos.

Um dos pilares da metodologia ágil é um cliente participativo. Isso tem duas vantagens: A primeira, é que o cliente vai pedir o que quer e esclarecer dúvidas. A segunda, que aplica nesse caso, é que o cliente terá a segurança de que a equipe está trabalhando bem, e que as mudanças pedidas foram atendidas.

Finalmente, as iterações curtas e a participação do cliente acabam com o efeito “janela de entrada”. Isso é, o cliente não se sente com apenas uma pequena janela de tempo para pedir funcionalidades e, dessa forma, evitam pedir aquelas que eles tem dúvida. O problema do método tradicional é que o cliente, por medo de não ter oportunidade de pedir uma funcionalidade no futuro, acaba pedindo coisas que ele teme que um dia poderá usar… mas que no fundo, o mais provável é que nunca vá.

Tem um grande porem aqui. Nós (IT) aceitamos o desenvolvimento e o amadurecimento das metodologias ageis porque sabemos como melhora o nosso trabalho, como podemos melhorar o produto e entregar o que realmente o cliente deseja.
Em contrapartida, o cliente final não gosta de ouvir que “o projeto não tem escopo”, “o projeto não tem data de entrega”, “o projeto não tem orçamento delimitado”… acredite, por mais que vc fale que o projeto dele vai variando com o tempo e que a cada iteração o escopo pode mudar, o que altera o cronograma e o custo, ele vai entender “Nós vamos sugar o seu dinheiro até vc rever o contrato”.

Metodologias ageis funcionam muito bem quando cliente e fornecedor falam a mesma lingua. IMHO, para se vender um projeto “seu” para um cliente que não “fala agile”, fica bastante dificil explicar pra ele sem ser waterfall… vc pode até fazer Agile dentro da sua equipe, mas para o cliente, escopo, prazo e custo são fixos desde o inicio do projeto.

rodrigoallemand:

Metodologias ageis funcionam muito bem quando cliente e fornecedor falam a mesma lingua. IMHO, para se vender um projeto “seu” para um cliente que não “fala agile”, fica bastante dificil explicar pra ele sem ser waterfall… vc pode até fazer Agile dentro da sua equipe, mas para o cliente, escopo, prazo e custo são fixos desde o inicio do projeto.

Concordo, e foi mais ou menos o que eu disse. É que muitas vezes o cliente que pede o sistema tem uma visão, equanto o cliente que cuida da parte financeira é quem exige o prazo e o escopo.

O que eu quis dizer é… se o cliente que está te pedindo consegue entender o estilo ágil, ótimo, façam um orçamento somente para agradar o setor financeiro e trabalhem o cliente que pediu e vai avaliar o produto.

Agora, se ele não entende esse estilo e está mais preocupado em fazer um contrato do que ter um bom software, então, infelizmente, é provável que seja melhor mudar de cliente, ou de método. Talvez o ideal seja mesmo usar o RUP (e seu modelo de mini-waterfall) e preparar-se com a carga de burocracia para “contra-atacar” as mudanças de idéia do seu cliente.

Afinal, para ele, o papel vale mais do que o sistema.

Acho que por isso uma das segurança que você deve oferecer é: O cliente tem que estar perto da equipe de desenvolvimento, pronto a responder suas dúvidas e ter papel ativo no processo. Isso não só gera um sistema mais próximo do desejado no final, como também dá ao cliente a segurança de que ele não está sendo passado para trás.

Mas, na verdade, introduzir XP num cliente mais ortodoxo é algo que leva tempo. Muito tempo. Comece a adotar o modelo em algumas funcionalidades do software e convide o seu cliente a acompanhar. Mostre a ele as vantagens em visitas e reuniões, até um dia que ele mesmo esteja falando em “mais agilidade”.

Por isso eu comentei do bom negociador. Ele tem que saber fazer isso sem parecer impositivo demais e mostrar os benefícios de forma que o cliente entenda sem pressiona-lo. E tem que ser capaz de fazer com que o cliente se sinta na obrigação de ter essa participação ativa, sem que isso pareça perda de tempo, ou uma imposição (na verdade, o bom negociador faz com que o cliente sinta que ter um papel ativo foi sua própria idéia, e não do negociador).

Isso lembra uma estória:

"Um grupo de cientistas colocou cinco macacos numa jaula. No meio da jaula, havia uma escada e sobre ela um cacho de bananas. Quando um macaco subia na escada para pegar as bananas, os cientistas jogavam um jato de água fria nos que estavam no chão. Depois de certo tempo, quando um macaco subia a escada os outros o espancavam. Com mais algum tempo, nenhum macaco subia mais a escada, apesar da tentação das bananas. Então, substituíram um dos macacos por um novo. Seu primeiro ato - claro!!! - foi o de subir a escada, dela sendo imediatamente arrancado pelos outros, que o surraram. Depois de algumas surras, o novo integrante do grupo acostumou-se à situação de que não deveria mais subir a escada. Nem o grande prêmio - um cacho de bananas!!! - faria com que ele se esquecesse que seus colegas o esperavam lá embaixo. Um segundo foi substituído e o mesmo aconteceu, tendo o primeiro substituto participado com entusiasmo na surra ao novato. Um terceiro, um quarto e finalmente o último dos veteranos foi substituído e o mesmo aconteceu. Os cientistas então ficaram com um grupo de cinco macacos que mesmo nunca tendo tomado um banho frio, continuavam batendo naquele que tentasse pegar as bananas. Se possível fosse perguntar a algum deles porque eles batiam em quem tentasse subir a escada, com certeza a resposta seria: “Não sei, mas as coisas sempre foram assim por aqui. As coisas seguem porque seguem.”

Realmente, não é tão fácil achar o tipo de cliente que entenda o espírito de agilidade.

Citando novamente o excelente texto que o s4nchez passou, há um trecho que diz:

O tradicional contrato de escopo fixo determina claramente qual será o custo, o prazo e o escopo. A qualidade pode até ser abordada, mas normalmente é sacrificada assim que o prazo aperta. Já o contrato de escopo negociável segue outro caminho. Visto que as quatro variáveis são conflitantes até certo ponto, não é possível fixar todas elas. Uma alternativa é fixar:

* Custo
* Prazo
* Qualidade

Assim, permite-se que o escopo absorva as incertezas do projeto. Neste caso, o cliente continua sabendo o quanto irá gastar, bem como quanto tempo o projeto irá durar. O que ele não sabe com exatidão é o que irá receber. Mas, na verdade, ele não sabia disso no caso do contrato de escopo fixo, ele apenas tinha a ilusão de saber, a ilusão da previsibilidade do escopo. Portanto, ele não perdeu absolutamente nada, apenas estamos assumindo uma relação contratual mais honesta e realista.

Num contrato de escopo fixo, os clientes em geral não percebem que têm a ilusão de saber o que realmente precisam; eles têm certeza que sabem. Só terão uma chance de se dar conta no final - e vão desperciçá-la, pois colocarão a culpa na equipe, que “não soube trabalhar direito”. Ainda por cima, na maioria das vezes um cliente só parte para a idéia do escopo variável quando já se prejudicou em vários outros de escopo fixo.

Para lidar com esses clientes, creio que o ideal seja seguir aquilo que o ViniGodoy falou:

Ao final do projeto, quando os requisitos levantados forem comparados com aqueles que realmente foram implementados, o cliente vai se dar conta de que as coisas realmente não funcionam da forma que ele e os desenvolvedores gostariam que funcionassem.