Estimativa de custos de software no gerenciamento ágil de projetos

Introdução

Uma das coisas mais difíceis de se fazer no desenvolvimento de software é determinar quanto tempo e quanto levará para entregar um novo produto de software. Deveria ser tão difícil? A resposta não é simples.

A estimativa de custos de software é inerentemente difícil, e os humanos são terrivelmente ruins em prever resultados absolutos. Não há dois projetos iguais; cada um é único no que se propõe a alcançar e único na miríade de parâmetros que formam sua existência. Muitas vezes, o que parece ser um problema simples na superfície é muito mais difícil ou tecnicamente desafiador de implementar na realidade. E, sem dúvida, haverá 'incógnitas' com o projeto que só poderão ser identificadas quando surgirem.

Além disso, não há duas pessoas iguais, seja você um cliente, um desenvolvedor ou um usuário. Viemos pré-carregados com nosso próprio conjunto de conhecimentos, experiências, valores, expectativas, atitude em relação ao risco e capacidade de adaptação.

Escrever software de boa qualidade é pão com manteiga para engenheiros seniores; criar produtos de software incríveis pode ser uma tarefa muito mais difícil para todos os envolvidos.

Mas quando se trata de software, entender a duração e o custo são fundamentais para a tomada de decisões estratégicas de negócios e isso é verdade se você estiver criando uma startup, realizando uma nova oportunidade de negócios ou permitindo que sua empresa tenha um melhor desempenho. O momento, o retorno do investimento e os benefícios entregues podem fazer, abalar ou quebrar o seu negócio. Você estará se perguntando: O que ganhamos com nosso dinheiro? Podemos prever nossos custos? Qual será o custo para criar o produto que queremos? Quando podemos lançar? Vamos obter um produto de qualidade para o nosso investimento? Vai crescer com o nosso negócio? Será que vai entregar valor de negócios?

Então, como você estima o tamanho, a duração e o custo de um projeto? Vamos explorar a estimativa de projetos Agile e os custos de desenvolvimento de software e como fazemos isso na Toptal.

Precificação e Estimativa de Contrato Tradicional

Tradicionalmente, usando práticas não ágeis, os projetos de software buscavam fixar funcionalidade ou escopo e deixar tempo e custo serem variáveis. Isso causa problemas:

1. Como você sabe que a funcionalidade corrigida no início de um projeto é realmente a funcionalidade que atende melhor à sua empresa ou clientes? Na maioria das vezes, a funcionalidade ou o escopo mudam, e é por isso que ouvimos falar de 'scope creep', o resultado das necessidades desejadas sendo identificadas ao longo do ciclo de vida de um projeto e sendo determinadas como necessárias ou obrigatórias

2. Quando o custo se torna uma variável, perdemos o controle sobre o retorno do investimento (ROI) que buscamos alcançar. O aumento do custo geralmente é um produto de riscos não identificados ou requisitos em mudança, o que significa que precisamos adicionar membros da equipe para fazer mais trabalho no mesmo período ou manter os membros da equipe por mais tempo. Nem é desejável

3. Quando o tempo é uma variável, perdemos o controle sobre a posição em nosso mercado. Talvez perdemos uma data importante do setor ou nossos concorrentes lançam seus produtos antes de nós, perdendo assim qualquer vantagem competitiva que nosso projeto possa ter tido.

Existem muitos outros resultados de tempo e custo variáveis, que muitas vezes são negativos e indesejáveis.

É claro que muitos clientes e organizações procuram consertar todos os três componentes desse 'triângulo mágico'. Infelizmente, é quase impossível de alcançar realisticamente. Há muitos elementos que conspiram para desestabilizar esse ideal, que acabam em produtos que não atendem a uma necessidade, demoram muito para beneficiar seus clientes ou custam muito para obter valor comercial.

Contratos ágeis para projetos de software

O custo é um produto do tempo e das pessoas (membros da equipe). Adicione mais tempo e você adicionará custos para empregar pessoas por mais tempo. Adicione mais membros à equipe e você aumentará o custo para entregar o mesmo valor comercial. As coisas que realmente queremos evitar. É por isso que os princípios ágeis acreditam em fixar o tempo e os membros da equipe e permitir que o escopo seja o componente variável.

O que soa melhor e aumenta a confiança das partes interessadas, custo fixo ou custo variável?

