Muitos rastreadores de problemas suportam algo chamado "marcos". Eu nunca encontrei um uso para eles. Parece que os marcos são úteis apenas quando você faz grandes envios agendados, mas não se você lançar novos recursos e correções de erros à medida que forem concluídos.

Quando / como você usaria marcos para organizar o desenvolvimento ágil?

Alguma equipe ágil os usa para se comunicar com o cliente quando ele espera ter uma nova versão do software (mesmo que essa versão esteja incompleta). Isso permite que o cliente planeje a migração para a nova versão, antes de ser lançada.

Por exemplo, para um software desenvolvido de forma ágil e lançado a cada 6 meses , os seguintes itens podem ser os marcos.

Alfa 1 - 19 de dezembro

O primeiro conjunto de recursos chegando, geralmente com erros. Isso é útil para testá-los e fornecer feedback

Alpha 2 - 23 de janeiro

Próximo conjunto de recursos, além de algumas correções para o feedback no Alpha

Beta 1 - 27 de fevereiro

Todo o recurso da versão atual está lá e ninguém será adicionado até o lançamento final. Novo desenvolvimento estará na próxima versão. Você ainda pode sugerir um pequeno ajuste ao já existente.

Beta final - 27 de março

O comportamento do recurso é completamente congelado, a menos que seja encontrada uma falha crítica. Somente bug será corrigido.

Release Candidate - 10 de abril

A versão final a ser lançada. Nenhum bug deve ser encontrado aqui. Se alguns forem encontrados, um novo candidato à liberação será criado.

Versão final - 17 de abril

A versão suportada é liberada ao público em geral, pois nenhum bug foi encontrado no candidato a lançamento

(Nota: eu não segui exatamente a semântica do ubuntu aqui)

Com esse plano de liberação em mãos, um cliente pode planejar com antecedência. Se um novo recurso é realmente esperado, ele pode testá-lo durante o estágio alfa para garantir que ele se encaixe no que é necessário. Os programadores podem começar a experimentar o novo recurso durante o estágio beta. O teste de regressão pode iniciar durante o estágio do candidato a liberação.

Saber quando o software será lançado e o que ele conterá é extremamente importante para muitos usuários. Usando o marco, você pode saber o que vai acontecer e quando . A mentalidade ágil ainda está lá, manifestada pelo fato de que, antes de uma certa data, o conjunto de recursos é variável . Isso é diferente do caminho em cascata , onde você planeja os recursos e a data de lançamento . E, claro, a próxima versão não está definida, novamente ao contrário do método cascata.

Portanto, para responder à sua pergunta: No ágil, o marco é usado para indicar quando decisões e ações importantes serão tomadas , mesmo que essas ações e decisões possam mudar.

Eu acho que o objetivo do marco é ter uma visão geral do programa / aplicativo candidato a lançamento / recurso (ou qualquer outra coisa que a equipe desenvolva).

Pode ser útil para desenvolvedores / trabalhadores:

Eu posso imaginar um sistema de rastreamento de problemas com muitas tarefas, correções, recursos etc. Ele tem um campo de marco. Acho que se sua equipe tem dois marcos e apenas um prefere seu cliente, que sua equipe comece a executar essas tarefas ou corrija esses bugs ou desenvolva esses recursos marcados com esse marco.

Pode ser útil para os gerentes:

Isso é uma coisa muito importante que a liberação será liberada para o ambiente de produção do cliente. Nesse caso, o marco é liberado para o ambiente de produção. Mas o marco pode ser marcar o pacote de recursos.

Pode ser útil para o cliente:

Pode ser que o cliente queira mostrar este programa, ou versão com correção de programas, ou novos recursos do programa para outra pessoa / organização. Portanto, o cliente precisa de uma versão estável do programa. Eu acho que quando o programa atingir esse marco, seria estável e liberável.

Se o cliente, gerentes e trabalhadores verificam bugs, tarefas e recursos no rastreador de problemas, acho que é melhor conhecer o marco deles.

Ao iniciar um projeto de desenvolvimento - independentemente da metodologia -, você deve sempre ter um plano aproximado, sobre os recursos "obrigatórios", os principais recursos, os recursos "realmente importantes" que deseja desenvolver e nos quais ordem. Idealmente, você também tem uma visão sobre o tempo de realização. Escrever esse plano em forma de marcos torna isso transparente para qualquer pessoa envolvida no projeto.

Em qualquer tipo de projeto real, esse plano deve ser adaptado à realidade de tempos em tempos. Talvez seja necessário reatribuir recursos para marcos diferentes, às vezes identifica-se coisas menos importantes do que se pensava anteriormente, às vezes é necessário adicionar alguns requisitos / recursos ausentes ao seu plano de desenvolvimento e às vezes pode ser necessário alterar a própria lista de marcos . IMHO, a principal diferença entre um projeto "cascata" e "ágil" é que, em um projeto ágil, você é honesto com o cliente sobre a necessidade de adaptação desde o primeiro dia. Nos projetos em cascata, você não possui mecanismos internos para alterar o planeje antes que o produto esteja "pronto" (e provavelmente com defeito). Em projetos ágeis,

Também há uma diferença na qual você analisa os detalhes sangrentos dos requisitos para qualquer marco. Os projetos em cascata tendem a analisar demais todos os recursos de cada marco antecipadamente; em projetos ágeis, você normalmente analisará apenas um recurso do próximo marco em profundidade.

Então, eu diria que especialmente em projetos ágeis, um plano de marcos ajuda as partes interessadas a entender que o desenvolvimento não é completamente arbitrário ou aleatório e que você ainda segue um plano geral.

Uma pergunta diferente é se você precisa do recurso "marcos" do seu rastreador de problemas. Um plano de marco geralmente é apenas um documento em seu formato de documento favorito, para que você possa mostrá-lo facilmente a qualquer parte interessada do seu projeto. Você precisa decidir por si mesmo se isso traz algum benefício para colocar os marcos no seu sistema de rastreamento de problemas ou se você prefere mantê-lo de uma maneira completamente diferente.

Você já respondeu sua própria pergunta. "... útil quando você faz grandes empurrões programados ..."

Como você está apenas fazendo trabalhos de manutenção e atualização, os marcos não fazem muito sentido. Exceto : mesmo ao escolher quais recursos iterar, é bom ter uma visão geral de onde todos os recursos estão indo para impedir que o desenvolvimento ágil fique fora de controle e para que o projeto pareça coeso.

Os marcos fornecem um ponto para medir quão bem as metas de longo prazo estão sendo alcançadas e um ponto para parar e considerar qual direção a futura iteração deve seguir.

Os marcos são úteis para o envolvimento do cliente, por exemplo: ao desenvolver um protótipo, um marco permitirá à equipe saber quais itens de trabalho devem ser concluídos para que um protótipo esteja pronto para apresentação.

Também é útil para implementações evolutivas, além de fornecer uma trilha de auditoria de desenvolvimento. Em uma equipe em que trabalhei anteriormente, o líder da equipe se separava do repositório principal para manter uma versão do produto naquele marco específico. Isso nos permitiu mostrar à alta gerência a evolução do produto e justificar o orçamento.

Todo recurso é um marco, por definição

uma ação ou evento que marca uma mudança ou estágio significativo no desenvolvimento

A utilidade de rastrear marcos individuais ou grupos de marcos para seu projeto, sua equipe e seu cliente é principalmente uma questão de gosto / estilo

Algumas equipes / clientes gostam de marcar marcos todos os dias ou mais, outros se contentam em fazê-lo com menos frequência

ADENDO: A palavra-chave é 'significativa' - que é subjetiva. Seus marcos podem variar. :)