Lidando com sprints e prazos com falha

80

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. ???
Andre Borges
fonte
31
O ponto 3 em "A ser feito" pressupõe que a não utilização do Scrum teria mudado tudo ao ter apenas 80% dos recursos prontos em um mês. Isso é ridículo.
Doc Brown
7
@ DocBrown, não posso concordar que seja ridículo. Descartar algumas atividades do Scrum, como reuniões retrospectivas e de demonstração, pode acelerar o desenvolvimento. E, no caso de um contrato sólido, isso pode ajudar a alcançar o objetivo final: fornecer uma quantidade fixa de recursos no final do prazo.
Andre Borges
26
@AndreBorges Sua sugestão para abandonar retrospectivas e demonstrações é a mesma que sugerir na remoção de freios de um carro. Claro, os freios apenas atrasam você Mas é isso que permite que você vá muito rápido.
eufórico
13
o mesmo problema permanece em qualquer sistema - observe que você pode praticamente substituir o scrum por um equivalente em cascata e a empresa ainda falha
jk.
6
Talvez se os gerentes de Scrum-Addicts tivessem prestado mais atenção durante as irritantes reuniões "retrospectivas", eles teriam tido a chance de pisar no freio nas semanas 1 ou 2, em vez de assistir ao projeto se aproximar do penhasco e pisar no acelerador. .
Dorus

Respostas:

134

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".

Doc Brown
fonte
47
+1 para "Um contrato de tudo ou nada é algo que nem o fornecedor do software nem o cliente se beneficiarão" . É a chave da contratação ágil.
precisa
5
E certamente é o caso de 80% não ser bom para alguns tipos de projeto (em última análise, é possível , embora improvável, que o ágil seja muito limitado para prever esses projetos). Por exemplo, não adianta ter 80% dos recursos do seu satélite quando você o inicia, e é por isso que você não mexe com a contingência nesses projetos. Se você não entregar, a missão do seu cliente falhará (ou será adiada), não há nada que você possa fazer no contrato para mudar isso.
Steve Jessop
6
@SteveJessop: Tenho certeza de que, mesmo quando você constrói algo tão complexo como o software para um satélite, existem prioridades diferentes para recursos diferentes e haverá muitos recursos em que o escopo pode variar até certo ponto. O prazo pode ser fixado para essa situação, é claro, porque quando você não colocar o foguete no espaço até dezembro do próximo ano, poderá não ter segunda chance.
Doc Brown
6
Mas, para este exemplo específico ... é claro que ninguém teria enviado novos horizontes se não conseguissem terminar o disco rígido da câmera. Mas mesmo para projetos nessa escala, aposto que um não está entrando no espaço com todos os recursos que eles imaginavam.
Zaibis
6
talvez pagar por marco ou funcionalidade também possa ser uma opção.
Bram
68

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.

Eufórico
fonte
9
@RubberDuck Ainda não existe uma metodologia de gerenciamento de projetos de software que permita que os recursos sejam decididos antecipadamente, com prazo definido e não seja muito caro. Escopo, tempo, dinheiro; Escolhe dois.
eufórico
8
@RubberDuck: O projeto já não é ágil, porque os requisitos são definidos. E a estimativa é de apenas três semanas. Não há nada magicamente ruim na cascata que a torne sempre atrasada, ela simplesmente não pode lidar com requisitos e mudanças vagas. Sim, eu usaria "cascata" neste caso, ou mais precisamente "vamos decidir o que precisa ser feito e fazê-lo".
RemcoGerlich 25/02
3
@RemcoGerlich ironicamente, "vamos decidir o que precisa ser feito e fazê-lo" é notavelmente ágil si :-)
gbjbaanb
2
@RemcoGerlich ah, acho que você não entendeu meu ponto de vista: o ágil não é realmente sobre os métodos de desenvolvimento, mas a capacidade de continuar o trabalho, usando o que você quiser. Afinal, trata-se de progresso, não de procedimentos. (por exemplo, uma equipe que apenas faz Scrum não é ágil, uma equipe que apenas faz o estilo cascata, mas que o modifica para se adequar às circunstâncias) é
gbjbaanb
2
Eu concordo com Doc Brown aqui. Você pode absolutamente ter um "limite de tempo" sem dizer exatamente "para quê". É perfeitamente razoável dizer, por exemplo, "nosso prazo é <alguma data>. Nessa data, enviaremos o que fizemos". O escopo do que é enviado não precisa ser definido no momento em que o prazo é criado. O desenvolvimento ágil tem tudo a ver com gerenciamento de escopo e comunicação do progresso em incrementos de tempo determinado, que na verdade são todos os mini-prazos próprios.
Eric King
15

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.

