Lidando com sprints e prazos com falha

Muitos livros e artigos do Scrum dizem que um sprint com falha (quando a equipe falha em concluir alguns recursos do Sprint Backlog) não é algo tão ruim, acontece de tempos em tempos, e pode ser realmente útil se a equipe aprender com seus erros e melhora algo nos seguintes sprints. E a equipe não deve ser punida por não concluir o trabalho com o qual se comprometeu.

Isso parece ótimo do ponto de vista do desenvolvedor, no entanto, digamos que temos uma empresa de software " Scrum-Addicts LLC " desenvolvendo algo para clientes sérios (" Money-Bags Corporation "):

1. Os gerentes de Scrum-Addicts sugerem criar um software para Money-Bags
2. Eles concordam com uma lista de recursos, e a Money-Bags pede uma data de envio
3. Os gerentes do Scrum-Addicts consultam sua equipe de scrum, e a equipe diz que serão necessários três sprints de uma semana para concluir todos os recursos
4. O gerente do Scrum-Addicts acrescenta 1 semana para a segurança, promete enviar o software em 1 mês e assina um contrato com a Money-Bags
5. Após 4 sprints (prazo de entrega), a equipe Scrum pode fornecer apenas 80% dos recursos (devido à inexperiência com o novo sistema, a necessidade de corrigir bugs críticos em recursos anteriores no ambiente de produção, etc.)
6. Como sugere o Scrum, neste momento, o produto é potencialmente entregável, mas a Money-Bags precisa de 100% dos recursos, conforme mencionado no contrato. Então eles quebram o contrato e não pagam nada.
7. Os Scrum-Addicts estão à beira da falência porque não receberam dinheiro da Money-Bags, e os investidores ficaram decepcionados com os resultados e não estão mais dispostos a ajudar a empresa.

Obviamente, nenhuma empresa de software quer estar no lugar dos Scrum-Addicts. O que não entendo sobre o Agile e o Scrum é como eles sugerem que as equipes devem lidar com o planejamento e os prazos para evitar a situação descrita acima. Então, para resumir, tenho 2 perguntas:

Quem é o culpado?

1. Gerentes, porque é o trabalho deles fazer o planejamento adequado
2. A equipe, porque eles se comprometeram a fazer mais trabalho do que podiam
3. Alguém

O que é para ser feito?

1. Os gerentes devem mudar o prazo duas vezes (ou 3x) depois da estimativa da equipe original.
2. Os membros da equipe devem ser incentivados a fazer todo o trabalho com o qual se comprometeram, não importando o quê (emitindo penalidades por sprints com falha)
3. A equipe deve abandonar o Scrum porque não se encaixa na política de prazos da empresa
4. Todos devemos abandonar o desenvolvimento de software e ingressar em um mosteiro
5. ???

Vejo vários problemas fundamentais de gerenciamento em seu exemplo:

• se um gerente de Scrum-Addicts assina um contrato de "prazo final", mas adiciona apenas uma margem de segurança de 33% em uma situação em que "um novo sistema está envolvido", isso é bastante imprudente.

• a disponibilidade de entregar pelo menos x% dos recursos após um mês poderia ter sido usada para negociar um contrato em que os clientes pagam o dinheiro pelo menos parcialmente quando ele obtém apenas 80% dos recursos no prazo. Um contrato de tudo ou nada é algo que nem o fornecedor de software nem o cliente se beneficiarão - isso significa não apenas 0 dinheiro para o fornecedor, mas também 0 recursos para o cliente. E uma metodologia de desenvolvimento do tipo tudo ou nada, como "Waterfall", permitirá apenas que você escreva esses contratos; uma abordagem ágil oferece possibilidades adicionais.

• analisar os resultados do primeiro ou dois sprints deveria ter tornado óbvio para o gerente que a equipe não pode cumprir o prazo. Portanto, ele deveria ter tomado ações anteriores e priorizar novamente as tarefas e os recursos restantes, ou tentar renegociar com o cliente mais cedo. Por exemplo, o gerente poderia ter tentado reduzir o escopo de alguns dos recursos restantes, para que a equipe pudesse entregar todos os recursos mencionados no contrato, mas cada um deles em um escopo reduzido.

