Devo usar o scrum para grandes projetos? [fechadas]

Trabalho como programador em um projeto desenvolvido para software genérico para postos de gasolina (a ser redistribuído para muitos clientes) há 18 meses. O projeto é grande. Hoje temos cerca de 150 mesas. Não usamos uma abordagem específica, ela não foi bem gerenciada.

Hoje, a tabela de pessoas tem cerca de 70 colunas, mas há 15 meses tinha cerca de 30 colunas. Esses novos campos surgiram para integrar outros módulos, como vendas, financeiro e contabilidade. Também muitos campos foram criados e excluídos.

Como resultado, tivemos muitas refatorações e retrabalhos. O projeto nunca fica pronto porque sempre há novos requisitos emergentes.

Aqui está minha dúvida: se tivéssemos usado uma abordagem usual de especificação, teríamos entrevistas, um documento de requisitos, diagramas de atividade, sequência e classe, para sabermos desde o início que a tabela "pessoa" precisaria de 70 campos, então tinha evitado muita refatoração.

O scrum poderia ajudar nesse projeto? Tenho a sensação de que, nesse caso, o scrum também acabaria sendo refatorado.

Sou apenas um programador, não um gerente de projetos. Estou me perguntando como deveria ter sido feito: com scrum ou com um design grande na frente.

Editar

Apenas para complementar o final desta história. Oito meses depois, fiz essa pergunta, depois de colocar o projeto em produção em alguns "clientes de teste", o projeto falhou oficialmente. O proprietário do produto decidiu abandonar o projeto. Ficou difícil corrigir problemas e muitos problemas de desempenho ocorreram.

Parece que você agitou o seu caminho em um processo de desenvolvimento descontrolado para criar um sistema de desenvolvimento sem fim. Isso também ocorre em sistemas ágeis.

O problema principal é a falta de requisitos e, embora sua solução possa parecer usar uma metodologia ágil para corrigir isso (como o ágil é projetado para mudar os requisitos), isso não resolveria o problema.

Mesmo métodos ágeis exigem um ponto de partida bastante firme. Eles respondem bem às mudanças de requisitos, mas são tão inúteis quanto qualquer outra metodologia se você começar sem requisitos. Você ainda precisa ter um plano para o qual está se dirigindo antes de começar. O Agile ajuda quando esse objetivo é desviado, mas não ajuda a definir esse objetivo.

Agora, é verdade que um projeto inicial fixo é muito rígido se você não souber exatamente o que está construindo.

Então, acho que você terá que passar da atual metodologia de 'caos' para algo mais organizado e terá que implementar uma quantidade razoável de design e planejamento. Você pode tentar fazer isso de uma só vez com uma metodologia pesada ou pode ser mais flexível com uma metodologia ágil. O que você não pode fazer é esperar qualquer metodologia para corrigir sua falta de planejamento inicial.

Aliás, o Kanban parece mais adequado às suas necessidades. O Scrum funciona melhor com pequenas equipes e projetos. O Kanban pode trabalhar com projetos maiores, mas também trabalha com uma abordagem de taxa de transferência de trabalho, para que as alterações no design sejam contínuas e não sejam divididas em sprints. Eu acho que você teria mais sucesso com isso.

18 meses, 150 mesas e ainda não está em produção? Soa como uma marcha da morte para mim. A única maneira de corrigir isso, se houver alguma chance de salvá-lo agora, é restringir drasticamente o escopo do seu projeto - pelo menos para o seu primeiro lançamento de produção. O que você precisa é de um planejamento adequado de liberação, objetivos pequenos e alcançáveis ​​e levar o sistema ao usuário final o mais rápido possível.

E quando você tiver seu primeiro lançamento em produção, com apenas um décimo dos requisitos implementados, precisará estendê-lo passo a passo pelo próximo bloco de requisitos, o que causará a "refatoração". Você também receberá feedback, o que significa correção de erros e requisitos alterados, o que causará refatoração também.

Agora, para sua pergunta - o Scrum ajudará? Talvez talvez não. O Scrum é uma ferramenta para apoiar o desenvolvimento iterativo e os requisitos variáveis, e focando as coisas importantes primeiro. Outros métodos "Agile" também fazem isso, e um processo não tão formalizado também pode lidar com isso. Mas enquanto você tenta trazer um monstro como esse em um "big bang" para a produção, não importa se você usa o desenvolvimento "ágil" ou "inicial", ambos falharão.

Portanto, antes de pensar no Scrum, primeiro repense seus objetivos e sua estratégia de lançamento e verifique se o Scrum é a ferramenta certa para isso, e não vice-versa.

Se você não pode gerenciar requisitos e não possui pessoas capazes de implementá-los adequadamente, o SCRUM não vai ajudá-lo (muito), e esse parece ser o verdadeiro problema que você está enfrentando.
O SCRUM pode ajudá-lo a lidar melhor com os requisitos em mudança do que com os sistemas mais estáticos de gerenciamento de projetos, mas não é o santo graal que fará magicamente tudo funcionar. De fato, a menos que seu pessoal esteja a bordo, disposto e capaz de trabalhar com a SCRUM, assim como o resto da organização, isso pode acabar piorando as coisas.

Se você tem uma tabela que cresceu tanto para caber em coisas para vincular com outros sistemas, eu postulo que o design do seu banco de dados é seriamente defeituoso, por exemplo. Nenhuma quantidade de SCRUM melhorará o design do seu banco de dados sem que você inclua pessoas que são boas no design do banco de dados em sua equipe e não tenham medo dessas alterações no design e nas mudanças que eles causarão no restante do sistema.

Observe que, quando escrevi esta resposta, não percebi que o sistema ainda não estava em produção.

Da maneira que você descreve seu produto, não acho que seu problema imediato seja o gerenciamento de requisitos, nem o processo de desenvolvimento. É o da arquitetura do seu sistema.

Você conseguiu criar um monólito - e bastante grande nisso. 150 mesas é muito para um sistema *. Em particular, você menciona que possui 40 novos campos nos últimos 15 meses apenas para integrar sistemas externos. Eu consideraria seriamente dividir seu sistema em vários serviços autônomos, provavelmente começando com serviços para integração a sistemas externos - mas depois identificando áreas de negócios separadas implementadas em seu monólito e, talvez, dividi-las em serviços separados.

Se você conseguir dividir esse monólito em bases de código manteníveis separadas, também poderá dividir seus desenvolvedores em equipes menores, com responsabilidades bem definidas em áreas específicas da sua empresa, e poderá ter várias equipes ágeis menores mantendo sua própria base de códigos, em vez de todos os hackers na mesma base de código.

Quanto ao motivo de você ter chegado a essa arquitetura, a causa raiz do seu problema, pode haver muitas respostas. Talvez esteja enraizado no seu processo de desenvolvimento, talvez todos os seus desenvolvedores só tenham experiência com software consistente transacional ou talvez seja uma consequência de como sua organização está estruturada (você é vítima da Lei de Conway ). Eu acho que há uma boa chance de que seja uma combinação dos dois últimos.

Eu não acho que implementar o scrum ou ser melhor no gerenciamento de requisitos ajudará a resolver seu problema imediato, nem a causa raiz. Ajustar a arquitetura para a complexidade do seu sistema e abordar a causa raiz do motivo pelo qual você construiu esse sistema.

* Alguns provavelmente argumentam que eles podem manter um sistema com 150 tabelas - ou eles mantiveram sistemas muito maiores, mas acredito que a maioria dos desenvolvedores considerará isso um grande número de tabelas para um sistema.