Ferramentas para Gestão do Processo de Desenvolvimento

Este artigo descreve a maneira como utilizamos algumas ferramentas, todas Open Source, para a gestão do desenvolvimento de software, na Q10 Informática, e como isto se encaixa ao nosso processo de referência.

Nosso desenvolvimento ainda não estão totalmente padronizado, assim como não temos uma gestão de projetos formal, mas estamos trabalhando ambas as questões. Dada a cultura da organização e a realidade do mercado, optamos por utilizar métodos ágeis, tanto para o desenvolvimento quanto para a gestão.

As ferramentas escolhidas para a Gestão do Desenvolvimento já estavam instituídas na Empresa, há algum tempo, e são amplamente conhecidas:
  • Bugzilla, um software para acompanhamento de demandas (Issue Tracking);
  • MediaWiki, para a publicação colaborativa de textos;
  • phpBB (Fórum), para discussões interativas;
  • SVN para gestão de configurações de fontes;
O SVN é relativamente novo na empresa e substitui o CVS, utilizado anteriormente. A migração foi motivada, principalmente, pela facilidade oferecida pelo SVN para renomear e mover arquivos dentro dos projetos, viabiliza refactorings mais agressivos e frequentes. Esta flexibilidade, que não é provida pelo CVS.

Bugzilla

Nosso primeiro esforço foi o de generalizar a utilização do Bugzilla para além do registro de problemas, centralizando nesta ferramenta toda a gestão de demandas para o desenvolvimento. Optamos por fazer o upgrade para o Bugzilla 3.2, em função, principalmente, das facilidades de configuração do Workflow, criação de campos personalizados e as buscas públicas, compartilhadas entre os usuários, além de outras melhorias em relação à versão 2.2 (ver aqui a lista completa).

As etapas da implantação do Bugzilla foram as seguintes:

1. Taxonomia das Classificações de produtos e componentes

Conduzimos discussões abertas entre todos os interessados até chegarmos a uma estrutura para as Classificações/Produtos/Componentes que fosse compreensível para todos. O desafio, aqui, foi estabelecer uma classificação que fizesse sentido para o negócio (principal motivador) mas que ainda permitisse alguma correlação com os componentes técnicos.

Nossa arquitetura atual nem sempre favorece isto e as vezes o mesmo componente técnico implementa mais de um componente de negócio. A princípio optamos pela visão de negócio, mas encontrar os nomes corretos, para não confundir com os componentes de implementação, foi um desafio.

2. Definição do Workflow

Optamos pela utilização de 2 workflows diferentes, um para produtos distribuidos para clientes e outro para os componentes que rodam nos nossos servidores.

Todos os bugzillas abertos para produtos distribuidos para clientes são abertos em um status de unconfirmed e devem ser reproduzidos pela equipe de testes. Com isto estimulamos todos os usuárioa a abrir ocorrências ou solicitações de funcionalidades diretamente na ferramenta, mas conseguimos filtrar estas solicitações antes de irem para a mesa de um desenvolvedor.

Os produtos também utilizam um estágio de validação do workflow, que permite que o desenvolvimento esteja concluido e validado mesmo antes de coloca-lo em produção. Esta etapa de validação é bastante útil para controlarmos o backlog real do desenvolvimento. A estrutura do workflow ficou assim:
  • UNCONFIRMED: utilizado apenas para produtos distribuidos. Nos demais, assumimos que a pessoa que abre o Bug tem evidências reais da sua repetitibilidade;
  • NEW: próximo estágio das demandas sobre produtos e estágio inicial da demais. Nesta etapa, uma demanda pode estar assinalada para a gerência de desenvolvimento;
  • ASSIGNED: o desenvolvedor já está indicado, mas ainda não está trabalhando;
  • WORKING: o desenvolvedor está trabalhando no problema;
  • RESOLVED: desenvolvomento liberou para Homologação;
  • VERIFIED: demanda homologada. Está aguardando uma janela de GMUD ou está sendo agrupada para participar de um relase. Nem todas as demandas passam por este estado. Em alguns casos, elas podem ir diretamente para a produção;
  • CLOSED: demanda em produção;
  • REOPEN: o pesadelo do desenvolvimento... sob o ponto de vista do workflow, isto é o mesmo que WORKING.
