Na última semana na Fratech, iniciamos um projeto grande de desenvolvimento. O projeto consiste em um ERP voltado para a indústria de manufatura, principalmente para empresas de pequeno porte. Como em todo projeto de software, o começo é sempre a parte mais arriscada, neste não seria diferente.

É no começo dos projetos que devemos decidir qual o caminho a ser tomado, qual a tecnologia a ser aplicada e principalmente, o que deve ser feito. O processo que utilizamos para responder a essas questões, podem definir o sucesso ou o fracasso de um projeto. Isso traz ainda mais responsabilidade (e problemas) no começo do projeto. Neste caso temos duas opções: Postergar esses problemas para um momento onde estejamos mais maduros em relação ao projeto (mera ilusão), ou enfrentá-los imediatamente.

Por esse e outros motivos, decidimos que a abordagem ágil seria a melhor opção neste caso. Usamos várias práticas ágeis que vimos funcionar efetivamente em outros projetos, para compor um processo customizado. Nesse contexto, iniciamos nosso projeto com os seguintes passos:

• Definir o objetivo do projeto:

  Nesta etapa devemos identificar os principais aspectos do sistema de forma abrangente e sucinta. Descrever o objetivo deste sistema, para que tenhamos em mente onde queremos chegar. Isso serve para mantermos o foco e a simplicidade do sistema e determinar o resultado que deve ser atingido.

• Definição das áreas e operações do sistema:

  Após definir o objetivo é interessante relacionar algumas das principais operações do sistema (não mais do que 10), com o objetivo de enteder qual a complexidade do sistema. É necessário ser abrangente para que se consiga uma visão geral de das partes do sistema. Uma vez que se tenha esta lista, deve-se organizá-la, agrupando os itens por áreas que compõe o sistema. Não estou falando de módulos, mas de conjuntos de operações de um único módulo do sistema. Dica: Comece pelas partes mais complexas, buscando assim estimular o conceito de early pain.

  Para isso, utilizamos o conceito de FBS (Feature Breakdown Structure) do FDD (Feature Driven Development), que nada mais é do que listar as funcionalidades de seus sistema, organizadas por áreas. Você pode variar os níveis e a estrutura de uma FBS, porém ela é muito útil para construir seu backlog.

  Exemplo de FBS usando templates de Mind Map Modeling (M3):



• Construção de protótipos de telas:

  Com as principais funcionalidades do sistema em mãos, é hora de criar alguns protótipos de tela e assim vivenciar a dificuldade na hora de implementar. Esses protótipos também são simples e abrangentes, de forma que pode-se utilizar wireframes para representar as telas. O objetivo deste passo não é saber como serão as telas, mas sim validar as descrições das funcionalidades descritas no item anterior. Lembre-se que neste momento você deve ter por volta de 10 funcionalidades apenas, o que mantém este processo simples e rápido.

  

Este processo completo não tomou mais do uma semana no projeto em questão. Isso contece porque o objetivo não é detalhar tudo o que precisa ser feito no sistema, afinal não acreditamos no Big Requirements Up Front, mas sim no modelo de design incremental adotado nas metodologias ágeis. Os passos seguintes a estes, fazem parte do desenvolvimento do software em si e incluem tarefas de modelagem, levantamento de requisitos continuamente e escrita de testes e código.

A partir deste ponto o backlog é composto pelos itens iniciais da FBS, conforme reuniões de priorização com o cliente. O time já está pronto para começar o desenvolvimento do software e após 2 semanas, entregar software funcionando. Conforme o time se aprofunda no desenvolvimento, deve atualizar a FBS com protótipos e descrições das funcionalidades, seguindo o conceito de design evolutivo. Pode-se também listar os critérios de aceitação ou casos de teste para cada funcionalidade. A FBS alimenta o backlog e, ao final do projeto, ela servirá para mensurar a quantidade de funcionalidades implementadas e como estão divididas. Como um mapa da aplicação.

Para mais informações sobre como desenvolver o escopo de sua aplicação veja este post do Manoel Pimentel.