O Scrum faz sentido ao implementar um novo back-end do compilador?

Eu tenho um idioma existente que preciso portar para uma nova plataforma. Provavelmente tentarei isso alterando o back-end do compilador existente.

É uma quantidade significativa de trabalho reescrever o back-end. Não vejo como dividir isso em histórias sensatas sem violar os critérios do INVEST.

Não vejo como cada história pode ser negociável - todas elas são necessárias para um compilador funcional. As histórias são todas de igual prioridade e não importa em que ordem eu as entrego. Eu preciso fazer todos eles.

Estou implementando algumas partes do software que têm prioridade mais baixa do que outras e vejo que podemos entregar isso de forma incremental. No entanto, há um núcleo significativo que é obrigatório .

Eu pretendo tentar seguir o Scrum, mas estou apenas passando pelas propostas?

Existem práticas recomendadas para esse tipo de projeto?

Lembre-se de que a principal razão pela qual os processos Agile foram criados foi lidar com os requisitos de mudança. Se os requisitos são definidos (requisitos verdadeiramente fixos são raros, mas eu confio em você aqui!), Algumas das práticas recomendadas para lidar com requisitos variáveis ​​- por exemplo, histórias negociáveis ​​- se tornam um tanto irrelevantes. Dito isto, seguir um fluxo de trabalho do Scrum ainda tem muito valor potencial em termos de programação e fornecimento de resultados. Mesmo que suas entregas não constituam um produto totalmente utilizável por um tempo, ainda há algo a ser dito para demonstrar o progresso ao seu cliente (e à equipe!).

Considere que todas as histórias "obrigatórias" compreendem um único épico: "Consiga compilar na plataforma X". Nesse caso, toda a epopeia precisa ser concluída antes que qualquer valor seja entregue ao usuário, mas geralmente é o caso no início de grandes projetos. Comece com uma história para compilar o programa mais simples possível e, em seguida, crie mais histórias para oferecer suporte a mais e mais recursos de idioma.

Acima de tudo, não se preocupe demais em tentar forçar todas as situações a se encaixar em uma abordagem altamente generalizada. O Agile deve funcionar para você, e não o contrário!

Claro que Scrum é útil. É uma metodologia que faz duas coisas para você:

1. Permite que seu projeto se adapte às mudanças e
2. Permite acompanhar o progresso e ter uma ideia de quando será concluído

Portanto, há algum valor em usá-lo.

Acho que algumas de suas condições prévias não estão corretas e é aí que você está se perdendo.

Não vejo como cada história pode ser negociável - todas elas são necessárias para um compilador funcional

Isso não é verdade. Você pode suportar um subconjunto do idioma e ainda ter um compilador que funcione sob determinadas condições. Certamente menos valioso que um compilador completo, mas ainda valioso.

Além disso, você entende mal o que significa "Negociável": não significa necessariamente "Opcional" e não há exigência de que as histórias sejam opcionais no INVEST. Uma história é um objetivo valioso e a negociação é sobre como alcançá-lo. Certamente haverá mais do que maneira de implementar o back-end de cada recurso de idioma. É aí que você precisa de negociação.

As histórias são todas de igual prioridade e não importa em que ordem eu as entrego.

Isso não está correto, como você diz abaixo que algumas histórias não são "obrigatórias", então certamente algumas são menos valiosas. Mas mesmo na categoria "must have": alguns recursos de linguagem são muito mais fundamentais que outros, e de maneira mensurável.

Uma maneira de medir isso é "quantas linhas de código podemos compilar em uma base de código existente" ou "quantos testes passam" se você tiver um conjunto de testes predefinido.

Existem também outras opções. Se você estava compilando um C-como a linguagem, a rigor só precisa de um ife gotoloop para ter um (mal) linguagem funcional e você pode implementar while, fore repeatcomo macros. Supondo que seja fácil escrever um uso de um pré-compilador, você pode ter uma solução barata (ei, estamos negociando? :-)

Em relação à adaptabilidade, o suporte a um idioma é um conjunto de requisitos bastante estático, mas os idiomas também mudam e também o conhecimento de suas necessidades . Você precisa implementar tudo? Existem coisas que você não precisa especificamente para seus objetivos? Um dos inquilinos básicos do ágil é o conhecimento de ter conhecimento incompleto. Você pode aproveitá-lo?