Se uma tarefa demorar mais do que você pensava, nenhuma metodologia de desenvolvimento o salvará. Mas uma abordagem ágil como o Scrum oferece aos gerentes mais oportunidades para controlar o que acontece nessa situação. Se eles não fazem uso dessas oportunidades, é claramente culpa deles, não da equipe, nem do Scrum, nem do cliente porque "ele não aceita agilidade".

Uma das declarações de valor do " Manifesto para o desenvolvimento ágil de software " é:

Colaboração do cliente sobre negociação de contrato

O fato de a Scrum-Addicts LLC negociar um contrato em vez de estabelecer uma colaboração com um cliente me faz questionar sua agilidade.

Uma coisa é clara: a agilidade precisa ser aceita por TODOS. Agilidade não é apenas para desenvolvedores. Gerentes e clientes também precisam aceitar os valores do Agile Manifesto. Se os clientes não aceitam agilidade e ainda exigem contratos rígidos e colaboração mínima, então não use o Agile ou encontre melhores clientes.

É culpa do cliente que eles estejam trancados em seus contratos com desenvolvimento orientado por prazos.

Quem é o culpado?

Gerentes, departamento jurídico, contadores - faça a sua escolha ...

Sei que o exemplo é um tanto artificial, mas o fato de que a empresa poderia ir embora sem pagar um centavo se não estivesse 100% satisfeito deveria ter despertado imediatamente, assim como misturar cascata e pensamento ágil.

Os clientes querem comer e comer o bolo - ficam felizes em aceitar cachoeiras, mini cascatas, ágeis e la-la-land, desde que obtenham o produto X por US $ Y pela data Z.

O desenvolvimento ágil exige absolutamente que a equipe de desenvolvimento e o cliente estejam na mesma página do ponto de vista da metodologia. As diferenças de pensamento na cultura acabam surgindo na lavagem é uma ilusão.

Projetos de TI lidam com incógnitas ; algumas dessas incógnitas são até desconhecidas . O que isso significa?

Tomemos, por exemplo, uma ponte de brinquedo para sua ferrovia modelo. Existem todos os parâmetros conhecidos por você:

• Você sabe o quão grande é o vale

• Você conhece o material das montanhas, sua altura, estabilidade etc.

• Você sabe quanto material você precisa

• Você sabe dos "projetos" anteriores quanto tempo você levou para criar coisas semelhantes

Existem muitas variáveis ​​envolvidas que influenciam o seu cálculo de investimento de tempo livre e dinheiro. Mas você poderia dizer, sem pensar, se está terminado no próximo fim de semana.

Dê um exemplo além:

• Digamos que você não construa a ponte para seu próprio modelo de ferrovia, mas sim para um completo estranho: seu trabalho é construir uma ponte ferroviária entre duas montanhas

• Digamos que você tenha quase nenhuma informação antes do cenário do modelo

• As informações sobre a paisagem são duas montanhas, que não parecem muito grandes

• A consistência da montanha é entre rocha e geléia

• O custo total tem no máximo 10 $

• O local de trabalho está completamente escuro e não há chance de luz: você só tem uma caixa de 8 fósforos

• O prazo é de 3 horas

Essa seria a analogia a um projeto de TI. Você tem experiência na construção de pontes e é fácil caminhar em terrenos conhecidos. O que dificulta é a escuridão . Há muitas coisas que você dificilmente pode prever: as medidas das montanhas só são conhecidas depois de cutucar algum tempo no escuro. Assim é a consistência das montanhas. Com isso, você pode fazer estimativas de quanto tempo você levará e quanto custará. Aqui, as incógnitas são coisas que você não conhece no início do projeto, como o terreno de concreto etc. Mas há coisas que você não pode prever, mesmo com a maior experiência e as estimativas mais conservadoras. Essas coisas são as incógnitas desconhecidas que carregam um pouco de caos.

Toda empresa de TI deve saber disso. Eles precisam lidar com o risco do projeto.

