Introdução

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

A estimativa de custos de software é inerentemente difícil, e os humanos são terrivelmente ruins em prever resultados absolutos. Não existem 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. Freqüentemente, 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ó podem ser identificadas quando surgem.

Além disso, não existem duas pessoas iguais, seja você um cliente, desenvolvedor ou usuário. Chegamos 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 um esforço muito mais difícil para todos os envolvidos.

Fornecer software incrível é um ato de equilíbrio Tweet

Mas quando se trata de software, entender a duração e o custo são fundamentais para tomar decisões estratégicas de negócios, e isso é verdade quer você esteja criando uma startup, percebendo uma nova oportunidade de negócio ou permitindo que seu negócio tenha um desempenho melhor. O momento, o retorno sobre o investimento e os benefícios entregues podem fazer, abalar ou quebrar o seu negócio. Você se perguntará: o que ganhamos com nosso dinheiro? Podemos prever nossos custos? Quanto custará para criar o produto que queremos? Quando podemos lançar? Teremos um produto de qualidade pelo nosso investimento? Vai crescer com o nosso negócio? Isso vai agregar valor ao negócio?

Então, como você faz para estimar o tamanho, a duração e o custo de um projeto? Vamos explorar a estimativa de projeto Agile e os custos de desenvolvimento de software, e como fazemos isso no ApeeScape.

Preço e estimativa de contrato tradicional

Tradicionalmente, usando práticas não ágeis, os projetos de software têm buscado fixar a funcionalidade ou o escopo e deixar que o tempo e o custo sejam variáveis. Isso causa problemas:

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

2. Quando o custo se torna uma variável, perdemos o controle sobre o retorno sobre o investimento (ROI) que buscamos alcançar. O aumento do custo é frequentemente um produto de riscos não identificados ou requisitos em mudança, o que significa que temos que 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 da indústria ou nossos concorrentes lançam seus produtos antes de nós, perdendo, assim, qualquer vantagem competitiva que nosso projeto possa ter.

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

Claro, muitos clientes e organizações procuram consertar todos os três componentes desse ‘triângulo mágico’. Infelizmente, é quase impossível alcançar de forma realista. Existem muitos elementos que conspiram para perturbar esse ideal, que acaba resultando 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ê adiciona custo para empregar pessoas por mais tempo. Adicione mais membros da equipe e você aumenta o custo para entregar o mesmo valor comercial. As coisas que realmente queremos evitar. É por isso que os princípios do Agile 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?

Claro, é importante que um produto cumpra suas promessas e as necessidades de seus clientes. Não é bom 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 Agile se concentram no seguinte:

como iniciar um fundo imobiliário de private equity

• Pacotes de trabalho de preço fixo - Todo o projeto é dividido em ‘mini’ versões lógicas que contribuem para o resultado completo do produto. Cada versão é um pacote de trabalho cujo preço é adequado. Conforme 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 um nível de redefinição de prioridades e recursos novos / revisados ​​a serem definidos pelo cliente.

• Rescisão antecipada - Isso permite que o cliente tente encerrar o projeto mais cedo se o suficiente do produto tiver sido entregue e não houver mais ROI a ser alcançado ao reter uma equipe de projeto que continuará a entregar ganhos marginais. Esta cláusula é normalmente permitida a qualquer momento e é válida desde que a equipe do projeto e o cliente mantenham uma relação de trabalho colaborativa forte, confiável e próxima. 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 por cento do valor restante do contrato e compensa o risco de reter 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. Portanto, promovemos mudanças, 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. Contanto que a mudança tenha o mesmo valor, não há custo adicional. Se a mudança for de valor inferior, trabalho adicional pode ser identificado ou puxado para frente da carteira restante. Esta cláusula é válida desde que a equipe do projeto e o cliente mantenham uma relação de colaboração de trabalho forte, confiável e próxima ao longo do 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 preços recentes podem ser adicionados ao final do projeto ou reverter para tempo e materiais.

• Estimativas de alcance - Existem duas maneiras de as estimativas serem divididas em um contrato de projeto Agile: uma faixa de duração ou uma variedade de recursos. Uma faixa 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 adiciona custo à medida que 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. No ApeeScape, preferimos incluir recursos em uma série de pontos da história, mantendo o escopo como a variável, mas prometendo fornecer um nível mínimo de valor ao cliente dentro do prazo fixo do pacote de trabalho ou projeto geral.

É importante lembrar que você sempre pode adicionar mais escopo posteriormente. Talvez você tenha começado a gerar receita, aumentou os usuários ou reduziu 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 de negócio.

Nossa abordagem para custos e preços de software

No ApeeScape, 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 na elaboração e adaptação do planejamento desde um alto nível inicial até os detalhes mais granulares, quando for apropriado e necessário, para evitar desperdícios e permitir mudanças gerenciadas.

As seguintes etapas são realizadas na elaboração de um orçamento e projeto de preço fixo:

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.

Então, começamos com um termo de abertura do projeto e um conjunto de alto nível de recursos 'épicos' que orientam a direção do projeto, com base em uma visão sólida e objetivos