Obviamente, é importante que um produto cumpra suas promessas e as necessidades de seus clientes. Não adianta gastar uma quantidade exata de tempo e uma quantidade exata de dinheiro se, no final, você tem um produto que ninguém quer ou pode usar de forma eficaz.

Portanto, os contratos ágeis se concentram no seguinte:

• Pacotes de trabalho de preço fixo - Todo o projeto é dividido em 'mini' lançamentos lógicos que contribuem para o resultado completo do produto. Cada versão é um pacote de trabalho com preço adequado. À medida que um pacote de trabalho é concluído, os pacotes de trabalho futuros são reestimados com base no que aprendemos com o anterior. Isso evita contingências desnecessárias e permite que um nível de repriorização e recursos novos/revisados ​​sejam definidos pelo cliente.

• Rescisão antecipada - Isso permite que o cliente procure encerrar o projeto antecipadamente se o produto tiver sido entregue suficiente e não houver mais ROI a ser alcançado mantendo uma equipe de projeto que continuará a fornecer ganhos marginais. Esta cláusula é normalmente permitida a qualquer momento e é válida desde que a equipe do projeto e o cliente tenham mantido um relacionamento colaborativo de trabalho forte, confiável e próximo. O benefício para o cliente é que o projeto terminará mais cedo, tendo entregue todos os valiosos recursos necessários para tornar o produto viável. Em troca, o fornecedor recebe 20% do valor restante do contrato e compensa o risco de retenção de pessoal.

• Mudanças flexíveis - Mudança é um tema que corre forte nas veias da entrega de software Agile. Esperamos não saber tudo o que precisamos para tornar um produto bem-sucedido desde o início. Assim, promovemos a mudança, com base em dados e feedback relevantes, para garantir que o produto certo seja entregue. No final de uma iteração, as alterações podem ser trocadas por recursos antigos que não são mais considerados necessários ou prioritários. Desde que a mudança seja de igual valor, não há custo adicional. Se a mudança for de valor menor, o trabalho adicional pode ser identificado ou puxado para frente do backlog restante. Esta cláusula é válida desde que a equipe do projeto e o cliente tenham mantido um relacionamento colaborativo de trabalho forte, confiável e próximo durante todo o projeto.

• Trabalho adicional - Ao longo da vida de um projeto, mais recursos podem ser identificados que não seriam alcançáveis ​​sob o contrato de preço fixo existente. Para este cenário, pacotes de trabalho adicionais com novos preços podem ser adicionados ao final do projeto ou reverter para tempo e materiais.

• Estimativas com intervalo - Existem duas maneiras de fazer o intervalo das estimativas em um contrato de projeto Agile: um intervalo de duração ou um intervalo de recursos. Um intervalo de duração permite que uma estimativa diga que o projeto ou pacote de trabalho levará de 12 a 16 semanas para um determinado conjunto de escopo. No entanto, adicionar duração aumenta o custo, pois você mantém os membros da equipe do projeto por mais tempo ou significa que eles não podem ser liberados para trabalhar em outros projetos de desenvolvimento. Na Toptal, preferimos variar os recursos em vários pontos da história, mantendo o escopo como variável, mas prometendo entregar um nível mínimo de valor ao cliente dentro do prazo fixo do pacote de trabalho ou do projeto geral.

Vale lembrar que você sempre pode adicionar mais escopo depois. Talvez você tenha começado a gerar receita, tenha aumentado os usuários ou reduzido os custos. De qualquer forma, é muito mais fácil pedir mais dinheiro e tempo se você já demonstrou um retorno ou melhoria e está entregando valor comercial.

Nossa abordagem aos custos e preços de software

Na Toptal, trabalhamos em estreita colaboração com nossos clientes e engenheiros para empregar técnicas que promovam a confiança das partes interessadas na duração e nos custos do projeto. Trabalhamos continuamente elaborando e adaptando o planejamento de um alto nível inicial até detalhes mais granulares quando for apropriado e necessário para evitar desperdícios e permitir mudanças gerenciadas.

Na elaboração de um projeto de orçamento e preço fixo são dados os seguintes passos:

1. Escopo inicial de alto nível

No início de um projeto, sabemos menos sobre seu resultado final. É loucura imaginar que é possível saber exatamente quais recursos nossos clientes e usuários precisam desde o início.