1) Existem várias maneiras de minimizar o risco (financeiro): o negócio pode incluir o cliente paga por cada incremento de trabalho. Portanto, após a entrega do incremento 1, uma taxa parcial deve ser paga. Desde que a Scrum-Addicts LLC atenda, há um risco financeiro mínimo. Quanto mais metas de sprint são planejadas, menor o risco total de cada sprint. Isso significa que, se a Money-Bags Corporation receber 80% do contrato, deverá pelo menos pagar 80% do valor do contrato. Se eles se recusaram a pagar após um sprint com falha, o risco não é tão alto quanto o recusa de pagar 100%.

2) Scrum-Addicts LLC tem um problema com seus desenvolvedores

Os gerentes do Scrum-Addicts consultam sua equipe de scrum, e a equipe diz que serão necessários três sprints de uma semana para concluir todos os recursos que o gerente do Scrum-Addicts adiciona 1 semana para ser seguro, promete enviar o software em 1 mês e assina um contrato com sacos de dinheiro

Isso sugere que: a) os desenvolvedores não têm experiência com o scrum ou b) estão fazendo o scrum errado. Quanto mais as equipes trabalham com o scrum, melhores são suas estimativas. Se as equipes fazem estimativas e o gerente adiciona um "buffer" como "segurança", o gerente parece conhecer melhor que a equipe, o que é um mau sinal . Se você tem uma equipe experiente, não há necessidade de um "gerente de buffer", a equipe incluiu isso já na estimativa. A idéia é que, quanto mais sprints a equipe trabalha, mais ela conhece seus pontos fortes e fracos e possui algumas métricas para fazer estimativas realistas. É claro que existem - como já mencionado - as incógnitas desconhecidasque tendem a dificultar as estimativas; ou pelo menos impreciso. Mas, a longo prazo, as estimativas devem melhorar cada vez mais.

Quem é o culpado?

1) Gestão

Como dito acima: há claramente uma falha no gerenciamento de riscos. Se a empresa está à beira da falência, ela merece. Se você trabalha em uma empresa assim: saia!

2) A equipe

Mesmo que a gerência seja totalmente estúpida, a equipe deveria ter se manifestado contra esse projeto. Um bom gerente deve conhecer os riscos; mas um bom desenvolvedor deve apontar riscos. E acima de tudo: a equipe deve relatar com antecedência se algo falhar.

O que é para ser feito?

Agora: leve bolsas de dinheiro para o tribunal

Para o futuro: não faça esses contratos

O Scrum não é o culpado pela falha no gerenciamento. O Scrum foi desenvolvido com base na experiência de muitos projetos de TI com falha. Não pode impedir falhas, nem pode curar a incompetência de equipes ou gerenciamento. A ideia básica é:

• estruturar formas de comunicação (quem fala com quem e quando)

• para incentivar a falha nos relatórios do desenvolvedor desde o início

• dividir problemas em tarefas e subtarefas

• estruturar tempo e capacidades (quem trabalha quando e o quê)

• distribuir as tarefas pelos intervalos de tempo

• torne o imprevisível um pouco mais previsível (planejando pôquer)

ou no geral: para minimizar riscos.

Scrum é uma ferramenta como um martelo. Se é uma boa ferramenta, depende do seu conhecimento de como usá-la. Mas às vezes uma chave de fenda se encaixa melhor. Você decide.

Primeiro, "Quem é o culpado?" é a pergunta errada a ser feita. Atribuir culpa é divertido e tudo mais, e provavelmente fará com que todos, exceto a (s) pessoa (s) culpada (s), se sintam aliviados (em um sentido "ei, não é minha culpa, o chefe disse isso!"), Mas não é um uso produtivo do seu tempo , e pode realmente ser contraproducente e causar uma queda no moral dos funcionários.

Uma maneira melhor de analisar é "O que causou o atraso?". Foi falta de experiência na tecnologia? Bugs críticos que não foram detectados no teste / controle de qualidade? Falta de teste / controle de qualidade? Muito otimista na estimativa? Sem levar em consideração as estimativas não tão otimistas da equipe? Alguém foi atropelado por um ônibus? Qualquer que seja a causa, a próxima pergunta é "Como garantir que isso não aconteça novamente?". Em alguns casos (provavelmente raros), a resposta para isso pode ser "livrar-se de algo assim", mas se você começar de "Preciso punir quem é responsável", é improvável que você veja a maioria dos casos onde não é a solução certa.

