Como esta EAP foi organizada
Em software, é tentador montar a EAP pelas etapas do desenvolvimento (análise, desenvolvimento, testes). O problema é que essas etapas se repetem para cada funcionalidade, e a EAP vira um cronograma disfarçado. Este exemplo organiza o segundo nível por entregas: requisitos, o aplicativo, qualidade e implantação, além do gerenciamento do projeto.
O que vale notar:
- O ramo "Aplicativo" é decomposto por funcionalidadeagenda do paciente, painel da clínica, lembretes automáticos e integração com o sistema de gestão. Cada uma é uma entrega que o usuário reconhece e que pode ser aceita separadamente.
- Os requisitos têm entregas concretashistórias de usuário priorizadas, com critérios de aceite, e um protótipo validado com as clínicas do piloto. "Levantar requisitos" seria uma atividade; o protótipo validado é o resultado.
- Qualidade tem pacotes própriosO plano de testes e o relatório de aceitação assinado pelo product owner são entregas com dono. Quando qualidade fica "dentro do desenvolvimento", ela é a primeira coisa comprimida quando o prazo aperta.
- Implantação vai além de publicar nas lojasInclui o treinamento das clínicas do piloto e um mês de suporte assistido. É aqui que muitos projetos de software falham: o sistema funciona, mas ninguém usa.
Como adaptar ao seu projeto
- Troque as funcionalidades pelas do seu produto. Mantenha cada uma como um pacote que o usuário reconhece.
- Em projetos ágeis, pense no segundo nível como épicos. As histórias de usuário ficam no backlog e são detalhadas perto da hora de desenvolver.
- Inclua os requisitos não funcionais que viram trabalho: segurança, desempenho, acessibilidade e adequação à lei de proteção de dados.
- Não esqueça a transição para a sustentação: documentação, monitoramento e quem atende os chamados depois do projeto.
Perguntas frequentes
EAP faz sentido em projetos ágeis?
Sim, como visão do todo. A decomposição em épicos, funcionalidades e histórias segue a mesma lógica da EAP. A diferença é que os níveis mais baixos são detalhados aos poucos, a cada iteração.
Onde entra a infraestrutura do sistema?
Pode ser um pacote dentro do aplicativo ("ambientes e publicação") ou um ramo próprio, se for grande, como na criação de uma nuvem nova ou na migração de servidores.
A integração deve ser um item separado?
Quando depende de outra equipe ou fornecedor, sim. Integrações são fontes frequentes de atraso e precisam de responsável e critério de aceite próprios.