Assim, começamos com uma carta de projeto e um conjunto de alto nível de recursos “épicos” que orientam a direção do projeto, com base em uma visão e objetivos sólidos

uma. Definição de visão e objetivos O que precisamos construir? O que você precisa alcançar e quais são seus objetivos de negócios? Entender essas questões nos permite definir a escala do projeto. Você precisa de um protótipo para testar uma ideia, conceito ou tecnologia inicial? Você identificou uma proposta clara que foi testada com seu mercado e está pronto para construir seu primeiro Produto Mínimo Viável (MVP)? Ou você está escalando seu negócio ou produto existente para levá-lo ao próximo nível?

b. Recursos “épicos” de alto nível Sem entrar em muitos detalhes, você desejará definir os recursos que seu produto possui para atender às necessidades de seu cliente. Esta é uma “lista de compras” estruturada que descreve o esqueleto do seu produto; muitas vezes, eles são chamados de "Histórias de usuário" ou épicos

c. Análise MoSCoW A análise MoSCoW é uma técnica que, de forma simples, ajuda a identificar o que é realmente necessário para viabilizar o produto e o que é bom ter. Aqueles que são identificados como “Obrigatórios” satisfazem o que incentivará os usuários a se engajarem e adotarem seu produto. Esses recursos identificados como “deveriam” surpreender e encantar seus clientes, mas podem ser construídos mais tarde. Os itens “Poderiam” geralmente não agregam valor comercial significativo, podem não aumentar o retorno e são as mais baixas de suas prioridades. Os recursos "Não" podem muito bem ser importantes um dia, mas estão fora do escopo desta iteração do projeto. No entanto, identificá-los agora pode ajudar a ter em mente a escala e o tamanho potenciais do produto para o futuro.

2. Proposta

Para tomar uma decisão sobre prosseguir com um projeto, é necessário basear essa decisão em dados bem informados: custo e duração. Estes são os mínimos que você precisa se perguntar: O que será necessário para criar o produto que queremos? Quando podemos lançar? Isso está alinhado com nossa estratégia de negócios e finanças?

Com os detalhes acima, estamos em condições de fornecer uma proposta. Nossos engenheiros são escolhidos a dedo para os requisitos específicos do projeto e trabalham em conjunto com um gerente de projeto para obter pelo menos uma solução técnica, uma duração estimada que entrega o escopo conhecido e um custo estimado para concluir o projeto.

Como mencionamos anteriormente, no início de um projeto sabemos menos sobre o que será entregue. Mantemos deliberadamente os recursos e o escopo vagos, pois fazer o contrário sugere que sabemos exatamente o que é necessário. Uma estimativa nesta fase seria a menos precisa, mas fornece orientação sobre se vale a pena prosseguir com o projeto.

A proposta é a primeira ferramenta na elaboração da duração e custo de um projeto. Uma vez que uma proposta é aceita, podemos avançar para fornecer uma cotação com preço fixo.

3. Planejamento de Liberação

O próximo nível de elaboração da estimativa é criar um plano de lançamento que fornecerá uma variedade de recursos em um determinado período de tempo. Derivamos isso de uma lista de recursos, do tamanho do projeto, da rapidez com que nossa equipe pode desenvolver software de qualidade que atenda às expectativas do cliente e técnicas para gerenciar o risco de incerteza.

uma. Product Backlog O product backlog é simplesmente uma lista ordenada de “Epics” ou “User Stories” que representa os recursos necessários para um produto. Essa lista começa como os épicos discutidos anteriormente, mas entre a equipe de projeto designada, o gerente de projeto e o cliente, agora os dividimos em itens mais significativos. Cada um dos itens representa uma parte do valor do negócio para o cliente. Não entramos em mais detalhes nesta fase, não precisamos conhecer os critérios de aceitação, não precisamos saber se um botão é azul ou verde, só precisamos saber que existe um botão que permite alguma tarefa a ser executado.

b. Estimativa Agora que temos nossa lista de recursos descritos como histórias de usuários, a equipe estima esses itens discretos de recursos usando uma técnica chamada “Planning Poker”. Esta é uma técnica útil que garante resultados rápidos e confiáveis ​​com base na opinião de especialistas e dimensionamento análogo. O Planning Poker atribui um número acordado para cada item representando seu tamanho e complexidade. Isso é chamado de ponto de história. Outras técnicas e tamanhos de estimativas ágeis, como 'dias ideais', estão disponíveis.

