Ágil em larga escala – Inception e preparação para PI Planning – SAFe

Quando trabalhamos com projetos ágeis em larga escala, utilizando o SAFe como framework, temos a PI Planning como um dos mais importantes eventos. É uma reunião  de planejamento com duração de 2 dias e que acontece a cada 10 semanas. O plano estabelecido e aprovado é o alinhamento entre todos os times do ART (Agile Release Train) para estas próximas 10 semanas (5 Sprints).

E o que devemos considerar na preparação deste evento? By SAFe:

  • Organizational readiness: strategic alignment and teams and trains setup (planning scope and context | business alignment | agile teams)
  • Content readiness: management and development preparednes (executive briefing | product vision briefing(s) | architecture vision briefing)
  • Facility readiness: the actual space and logistics for the event (facility | tech support | communication channels)

Adicionalmente, fiz um resumo que pode ajudar na preparação para a PI Planning:

Premissas de Produto

Lean Inception, por exemplo, é uma ótima oportunidade de cocriar o produto a ser discutido na PI Planning. Desta forma, o escopo do produto ficará muito mais claro para o time durante a reunião de PI Planning, onde será feito o refinamento de atividades e estimativas (planning poker).

lean-inception.png

A organização do backlog do produto é essencial: Epic > Features > User Story > Tasks. Uma boa prática é criar tudo em sua ferramenta de gestão ágil (no meu caso utilizei o Azure DevOps) nesta fase de Inception e refinar o entendimento com as estimativas na PI Planning. A prototipação das telas complementa este trabalho.

historias-vsts

Criar uma WBS (work breakdown structure) para representar as Epics e Features que serão discutidas na PI Planning é outro recurso que pode ser utilizado por PMs e POs na apresentação do produto nesta reunião.

wbs-features

Quando estiver iniciando um novo projeto (1ª PI Planning), vale a pena acompanhar o entendimento de todos os times, principalmente PM, POs e SMs. Recomendo inclusive executar uma mini jornada (2 horas) de PI Planning com os principais participantes.

jornada-PI-Planning

Em estágios mais avançados, vale verificar se os feedbacks coletados no final da última PI foram trabalhados e os pontos que não foram bem, devem estar resolvidos.

feedback

Premissas Técnicas

Alguns dos principais pontos técnicos que devem ser garantidos antes das PI Plannings:

  • Arquitetura: visão da solução e como será a integração entre os sistemas. Também apoia o time na definição de requisitos funcionais, não funcionais e dos enablers. Os enablers apoiam as atividades da Architectural Runway a prover funcionalidades de negócio. Inclui infraestrutura, compliance, exploração e arquitetura de sistemas.
  • Infraestrutura: provisionamento dos ambientes em cloud e estrutura (VPN, rede, acessos, etc.) para suportar o trabalho a ser executado. É esta frente que cuida de banco de dados na sua empresa? Se sim, deve estar envolvido na estruturação das bases, padronização de objetos e otimização das instâncias.
  • ALM: criar os projetos e times de projeto (por exemplo no Azure DevOps), estrutura do código-fonte, estratégia de versionamento (branch, merge e commit) e Continuous Integration (build e release).
  • Outros: segurança da informação e demais áreas que devem ser envolvidas.

* The Architectural Runway consists of the existing code, components, and technical infrastructure needed to implement near-term features without excessive redesign and delay.

Azure-Architecture.png

Facilities

Garantir a reserva das salas com capacidade para todos os participantes. Também confirmar a reserva das salas necessárias para os breakouts – recursos de videoconferência, Datashow, etc.

Viabilizar materiais para PI Planning (flipcharts, post-its, canetas, canetões e folhas de sulfite) e acesso a ferramentas que serão utilizadas no projeto. O coffee é outro ponto a ser considerado no evento.

Usuários e grupos de permissões no Azure DevOps

Ao criar seus projetos e times no Azure DevOps, temos outro passo importante que é a gestão de usuários e permissões de quais recursos irão utilizar. Os principais planos de usuários são:

  • Basic: até 5 usuários e dispõe de recursos como criar e editar work items, build, release e outros.
  • Stakeholder: não tem limite de usuários, mas acesso restrito de recursos. Recomendado para usuários que precisam visualizar o backlog do projeto.
  • Visual Studio subscribers: possui recursos adicionais, tais como o Test Manager.

Para visualizar os usuários da conta de sua organização, acesse o Azure DevOps em  Organization Settings e Users. Veja no sumário quantos usuários estão utilizando cada tipo de licença e as extensões de Test Manager e Package Management.

azure-devops-users

Já em Organization Settings > Security do Azure DevOps, podemos criar grupos e habilitar as permissões relacionadas a estes grupos. Os membros do grupo herdam as permissões concedidas ou revogadas.

azure-devops-group

O quadro abaixo exibe as principais permissões que podemos gerenciar no Azure DevOps. As permissões estão relacionadas a estrutura (projetos ou times de projetos) ou as features. Veja que as configurações vão desde repositórios, CI (build/release), aprovações até análise de dados e manipulação de work items.

vsts-permissions
Fonte: Permissions – Azure Devops

O Azure DevOps já atribui permissões padrão aos usuários, como por exemplo de acesso a ferramenta.

E a gestão de acessos – inclusão e revogação de usuários, assim como a gestão dos grupos e permissões de acesso podem ser feitos nas mesmas áreas citadas anteriormente (Organization Settings > Security e Organization Settings > Users).

azure-devops-add

É isso… em breve falaremos sobre a gestão de usuários com Azure Active Directory (Azure AD) e os detalhes de como distribuir os recursos entre usuários e grupos.