3. Especificando e desenvolvendo

Centralizamos no Bugzilla toda a especificação das tarefas, semelhante a uma User Story do XP (eXtream Programming). Estas especificações são refinadas durante todo o ciclo de aceitação da demanda, desenvolvimento e testes.

Os documentos e protótipos são anexados à demanda, assim como todo o esclarecimento de dúvidas, que é feito através dos comentários no Bugzilla, que funcionam como registro do que foi decidido.

O encerramento do Bug é feito com o registro de um build onde a demanda foi atendida. Isto gera um requisito para o sistema de gerenciamento de versões, para que a numeração dos builds seja crescente e que o usuário possa saber que uma demanda atendida no build 1.2.3.23 estará presente no build 1.2.4.27. Isto é fácil de falar mas pode sem complicado, quando temos branches nos projetos e muito desenvolvimento concorrente.

4. Utilizando, utilizando, utilizando...

Definido o processo, o importante é exercitar. Nossa Empresa, felizmente, tem uma cultura de informalidade que favorece e estimula a comunicação entre entre as pessoas e não precisamos de muito esforço para convencer a todos das melhorias que vieram com o processo.

Mas não optamos, também, por publicar normas muito rígidas. Publicamos apenas um pequeno guia de utilização na nossa Wiki.

Wikimedia

Para a Wikimedia, nossa política foi:

1. Registrar todo o conhecimento, sem preocupação da indexação

Para encontrar uma informação, quase sempre é melhor se utilizar a busca, já que manter índices consistentes para as páginas é sempre muito difícil. O importante é registrar tudo o que fazemos.
  1. Históricos dos desbravamentos: toda vez que algém precisa configurar um novo sistema ou escolher uma biblioteca para utilzizar em um sistema, esta pessoa é responsável por registrar esta história, para uso posterior de toda a equipe. Nosso colega Emerson, cunhou a expressão Fábrica de Salsichas para os desbravamentos maiores e para os procedimentos de preparação da infra-estrutura;
  2. Procedimentos operacionais: registrados sempre que são definidos;
  3. Instalação e configuração dos sistemas desenvolvidos;
  4. Procedimentos para compilação e montagem dos ambientes;
  5. Roadmap das versões: este é um tipo de publicação que precede o registro de uma demanda no Bugzilla, sempre que existe a necessidade de juntarmos uma visão maior para o desenvolvimento de uma nova versão ou um novo produto.
  6. Arquitetura dos sistemas: uma página que descreve a estrutura geral do sistema e a tecnologia empregada no seu desenvolvimento;
Os itens 5 e 6 exigem um pouco mais de formalismo, mas estamos avançando incrementalmente, na base do "registra o conhecimento e melhora quando for possível".

Fórum (phpBB)

Antes de atingirmos uma arquitetura final para um sistema ou versão, utilizamos bastante o Fórum (phpBB), como uma forma de conduzirmos discussões abertas que ficam registradas para consultas futuras.

Utilizamos o fórum para bate-papos genéricos na empresa e na área de desenvolvimento, mas como ferramenta de gestão, ele é empregado em duas atividades:
  1. Discussões sobre soluções tecnológicas para resolver uma arquitetura, tais como linguagens ou bibliotecas;
  2. Controle das Reuniões de Gestão: semanalmente fazemos uma reunião de gestão, para acompanhamento de projetos e padronização dos processos do desenvolvimento. Utilizamos o Fórum para registrar as pautas e atas das reuniões, anexando na própria ferramenta documentos de apoio ou relatórios que se façam necessários.
Comments