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.

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