Desenvolvimento ágil de software: Como você reage * financeiramente * à alteração dos requisitos do usuário?

Sempre me perguntei algo ao ler sobre todo esse "desenvolvimento ágil" aqui no SE e em outros sites:

Na engenharia de software "tradicional", você

1. coletar os requisitos do usuário,
2. escreva uma especificação com base nesses requisitos,
3. entregá-lo ao cliente e cobrá-lo pelo trabalho realizado até agora,
4. faça um projeto técnico (aproximado), para que você possa estimar o custo da implementação,
5. forneça ao usuário uma cotação de preço para a implementação,
6. aguarde o cliente assinar a especificação e aceitar a oferta,
7. projetar, implementar, testar,
8. conta.

Se, durante o processo, os requisitos forem alterados, você enviará uma oferta (com um preço) para as alterações desejadas (ou faça gratuitamente se a alteração for pequena, você gosta do cliente e o cliente não faz isso com muita frequência) .

Então, como isso funciona (financeiramente) em um projeto ágil, onde mudanças frequentes de requisitos fazem parte do processo?

• Você escreve uma oferta para cada alteração de design? (Isso não seria uma bagunça?)
• Ou você negocia um preço fixo e espera que o cliente não altere os requisitos com muita frequência? (Pode ser arriscado, conheço clientes que usariam essa oportunidade para solicitar novos recursos por anos antes de aceitar que o projeto foi concluído.)
• Ou você apenas cobra o cliente pelo tempo total necessário? (Pode ser arriscado para o cliente, que não conhece o custo antecipadamente.)

Em um mundo ágil ideal, você concorda com um preço antecipado e várias horas, mas não com o escopo. O cliente decide qual é o produto útil mínimo, e não o produto que realmente deseja, e isso deve ser estimado bem abaixo do número de horas acordadas.

Então você entrega a eles iterativamente e eles mudam de idéia o que querem, mas você nunca repassa o número de horas acordadas. Em teoria, e geralmente na prática, eles acabam com o produto que realmente precisam, em vez do produto que realmente desejam.

E se eles quiserem continuar pagando por horas extras após o valor original acordado, tudo bem também. Se você fizer um trabalho suficientemente bom para tornar o progresso visível, por meio de fichas, Greenhopper ou o que quer que seja, você pode tornar muito óbvio para o cliente quais recursos eles estão perdendo (ou pelo menos depriorizando) cada vez que adicionam algo novo, o que em grande parte coloca uma parada para mudanças frívolas.

Existem dois riscos dignos de nota aqui. A primeira é que o cliente pode ficar assustado, se ele não entendeu a Agility antecipadamente. Parece que ele está assumindo todo o risco. Somente a experiência mostra que ele não é realmente.

A segunda é que eles devem estar envolvidos, durante todo o processo, ou todos perderão. Muitos clientes não conseguem entender o quão engajados devem estar até que seja tarde demais.

Mas se você, como empresa, explicar bem o suficiente, todos serão vencedores.

Algumas pessoas tentaram para dar soluções para usar agilidade em projetos de preço fixo no passado. Pessoalmente, acho que geralmente não é possível.

O Scrum, em particular, é adequado para empresas de software de produtos e é menos usado em empresas de serviços.

Você pode usar um pouco de agilidade em seus projetos, como iterações, stand-ups diários, burndorn etc., mas posso garantir que, se você oferecer uma certa quantidade de itens por um determinado preço e entregar menos do que o que estava no contrato, você terá um problema.

Por favor, não sirva Agility à todos os molhos . Devemos usar a solução apropriada para um determinado problema.

Isso não está realmente relacionado à programação Agile ou a qualquer modelo que você use. Trabalhando como freelancer, uso uma mistura de modelos Waterfall e V, mas ainda tenho o mesmo problema: e se o cliente quiser mudar alguma coisa durante o design detalhado? E se ele fizer alterações durante a implementação?

A abordagem que você deve usar depende do cliente e de suas relações.

Se um contato é essencial para tudo o que você faz para esse cliente, porque você sabe que ele tenta não pagar quando pode, ou tenta processá-lo sempre que possível, sim, você deve escrever uma oferta para cada cliente. pequena mudança nos requisitos. Não é uma bagunça: se você estiver bem organizado, pode não ser muito difícil acomodar um novo requisito durante o desenvolvimento. Mas, com certeza, é uma perda de tempo e dinheiro, e é bastante estranho ter que assinar uma oferta de mudança que levará duas horas para ser implementada.

