Principais papéis / funções

Antes de iniciar a descrição de papéis, é importante enfatizar que, na DTI, o DL (Developer Leader) é o grande responsável pelo sprint. Ele deve garantir que as coisas aconteçam conforme “espírito DTI”. Ele é o “DONO” do sprint. Muitas vezes irá acumular algumas das funções descritas abaixo.

Papéis Cliente

Os papéis abaixo não irão NECESSARIAMENTE existir. Consiste de uma composição típica, mas pode variar principalmente em função da cultura e tamanho do cliente e várias funções podem ser executadas por uma mesma pessoa.

• Gerente de Projetos Cliente: É o responsável pelo projeto do ponto de vista do cliente. Tem a função de prover informações sobre restrições de prazo, custo e escopo para o restante da equipe. Caso o gerente do cliente seja o Gerente do Projeto, sem a co-participação de um gerente DTI, ele será responsável por não apenas prover as restrições, mas gerar todo o plano de prazo, custo e escopo.
• Líder Técnico Cliente: É o principal contato técnico no cliente e que irá direcionar as atividades da análise e definir a solução técnica*, junto com o DL da DTI.
• Usuário Chave Cliente: É o representante do cliente no projeto. Tem o papel de prover as principais informações e regras de negócio para detalhamento dos requisitos.
• Analista de Negócios Cliente: Faz a intermediação entre o usuário chave e o restante da equipe para que seja seguido um processo formal mais formal de detalhamento e visão dos produtos de software do cliente.
• Analista de Qualidade Cliente: Definirá os critérios e requisitos de aceitação, conforme política de qualidade do cliente.

*IMPORTANTE: A solução técnica deve ser sempre aderente ao direcionamento arquitetural definido ao início do projeto.

Papéis DTI

• Gerente de Projeto: É responsável pelo planejamento de prazo, custo e escopo do projeto e também pela comunicação com o cliente.
• Developer Leader: Conforme introdução, é o “DONO” do sprint do ponto de vista da DTI. Deve garantir que a equipe entenda os requisitos para que sejam posteriormente implementados. Deve definir a solução técnica junto ao cliente.
• Developer: Responsável pelo auxílio do DL na documentação dos requisitos, iniciar a preparação de roteiros de teste e protótipos de tela.

Fluxo Geral de Análise

Estabelecimento de Backlog

O Backlog com os itens de escopo ou requisitos deve ser gerado pelo cliente, visto que as necessidade surgem de seu negócio.

Para início da análise, uma lista candidata de requisitos deve ter sido previamente elencada pelo cliente e, de preferência, com uma estimativa preliminar de tamanho.

Preparação

A preparação corresponde às atividades que devem ocorrer antes do início do sprint para que recursos e entradas necessárias estejam realmente pontas e disponíveis para execução da análise.Caso esta etapa seja inexistente ou mal feita, há grande risco de impossibilidade de realização da análise ou ocorrência de atrasos, principalmente nos primeiros dias previamente planejados.

Elaboração de Agenda da Análise

Corresponde ao detalhamento e micro planejamento em si para os dias referentes à etapa de análise com a definição de quais requisitos e temas serão discutidos em cada dia.Esta atividade tem uma importância muito grande para que haja convergência da análise no tempo previsto.Além da agenda, em si, devem ser geradas as metas e o burn down para acompanhamento diário da fase de análise.

O template para construção da agenda diária e burndown pode ser obtido em: https://xp-dev.com/svn/DTI-Metodologia/02-Sprint/DTI - Sprint - Analise - Template - Planejamento e Burndown.xlsx

Execução e Envio de Checklist

Para que não haja esquecimento de itens necessários para início da análise, desde a reserva de salas e projetores, até a convocação dos usuários chave, é importante que seja executado um checklist que contém o histórico do que tipicamente deve estar pronto ou ser realizado, seja pela DTI ou pelo cliente.Após verificação do checklist, é importante que ele seja enviado ao responsável pelo sprint no cliente (normalmente o Gerente e o Líder Técnico) para que eles sejam lembrados de atividades que tenham que realizar. Se possível, fazer também uma ligação ou envio de mensagens indicando que o checklist foi enviado por email.

O template de checklist pode ser obtido em: https://xp-dev.com/svn/DTI-Metodologia/02-Sprint/DTI - Sprint - Checklists.xlsx.

Dinâmica Diária

A diâmica diária consiste de um sub processo repetido diariamente ao longo da análise.

Apresentação de Alinhamento de Agenda e Metas Diárias

Deve haver uma apresentação inicial, no primeiro dia e horário da etapa de análise para que todos fiquem alinhados sobre como a análise será direcionada.

É muito comum que as pessoas envolvidas na análise não saibam exatamente o que será feito e o que é esperado de cada um.

Esta atividade é crucial para mitigar riscos de não convergência da análise. Uma vez alinhadas com todos os participantes as metas, agenda, escopo, o risco de não convergência é bastante diminuído, visto que a tendência é que todos farão esforços para cumprir o que foi combinado em conjunto.