O final desse processo determinará o tamanho do projeto e as dependências entre os recursos. O tamanho é determinado pela soma de todos os pontos de história dos itens no backlog do produto. Se esse número for igual a 120, então o tamanho do nosso projeto é de 120 pontos de história.

c. Priorização Agora que temos um backlog e um tamanho para o projeto, estamos em condições de priorizá-lo com o cliente. Trata-se realmente de identificar o que é mais valioso para o cliente, a fim de alcançar os resultados desejados. O item no topo da lista é considerado o mais importante, o segundo item é menos importante que o primeiro e assim sucessivamente na lista. Dois itens não podem ser tão importantes quanto o outro, a prioridade de cada item é de importância relativa ou valor para cada um dos outros itens.

Essa abordagem de priorização é um marco importante no planejamento de um projeto de software. Agora sabemos o que é importante para o cliente e em qual ordem concluir o trabalho, cuidando das dependências, para entregar um produto que atenda às expectativas.

d. Planejamento de lançamento Até o momento, determinamos o que acreditamos ser o produto e qual o tamanho dele.

Agora, determinamos quanto tempo levará para entregar um produto liberável. O cliente e a equipe, incluindo designers, engenheiros, testadores, scrum master e gerente de projeto, trabalham juntos para identificar o que pode ser alcançado e com que rapidez o trabalho pode ser feito para criar um plano de lançamento.

O plano de lançamento também fornece informações sobre como o projeto se alinhará aos planos estratégicos do cliente.

E, finalmente, esse plano garante que a equipe do projeto tenha uma luz orientadora que conduza o caminho e defina um ponto final lógico para o desenvolvimento.

Antes de começarmos, garantimos que entendemos a definição acordada de “pronto”. Este é um determinado conjunto de critérios que um cliente aceitará como completo e também atende a todos os requisitos de engenharia para ser considerado liberável.

Para pegar um cenário básico, pegamos o número total de pontos de história que obtivemos ao dimensionar nosso backlog e dividimos isso pela velocidade prevista de nossas equipes. (A velocidade do NB é normalmente expressa como um intervalo, mas para simplificar, usaremos um único número aqui.) Trabalhamos em iterações de duas semanas para que nossa velocidade seja refletida por quanto podemos concluir em um ciclo de duas semanas com o disponível capacidade da equipe. Se nossos pontos de história totalizassem 120 e prevemos completar 20 pontos por iteração, a duração total do desenvolvimento seria de 12 semanas ou 6 iterações. Adicionamos a isso um sprint 0 de 2 semanas e um sprint de preparação de lançamento de duas semanas. No total, a duração do nosso projeto é de 16 semanas. Existem técnicas que podemos usar que ajudariam a construir um buffer de risco apropriado em nosso planejamento, que discutiremos mais adiante. Mas, resumindo, usamos o buffer para gerenciar o risco de incerteza e chegar a um acordo mínimo de pontos de história esperados a serem entregues. O resultado pode ser um intervalo de 90 a 150 pontos de história entregues, sendo 90 o mínimo que seria aceitável para criar um produto viável.

Alternativamente, se o projeto deve ser concluído em uma determinada data, em digamos 10 semanas, a equipe determinaria quanto do backlog pode ser concluído nesse tempo. Se anteciparmos 20 pontos de história por sprint, mais o Sprint 0 e um sprint de lançamento, estaríamos visando 60 pontos concluídos até o final do projeto. Mais uma vez, procuraríamos gerenciar o risco adicionando um buffer apropriado, o que pode resultar em uma meta de 45 a 75 pontos de história concluídos e prontos para lançamento. Os 45 pontos da história estariam alinhados com o mínimo aceitável para entregar um produto viável e valioso. Este é um cenário em que você pode esperar adicionar um membro da equipe para aumentar a velocidade, se apropriado.

É claro que todos os itens acima são apoiados por comunicação e colaboração de boa qualidade entre todas as partes para obter um plano de lançamento que seja alcançável, realista e aceitável para o cliente.

4. Contrato de Preço Fixo

Depois que um plano de lançamento é acordado, podemos criar uma cotação para um contrato de projeto de preço fixo. Como mencionado anteriormente, é aconselhável manter a duração do projeto e a equipe fixa e o escopo variável.