Robbie Dee
fonte
12

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.

Thomas Junk
fonte
1
Há outro aspecto do Scrum que é de vital importância para entender por que esse projeto falhou: o scrum abraça o fracasso . Espera-se que o primeiro par de sprints de uma nova equipe ou projeto falhe. Através do processo scrum de retrospectivas, a equipe se aperfeiçoará e, a longo prazo, se tornará precisa em suas estimativas, mas apenas enquanto permanecer a mesma equipe trabalhando no mesmo projeto. Quando qualquer uma dessas alterações, você deve novamente esperar alguma falha, pois as variáveis ​​subjacentes estão mudando.
Cronax
9

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.

Iker
fonte
3
-1 O ponto do ágil é que muitos dos riscos simplesmente não podem ser previstos. Por exemplo, eles adicionaram um buffer de 1 semana para o caso de ocorrer algum problema. Você sempre pode triplicar o tempo necessário, mas perde a concorrência que não faz isso. O Agile deve adotar a mentalidade "Está pronto quando está pronto". O que é simplesmente incompatível com contratos e prazos, conforme descrito.
eufórico
3
@Euphoric Não posso concordar inteiramente. Sim, o ponto do Agile é que muitos riscos não podem ser previstos, e é para isso que serve o buffer, eu garanto. No entanto, isso não significa que todos os riscos são imprevisíveis, nem significa que você deve entrar em um projeto às cegas, sem considerar os riscos que pode prever.
Iker
2
@Iker Um não se opõe ao outro, mas o ponto de ser realmente ágil no processo de desenvolvimento é que a mentalidade "É feito quando é feito", tanto para o cliente quanto para a equipe. Claro, sempre há alguns riscos que você pode prever, mas nunca é possível prever com êxito todos os riscos possíveis e exatamente qual o impacto que eles terão no seu progresso. A menos que você possa ver o futuro de alguma forma. É por isso que o trabalho ágil exige contratação específica, na qual você concorda que "continuaremos trabalhando até que o dinheiro acabe, ou uma das partes não esteja mais disposta ou não possa ou todas as necessidades dos clientes sejam atendidas"
Cronax
ok, votei isso para a rejeição imediata da culpa como conceito. Concordo que a culpa é um componente improdutivo que distrai o sucesso. Vamos mudar a questão. Talvez pudéssemos dizer "como poderíamos ter lidado com isso"? "como podemos transformar isso em sucesso para nós?" "que mudanças de todas as partes poderiam ter resultado em um resultado positivo?" eu posso concordar em mudar a "culpa" para "responsável", mas como todo projeto com um fornecedor e um cliente é uma interação de equipe, a 'equipe' com escopo global não é responsável de qualquer maneira? a questão de quem é o culpado torna-se retórica.
21716 Joshua K
4

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.

gbjbaanb
fonte
6
"Jogo pronto para o Natal" pode ser um poster para o Scrum. Envie os 80% que você terminou, venda o restante como DLC. Essa não é a situação hipotética discutida aqui, onde o prazo fixou tempo e escopo, com uma penalidade de 100% para entrega parcial.
MSalters 25/02
2
@MSalters, você assume que o jogo funciona, que 80% podem não ter os recursos que podem ser adicionados mais tarde, mas quebrar a funcionalidade ou travar bugs. Ele não tem que ser um jogo, poderia ser qualquer software que precisa ser enviado para um prazo claro e imutável (como nem mesmo a Apple pode adiar Natal!)
gbjbaanb
6
Essa é a premissa básica do Scrum! Funcionalidade quebrada não conta. Se você é do fundo do Waterfall, verá que o Scrum prioriza a correção de erros em vez de adicionar novos recursos. "80% concluído" significa que há níveis ausentes, chefes ausentes etc.
MSalters 25/02/16
1
@gbjbaanb Por esse raciocínio, algo pode ser feito 99,9%, mas ainda não funciona, porque trava imediatamente após a inicialização.
user253751
@immibis, mas isso é verdade. Coisas como jogos não tendem a deixar os recursos de fora até o final, a maioria das partes de um jogo precisa ser implementada para que o conjunto funcione - enquanto você pode remover alguns recursos (e eu sei que os jogos fizeram isso) eles não adicionam recursos incrementalmente. Portanto, um chefe desaparecido seria um jogo quebrado. Apenas escolhi os jogos como exemplo, pois eles tendem (principalmente antes da entrega pela Internet) como exemplos de prazos rígidos.
Gbjbaanb
4

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.