Concluindo, para responder sua pergunta mais diretamente: você precisa de processos ágeis quando seus requisitos são imutáveis? Definitivamente não! Eles são utilizáveis? Provavelmente sim! Eles valem o seu tempo? Provavelmente não - mas seus requisitos são imutáveis? Nas minhas experiências anteriores, "requisitos imutáveis" => "proprietário preguiçoso do produto" - não é uma regra, mas vale a pena lembrar.

TL; DR

Todos os controles de gerenciamento de projetos adicionam sobrecarga. Não adicione despesas gerais desnecessárias.

Scrum é o martelo errado aqui (não seja um prego)

Scrum é uma estrutura de gerenciamento de projetos, e não um conjunto de práticas de desenvolvimento adequadas para um desenvolvedor individual. A menos que você esteja gerenciando projetos, o Scrum provavelmente é a escolha errada.

Além disso, quando você diz:

As histórias são todas de igual prioridade e não importa em que ordem eu as entrego. Eu preciso fazer todos eles.

você está sugerindo algumas coisas:

1. O projeto tem valor zero, a menos que todas as histórias estejam 100% concluídas.
2. As histórias não dependem uma da outra.

Se ambas as afirmações forem verdadeiras, não há realmente sentido em usar uma estrutura ou prática projetada para priorizar o trabalho por valor ou ordem de dependência.

Alternativas sugeridas

Qualquer projeto de desenvolvimento pode se beneficiar de algumas práticas ágeis. Em particular, no seu caso específico, eu recomendaria:

1. Garanta que todas as suas histórias tenham uma "definição de concluído" que inclua testes de unidade e aceitação.
2. Integrar e refatorar frequentemente; não deixe uma tarefa gigante de integração no final do projeto.

Além disso, mesmo que seu produto realmente tenha valor zero, a menos que todas as histórias sejam concluídas, eu gastaria algum tempo agrupando as histórias em temas que você pode tratar como marcos concluídos. Ser capaz de dizer "concluí o recurso foo" geralmente é mais útil do que dizer "já fiz 23/117 histórias aleatórias". YMMV.

Entendo suas preocupações, mas acredito que ainda há valor para você no uso do scrum.

É certo que as histórias de usuários são muito mais fixas do que em um aplicativo voltado para o consumidor. Portanto, esse aspecto do scrum fornecerá menos valor.

Onde eu acho que você obterá valor é dos lançamentos iterativos e frequentes . Ter um produto potencialmente liberável no final de cada sprint obriga a manter alta a qualidade do código e a dívida técnica baixa. Também é uma ótima maneira de encontrar defeitos com antecedência.

Eu acho que você também se beneficiaria de conhecer sua velocidade . Após várias corridas, você pode ver quantos pontos de esforço sua equipe está finalizando em cada corrida. Isso fornece uma métrica objetiva para ajudar a determinar a data de envio.

Acima de tudo, lembre-se de que o ágil é adjetivo . No final de cada corrida, você deveria realizar uma reunião retrospectiva e, em seguida, adaptar seu processo às suas necessidades. Se houver uma parte do processo scrum que não se aplica ao desenvolvimento do compilador, remova-o. Se houver algum outro elemento do processo que possa beneficiar você, inclua-o. A parte mais importante do ágil, na minha opinião, é conhecer o seu processo e melhorar constantemente para a sua situação específica.

(Observe que nunca fiz scrum em um projeto de compilador; siga meus conselhos com um pouco de sal.)

Sim, desde que você se lembre de que o Scrum não é um conjunto de regras estritas a serem seguidas. Você pode ajustá-lo ao seu projeto. Sprints, standups e scrums semanais ainda serão úteis para promover uma melhor comunicação entre os membros da equipe e para garantir que o projeto continue na direção pretendida.

Todas as histórias podem ter a mesma prioridade, mas é necessário levar em consideração a dificuldade relativa de implementá-las. Você não deseja manter os itens mais difíceis até o final do projeto. Você vai querer começar a trabalhar neles o mais rápido possível.