A cotação de um contrato de preço fixo é entregue juntamente com uma declaração de trabalho e cronograma de pagamento acordado.

Desde que haja confiança, comunicação, colaboração e prontidão para entrar no espírito de um projeto de software Agile, todas as etapas acima nos permitem entregar uma cotação com um grau realista de confiança de que um projeto será entregue no prazo e no orçamento. É claro que haverá ocasiões em que um projeto será entregue com antecedência ou atraso e lidamos com essas variações com a máxima transparência.

Técnicas de estimativa

O planejamento e a estimativa ágeis são suportados por várias técnicas que uma equipe de desenvolvimento pode usar para ganhar confiança em seu tamanho, esforço, duração e custo. Aqui estão alguns dos que nossas equipes usam para estimar o tamanho e o custo de um projeto de software.

Estimando o tamanho

O tamanho do projeto é realmente uma apreciação de seu escopo, complexidade, dimensões, risco e magnitude. Para usar uma analogia, trata-se de entender se estamos construindo a Torre Eiffel ou a Grande Muralha da China. A Torre Eiffel é uma estrutura alta, pesada e complexa construída em um ambiente urbano apertado. A Grande Muralha da China é uma estrutura relativamente simples, mas longa e robusta, abrangendo muitos quilômetros de terreno ondulado.

Embora ambos sejam grandes projetos a serem entregues, seu escopo, complexidade, dimensões, magnitude e, portanto, tamanho são diferentes.

É importante gerenciar expectativas com estimativas. Nunca são previsões, compromissos ou garantias. Ao discutir o tamanho total, a duração total e o custo total, sempre trabalhamos dentro de intervalos, de modo a mitigar riscos, incertezas e incógnitas.

Histórias que representam recursos do seu produto são dimensionadas individualmente e estimadas usando pontos de história ou dias ideais. O número total dessas unidades define o tamanho total do projeto.

Pontos de história

Os pontos de história são uma unidade de medida que expressa o tamanho geral de uma história de usuário. O tamanho de uma história, quando estimado, inclui todos os aspectos de design, engenharia, teste, revisão de código, integração, etc.

Cada tamanho de uma história é relativo a outra história. Assim, por exemplo, a História A pode ser dimensionada como um ponto, a História B como dois pontos e a História C como três pontos. Aqui, a história C é pelo menos três vezes o tamanho da história A e pelo menos metade do tamanho da história B.

Se as seguintes histórias em nosso backlog de produto tiverem os tamanhos associados:

O tamanho total do projeto é de 12 pontos de história.

Dias ideais

Esta é uma medida de tamanho expressa em dias. Ele remove o conceito de despesas gerais, como interrupções, atividades de planejamento ágil, leitura de e-mails e outras atividades não relacionadas ao projeto. Ele se concentra apenas em quanto tempo levaria se você trabalhasse em algo continuamente sem interrupção, em vez do tempo decorrido do início ao fim.

Normalmente, ao estimar em um nível alto quando sabemos menos sobre um projeto, estimaríamos em dias ideais, pois esse é um conceito mais fácil de correlacionar com a história e a experiência passadas do que um número abstrato, como um ponto de história. Especialmente quando as histórias de alto nível são mais épicas por natureza, com poucos detalhes e possivelmente contendo elementos adicionais quando divididas em uma data posterior.

Ao estimar em um nível mais granular, digamos uma história em um backlog de produto estabelecido, qualquer uma das abordagens pode ser usada e seria decidida pela equipe de engenharia. Existem benefícios para ambas as abordagens e cada equipe terá sua preferência.

Técnicas de Estimativa

Estimativas compartilhadas As estimativas não são realizadas isoladamente. Eles são executados de forma colaborativa por toda a equipe de engenharia e incluem design, banco de dados, servidor, interface do usuário de front-end, controle de qualidade e outros especialistas multifuncionais. Isso evita problemas de não considerar todos os aspectos do trabalho envolvido para concluir um recurso e garante que nenhuma pessoa tenha o ônus ou a infelicidade de super ou subestimar o tamanho de um recurso. A equipe combinada terá uma visão que pode ser discutida e acordada.