para. Visão e definição de objetivos O que precisamos construir? O que você precisa alcançar e quais são seus objetivos de negócios? A compreensão dessas 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 proposição clara que foi testada com seu mercado e está pronto para construir seu primeiro Produto Mínimo Viável ( MVP )? Ou você está dimensionando 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 tem para atender às necessidades do cliente. Esta é uma “lista de compras” estruturada que descreve o básico do seu produto; muitas vezes, estes são referidos como “ Histórias de usuários ”Ou épicos

c. Análise MoSCoW Análise MoSCoW é uma técnica que, simplificada, ajuda a identificar o que é realmente necessário para tornar o produto viável e o que é bom ter. Aqueles que são identificados como “Obrigatórios” satisfazem o que irá encorajar os usuários a se envolver e adotar seu produto. Os recursos identificados como “Deveria” surpreenderão e encantarão seus clientes, mas podem ser desenvolvidos posteriormente. Os itens “poderiam” muitas vezes não agregam valor comercial significativo, podem não aumentar o retorno e são a mais baixa de suas prioridades. Os recursos do tipo 'Não vou' podem muito bem ser importantes um dia, mas estão fora do escopo para esta iteração do projeto. No entanto, identificá-los agora pode ajudar a ter em mente a escala e o tamanho potencial do produto para o futuro.

2. Proposta

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

Com os detalhes acima, podemos apresentar 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 forneça o escopo conhecido e um custo estimado para concluir o projeto.

Como mencionamos antes, no início de um projeto sabemos menos sobre o que será entregue. Nós deliberadamente mantemos 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 continuar com o projeto.

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

3. Planejamento de liberação

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

para. Backlog do produto o carteira de produtos é simplesmente uma lista ordenada de “Epics” ou “User Stories” que representa os recursos necessários para um produto. Esta lista começa como as epopeias discutidas anteriormente, mas entre a equipe de projeto designada, o gerente de projeto e o cliente, agora dividimos isso em itens mais significativos. Cada um dos itens representa uma parte do valor comercial para o cliente. Não entramos em mais detalhes nesta fase, não precisamos saber os critérios de aceitação, não precisamos saber se um botão é azul ou verde, apenas 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 a cada item, representando seu tamanho e complexidade. Isso é chamado de storypoint. De outros Estimativa ágil técnicas e tamanhos, como ‘ dias ideais ', Estão disponíveis.

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

c. Priorização Agora que temos uma carteira de pedidos e um tamanho para o projeto, estamos em uma posição para priorizá-lo com o cliente. Na verdade, trata-se 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 por diante ao longo da 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 para que fim realizar o trabalho, cuidando das dependências, para entregar um produto que atenda às expectativas.

d. Planejamento de Liberação Até o momento, determinamos o que acreditamos ser o produto e quão grande ele é.

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 liberação.

O plano de liberação também dá uma ideia de como o projeto se alinhará com os planos estratégicos do cliente.

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