Dentro do projeto, você já está afundado. O prazo chegou e se foi, você avisou o cliente assim que ficou claro que ele escaparia (porque você fez isso, certo? Se não, isso faz parte do problema), e agora ele precisa ser manuseado da maneira que precisa. no contrato (na verdade está escrito no contrato, certo?). De um modo geral, isso deve envolver a negociação com o cliente como você vai entregar o que está faltando. Muitas pessoas gostam de pensar em um contrato como algo que não pode ser mudado, mas enfrentam: a) desistir do contrato e não ter o que você comprou; b) processar a empresa por quebra de contrato e gastar muito dinheiro em juízo, ec) negociando como obter seu produto com o mínimo de problemas possível, a maioria das empresas escolhe c.

Olhando para o futuro, antes de citar um preço / prazo para um cliente, você deve analisar os riscos envolvidos em um prazo escorregadio ou exceder os custos (quais são as possíveis causas para uma coisa dessas? Quais causas você pode atenuar de alguma forma e quais você não pode e apenas planejar) e usar essas informações para ajudar a decidir o que você promete. Se for 100% ou nada, obviamente você citará preços mais altos e prazos mais longos, porque o risco é maior.

Você notará que não falei sobre o Agile em toda essa resposta. Isso porque (vou esquecer o envolvimento do cliente no Scrum por um segundo, embora seja muito, muito importante) neste momento, isso realmente não importa. Você enfrentará esse problema no Agile, no Waterfall ou em qualquer processo de desenvolvimento usado. Sim, o Agile deve ajudá-lo a gerenciar melhor os riscos, permitindo que você veja se eles se tornaram problemas reais mais cedo e envolvendo o cliente no próprio processo para que eles sejam sempre informados, mas não é uma panacéia.

Em primeiro lugar, este é um problema com qualquer metodologia de desenvolvimento. Pelo menos com um sistema de desenvolvimento iterativo, você tem algo para mostrar ao cliente no final do prazo, o que pode ser suficiente para obter uma extensão para concluir o produto (mesmo que o cliente não pague mais!).

Há casos em que um prazo é um prazo; imagine que você esteja escrevendo um jogo e ele absolutamente deve ser lançado a tempo das férias de Natal. Entender isso errou muitas empresas!

Para métodos ágeis que precisam concluir uma certa quantidade de recursos em uma determinada data, o scrum provavelmente não é o melhor método a ser usado (como eu sempre achei que o scrum torna o dev mais lento e não permite agilidade suficiente para alterar o processo quando necessário.

O que você precisa, independentemente da metodologia, é configurar uma lista de pendências de recursos necessários para dar visibilidade ao progresso. O progresso por sprint não é bom o suficiente, você não saberá se está atingindo o objetivo final. Portanto, uma metodologia no estilo kanban seria melhor: defina todos os recursos à esquerda e trabalhe-os no sistema para mostrar o progresso até a conclusão.

Isso concentra a mente das pessoas no que ainda precisa ser feito de uma forma que o Scrum não lide, e permite que outras pessoas, exceto a equipe de desenvolvimento, vejam o que resta e se você provavelmente atingirá o objetivo (e, assim, gerencie as expectativas do cliente mais cedo). ou organize esses bônus de horas extras antes que eles sejam necessários).

O Scrum é um sistema que trabalha para sempre, definindo e refinando continuamente algo. Simplesmente não é adequado para esse tipo de desenvolvimento. Outros podem gerenciar esse sistema e ainda manter o conceito de desenvolvimento iterativo; Kanban é um desses, Crystal, outro. Mas o essencial é entender que, se você segue o Scrum religiosamente, não está sendo ágil. Qualquer sistema Agile verdadeiro deve ser capaz de se transformar para lidar com esses problemas específicos, por isso foi chamado de ágil em primeiro lugar, é sobre fazer o que precisa ser feito e, se um prazo fixo fizer parte disso, você deve considere isso da maneira que você trabalha.

