Técnicas de estimativas ágeis

Neste post, vamos abordar técnicas de estimativas ágeis, conceitos de planejamento adaptativo e recomendações de uso, baseado nas fases do ciclo de vida de gestão de projeto ágil. Também como prover visibilidade do projeto em múltiplos níveis da empresa.

O planejamento adaptativo, utilizado na gestão ágil, adota um processo contínuo (realizado ao longo do projeto) que oferece mecanismos de atualizações frequentes. Esta flexibilidade permite reduzir os riscos, entregar valor de negócio antecipadamente e maior visibilidade.

waterfall-agil-01

Na iniciação do projeto, as estimativas são feitas em alto nível para apoiar as análises de investimento. E são refinadas continuamente durante todo o projeto. As técnicas de estimativas são colaborativas, e assim, todas as pessoas apropriadas devem ser incluídas no processo.

A maioria das técnicas utilizam unidades relativas, por exemplo o uso de pontos facilita a comparação entre os itens que estão sendo estimados (ao invés de estimar em “dias” diretamente), evitando “prever o futuro”, onde algumas leituras sinalizam que é uma dificuldade do ser humano.

T-Shirt Sizes

Abordagem de estimativa em alto nível para backlog grande com muitos itens a serem avaliados. Os itens são estimados em PP, P, M, G e GG, de acordo com as discussões e decisão comum/colaborativa das equipes. É uma forma rápida de ter uma ideia do tamanho total do backlog.


Planning Poker

Recomendado para estimar user stories (ou das tarefas) em quantidade relativamente pequena de itens (até 10). Os participantes, em geral, realizam votações utilizando a Sequência de Fibonacci. Quando há grande divergência nas pontuações, a votação é repetida até o time obter um consenso sobre a precisão da estimativa. A boa prática é trabalhar com até 13 pontos.


Affinity Mapping

É uma técnica que envolve agrupar os itens em categorias ou coleções similares. Utilizada para garantir que as unidades de story points se mantêm consistentes ao logo de todo o projeto.

A forma de triangulação oferece uma visão comparativa das estimativas e permite verificação. Pode ser uma alternativa quando há um grande número de histórias a serem estimadas, acelerando o processo de estimativas consideravelmente.

Migração Azure DevOps, TFS e Azure DevOps Server – Parte I

Com a adoção do Azure DevOps  (área Boards | Repos | Pipelines | Test Plans | Artifacts) em diversas empresas como a solução para o ciclo de desenvolvimento das aplicações, algumas dúvidas sobre o funcionamento do backup e migração dos dados surgiram, devido ao interesse em garantir a segurança para os artefatos criados pelos times.

E então, existe alguma ferramenta ou recurso nativo para executar a migração dos dados? Vamos começar pelo VSTS Sync Migrator, que não é tão friendly, mas apoia nas seguintes operações:

  • Migração dos dados do TFS para o TFS
  • Migração dos dados do TFS para o Azure DevOps Services
  • Migração dos dados dos Serviços de Devops do Azure para TFS
  • Atualização em massa nos serviços TFS ou Azure DevOps

Outra ferramenta muito utilizada é o Data Migration Tool for Azure DevOps. Esta ferramenta possui um guia com todos os passos para realizar a migração do Azure DevOps Server para o Azure DevOps Services. A recomendação geral deste processo é:

  • Identificar os artefatos mais importantes que deseja incluir na migração – código-fonte, work items, build pipelines, planos de testes, etc.
  • Escolher o melhor horário para fazer a migração
  • Preparar as organizações de destino, criando a organization e team projects necessários no Azure DevOps, provisionando os usuários e configurações básicas
  • Considerar tornar os deployments do Azure DevOps Server (origem) como read-only

Também pode ser feita a migração entre Organizações (Organizations) no Azure DevOps de forma manual. Neste post, vamos abordar a migração de work items da área Boards entre organizações diferentes do Azure DevOps.

1. Criando a Query

O primeiro passo é ter o AZURE DEVOPS ADD-IN PARA EXCEL instalado e configurado. Em seguida, crie uma Query (em Boards > Queries) para relacionar todos os work items que deseja fazer a migração.

2. Estruturando os times e cadência

Crie no Azure DevOps de destino as Iterations (sprints) e Areas que os times de projeto irão utilizar. Elas são as colunas Iteration Path e Area Path e podem ser utilizadas na migração para ajudar na organização dos work items. Por exemplo:

  • Work item: Criar API de retorno dos dados
  • Iteration Path: Sprint 01
  • Area Path: Time Backend e API

3. Acesse os dados do Azure DevOps (origem) no Excel

Com o Excel aberto, acesse via query, os work items do Azure DevOps (origem) que serão migrados para a outra Organização.

4. Realize a migração via Publish

Com outro Excel aberto, conecte no Azure DevOps (destino) na opção Input List e configure as colunas (choose columns) na mesma ordem do Excel com os work items de origem.

Feito isso, copie e cole os work items e utilize a opção Publish para publicar no Azure DevOps (destino). Recomendo iniciar pelo nível mais alto da estrutura (Epic – Feature – Requirements – Tasks), pois embora não há migração do relacionamento entre eles, você pode configurar em Links and Attachments estes relacionamentos.