Aspectos importantes a serem alinhados:
- Cronograma
- Principais processos de negócio envolvidos no sprint
- Agenda de todos os dias em alto nível
- Escopo em alto nível
- Forma de acompanhamento (ritos diários). Ex.: Reunião diária e acompanhamento por burndown
- Horário de início das atividades em cada dia

Detalhamento Requisitos

O detalhamento dos requisitos é a principal atividade da análise. O objetivo é gerar a documentação necessária para a construção dos requisitos.

É importante ter em mente o aspecto da agilidade, ou seja, os requisitos devem ser detalhados até que os principais riscos sejam mitigados. Deve ser gerada uma documentação “inteligente”; aquilo que faz sentido e que vale a pena ser documentado.

A documentação básica consiste em descrever as regras de negócio, o protótipo de telas e a descrição de campos.

No entanto, pode haver requisitos mais complexos e, neste caso, o DL pode optar pela geração de outros documentos, como um diagrama de estados, para que o entendimento seja facilitado durante a construção.

A documentação deve seguir o template: https://xp-dev.com/svn/DTI-Metodologia/02-Sprint/DTI - Sprint - Analise - Template - Especificacao de Requisito.docx

Alguns artefatos opcionais, porém com necessidade de geração frequente:
- Modelo de classes e banco
- Diagramas de estado
- Queries muito complexas
- Diagrama de componentes (quando há aspectos de integração)
- Protótipos: Baixa fidelidade (esboços, wireframes), Alta fidelidade (imagens em png / jpg) e Navegáveis (html e mocks)

Reunião Diária

A reunião diária, como o próprio nome diz, deve ser um alinhamento ao meio ou fim do dia com TODA a equipe, incluindo o cliente para avaliar se os objetivos estão sendo cumpridos ou se alguma ações devem ser executadas para garantir convergência.

Ajuste Metas e Agenda

Após a realização da reunião diária, ou mesmo em função de algum evento qualquer ao longo da fase de análise, algumas ações de ajuste podem ser tomadas. Tipos de ação que podem ser decididas pelo time:
- Ajustes simples de metas e agenda para o dia posterior
- Aumento do número de dias da fase de análise em função de algum gap encontrado*
- Diminuição ou aumento de escopo da fase de análise*Interrupção da análise*

As ações marcadas com um asterisco* devem ser prontamente escaladas para o Gerente de Projeto da DTI e, em caso de não haver um Gerente direto, alinhadas com o responsável pelas Operações da DTI.

Encerramento

O encerramento corresponde às atividades finais de compilação de toda a discussão e documentação gerada ao longo dos dias de análise com o objetivo de consolidar os próximos passos rumo à fase de construção.

Planning Poker

O planning poker tem por objetivo estabelecer a ordem de grandeza dos requisitos documentados.

Ele deve ser sempre realizado em conjunto com o cliente, de forma que ele esteja confortável com as estimativas e facilite o andamento e acompanhamento do projeto.

Em caso de conflitos, é importante que as discussões sejam mantidas de forma a justificar os valores estimados. Em último caso, caso não haja consenso, o DL pode entrar em contato com outro DL mais sênior da DTI e solicitar apoio para mediação do ponto de conflito.
Ao final do planning poker, o tamanho, em pontos, do sprint é então definido.

Planejamento Construção

Com base nas disponibilidade total de horas das pessoas previamente alocadas para construção do sprint, do resultado do planning poker e outras restrições, como prazo, por exemplo, o planejamento da construção, testes de homologação do sprint deve ser gerado.

O template pode ser obtido em: https://xp-dev.com/svn/DTI-Metodologia/02-Sprint/DTI - Sprint - Construcao - Template - Planejamento e Burndown.xlsx.

Revisão de Alocação Necessária

A etapa de planejamento pode gerar a demanda por recursos adicionais para que seja viável a construção do sprint. Caso isto ocorra, o DL deve envolver o Gerente de Projetos da DTI (se for o caso) e o responsável pelas Operações da DTI para definição de ajustes de alocação.

Formalização Encerramento Análise e Início Construção

Após encerramento das atividades anteriores, um resumo das definições deve ser formalizado junto ao cliente.

Caso não tenha sido criado um repositório na DTI para arquivamento da documentação gerada, ele deve ser criado neste momento. Em alguns casos, o cliente pode ter seu próprio sistema de arquivamento.

É muito importante que seja feita uma análise de riscos de negócio e técnicos e que isto seja alinhado com os responsáveis pelo cliente, principalmente o Gerente de Projetos e Líder Técnico.

Principais artefatos a serem arquivados:
- Todos os documentos de detalhamento dos requisitos
- Comunicações importantes trocadas por email com o cliente, principalmente sobre planejamento, problemas e riscos
- Planejamento das etapas seguintes (construção e homologação)

Principais aspectos de formalização:
- Tamanho e velocidade do sprint
- Itens de escopo (requisitos priorizados para construção)
- Planejamento e riscos