O paradigma de desenvolvimento está fora de sincronia com o paradigma do contrato. Idealmente, a maneira como os contratos são escritos mudaria, mas é improvável que isso realmente aconteça. No entanto, mesmo se você desistisse do scrum, ainda teria surpresas e prazos perdidos (apenas provavelmente seria muito mais tarde porque você fez todo o design inicial e tudo estava errado !!).

Com ou sem uma alteração na forma como os contratos são escritos, você envia o que está trabalhando . Em seguida, cumpra o contrato consumindo um ciclo de tempo de desenvolvimento para concluir os recursos que você não concluiu.

É bom que você não cumpriu tudo o que prometeu no dia em que prometeu? Não, mas seu cliente ficará muito mais feliz se você puder entregar algo que funcione dentro do prazo e, em seguida, entregar o restante rapidamente depois do que se você estiver atrasado e não tiver nada para oferecer.

Muitos livros e artigos do Scrum dizem que um sprint com falha (quando a equipe falha em concluir alguns recursos do Sprint Backlog) não é algo tão ruim, acontece de tempos em tempos, e pode ser realmente útil se a equipe aprender com seus erros e melhora algo nos seguintes sprints. E a equipe não deve ser punida por não concluir o trabalho com o qual se comprometeu.

A maneira como você "castiga" esse tipo de comportamento é limitando a quantidade de trabalho que os que não terminaram podem realizar no próximo sprint. As chances de trabalhar em coisas legais estão desaparecendo. A recompensa por fazer um bom trabalho é mais trabalho.

Isso parece ótimo do ponto de vista do desenvolvedor, no entanto, digamos que temos uma empresa de software "Scrum-Addicts LLC" desenvolvendo algo para clientes sérios ("Money-Bags Corporation"):

Os gerentes do Scrum-Addicts sugerem criar um software para o Money-Bags Eles concordam com uma lista de recursos, e o Money-Bags pede uma data de envio Os gerentes do Scrum-Addicts consultam sua equipe de scrum, e a equipe diz que levará três semanas sprints longos para completar todos os recursos O gerente do Scrum-Addicts adiciona 1 semana para ser seguro, promete enviar o software em 1 mês e assina um contrato com a Money-Bags Após 4 sprints (prazo de entrega), a equipe Scrum pode fornecer apenas 80% de recursos (devido à inexperiência com o novo sistema, a necessidade de corrigir bugs críticos em recursos anteriores no ambiente de produção, etc ...) Como sugere o Scrum, neste momento, o produto é potencialmente entregável, mas o Money-Bags precisa de 100% de recursos, conforme mencionado no contrato. Então eles quebram o contrato e não pagam nada.

Os Scrum-Addicts estão à beira da falência porque não receberam dinheiro da Money-Bags, e os investidores ficaram decepcionados com os resultados e não estão mais dispostos a ajudar a empresa.

Se na segunda-feira eu apostar US $ 100 que chove na quinta-feira e não chove até sexta-feira, você estaria certo em levar meu dinheiro. Se, em vez de uma chance de apostar, o que você deseja é uma previsão do tempo, precisamos de um contrato que permita uma previsão atualizada na terça-feira.

Obviamente, nenhuma empresa de software quer estar no lugar dos Scrum-Addicts. O que não entendo sobre o Agile e o Scrum é como eles sugerem que as equipes devem lidar com o planejamento e os prazos para evitar a situação descrita acima.

Pense em por que MB quer pegar a bola e ir para casa. MB não exigiu que o trabalho fosse realizado em um mês desde o início. A SA prometeu 100% dos recursos críticos em um mês e não entregou. SA definiu o prazo não MB. A SA adicionou arbitrariamente uma semana ao prazo. Então, por que esse prazo é final?

Ocasionalmente, quando competem pelo software de trabalho, as empresas cedem à tentação de se exibir e prometer a lua. Profissionais estabelecem cuidadosamente se uma lua é necessária. Qual é a necessidade mais crítica do MoneyBags? 100% dos recursos ou um produto em funcionamento dentro de um mês? Eles sabem o que é realmente crítico? Existe algum evento próximo estabelecendo um prazo final?