Estimativas Análogas É aqui que consideramos duas características discretas e decidimos que uma é relativamente menor ou maior que a outra. Podemos olhar para uma determinada história e concordar que ela é pequena em tamanho e, se estiver usando pontos de história, podemos atribuir a ela um tamanho de dois. A próxima história pode ser considerada grande em comparação com a primeira, e nós lhe daríamos um tamanho de cinco. Isso sugere que um grande é pelo menos duas vezes o tamanho de um pequeno recurso.

Continuaríamos este exercício com todas as histórias. Depois de concluído, podemos colocar todos os andares pequenos, médios, grandes e extragrandes lado a lado e verificar nosso dimensionamento para garantir que haja um nível de uniformidade em nossa estimativa.

Planning Poker Muito tem sido escrito sobre Planning Poker; Eu também mencionei isso no meu blog anterior. Um dos melhores recursos para compreendê-lo está aqui.

Em essência, combina opinião de especialistas, analogia e colaboração em equipe em um processo fácil, rápido e confiável.

Reúne vários especialistas que são mais adequados para construir uma estimativa com base na experiência técnica e de domínio, um diálogo animado e uma justificativa sólida.

Velocidade

A velocidade é uma medida da capacidade de uma equipe de realizar o trabalho em uma determinada iteração (ou sprint).

Ele é expresso como um intervalo, por exemplo, de 23 a 32 pontos de história por sprint, especialmente no início da vida de um projeto. Geralmente, isso ocorre porque, a menos que a mesma equipe tenha trabalhado antes no mesmo problema, é difícil descrever exatamente qual será a velocidade da equipe. Observe, nos referimos à velocidade de uma equipe e não de um indivíduo!

Usamos a velocidade para planejar nossos lançamentos e adaptar nossos planos e pacotes de trabalho à medida que avançamos em um projeto, permitindo-nos ajustar nossa previsão de conclusão regularmente e com precisão por meio da execução.

Quando começamos, somos forçados a definir uma faixa de velocidade com muito poucos dados. Podemos usar valores históricos se a equipe e o espaço do problema forem os mesmos, o que geralmente é menos provável. Podemos executar uma iteração para ter uma ideia da velocidade de uma equipe que está realmente trabalhando no projeto, mas isso é caro e não funciona se as decisões ainda precisam ser tomadas para concordar em iniciar um projeto. Ou podemos fazer uma previsão.

Prever uma velocidade envolve pegar as histórias de um sprint e dividi-las em tarefas que são executadas para completar a história. Estimaríamos o número de horas que cada tarefa levará, o que inclui design, desenvolvimento, teste e assim por diante, e avaliaríamos quanta capacidade a equipe teria em um determinado sprint. Uma capacidade de 70 por cento para uma equipe desimpedida é uma boa base. Então, em uma situação simples, se o total de horas disponíveis para a equipe for:

• 4 membros da equipe * duas semanas * 40 horas por semana = 320 horas
• Multiplicado por nossa capacidade de 70% = 224 horas
• Adicione todas as tarefas de recursos e pare de contar em 224
• Pegue todos os recursos concluídos, some seus pontos de história e você obtém sua velocidade, digamos 36
• Aplique 20% em cada lado para obter um intervalo do mais baixo e do mais alto, para chegar a uma velocidade estimada de 29 a 43 pontos de história.

A velocidade geralmente varia nas primeiras duas a quatro iterações e depois se estabiliza dentro de uma pequena faixa de pontos. Assim, onde nosso intervalo inicial antes do sprint um era de 29 a 43, no sprint quatro, pode atingir um platô de 34 a 38. Isso nos dá mais confiança na previsão de nossa data final de conclusão.

Planos de buffer para risco e incerteza

Todos os projetos de software vêm com um nível de incerteza. Essa incerteza diminui à medida que avançamos no projeto e mais se sabe sobre nossa tecnologia, ambiente, desempenho e as necessidades do cliente e dos usuários.

Nós mitigamos essa incerteza ou risco com um buffer no cronograma, o que representa uma margem de erro em nossa estimativa e as incógnitas que não podemos determinar antes do início do desenvolvimento.

Normalmente, há dois tipos de buffer: Recurso e Agendamento. Como muitas vezes definimos um preço fixo para uma data de entrega fixa, é preferível usar o buffer de recursos.

Essa abordagem nos dá uma estratégia de mitigação de risco confiável e dá ao cliente confiança no que eles devem esperar ver como resultado quando o projeto estiver concluído.