Pato de borracha
fonte
3
Sim, às vezes o cliente fica mais feliz se a equipe fornecer pelo menos algumas partes dos recursos de trabalho, mas esse nem sempre é o caso. Estou falando de casos em que (1) o produto é inútil para os usuários finais, a menos que 100% dos recursos sejam implementados (por exemplo, exige certificação cara que precisa ser feita apenas quando tudo estiver concluído) ou (2) o cliente é uma empresa antiga com a abordagem "tudo ou nada": se o produto não estiver 100% pronto, consideramos que ele falhou, quebre o contrato e demitir todos os responsáveis.
Andre Borges
2
O cliente sempre ficará mais feliz em ver o progresso na maneira de trabalhar com o software. A certificação cara pode esperar até que o produto atenda à sua satisfação. Liberá-lo para o cliente não significa que eles precisam divulgá-lo ao público. No caso 2, não há realmente nenhuma opção a não ser que suas equipes jurídicas / de vendas escrevam contratos melhores. Honestamente, seus problemas seriam os mesmos, se não piores, com a cachoeira lá.
25416 RubberDuck
2
@AndreBorges Certamente o cliente ficará mais feliz em ver 80% dos recursos do que em ver 0% dos recursos? Pelo menos dessa maneira, o cliente sabe que o produto está praticamente pronto.
user253751
@immibis, se você diz isso, significa que ficou feliz o suficiente para evitar alguns clientes 'peculiares' em seu trabalho. Existem algumas grandes empresas desajeitadas relacionadas ao governo que impõem termos contratuais não tão razoáveis, mas se você investir todos os seus recursos em suas tarefas e conseguir obter sucesso, eles pagam um dinheiro sério que pode elevar muito sua pequena empresa. No entanto, se você falhar, poderá encontrar um novo emprego. É o risco que algumas pessoas estão dispostas a assumir.
Andre Borges
2
Exatamente! Devido à sua burocracia interna e falta de equipe de gerenciamento experiente, às vezes é mais fácil para uma grande empresa considerar um prazo com falha como um "experimento malsucedido" e abandonar o projeto por completo, do que se esforçar mais para tentar comunicar e renegociar o escopo. Triste, mas é verdade :(
Andre Borges
1

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.

candied_orange
fonte
Eu gostaria de simplesmente assumir que você significou Sprint não backlog - Eu quis dizer exacly o que eu escrevi na questão: o sprint backlog
Andre Borges
as pessoas que fazem trabalhos criativos, como a programação, respondem melhor se tiverem três coisas: Autonomia, Domínio e Propósito - esse pode ser um tópico enorme para especulação por si só, mas o fato é que, infelizmente, muito trabalho de programação está se tornando menos criativo e mais rotina (tarefas monótonas, pilha tecnológica fixa e conjuntos de fetais, contratos estritos). Portanto, em muitos casos, a cenoura e o pau funcionam bem.
Andre Borges
@AndreBorges Você está certo, eu estava pensando no backlog do produto. Recentemente, tenho trabalhado com uma ferramenta que chama a lista de pendências do sprint e a lista de pendências do produto. Você me pegou perdendo a luta para impedir que meu vocabulário se tornasse proprietário.
Candied_orange 29/02
A programação do @AndreBorges nunca será cheia de envelopes. É firmemente um problema de vela. O motivo é que qualquer problema repetitivo pode ser resolvido com o mesmo código que resolveu o primeiro problema. Apesar disso, a gerência pode adotar uma mentalidade em que acha que a criatividade é um problema a ser eliminado. Eu trabalhei e corri de várias dessas lojas. Eles não mantêm boas pessoas. Eles não produzem um bom software. Desenvolvedores são artesãos. Tentar transformá-los em trabalhadores da linha de montagem só prejudica sua causa. Meu trabalho não é virar ovos. É para garantir que os ovos sejam virados.
Candied_orange 29/02
0

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.

JeffO
fonte
0

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.
BatteryBackupUnit
fonte