Se eu fosse Scrum-Addicts negociando esse contrato, gostaria de saber muito mais sobre as necessidades comerciais da Money-Bags e estruturar o contrato para conceder tanta flexibilidade quanto a Money-Bags estiver confortável. Eu ensinaria a eles como o processo ágil funciona para que eles saibam o que esperar de nós.

Dessa forma, em vez de esperar que tudo funcione repentinamente perfeitamente em um mês, eles esperariam avaliar o primeiro produto em 1 a 2 semanas.

Então, para resumir, tenho 2 perguntas:

Quem é o culpado? Gerentes, porque é o seu trabalho para fazer o planejamento adequado
A equipe, porque o compromisso de fazer mais trabalho do que eles poderiam
Alguém

Qualquer um poderia ter parado com essa farsa antes de chegarmos um mês adiante.

Eu poderia até culpar a Money-Bags Corp por contratar uma equipe que obviamente representava fraudulentamente um processo em cascata como sendo ágil. O próprio contrato deixa claro que isso não é ágil. Planejar a execução em um mês não a torna ágil.

Se você insistir que é ágil, é ágil com apenas um sprint que dura um mês. O que, sim, eu não recomendaria, porque isso é novamente a mesma coisa que a cascata.

O que é para ser feito?

E quanto ágil? Entregar algo a cada corrida? Receber feedback antes do prazo? Semana longa sprints? Que tal renegociar o contrato draconiano no exato momento em que você suspeita que o prazo está em perigo, em vez de se esconder e orar? No mínimo, você pode parar de perder tempo em um projeto condenado e encontrar um cliente mais razoável.

Os gerentes devem mudar o prazo duas vezes (ou 3x) depois da estimativa da equipe original.

Os multiplicadores de prazo são tão úteis quanto ajustar o relógio com 15 minutos de antecedência, para que você nunca se atrase. Você só pode se enganar tanto tempo antes de perceber o que está fazendo.

As primeiras estimativas estão erradas. Tente capturar o quão errado. 5 semanas, mais ou menos algumas semanas, é uma expressão simples que permite expressar o quão incerta é a data de conclusão. Em vez de tentar adivinhar com precisão, você adivinha o quão selvagem é o seu palpite. Faça algum trabalho real e obtenha alguns dados reais. Depois, você pode começar a fazer estimativas com um intervalo mais restrito. Uma a duas semanas é bastante tempo para fazer isso.

Os membros da equipe devem ser incentivados a fazer todo o trabalho com o qual se comprometeram, não importando o quê (emitindo penalidades por sprints com falha)

Os membros da equipe devem ser incentivados. Falha, confirmada ou não. Em vez de construir qualquer consequência artificial, como punições ou até bônus (cenoura e pau), estudos mostraram que as pessoas que fazem trabalhos criativos, como a programação, respondem melhor se tiverem três coisas: Autonomia, Domínio e Propósito.

Daniel Pink tem uma palestra do TED sobre isso. A palestra é sobre motivação não ágil, mas eu vi facilmente como mapear esses pontos para ágil:

Autonomia - quero dirigir minha própria vida - deixe-me escolher o trabalho da lista de pendências.
Maestria - Quero melhorar algo que importa - Feedback do cliente.
Objetivo - quero fazer parte de algo maior que eu - uma equipe colaborativa.

A equipe deve abandonar o Scrum porque não se encaixa na política de prazos da empresa. O Scrum pode atingir um prazo com mais precisão do que a cascata. Dado um prazo, o scrum pode cumpri-lo. Ele pode atender a apenas 1 dos 47 recursos, dependendo do tempo, recurso e habilidade, mas pode atender.

Um projeto ágil pode ser elaborado de maneira tão extrema que, toda noite, quando a equipe volta para casa, está pronta para o envio. Isso parece bobagem, a menos que você pense no envio como pedindo ao cliente para testar e fornecer feedback. Quanto mais cedo isso acontecer, mais cedo você poderá fazer ajustes. Isso atinge todos os prazos possíveis. Apenas nem todos os recursos. Mas ele orienta você para os recursos que importam.

