Um Processo Típico de Desenvolvimento

Advertência ao leitor. Infelizmente, não tive tempo (ainda) de produzir uma descrição completa de um processo de desenvolvimento. Produzi apenas uma descrição resumida de um processo típico. Falta falar de ferramentas, condições de entrada e saída, melhorar as descrições, dar mais exemplos, definir melhor os artefatos e fornecer exemplos dos mesmos, etc. Um dia ...

Outra advertência ao leitor. Este processo é relativamente "light". Muitas pessoas usam processos mais pesados com muito mais artefatos permanentes. Não estou dizendo que este é o melhor. É apenas um exemplo (mas que funciona).

Lembre que temos que definir quem faz o quê, quando e como.

Quem: Os Papeis

A descrição de papeis segue. Claro que alguns papeis poderão ser assumidos pela mesma pessoa, dependendo do tamanho do time.

Papel	Responsabilidades	Pessoas alocadas
Board de Mudança	Aprova mudanças nos requisitos e mudanças arquiteturais
Cliente	Fornece Use Cases e requisitos não funcionais É um usuário final direto do produto Fornece Testes de Aceitação Toma decisões de business, isto é, mudanças nos requisitos
Customer Liaison	Comunica regularmente com o cliente para obter requisitos, mudanças de curso, etc.
Documentador	Cria documentação ou organiza a documentação produzida pelos outros Cuida de controle de mudanças de artefatos com a ferramenta de Controle de Versão Check-in e check-out Mantém a home page do projeto atualizada
Programador (ou Desenvolvedor ou Engenheiro de Software)	Design, Interface HM, Programação e Testes de Unidade Deve ser bom para comunicar, programar e descobrir formas simples de resolver problemas Deve programar bem, refatorar e testar bem Responsável por parte da documentação (aquela referente ao código sob sua responsabilidade)
Project Manager	Dedica pelo menos 2 ou 3 horas por semana pensando na gerência do projeto, mesmo que tenha outras atribuições de programador As horas que se "perdem" fazendo isso se compensam facilmente pelo controle que se obtem sobre o desenvolvimento Se não fizer isso, o projeto se torna frouxo e vai demorar mais tempo para ser terminado Organiza, rastreia e informa sobre projeto Gerencia documentos Comunica com sponsor Assegura a continuidade do projeto Assegura que cada pessoa do time tenha tarefas alocadas e esteja fazendo seu papel Conversa com cada membro do time, pelo menos 1 vez por dia sobre o andamento das tarefas. Bastam alguns minutos Lidera a reunião semanal de acompanhamento (1 hora) Trata de aspectos como recursos, RH, treinamento, responsabilidades para o resto da empresa, verifica métricas e as mostra para pessoas interessadas, etc.
Sponsor	Aprova e suporta o projeto Fornece os Business Requirements Fornece algumas restrições de projeto (tempo, orçamento, datas especiais, ...)
Tester	Transforma testes de aceitação especificados pelo Cliente em código Lembre que testes de unidade são feitos pelos Programadores e não pelo Tester
(Tiger Teams) Membros de Equipes de Emergência	Investigam problemas urgentes rapidamente
Tracker	Acompanhar e prover feedback sobre Métricas Qualidade das estimativas Big picture Riscos Deve coletar informação de métricas sem ser um constante intruso Divulga métricas de alguma forma visível Atualiza o cronograma, usando alguma ferramenta apropriada Como ele assume o papel de Avaliador de Riscos, ele: Identifica e avalia riscos Ajuda a bolar planos de recuperação

Quem decide o quê?

Neste processo, Business (Sponsor e Cliente) decidem:
- O escopo (o que fazer)
- Prioridades (em que ordem)
- Composição de releases
- Data de releases
Os técnicos decidem:
- Estimativas de tempo para cada Use Case
- Consequências de decisões que o Business toma
- Que processo usar
- Escalonamento detalhado

O Quê, Como: As Atividades do Processo

Idéia Geral do Processo