Manifesto Ágil: valores e princípios

A História

O Manifesto Ágil foi escrito em 2001 por 17 profissionais de software que já praticavam Scum, Extreme Programming, Crystal Clear e outros frameworks. Embora os participantes não tenham concordado com frequência, encontraram um consenso em torno de quatro valores principais.


Os Autores

Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
Robert C. Martin
Steve Mellor
Dave Thomas
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Ken Schwaber
Jeff Sutherland


Valores do Manifesto Ágil

“Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:”

https://www.manifestoagil.com.br/
  1. Indivíduos e interações mais que processos e ferramentas
  2. Software em funcionamento mais que documentação abrangente
  3. Colaboração com o cliente mais que negociação de contratos
  4. Responder a mudanças mais que seguir um plano


Os 12 princípios do Manifesto Ágil

Nós seguimos os seguintes princípios:

  • Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.
  • Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.
  • Entregar software funcionando com freqüencia, na escala de semanas até meses, com preferência aos períodos mais curtos.
  • Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diáriamente, durante todo o curso do projeto.
  • Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.
  • O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.
  • Software funcional é a medida primária de progresso.
  • Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.
  • Contínua atenção à excelência técnica e bom design, aumenta a agilidade.
  • Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.
  • As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.
  • Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

Link: http://agilemanifesto.org/

Assessment Ágil – Avaliação de maturidade

Com a disseminação das práticas ágeis nas organizações, vieram também ajustes nos frameworks, novas discussões e conceitos da aplicabilidade. Alguns marcos importantes desta linha do tempo:

  • 2000/2001 Agilidade nos times de TI: uso de práticas ágeis no departamento de TI.
  • 2010/2011 Escala ágil além da TI: outros departamentos também utilizam agilidade.
  • 2015/2016 Business Agility – Enterprise: capacidade da organização responder rapidamente às mudanças do mercado, orientada a valor.
  • 2018/2019 Digital Decoupling: trabalha com elementos de valor de forma desacoplada (não mais produtizado).

E assim, as empresas precisam conhecer e monitorar estas práticas continuamente para maximizar seus benefícios. Vale mencionar que being agile x doing agile não deve ser uma meta em si. Medir o rigor de uso dos princípios ágeis também não é o ponto. Avalie a equipe em relação aos princípios ágeis que fazem sentido como propósito para obtenção do sucesso.

Claro que a aplicação dos modelos de maturidade exige alguns cuidados, por simplificarem demais algumas áreas complexas e não lineares. Por exemplo, consideram o crescimento como uma progressão linear, marcado por fases e características únicas. Também a impressão de que o que ficou a direita da maturidade é “bom”, enquanto a esquerda é considerada “ruim”.

Alguns modelos de assessment amplamente utilizados no mercado para avaliar a maturidade ágil dos times são:

1. Agile Assessment tool – Agile Maturity Model (AMM)

Umas das primeiras ferramentas de avaliação ágil, muito direcionada a maturidade na adoção de valores, princípios e práticas ágeis. Os atributos de cada nível buscam ser claramente definidos e o mais discricionários possível, concentrando na capacidade de alterar práticas (não avalia o progresso da mudança de cultura)

Agile Maturity Model 

Com a adição da ferramenta Agile Health Radar, as equipes incluíram a visão da cultura em relação às suas próprias iniciativas e ao portfólio.

Agile Health Radar

2 – Agile Maturity Curve

Neste modelo, há a adição de três áreas que ajudam a habilitar a gestão ágil nos times: arquitetura, release planning e governança. No “one size fits all” – a implementação bem sucedida de frameworks pode exigir ajustes de acordo com as camadas e necessidades do negócio.

Agile Maturity Curve
Agile Maturity Curve

3 – Maturity Model

Propõe cinco categorias para a organização atingir o Agile Maturity, com objetivos claros e específicos para cada uma. O primeiro desenho representa o guia para implementação do modelo, seguido do exemplo dos cinco níveis (Level 1 – Level 5) de maturidade da liderança (leadership).

Agile Maturity Categories
Maturity Model Guide
Agile Maturity Example
Maturity Model Guide Example

4 – The Agile Principles Checklist

Avalia a maturidade ágil da equipe em relação aos 12 princípios do Manifesto Ágil. A ferramenta surgiu com base no livro Scrum Mastery (de Geoff Watt), devido a simplicidade da abordagem de uma equipe se mapeando com os 12 princípios ágeis.

How Agile is my Team
The 12 Agile Principles

5 – Agile Maturity Assessment

Baseado principalmente no Scrum e priorização da pontuação da avaliação MoSCoW. Ajuda a fornecer a visão as is e to be de agilidade.

Agile Maturity Assessment

6 – Roda Ágil

Dinâmica de avaliação da maturidade ágil com pontuação de 1 a 5 para cada item, baseado nos quatro valores do Modern Agile (pessoas sensacionais, valor a todo instante, segurança um pré-requisito, experimente e aprenda rápido).

Roda Ágil