Todos devemos abandonar o desenvolvimento de software e ingressar em um mosteiro

Certo, como me trancar em um quarto longe da vida real vai me fazer escrever um código MENOS.

Editei esta resposta no tamanho certo. Se você estiver curioso, leia o histórico de edições.

Todo mundo tem que ser ágil. Qualquer que seja sua decisão, pareça quem faz o quê, como, quando, onde e por que todas as partes. Clientes, gerenciamento e desenvolvedores ágeis.

Você não pode dar uma data de entrega muito longe no futuro. Você dá uma estimativa.

Alguém precisava gerenciar as expectativas do cliente. O motivo pelo qual você não se preocupa muito em ter alguns sprints para trás é porque você se ajusta para impedir que todo o projeto fique para trás. Se você concluir que, após um ou dois sprints, não concluirá a "data de entrega", é quando você avisa o cliente.

Agora o que você quer fazer? Livre-se dos recursos desnecessários ou mova a data. Se você pudesse entregar a tempo, você faria. Não hesite em trazer más notícias.

Quem sabe, em alguns projetos, você poderá enviar mais cedo.

Você não pode ser ágil se o cliente não quiser.

Objetivo

Acredito que as duas "métricas" a seguir devem servir de base para qualquer decisão comercial:

• é o trabalho rentável (para o cliente)
• estamos trabalhando o mais eficiente possível

Estes são bastante universais. É claro que fica mais complicado muito rápido, por exemplo, o trabalho lucrativo é sobre o produto fazendo a coisa certa, o usuário sendo capaz de usá-lo, o produto sendo comercializado corretamente etc. - para muitos desses " viciados em Scrum " LLC "não está assumindo responsabilidade.

Questão

O contrato não está focado nas metas descritas acima. Existe uma cláusula "tudo ou nada" - faça tudo e seja pago, ou faça nada e não seja pago. No entanto, isso não está diretamente relacionado ao valor que está sendo criado. Outra desvantagem é a seguinte: agora precisamos gastar tempo e dinheiro para garantir e verificar se o contrato está sendo seguido. Por que diabos nós queremos gastar esse dinheiro? Como garantir que um contrato seja cumprido ajuda quando os requisitos mudam nesse meio tempo e descobrimos que o software solicitado não está gerando valor? Há apenas mais dinheiro indo pelo ralo! Agora, é claro, há uma razão para esse comportamento:

• Culturalmente, estamos acostumados a comprar coisas assim. Esperamos comprar software como faríamos para um carro: escolha uma configuração, receba um preço e prazo, e fique muito infeliz se esses dois não forem cumpridos.
• queremos descarregar riscos e responsabilidade
• queremos estabilidade, isso ajuda no planejamento e nos faz sentir melhor (e também nosso cliente, que é um aspecto importante!)

No final do dia, teremos que escolher um compromisso que nos permita satisfazer nossos objetivos da melhor maneira possível.

É assim que deve funcionar

• tenha um contrato de serviços e trabalho em vez de um produto
  • precisa ser rescindido em prazo relativamente curto
• trabalhem em conjunto para garantir a eficiência ideal
• envolve todas as partes necessárias, tanto da " Scrum-Addits LLC " quanto da " Money-Bags Corporation " - um "ponto de contato único" que encapsula todas as informações que não funcionam aqui.

Bem, eu basicamente disse "seja ágil". Agora, aqui está o porquê:

• processo e contrato são otimizados para gastar tanto dinheiro na meta possível
• você precisará confiar no contratado para fazer o trabalho dele e não precisará investir muito dinheiro para verificar se ele está preparado para o trabalho.
• a capacidade de processar seu contratado se suas expectativas / contrato não forem atendidas geralmente não ajuda, porque isso custará mais do que apenas abandoná-lo. Algumas das principais preocupações aqui são o tempo de colocação no mercado. Você provavelmente perderá muito mais dinheiro / negócios indo a tribunal do que receberá.
  • no final do dia, você terá que assumir alguns riscos.