O processo é iterativo-incremental
O processo procura colocar um release inicial nas mãos do cliente o mais rapidamente possível de forma a obter melhor feedback do cliente sobre a funcionalidade
A primeira iteração deve portanto:
- Testar a arquitetura completa
- Ser mínima (cliente escolhe o que vai nela)
- Risk-Confronting (técnicos escolhem as coisas mais difíceis primeiro para minimizar o risco)
Demais mudanças são integradas à versão de produção o mais rapidamente possível, em pequenos incrementos, de forma a evitar grandes integrações
- "Continuous integration"
Já que o cliente está perto de nós, teremos muita interação com ele e não precisamos de "sign-off" de requisitos para nos proteger. O cliente pode mudar os requisitos a qualquer momento. Nós estamos prontos para alterar o código devido a nosso foco em testes automáticos.
"Travel light"
- Temos poucos artefatos permanentes sob controle de mudança
- Não há longos relatórios
- Não há longas reuniões

As atividades

[Depois, devo melhorar essa descrição e incluir: Fase, atividade, descrição, como fazer (sub-atividades ou WBS), artefatos (deliverables), artefatos sob controle de mudança, quem aprova e como, responsáveis, condição de entrada, etc.]

A Fase de Planejamento e Elaboração

Obtenção de Requisitos

Os requisitos de Business são obtidos do Sponsor [Project Manager + Customer Liaison]
- O resultado deste levantamento está num Documento de Visão e Escopo, descrito aqui
Identifique classes de usuários do produto
Identifique representativos apropriados das classes de usuários
Escolha uma técnica de obtenção de requisitos
- Algumas técnicas estão descritas aqui
Elabora-se um cronograma para a obtenção dos Use Cases, Requisitos Funcionais e Requisitos Não Funcionais
- Seguir essas dicas para elaborar cronogramas
Loop para cada parte do sistema
- Usar as técnicas de obtenção de requisitos para desenvolver Use Cases para um pedaço do sistema [Customer Liaison + 1 pessoa]
- Transformar os Use Cases numa lista de requisitos funcionais [Customer Liaison + 1 pessoa]
- Os requisitos não funcionais são obtidos do cliente [Customer Liaison + 1 pessoa]. Se não sabe o que são requisitos não funcionais, clique aqui
- Todos os requisitos são numerados de forma a facilitar inserções e remoções
- Para melhorar o entendimento dos requisitos por perte de todos os participantes, pode-se fazer um modelo conceitual aqui (modelo de análise)
  - Não precisa entrar sob controle de mudança, pois, neste processo, o modelo conceitual só é necessário (quando o é) até ser substituído pelo código da primeira iteração
  - Acreditamos que a combinação de requisitos/código/testes será suficiente como artefatos permanentes
  - Já que o modelo conceitual não é permanente, não precisa ser feito com uma ferramenta especial. Basta rascunho em papel.
- Desenvolver protótipos de interface com o usuário se for necessário para esclarecer requisitos que não ficaram bem entendidos
- Desenvolver os testes de aceitação a partir dos Use Cases
  - No presente processo, o cliente especifica os testes de aceitação
- Repetir o loop para outras partes do sistema
Artefatos: Documentos HTML + Modelo de Use Cases em UML com Rational Rose + cronograma
Controle de mudança: Sim
Quem aprova: Sponsor, Cliente, Project Manager

Elaboração do Projeto Arquitetural

Projetar a arquitetura [Os desenvolvedores, talvez não todos]
- Se você não sabe o que vai num projeto arquitetural, clique aqui.
Artefato: Qualquer mídia, até rascunho em papel
Controle de mudança: Não
- Neste processo, o projeto arquitetural só é necessário até ser substituído pelo código da primeira iteração
- Acreditamos que a combinação de requisitos/código/testes será suficiente como artefatos permanentes
Quem aprova: Os desenvolvedores

Priorização da Funcionalidade

