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

15

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?

Dave Hillier
fonte
1
@ Sklivvz atualizado faz mais sentido?
precisa
1
Como alternativa ao scrum, dê uma olhada no kanban. Ambos são ágeis, mas o AFAIK kanban é melhor para o tipo de trabalho que você está realizando, enquanto o scrum é melhor para trabalhos que podem ser divididos em diferentes prioridades.
precisa saber é o seguinte
O @Izkata Kanban ainda espera uma fila de entrada priorizada, por valor ou por hora de chegada. A proposição de valor tudo ou nada é o bloqueador fundamental ao considerar qualquer tipo de modelo de desenvolvimento iterativo.
precisa saber é o seguinte
@CodeGnome Hm .. Admito não ter feito o kanban, mas entendi que é bom ter muitas coisas abrangentes, como descrito nesta pergunta: Se você trabalha para cada cartão em seu próprio ramo, mescla-o ao tronco quando estiver completo, essa é uma "iteração" / release. Eles apenas se sobrepunham, ao contrário dos sprints no scrum.
precisa saber é o seguinte
2
Os requisitos não serão alterados. Você simplesmente não pode mais acreditar nisso.
Jeffo

Respostas:

22

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!

vaughandroid
fonte
1
Os requisitos sempre mudam e pensam que não serão até que o código seja escrito e aprovado (supondo que os responsáveis ​​sigam as regras) esteja apenas sendo negado.
Jeffo
@ Jeffff Eu concordo: a mudança de requisitos é um recurso procurado do ágil, por exemplo, é por isso que temos demos.
precisa saber é o seguinte
1
@ Jeffff Se você quiser escolher, os requisitos nem sempre mudam, eles quase sempre mudam . Vou mudar minha redação independentemente.
vaughandroid
1
Acho esta resposta desagradável. "Comece com uma história para compilar o programa mais simples possível e, em seguida, crie mais histórias para dar suporte a mais e mais recursos de linguagem". Mas é provável que exija 6 meses de trabalho para construir uma estrutura antes que o menor programa possa ser construído! Esta não é uma resposta realista que descreve o uso de uma abordagem ágil para um sistema de back-end.
Dan Nissenbaum 8/12
10

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.

Sklivvz
fonte
3
+1 para " Isso não é verdade. Você pode oferecer suporte a 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. " Porque isso cria uma unidade testável e utilizável antes o fim do desenvolvimento.
Ross Patterson
2
E também "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 predefinido de testes". - Eu acho que é importante poder demonstrar progresso.
precisa
+1, apesar de um ponto que estou faltando aqui é que os requisitos para um compilador também podem ser cortados "horizontalmente" em vez de "suportar o recurso de idioma X". O compilador pode precisar otimizar as coisas (próprio requisito), pode gerar informações de depuração (próprio requisito), pode atender a alguns requisitos de desempenho e assim por diante.
Doc Brown
Os requisitos do @DocBrown certamente podem ser horizontais, mas as histórias precisam ser verticais.
Sklivvz
"Como usuário do compilador, quero entrar DavesCompiler -O9 program.ce a saída deve ser uma versão altamente otimizada do program.c (definição mais formal do que significa altamente otimizado a seguir)" - parece uma história razoável para mim.
Doc Brown
4

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.

CodeGnome
fonte
1
Não afirmei ser um desenvolvedor individual.
precisa
@DaveHillier "Eu tenho um idioma existente ... provavelmente vou tentar isso ... planejo tentar seguir o Scrum." Nada disso diz algo sobre equipes, outras pessoas ou a necessidade de gerenciamento formal de projetos. Mesmo se houver 347 de vocês trabalhando no projeto, a resposta ainda será válida se sua premissa for válida. Caso contrário, atualize sua pergunta e farei o possível para atualizar a resposta conforme apropriado.
precisa saber é o seguinte
1
Ninguém mais fez tal suposição. Eu concordo com parte do que você escreveu.
precisa saber é o seguinte
4
@DaveHillier Li sua pergunta da mesma maneira que o CodeGnome, de que você seria um desenvolvedor solo nesse projeto. O uso excessivo de em Ivez de Weprovavelmente é o motivo.
Izkata
Ferramenta errada, martelo não errado. Um martelo é um martelo, nem todos os problemas são pregos :-)
Sklivvz
2

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

epotter
fonte
0

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.

Mchl
fonte
Scrum is not a set of strict rules to follow- eu pensei que é exato o contrário. Não é como se tivesse apenas algumas regras, mas você precisa cumpri-las (por exemplo, Standups diários, Definição de Concluído, Pontos da História)?
Uooo 28/08
Você está defendendo o ScrumBut ?
precisa
@Uooo, apenas o primeiro dos três mencionados é Scrum, o restante são apenas boas práticas, mas não estritamente fundamentais.
precisa saber é o seguinte
@ Sklivvz É por isso que muitos gerentes de projeto pensam "estamos fazendo standups diários, então estamos fazendo scrum" ? Scrum é mais do que apenas standups diários.
Uooo
1
@ Sklivvz ok, agora entendi o que você quer dizer com isso :-) Eu pensei que você quis dizer apenas fazer standups já é scrum.
Uooo