Para outros clientes, a abordagem que funciona bem é a seguinte:

• Ao assinar a primeira oferta, especifique o custo estimado e o custo máximo. O custo estimado não significa nada legalmente: é apenas uma estimativa. O custo máximo tem valor legal: se você disser que o produto custará US $ 3.000 para seu cliente e, finalmente, custará US $ 3.157,24, o cliente ainda precisará pagar US $ 3.000. Na prática, na maioria dos casos, o custo real será menor que o máximo especificado e mais próximo da sua estimativa.

• Quando o cliente solicitar a alteração de um requisito, estime o custo e compare com o custo e o estado reais. Se você quase terminou o produto e o custo real é de US $ 2.108,36 e o ​​custo da alteração é estimado em US $ 150, basta fazê-lo. Se, por outro lado, houver o risco de atingir o máximo, informe ao cliente que você deve reavaliar o custo total juntos.

Ágil e 'Escreva uma oferta' parece uma antítese :) - a última não é uma engenharia de software produtiva: D

Ok, agora que temos a piada fora do caminho - voltando à realidade.

"Como isso funciona no Agile ?" - o contrato complica as coisas, mas espero deixar claro. O Agile baseia-se no princípio de `` confiança '' e `` trabalho colaborativo '', o que significa que o cliente pode mudar o que quer que seja, quando e entende que ele pode custar um pouco mais ou se não é intrusivo, talvez sem nenhum custo extra.

O que isto significa? Isso significa que o contrato indica que nós (o cliente) fixamos uma estimativa inicial de custo e a variação de +/- que podemos lidar, por exemplo, lance de US $ 100 mil, mas estou disposto a subir até US $ 120 mil (isso PODE não ser parte do contrato, mas na mente do cliente).

Agora, quando uma mudança de design ocorre, você agiliza a estimativa e o planejamento - reúne sua equipe e pergunta a eles a estimativa do "ponto da história" e a complexidade da fatoração das mudanças. Devido a algumas estimativas de velocidade, você pode multiplicá-las e fornecer uma estimativa de cronograma. Deve ser relativamente fácil reduzir o custo por ponto da história, se você conhece a equipe e seus salários relativos (por favor, não calcule a média do salário de TODOS, você sucumbirá à falha das médias).

Você precisa voltar para o cliente com as informações financeiras? NÃO. Não necessariamente. Você fará com que o cliente priorize esses itens e os insira no local correto na lista de pendências. Agora que você sabe o tamanho da lista de pendências (você deveria, se ainda não o conhece) e com base nos dados financeiros (custo por ponto da história), sabe quais requisitos de baixa prioridade podem não ser possíveis com o orçamento fornecido. MOSTRE a eles o backlog reprioritized com a estimativa de recursos factíveis conforme contrato $$. Então deixe-os decidir se estão dispostos a pagar mais para obter mais se / quando você / eles chegarem lá. Se eles quiserem de graça ... você toma uma posição e diz a eles que vai custar mais.

Isso deve ajudar sem que você volte constantemente às finanças, se puder ter esse gráfico em algum lugar para o cliente ver.

Espero que isto ajude!

A experiência de outras pessoas provavelmente variará, mas uma maneira que eu já vi fazer é a mesma que a sua "tradicional", com algumas coisas a serem observadas:

1. Construa algumas despesas gerais para alterações (por exemplo, 10%)
2. Avalie e fature separadamente grandes alterações ou alterações agregadas e de faturamento além do custo interno (um bom, embora não programado, exemplo é um trabalho de design, onde geralmente o custo inicial inclui, digamos, 3 revisões e revisões subsequentes ou talvez redos totais. extra)

Freqüentemente, também, os projetos ágeis começam como um item "essencial" e saem de lá de forma modular, conforme necessário (vi isso acontecer bastante nos projetos com os quais me envolvi). Então, você começa com um produto principal, digamos que seja um aplicativo de mapeamento. A primeira implementação é apenas um mapa que se concentra na sua localização atual (o que o cliente solicitou inicialmente).

O cliente decide então que deseja receber quedas de pinos de certas atrações ao seu redor. Ok, é uma peça muito grande (relativamente falando), então você a fatura como um novo "módulo" ou pedido de compra. Alterações em itens como a cor ou o design desses pinos são incorporadas ao custo desse pedido. As direções e as sobreposições são outro pedido de compra, pois não foram solicitadas até o início do outro pedido, e assim por diante.