Estimar tempo necessário a cada Use Case [Desenvolvedores]
Em função deste tempo de da importância de cada Use Case (talvez parcial) para o Business, cada Use Case recebe uma prioridade, indicando em que iteração deverá entrar, a princípio. Isso poderá mudar depois, sem problema. [Cliente, Customer Liaison, Project Manager]
- Lembre a Idéias Geral, acima, sobre a Primeira Iteração
Elabora-se o cronograma para o primeiro release. O cronograma é mantido de forma detalhada para o próximo mês; o resto pode ser aproximado.
Artefatos: Um documento HTML
Controle de Mudança: não
Quem aprova: Cliente, Project Manager

A Fase de Construção

Para entender o que segue, observe a semântica que estamos associando às seguintes palavras:
- Release: Conjunto de Use Cases úteis para a produção e onde haverá necessidade de ter treinamento dos usuários, documentação externa completa, etc.
- Use Case: Um conjunto de ações feitas por um usuário do produto que resulta em valor para o cliente
- Tarefa: Pedaços mínimos necessários para implementar um Use Case. Um conjunto de tarefas é portanto o Work Breakdown Structure (WBS) de um Use Case
- Iteração: Neste processo, uma iteração ocorre na integração de qualquer funcionalidade à versão de produção. Lembre que entramos em produção com a primeira iteração. Depois disso, cada tarefa, ou talvez Use Case, poderá ser integrado ao ambiente de produção, com muita frequência
Observe também que nem todo processo define essas palavras assim (principalmente iteração e tarefa)
Os passos abaixo são repetidos em loop
- Há um loop externo: cada release
- Há um loop interno: cada iteração

Construção do próximo release

Consultar usuário sobre definição do próximo release: quais Use Cases (mesmo que parciais) entrarão? [Cliente, Customer Liaison]
Dividir cada Use Case em Tarefas (Work Breakdown Structure - WBS) [Desenvolvedores]
- Usar tarefas pequenas (de 8 a 16 horas de trabalho)
Estimar o tempo de cada tarefa e suas dependências [Desenvolvedores]
Atualizar cronograma
Tarefas são divididas entre desenvolvedores que programam, fazem testes de unidade 100% dos testes de unidade devem rodar [Desenvolvedores]
- Observe que este passo implica em fazer Análise mais detalhada com o Cliente, se necessário
- Quando requisitos mudam ao longo do tempo, devem passar pelo Board de Mudança e devem entrar sob controle de mudança
- Idem, com respeito ao projeto arquitetural
- O design de baixo nível é feito no papel, sem artefatos permanentes
Enquanto isso, o Tester prepara os testes de aceitação, roda os testes de aceitação junto com o cliente [Tester, Cliente]
Para terminar uma tarefa, os programadores devem completar a Transição para Produto, o que inclui documentação e considerações de instalação [Desenvolvedores]
Antes de passar para a fase de integração, deve-se conduzir uma auditoria de design/código [Desenvolvedores nomeados pelo Project Manager] e de documentação [Cliente]
Após aceitação na auditoria, integra o resultado ao sistema de produção. Isso pode ser feito frequentemente, até uma vez por dia. [Tester]
Artefatos: Cronograma, Código, testes de unidade e testes de aceitação, outros artefatos de acompanhamento de processo (ver documento de gestão do processo)
Controle de Mudança: Sim, só para os 3 artefatos acima
Quem aprova:
- O que vai no próximo release: [Cliente]
- Design/Code review: [Desenvolvedores indicados pelo Project Manager]
- Documentação e testes de aceitação: [Cliente]

A Fase de Implantação

Como estamos usando um processo com integração contínua, há integração no produto final que está em produção com muita frequência (até 1 vez ao dia, sem problemas)
Os usuários são treinados sob demanda

Controle de Mudança

Mudanças aos requisitos são indicados pelo Cliente e aprovadas ou não pelo Board de Mudança
- Mudanças que devem passar por este processo de aprovação são apenas aquelas que afetem o documento de requisitos
- Pequenas mudanças podem ser aceitas e feitas pelos desenvolvedores sem burocracia
Mudanças à arquitetura são indicados pelos desenvolvedores e aprovadas ou não pelo Board de Mudança