Release os prazos geralmente são fixos, impostos externamente por coisas como feiras, pressões contábeis ou obrigações contratuais. Mas como o objetivo é colocar o software funcionando nas mãos dos usuários o mais rápido possível para fazer "correções de curso" o mais rápido possível, todo esforço é feito para manter release ciclos de desenvolvimento de software o mais curto possível. Agile release os ciclos certamente devem ser mantidos com menos de um ano e geralmente são tão curtos quanto seis meses ou três meses. A release é, por sua vez, composto de iterações. Para um determinado projeto, a duração da iteração normalmente será fixada entre uma semana e um mês. Se o release é em seis meses e as iterações serão de duas semanas cada, o release consistirá em 13 iterações.
Em alguns ambientes, o software pode ser entregue aos usuários, ou pelo menos a um subconjunto de usuários, de forma incremental no final de cada iteração ou a cada duas iterações. Depois que uma lista inicial de recursos foi identificada, priorizada e potencialmente estimada, a equipe realiza um release reunião de planejamento para estabelecer o release agendar e determinar quais recursos provavelmente podem ser entregues. o geral release plano em termos de recursos priorizados é usado para alimentar diretamente os planos de iteração individuais.
Alguns métodos Agile enfatizam a separação clara de responsabilidades entre programadores e clientes. Durante o planejamento, somente o cliente é responsável pelas decisões de negócios e priorização e somente os programadores são responsáveis pela estimativa de tarefas e execução do desenvolvimento. métodos Agile também desencoraja fortemente a administração de impor caprichosamente escolhas tecnológicas ao grupo de desenvolvimento, dando aos desenvolvedores tanta liberdade quanto possível para escolher as melhores ferramentas para o sistema e o projeto.
Preliminar release planejamento
O objetivo inicial release planejamento é estimar aproximadamente quais recursos serão entregues pelo release prazo (presumindo que o prazo seja fixo) ou para escolher uma data aproximada de entrega para um determinado conjunto de recursos (se o escopo for fixo). Usamos essas informações para decidir se o projeto produzirá ou não ROI suficiente para pelo menos se pagar e, portanto, se devemos ou não prosseguir.
Inicie release as reuniões de planejamento raramente duram mais do que um dia – ou dois meios-dias, se você simplesmente não aguenta ficar em uma reunião o dia inteiro. Primeiramente, o cliente apresenta as funcionalidades priorizadas a serem entregues. Idealmente, os desenvolvedores já criaram estimativas aproximadas de quanto trabalho é necessário para implementar cada um desses recursos.
Usando as estimativas dos desenvolvedores e as prioridades de recursos do cliente, a equipe estabelece um release planeje, mapeando recursos de maneira muito aproximada para as primeiras iterações. Os desenvolvedores podem descobrir que recursos de prioridade relativamente baixa representam riscos de design ou arquitetura e, portanto, podem pedir aos clientes que considerem atribuí-los a iterações anteriores de qualquer maneira, a fim de abordar esses riscos potenciais o mais cedo possível no projeto.
É extremamente útil se a velocidade da equipe de desenvolvimento em um release já é conhecido. Nesse caso, se o escopo for fixo, divida a estimativa total de todos os recursos necessários pela velocidade da equipe para fornecer o número aproximado de iterações necessárias para entregar a funcionalidade e, portanto, o prazo. Se o prazo for fixo (como é típico), multiplique a velocidade pelo número de iterações para obter uma noção inicial de quantos recursos podem ser entregues. Se a velocidade da equipe de desenvolvimento não for conhecida, eles devem fornecer uma estimativa para ela e o release O plano deve ser entendido como menos preciso nas primeiras iterações, até que um número de velocidade confiável possa ser derivado.
Preliminar release plano
O inicial release O plano raramente satisfaz todas as partes – ou não será entregue funcionalidade suficiente ou parece ser necessário muito tempo para entregar a funcionalidade desejada. Mas no mundo ágil, a equipe encara essas duras verdades e desenvolve um plano de desenvolvimento de software em torno delas. Ninguém acredita em milagres de escopo que irão satisfazer a todos. Em vez de praticar a negação coletiva, a equipe usa métricas e negociações reais para fazer escolhas difíceis o mais próximo possível do início do projeto.
Os líderes de pensamento ágil concordam que, embora seja possível para ajustar escopo, prazo, recursos e qualidade para um determinado projeto, as únicas variáveis que respondem bem ao ajuste são prazo e escopo. Pesquisas extensas mostraram que equipes maiores tendem a entregar sistemas de qualidade inferior mais lentamente, enquanto equipes menores tendem a entregar sistemas de qualidade superior mais rapidamente. De fato, pode ser necessário adicionar programadores a uma equipe, mas isso provavelmente atrasará a equipe por pelo menos algum tempo, não a acelerará. Uma vez que aceitamos essas descobertas, então aceitamos que em nosso release planejamento, devemos ajustar o escopo ou o prazo para produzir um release plano que é acordado para ser viável por patrocinadores, clientes, desenvolvedores, gerentes e outras partes interessadas. O fato de a equipe fazer essas escolhas difíceis de antemão reduz o risco geral do projeto. Isso aumenta as chances de que a equipe produza um conjunto de recursos que retorne o investimento das partes interessadas mais do que adequadamente dentro do prazo.
Planejando o release continuamente
O inicial release plano é entendido como difícil. Deve ser detalhado o suficiente apenas para nos iniciar, prevendo que o projeto trará retorno sobre o investimento suficiente para mais do que pagar por ele. (Se a inicial release Se o plano prevê um ROI muito baixo para justificar o projeto, podemos cancelá-lo antes de desperdiçar muito dinheiro.) Em projetos Agile, planejamos continuamente e corrigimos nosso curso à medida que avançamos. Um dos principais mecanismos para correção de curso é permitir que o release planeja evoluir em resposta a todos os tipos de feedback. Levará pelo menos algumas iterações para que a velocidade da equipe se estabilize. Às vezes, as iterações oferecem menos funcionalidade do que o planejado e, às vezes, mais. Recursos, opções arquitetônicas, opções de design ou opções de estrutura ou tecnologia podem ser muito arriscadas ou simplesmente impraticáveis. A interface do usuário pode exigir revisão. A equipe pode ser perdida ou adicionada. As prioridades dos recursos podem mudar. Todos esses fatores nos ajudarão a revisar e refinar o release planejar continuamente. Quando cada novo plano de iteração é publicado, também deve ser publicado um release plano que reflita a nova realidade.
Inicialização e finalização
Muitas equipes Agile planejam entregar apenas uma pequena quantidade de funcionalidade na primeira iteração (geralmente chamada de “iteração 0”), a fim de permitir explicitamente a resolução de problemas técnicos e logísticos iniciais e talvez também enfatizar a arquitetura de ponta a ponta. Isso pode ser crítico para equipes com pouca ou nenhuma experiência ágil. Para uma equipe sem uma boa métrica de velocidade, isso pode significar que somente no final da segunda ou terceira iteração a velocidade se tornou estável e confiável.
Algumas equipes também agendam até duas iterações no fechamento do projeto para estabilização, integração e teste em todo o sistema, correção de bugs e conclusão da documentação do usuário. Em um projeto ágil ideal, isso não seria necessário, mas no mundo real depende das práticas Agile específicas que a equipe segue, da estrutura organizacional, da complexidade geral do sistema, das entregas não codificadas esperadas da equipe, da complexidade de sistema deploymento e fatores semelhantes.
Perguntas Frequentes
Eu realmente preciso usar releasese um release plano?
Algumas equipes conseguem sobreviver sem planejamento ágil no release nível. Por exemplo, um ASP pode simplesmente entregar software em produção a cada iteração (ou seja, a cada poucas semanas), portanto, cada iteração é efetivamente uma release e planejamento ágil simples por iteração pode ser suficiente. Se, por outro lado, algum nível de visibilidade for exigido pela gerência no software release de grupos nível (ou seja, progresso, status, mudança do plano inicial de desenvolvimento de software, etc.), então releaseplanejamento e gerenciamento de alto nível podem ser inestimáveis.
Quão grandes são releases?
Releases normalmente variam entre dois e 12 meses. por mais tempo releases, pode fazer sentido dividi-lo em vários sub-releases.
Quantas iterações estão em um release?
O número de iterações dentro de um release é normalmente conduzido pelo cronograma. Se um release é de seis meses e as iterações são de duas semanas, então 13 iterações devem ser agendadas para o release.
Quem participa de release planejamento?
Para equipes menores, pode fazer sentido que toda a equipe multifuncional participe para fins de entrada e responsabilidade. Para equipes e organizações maiores, um subconjunto da equipe pode ser selecionado ou eleito para representar a equipe.
Quanto tempo faz release as reuniões de planejamento duram?
Release as reuniões de planejamento geralmente duram entre quatro e oito horas.
Quanto trabalho é feito na preparação para um release Reunião de planejamento?
Geralmente, um pouco de trabalho foi feito antes de um release reunião de planejamento em termos de aprovação do projeto, orçamento, visão, identificação da equipe etc. estimativas de nível.
Faz o release mudança de plano durante o release?
À medida que mais informações são descobertas, a funcionalidade é entregue, mais sobre o sistema é compreendido, as necessidades de negócios evoluem e as prioridades mudam, a composição geral do release quase definitivamente mudará. Embora esperada, a evolução do software release gestão ao longo do tempo terá de ser comunicado a todas as partes interessadas adequadas.
