Muitos acham que ser ágil é não planejar. Decidir escrever uma série de artigos que voltam ao básico da gestão ágil. Uma abordagem independente de metodologia, onde tentarei explicar o porque de algumas práticas. Neste artigo, falarei sobre o planejamento inicial, deste ponto de vista.
Há alguns meses atrás, escrevi sobre como iniciamos projetos ágeis na Fratech. Agora neste artigo, venho descrever o porque fazemos desta maneira.
Planejamento Inicial
Projetos Ágeis tem um período de planejamento inicial. Claro que conta com algumas diferenças em relação ao modelo tradicional.
A primeira grande diferença é que o planejamento inicial demora alguns dias, uma semana ou duas no máximo. Esse é o tempo necessário para contextualizar todos os envolvidos e definir o objetivo comum do projeto. Comparado aos meses de levantamento de requisitos e preparação de documentos e diagramas do modelo waterfall, esse é um tempo bem pequeno.
A segunda grande diferença é que os documentos resultantes do planejamento não são muito importantes. Servem mais como um guia, mas alguns até dizem que podem ser descartados. O fato é que acreditamos que o ato de planejar é muito mais importante valioso do que o plano em si. Isso ressalta a importância de todos os envolvidos no projeto participarem ativamente do planejamento.
É nesta fase que se definem os objetivos, metas, declaração de visão, plataforma tecnológica, restrições tecnológicas e padrões a serem seguidos. Em outras palavras, é nesta fase que se definem as diretrizes técnicas e de negócio do projeto. Aqui, define-se também a equipe e o papel de cada um dentro do projeto.
Para que conseguir realizar um bom planejamento. O planejamento gera contexto e permite que as pessoas envolvidas tomem conhecimento do que deve ser feito e quando deve ser feito. É fundamental para que todos possam ser pró-ativos e caminhe na mesma direção, além de permitir que todos saibam quando estão chegando perto do objetivo. Mas para que isso aconteça, é fundamental que todos participem do planejamento, pois somente através da participação é que existe o comprometimento. É impossível alguém se comprometer a buscar um objetivo se ele não tiver participado da definição deste objetivo.
Devido a natureza dinâmica dos projetos de desenvolvimento de software, faz-se necessário um plano flexível e abrangente. Como veremos no capítulo sobre requisitos, os projetos estão em constante mudança e, cabe a nós, criarmos um plano que permita a mudança constante. Por isso, não deve especificar detalhadamente o resultado do projeto, mas deve se limitar a descrever como o projeto será realizado. O plano deve determinar os papéis de cada um dentro do projeto, deve determinar como serão levantados os requisitos e quais as subfases do projeto.
Como todos participam desse planejamento, o comprometimento em relação ao que foi definido neste momento será muito grande. Todo este planejamento não deve demorar muito mais do que 2 semanas, dependendo do tamanho do projeto e dos recursos disponíveis.
Declaração de Visão
É bom que se determine os objetivos e metas do projeto, de forma que todos saibam, em alto nível, qual o resultado esperado do projeto. É importante determinar restrições de ambiente e expectativas gerais. É bom descrever, em 1 ou 2 folhas A4, qual é o software desejado. Chamamos este documento de visão geral. Ele deve ser escrito pelo cliente que, dentro do limite de 1 ou 2 folhas, deve descrever de forma abrangente, as partes mais importantes do software.
Também é interessante criar um modelo inicial do fluxo das informações dentro do sistema. Nós o chamamos de fluxo de negócio, que deve mostrar as principais operações de negócio realizadas pelo usuário do sistema, quando operando o mesmo.
Tudo isso serve para guiar a equipe e o cliente ao longo do desenvolvimento.
Estimativa Inicial
O cliente também deve listar algumas das funcionalidades que ele espera ter no software, sem o compromisso de limitar o escopo, mas apenas para garantir que ele não esqueça o que deve ser implementado. Essas funcionalidades compõem uma lista conhecida como Backlog e podem ser ordenadas por prioridade, tamanho ou complexidade das funcionalidades.
O backlog pode ser utilizado para criar uma estimativa inicial de esforço e complexidade para o projeto. Essa estimativa serve como parâmetro para definir viabilidade, custo estimado e pode até mesmo ajudar no contrato, porém é de extrema importância lembrar que são apenas estimativas e que, apesar de aproximadas, não são os números reais.
