Release Os prazos são frequentemente fixos, impostos externamente por fatores como feiras comerciais, pressões contábeis ou obrigações contratuais. Mas, como o objetivo é disponibilizar software funcional aos usuários o mais rápido possível para que ajustes possam ser feitos o quanto antes, todo esforço é feito para manter os ciclos de desenvolvimento de software o mais curtos possível. Os ciclos de lançamento ágil devem ser mantidos abaixo de um ano, frequentemente com duração de seis ou três meses. Um lançamento, por sua vez, é composto por iterações. Para um determinado projeto, a duração de cada iteração geralmente é fixada entre uma semana e um mês. Se o lançamento ocorrer em seis meses e as iterações durarem duas semanas cada, o lançamento consistirá em 13 iterações.
Em alguns ambientes, o software pode ser entregue aos usuários, ou pelo menos a um subconjunto deles, de forma incremental ao final de cada iteração ou a cada duas iterações. Após a identificação, priorização e possível estimativa de uma lista inicial de funcionalidades, a equipe realiza uma reunião de planejamento de lançamento para estabelecer o cronograma geral de lançamento e determinar quais funcionalidades provavelmente poderão ser entregues. O plano geral de lançamento, em termos de funcionalidades priorizadas, é então usado para alimentar diretamente os planos de iteração individuais.
Algumas metodologias Agile enfatizam a clara separação 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 Além disso, desencorajamos veementemente a gerência de impor arbitrariamente escolhas tecnológicas ao grupo de desenvolvimento, dando, em vez disso, aos desenvolvedores a maior liberdade possível para escolher as melhores ferramentas para o sistema e o projeto.
Planejamento de lançamento preliminar
O objetivo do planejamento inicial de lançamento é estimar aproximadamente quais funcionalidades serão entregues até o prazo final (presumindo que o prazo seja fixo) ou escolher uma data de entrega aproximada para um determinado conjunto de funcionalidades (se o escopo for fixo). Usamos essas informações para decidir se o projeto gerará retorno sobre o investimento (ROI) suficiente para, pelo menos, se pagar, e, portanto, se devemos ou não prosseguir.
As reuniões iniciais de planejamento de lançamento raramente duram mais de um dia – ou dois meio-dias, caso você simplesmente não aguente ficar em uma reunião o dia inteiro. Primeiro, o cliente apresenta as funcionalidades priorizadas a serem entregues. Idealmente, os desenvolvedores já terão elaborado estimativas aproximadas do trabalho necessário para implementar cada uma dessas funcionalidades.
Com base nas estimativas dos desenvolvedores e nas prioridades de funcionalidades definidas pelo cliente, a equipe elabora um plano de lançamento, mapeando as funcionalidades de forma aproximada para as primeiras iterações. Os desenvolvedores podem constatar que funcionalidades de baixa prioridade representam riscos de design ou arquitetura e, portanto, podem solicitar aos clientes que considerem atribuí-las a iterações anteriores, a fim de mitigar esses riscos potenciais o mais cedo possível no projeto.
É extremamente útil se a velocidade de desenvolvimento da equipe em uma versão anterior já for conhecida. Nesse caso, se o escopo for fixo, você divide a estimativa total de todos os recursos necessários pela velocidade da equipe para obter 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), você multiplica a velocidade pelo número de iterações para ter 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, e o plano de lançamento deve ser entendido como menos preciso durante as primeiras iterações, até que um número de velocidade confiável possa ser obtido.
Plano de lançamento preliminar
O plano de lançamento inicial raramente satisfaz todas as partes – ou não serão entregues funcionalidades suficientes, ou o tempo necessário para entregar as funcionalidades desejadas parecerá excessivo. Mas no mundo ágil, a equipe encara essas duras realidades e desenvolve um plano de desenvolvimento de software que as leve em consideração. Ninguém acredita em milagres de escopo que satisfaçam a todos. Em vez de praticar a negação coletiva, a equipe utiliza métricas reais e negociação para tomar decisões difíceis o mais próximo possível do início do projeto.
Líderes de pensamento ágil concordam que, embora seja possível Para ajustar o escopo, o prazo, os recursos e a qualidade de um projeto, as únicas variáveis que respondem bem a ajustes são o prazo e o escopo. Pesquisas extensivas mostram que equipes maiores tendem a entregar sistemas de menor qualidade mais lentamente, enquanto equipes menores tendem a entregar sistemas de maior qualidade mais rapidamente. Pode ser necessário adicionar programadores a uma equipe, mas isso provavelmente irá desacelerá-la por um tempo, e não acelerá-la. Uma vez que aceitamos essas descobertas, também aceitamos que, em nosso planejamento de lançamento, devemos ajustar o escopo ou o prazo para produzir um plano de lançamento viável para patrocinadores, clientes, desenvolvedores, gerentes e outras partes interessadas. O fato de a equipe tomar essas decisões difíceis antecipadamente reduz o risco geral do projeto. Isso aumenta as chances de a equipe produzir um conjunto de funcionalidades que retorne o investimento das partes interessadas de forma mais do que adequada dentro do prazo.
Planejando o lançamento continuamente
O plano de lançamento inicial é entendido como um esboço. Ele deve ser detalhado o suficiente apenas para nos dar um ponto de partida, prevendo que o projeto trará um retorno sobre o investimento (ROI) suficiente para mais do que cobrir os custos. (Se o plano de lançamento inicial 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 rumo conforme avançamos. Um dos principais mecanismos para correção de rumo é permitir que o plano de lançamento evolua em resposta a todos os tipos de feedback. Serão necessárias pelo menos algumas iterações para que a velocidade da equipe se estabilize. As iterações às vezes entregarão menos funcionalidades do que o planejado e, às vezes, mais. Recursos, escolhas arquitetônicas, escolhas de design ou escolhas de framework ou tecnologia podem se mostrar muito arriscadas ou simplesmente inviáveis. A interface do usuário pode precisar de revisão. Pode haver mudanças na equipe, com novas contratações ou desligamentos. As prioridades dos recursos podem mudar. Todos esses fatores nos ajudarão a revisar e refinar o plano de lançamento continuamente. Quando cada novo plano de iteração for publicado, um plano de lançamento revisado, que reflita a nova realidade, também deverá ser publicado.
Início e conclusão
Muitas equipes Agile planejam entregar apenas uma pequena quantidade de funcionalidades na primeira iteração (frequentemente 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 testar a arquitetura de ponta a ponta. Isso pode ser crucial para equipes com pouca ou nenhuma experiência em metodologias Agile. Para uma equipe sem uma boa métrica de velocidade, isso pode significar que somente ao final da segunda ou terceira iteração a velocidade se tornará estável e confiável.
Algumas equipes também programam até duas iterações no encerramento do projeto para estabilização, integração e testes 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 relacionadas a código esperadas da equipe, da complexidade da implantação do sistema e de fatores semelhantes.
Perguntas
Será que eu realmente preciso usar versões e um plano de lançamento?
Algumas equipes conseguem se virar sem planejamento ágil no nível de lançamento. Por exemplo, um provedor de serviços ágil (ASP) pode simplesmente entregar software em produção a cada iteração (ou seja, a cada poucas semanas), portanto, cada iteração é efetivamente um lançamento e um planejamento ágil simples por iteração pode ser suficiente. Se, por outro lado, algum nível de visibilidade for exigido pela gerência do software, a abordagem pode ser diferente. gerenciamento de liberação Em termos de nível (ou seja, progresso, status, mudança em relação ao plano inicial de desenvolvimento de software, etc.), o planejamento e gerenciamento em nível de lançamento podem ser inestimáveis.
Qual o tamanho dos lançamentos?
ReleaseOs prazos de lançamento geralmente variam entre dois e doze meses. Para lançamentos mais longos, pode ser interessante dividi-los em vários sublançamentos.
Quantas iterações há em uma versão?
O número de iterações em uma versão geralmente é determinado pelo cronograma. Se uma versão tem duração de seis meses e as iterações são de duas semanas, então 13 iterações devem ser programadas para essa versão.
Quem participa do planejamento de lançamento?
Para equipes menores, pode ser interessante que toda a equipe multifuncional participe, tanto para contribuir quanto para garantir a prestação de contas. Para equipes e organizações maiores, um subconjunto da equipe pode ser selecionado ou eleito para representá-la.
Qual a duração das reuniões de planejamento de lançamento?
Release As reuniões de planejamento normalmente duram entre quatro e oito horas.
Quanto trabalho é feito na preparação de uma reunião de planejamento de lançamento?
Geralmente, bastante trabalho já foi feito antes de uma reunião de planejamento de lançamento, em termos de aprovação do projeto, orçamento, visão, identificação da equipe, etc. Com relação à funcionalidade, o cliente provavelmente já dedicou tempo trabalhando com a equipe de desenvolvimento para identificar os recursos iniciais, bem como, possivelmente, detalhá-los e fornecer estimativas iniciais de alto nível.
O plano de lançamento muda durante o lançamento?
À medida que mais informações são descobertas, funcionalidades são implementadas, o sistema é melhor compreendido, as necessidades de negócios evoluem e as prioridades mudam, a estrutura geral da versão certamente se transformará. Embora prevista, a evolução da gestão de versões de software ao longo do tempo precisará ser comunicada a todas as partes interessadas relevantes.