Buffers de recursos

Com um buffer de recursos, estamos prevendo que entregaremos um determinado conjunto de recursos, mas, idealmente, completaremos um conjunto adicional de recursos. Isso deve refletir pelo menos o conjunto mínimo de recursos que o cliente considera necessário para lançar um produto viável, mas mais podem ser entregues dentro do prazo se todas as várias influências internas e externas permitirem.

Assim, um cliente pode decidir que os recursos de maior prioridade do backlog do produto, somando até 100 pontos de história, são os mais importantes. Eles então podem considerar recursos adicionais que somam mais 30 pontos de história. A equipe, portanto, planejará com base na entrega de 130 pontos de história, com o mínimo de 100 sendo concluído até o final da data de conclusão programada para o contrato de preço fixo fornecido.

Alguns pensamentos finais

Ágil pode ser um conceito muito difícil de entender e adotar completamente. Isso não é menos verdade ao gerenciar tópicos sensíveis, como preço, escopo e duração. Infelizmente, eu sei em primeira mão que clientes exigentes querem tudo pronto e estão ansiosos para culpar o fornecedor quando tudo começar a desmoronar. Da mesma forma, estou ciente dos fornecedores que se empenham, não respondem e não respondem às necessidades do cliente. Seguir um caminho ágil é fundamentalmente construído com confiança, bons relacionamentos e comunicação estelar. Esses devem ser valores mantidos por ambas as partes, a fim de manter um projeto saudável para benefício igual, satisfação e sucesso para todos os envolvidos. Manter uma mente aberta e uma atitude construtiva em relação à colaboração e à negociação é a melhor maneira de evitar que os relacionamentos azedem.

Trabalhei com clientes que acharam difícil adotar a natureza adaptativa do Agile e abrir mão de uma atitude de comando e controle. É difícil deixar ir e colocar toda a sua fé e confiança em uma equipe que você não conhece. Muitas vezes, os clientes podem querer criar todos os requisitos antecipadamente como uma especificação do que será entregue. Isso lhes dá uma sensação de confiança de que o escopo de um projeto está bem definido. Mas, em última análise, isso não se materializa como uma abordagem bem-sucedida. Se estivermos presos ao escopo e às demandas irreais em um contrato, os problemas surgirão muito rapidamente.

Sabemos que, ao adotar essa abordagem nos métodos tradicionais, o escopo muda, as incógnitas são descobertas ou o que pensávamos que o cliente queria não é mais verdade ou está longe da realidade. Adotar uma abordagem adaptativa de preços, planejamento e escopo permite que os clientes identifiquem verdadeiramente que seu produto é exatamente o que seu mercado precisa. Ele permite que um fornecedor seja responsivo, imaginativo e eficiente também. Aproveitar a colaboração entre cliente e fornecedor na negociação do contrato é fundamental.

Os fornecedores precisam ser honestos e os clientes precisam ser realistas sobre o que pode ser alcançado desde o início. Um fornecedor que promete metas irreais e depois aumenta os custos pode ganhar o contrato inicial, mas logo perderá o favor de um cliente insatisfeito. Muitas vezes, os relacionamentos se rompem devido à falta de confiança entre as partes. A confiança deve ser construída desde o início e mantida ao longo de um projeto. Um fornecedor deve ser flexível e cooperar com as necessidades em constante mudança. Os clientes sempre querem mais; é uma consequência natural de fazer negócios. Deve haver uma troca de valor igual e benéfica entre ambos os lados. Para os clientes, eles procuram criar valor para seus negócios. Para os fornecedores, eles devem procurar criar valor formando relacionamentos duradouros com os clientes. Observar os valores e princípios orientadores do Manifesto Ágil é uma base sólida para formar relacionamentos fortes, equilibrados e duradouros.

Resumo

Espero que isso tenha lhe dado algumas dicas sobre como planejar, estimar e definir um preço para um projeto de software Agile. Todas as abordagens e técnicas acima são projetadas para construir confiança em uma equipe e para construir confiança nas mentes dos clientes sobre quanto tempo e quanto levará para construir um produto de software. E, finalmente, para construir confiança na tomada de decisão de prosseguir.

Siga estas diretrizes e você certamente encontrará um caminho satisfatório para dar vida ao seu produto de software.