Refatoração em desenvolvimento ágil
Em um projeto de desenvolvimento de aplicativo, o escopo completo do projeto não foi considerado no design do aplicativo. Portanto, a refatoração frequente de códigos para acomodar mudanças está impactando negativamente o cronograma de entrega do projeto, o que se tornou necessário durante um sprint. Qual a melhor forma de controlar isso para minimizar o risco de ultrapassar a data acordada de entrega do projeto, uma vez que as partes interessadas não estão dispostas a se comprometer?
Respostas
TL; DR
Parte de qualquer estrutura de gerenciamento de projetos, mas especialmente estruturas ágeis como Scrum, é a necessidade de gerenciar continuamente as expectativas das partes interessadas. As pessoas querem o que querem quando querem, mas uma grande parte do gerenciamento de projetos é explicar às pessoas o que elas podem realmente ter dentro das várias restrições que impactam o projeto. À medida que o projeto evolui, também deve evoluir a compreensão do que é atualmente viável dentro das restrições então atuais, especialmente quando o que é viável diverge do que foi originalmente planejado.
O retrabalho é esperado
A refatoração altera a implementação sem alterar o comportamento externo. Com toda a probabilidade, você não está realmente refatorando; você está pagando dívidas técnicas ou executando retrabalho e integração, que não são intrinsecamente a mesma coisa.
Frameworks como Scrum tratam vários tipos de trabalho (incluindo refatoração e retrabalho) como uma compensação aceitável para controle empírico e design. Isso é tratado no processo de estimativa e (corretamente) aparece como um obstáculo à velocidade à medida que aumenta o débito tecnológico, a complexidade ou o ritmo de mudança. Isso é esperado e desejável em uma estrutura iterativa, porque cada loop inspecionar e adaptar fornece uma oportunidade para alterar o escopo, priorização ou abordagem.
O retrabalho é o custo do controle empírico. Você realmente não pode evitá-lo em projetos complexos, como o desenvolvimento de software. Scrum apenas torna o retrabalho visível para a equipe e as partes interessadas como o custo de fazer as mudanças necessárias ou desejáveis.
Consertado - tudo não é possível
O "triângulo de ferro" postula que você pode ajustar um projeto controlando por orçamento, escopo ou cronograma, com qualidade uma quarta dimensão implícita impactada pelos outros três controles deslizantes. O gráfico a seguir mostra isso.
Frameworks ágeis como Scrum geralmente tratam o escopo, e especialmente o escopo do projeto , como o controle deslizante principal perguntando:
Quanto escopo podemos caber na caixa de tempo de um único Sprint ou caber em nosso plano de lançamento ágil ?
Atualmente, seu projeto está tentando corrigir o escopo e o cronograma. Isso deixa apenas o orçamento como seu controle deslizante disponível. Se você tentar bloquear isso também, seu projeto irá falhar ou a qualidade será prejudicada, ou ambos. Você simplesmente não pode fazer preço fixo, escopo fixo e cronograma fixo em qualquer estrutura de projeto, mantendo a qualidade; Scrum simplesmente torna isso mais óbvio e torna as compensações mais visíveis.
O objetivo do Scrum não é fazer desaparecer o triângulo de ferro magicamente. Em vez disso, força o projeto (bem como as partes interessadas e patrocinadores) a chegar a um acordo com as compensações inerentes. O Scrum permite que os stakeholders determinem se algo é "bom o suficiente" para enviar no final de cada Sprint, e o Product Owner tem a oportunidade de ajustar o escopo e a priorização durante o Refinamento do Backlog e o Planejamento do Sprint. As partes interessadas precisam aproveitar esses eventos como uma forma de garantir que eles obtenham o maior valor possível dentro do plano de liberação; nunca é uma garantia de devolução do dinheiro de que o projeto estará 100% completo ou adequado ao propósito ao final de uma série fixa de Sprints.
Diminuir custos afundados
Outro aspecto do desenvolvimento ágil é a oportunidade de "falhar cedo". Quando é provável que um projeto falhe por qualquer motivo, frameworks ágeis como Scrum dão ao Dono do Produto a oportunidade de economizar dinheiro cancelando um Sprint e planejando um novo com base nas expectativas alteradas, ou permitindo que os stakeholders cancelem o restante do projeto se não servirá aos seus propósitos. Este último não tornará o projeto bem-sucedido, mas reduzirá os custos irrecuperáveis associados ao projeto.
Nada que ninguém faça pode garantir o sucesso de um projeto. O melhor que você pode fazer é controlá-lo e eliminar um projeto condenado o mais cedo possível, quando o sucesso não for mais uma opção.
O que você pode fazer agora
Primeiro, reconheça que você está no caminho para uma marcha da morte. Se você não enfrentar essa verdade, nada mais que você faça terá importância.
Em seguida, descubra se o problema é design, dívida de tecnologia, expectativas irracionais ou outra coisa. Não importa qual é a causa ou causas básicas; você só precisa torná-los visíveis para que a equipe e as partes interessadas possam resolvê-los de forma colaborativa .
Finalmente, comunique o status atual claramente. Se você está no ritmo de um lançamento completo alguns ciclos após a data de entrega projetada originalmente, discuta se o projeto pode ajustar o vértice "tempo". Se você não pode ou não quer ajustar o cronograma, ainda pode cumprir o prazo fixo aumentando os custos ou reduzindo o escopo. As partes interessadas negociariam a entrega no prazo para cortar um pouco de funcionalidade demorada? Você não saberá a menos que pergunte.
Se o projeto não puder ou não quiser fazer nenhuma das coisas acima, prepare-se para o fracasso. Reveja seu currículo e espero que tenha aprendido lições valiosas que você possa usar em seu próximo projeto ou próximo trabalho. Acima de tudo, espero que você tenha aprendido a se comunicar desde o início e com frequência sobre suposições, desafios, requisitos de estrutura e compensações, e internalizou a importância de gerenciar continuamente as expectativas das partes interessadas.
Você está produzindo um incremento implantável de produto a cada sprint? Nesse caso, as datas de entrega acordadas já estão sendo cumpridas e essa é a melhor maneira de minimizar os riscos e dar ao cliente confiança no que você está fazendo. Os stakeholders (por meio do product owner) devem decidir o que desejam e quando, então o mais importante é que eles continuem a ver você entregando valor e que você receba feedback sobre melhorias, mudanças e correções necessárias para o produto. Obter o feedback deles é a chave aqui. Os clientes podem, compreensivelmente, ficar preocupados se o cronograma se estender sem um novo escopo funcional, mas assim que você começar a incluir as melhorias mais recentes que eles consideram prioritárias, eles estarão mais propensos a apreciar a necessidade de flexibilidade.