Antes de começar, 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 obter um cenário básico, pegamos o número total de pontos de história que obtivemos com o dimensionamento de nosso backlog e o dividimos por nossas equipes antecipadas velocidade . (NB a velocidade é 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 completar em um ciclo de duas semanas com o disponível capacidade da equipe. Se nossos pontos de história totalizassem 120 e esperamos 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 uma reserva de risco apropriada em nosso planejamento, que discutiremos mais tarde. Mas, em resumo, 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 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 naquele tempo. Se anteciparmos 20 pontos de história por sprint, mais Sprint 0 e um sprint de lançamento, teremos como meta 60 pontos concluídos até o final do projeto. Novamente, procuraríamos gerenciar o risco adicionando um buffer apropriado, o que poderia resultar em uma meta de 45 a 75 pontos de história concluída e pronta para ser liberada. Os 45 pontos de história se alinham 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.

Obviamente, todos os itens acima são suportados por comunicação e colaboração de boa qualidade entre todas as partes para derivar 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 liberação é acordado, podemos criar uma cotação para um contrato de projeto de preço fixo. Conforme mencionado anteriormente, é aconselhável manter a duração do projeto e a equipe fixas e o escopo variável.

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

Contanto 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 fornecer uma cotação com um grau realista de confiança de que o projeto será entregue no prazo e no orçamento. Claro, haverá ocasiões em que um projeto é entregue mais cedo ou mais tarde e lidamos com essas variações com a máxima transparência.

Estimativa Técnica

O planejamento e a estimativa do Agile são suportados por uma série de 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 fechado. A Grande Muralha da China é uma estrutura relativamente simples, mas longa e robusta, cobrindo muitos quilômetros de terreno ondulado.

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

É importante gerenciar as expectativas com estimativas. Nunca são previsões, compromissos ou garantias. Quando discutimos tamanho total, duração total e custo total, sempre trabalhamos dentro de faixas, de forma a mitigar riscos, incertezas e incógnitas.

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

Story Points

Os pontos da história são uma unidade de medida que expressa o tamanho geral de uma história do 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 tem 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 nossa carteira de produtos tiverem os tamanhos associados:

História	Tamanho
PARA	1
B	5
C	3
D	1
É	2

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

Dias ideais

Esta é uma medida de tamanho expressa em dias. Ele remove o conceito de sobrecargas, 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, ao invés do tempo decorrido do início ao fim.

Normalmente, ao estimar em um alto nível 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 experiência anteriores do que um número abstrato, como um ponto da 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, diga uma história em um backlog de produto estabelecido, qualquer abordagem pode ser usada e seria decidida pela equipe de engenharia. Há benefícios em 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 em conjunto e incluem design, banco de dados, servidor, interface de usuário front-end, QA e outros especialistas multifuncionais. Isso evita problemas de não considerar todos os aspectos do trabalho envolvidos para concluir um recurso e garante que nenhuma pessoa tenha o fardo ou azar 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 usarmos os pontos da história, podemos dar a ela o tamanho dois. A próxima história pode ser considerada grande em comparação com a primeira, e lhe daríamos um tamanho cinco. Isso sugere que um grande é pelo menos duas vezes o tamanho de um pequeno.

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 foi escrito sobre o Planning Poker; Eu também mencionei isso no meu Blog . Um dos melhores recursos para entendê-lo é Aqui .

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

Ele 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

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

É expresso como um intervalo, por exemplo, 23 a 32 pontos da 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, o que nos permite ajustar nossa previsão de conclusão regularmente e com precisão durante a 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 realmente está trabalhando no projeto, mas isso é caro e não funciona se ainda houver decisões a serem tomadas sobre o acordo de iniciar um projeto. Ou podemos fazer uma previsão.

Prever a velocidade envolve pegar as histórias de um sprint e dividi-las em tarefas que são realizadas para completar a história. Estimaríamos o número de horas que cada tarefa levaria, 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 não sobrecarregada é uma boa linha de 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 por cento = 224 horas
• Some 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 por cento de cada lado para obter uma faixa do menor e do maior, para chegar a uma velocidade estimada de 29 a 43 pontos por história.

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

Planos de proteção para risco e incerteza

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

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, existem dois tipos de buffer: Recurso e Programação. Como costumamos definir um preço fixo para uma data de entrega fixa, é preferível usar o buffer de recurso.

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

Buffers de recursos

Com um buffer de recursos, estamos prevendo que entregaremos um determinado conjunto de recursos, mas o ideal é completar 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.

Portanto, 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, irá 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

Agile pode ser um conceito muito difícil de compreender e adotar totalmente. Isso não é menos verdadeiro ao gerenciar tópicos sensíveis como preço, escopo e duração. Infelizmente, sei em primeira mão que clientes exigentes querem que tudo seja consertado de antemão e estão ansiosos para culpar o fornecedor quando tudo começar a se desfazer. Da mesma forma, conheço fornecedores que se esforçam, não respondem e não respondem às necessidades dos clientes. Seguir um caminho Agile baseia-se fundamentalmente em 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 e com igual benefício, satisfação e sucesso para todos os envolvidos. Manter a mente aberta e uma atitude construtiva em relação à colaboração e negociação é a melhor maneira de evitar que os relacionamentos azedem.

Eu trabalhei com clientes que acharam difícil abraçar a natureza adaptativa do Agile e abrir mão de uma atitude de comando e controle. É difícil abandonar e colocar toda a sua fé e confiança em uma equipe que você não conhece. Freqüentemente, os clientes podem desejar 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 restritos ao escopo e às demandas irrealistas em um contrato, os problemas surgem muito rapidamente.

Sabemos, ao adotar essa abordagem em métodos tradicionais, que mudanças de escopo, incógnitas são descobertas ou o que pensávamos que o cliente queria não é mais verdade ou está muito errado. Adotar uma abordagem adaptativa de preço, planejamento e escopo permite que os clientes identifiquem verdadeiramente seu produto para ser exatamente o que seu mercado precisa. Ele permite que um fornecedor seja responsivo, criativo e eficiente. Aproveitar a colaboração entre o cliente e o 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 irrealistas e então aumenta os custos pode ganhar o contrato inicial, mas logo perderá o favor de um cliente insatisfeito. Muitas vezes, os relacionamentos são interrompidos devido à falta de confiança ou seguranç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 mudanças nas necessidades. Os clientes sempre querem mais; é uma consequência natural de fazer negócios. Deve haver uma troca de valor igual e benéfica entre os dois lados. Para os clientes, eles procuram criar valor para seus negócios. Para os fornecedores, eles devem procurar criar valor por meio da formação de 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 longos.

Spring Boot Security Rest autenticação

Resumo

Espero que isso tenha lhe dado algumas dicas sobre o planejamento, estimativa e definição de um preço para um Ágil projeto de software. Todas as abordagens e técnicas acima são projetadas para construir confiança em uma equipe e construir confiança nas mentes dos clientes sobre quanto tempo e quanto será necessário para construir um produto de software. E, finalmente, para construir confiança ao tomar a decisão de prosseguir.

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