Software Público Brasileiro

\section{Processo e organização do desenvolvimento}
\label{sec:process}

A nossa equipe de desenvolvimento era composta por profissionais com diferentes
níveis e habilidades, sendo a maioria deles estudantes de graduação de
engenharia de software (a partir do 4º semestre de curso). Uma vez que os
alunos não podiam dedicar muitas horas por semana ao projeto, eles sempre
tiveram a flexibilidade para negociar seus horários de trabalho durante o
semestre, a fim de não prejudicar a sua formação. Sua rotina de trabalho diária
no projeto incluiu programação e tarefas de DevOps (contabilizando 16
horas-semanais).

O desenvolvimento do projeto SPB exigiu uma vasta experiência, que os alunos de
graduação geralmente ainda não têm. Por essa razão, alguns desenvolvedores
sênior se juntaram ao projeto para ajudar com as questões mais difíceis e
transferir conhecimento aos alunos. Sua principal tarefa era fornecer soluções
para problemas complexos. Como esses profissionais são muito hábeis e o projeto
não poderia financiar um trabalho de tempo integral, eles trabalharam
parcialmente no projeto (20 horas-semanais). Além disso, eles viviam em estados
diferentes espalhados pelo Brasil, ou até outros países, o que levou muita da
comunicação a ser on-line.

Em resumo, nosso processo de trabalho foi baseado em práticas de
desenvolvimento de software livre e colaborativo. O processo de desenvolvimento
foi definido com base na adaptação de diferentes práticas ágeis e de software
livre, destacando o alto grau de automação resultante das práticas de DevOps.
Assim, o processo de trabalho foi executado de forma cadenciada e contínua.

Finalmente, o último grupo de participantes desse projeto foi composto por
funcionários do Ministério
do Planejamento, Desenvolvimento e Gestão (MP). Todas as decisões do projeto,
validações e definições de escopo foram feitas com eles. Dessa forma,
desenvolvemos produtos de software de forma incremental, com lançamentos
alinhados aos objetivos estratégicos do negócio. Como se pode ver, o projeto
tinha muitos tipos diferentes de \textit{stakeholders} que tinham de ser
organizados e sincronizados.

\subsection{Organização da equipe}

Aproximadamente 70\% das equipes de desenvolvimento foram compostas por
estudantes de engenharia de software da UnB e que trabalharam fisicamente no
mesmo laboratório. Cada aluno tinha seu próprio horário baseado em suas aulas,
o que complicava a implementação da programação em pares. Os desenvolvedores
sênior tentavam sincronizar sua agenda com os alunos em sua sub-equipe. Para
lidar com esse ambiente, tivemos algumas regras básicas que guiaram a
organização do projeto:

\begin{enumerate}
\item As aulas têm alta prioridade para estudantes de graduação;
\item Trabalhe em pares sempre que possível (local com os demais estudantes ou
      remotamente com um sênior).
\item Deve haver uma manhã ou uma tarde por semana quando \emph{todos} deverem
      estar juntos fisicamente no laboratório (exceto, é claro, os membros da
      equipe remota, mas que estarão on-line).
\item A cada 2 ou 3 meses, os desenvolvedores sêniors (residentes no Brasil)
      voaria e trabalharia ao lado dos alunos por uma semana.
\end{enumerate}

Com as regras acima, dividimos todo o projeto em quatro equipes diferentes:
Colab, Noosfero, Design e DevOps. Cada equipe tinha um líder (\textit{coach})
responsável por reduzir o problema de comunicação com as outras equipes e
ajudar os membros a se organizar da melhor maneira para todos (sempre
respeitando seu tempo de trabalho). O \textit{coach} sempre foi um dos alunos
que trabalhava como desenvolvedor na equipe com o dever extra de registar as
tarefas atuais desenvolvidas na iteração (\textit{sprint}) e com a
responsabilidade de conversar com outras equipes. Uma coisa importante a
observar é a mutabilidade da equipe e do \textit{coach}, pois durante o projeto
muitos alunos mudaram de equipes para tentar ter diferentes experiências em
diversas áreas. 

Uma característica das equipes foi a presença de (pelo menos) um sênior por
equipe. Isso era essencial, porque as decisões difíceis e os problemas
complexos, geralmente, foram resolvidos ao consultá-los. Essa dinâmica
incentivamos aos demais alunos a terem o mesmo compartamento do \textit{coach}
mesmo sem serem. Por fim, os desenvolvedores sêniors trabalharam diretamente
com os alunos, e isso foi importante para dar ao graduando a oportunidade de
interagir com profissionais experientes em sua área e manter o conhecimento
fluindo no projeto.

Por fim, tivemos ainda dois últimos elementos da organização da equipe que
foram essenciais para a harmonia do projeto: o \textit{meta-coach} e
professores. O primeiro era um engenheiro de software recentemente graduado
(nossos ex-alunos) e que queria continuar trabalhando no projeto; estes últimos
eram professores que orquestraram todas as interações entre todos os membros do
projeto, inclusive do governo federal. O \textit{meta-coach} normalmente
trabalhava em uma equipe específica e tinha a tarefa extra de conhecer o estado
atual de todas as equipes. Os professores e \textit{meta-coach} trabalharam
juntos para reduzir o problema de comunicação entre todas as equipes (o que
tornava-se mais complexo conforme a evolução do volume de trabalho). Por
último, todas as tarefas burocráticas, como a elaboração de relatórios sobre o
progresso do projeto para o Ministério, foi tratada pelos professores, mas com
o envolvimento de toda a equipe.

\subsection{Comunicação e gestão das tarefas}

Nossa equipe tinha muitas pessoas trabalhando em conjunto, e a maioria dos
sêniors trabalhavam remotamente. Além disso, tentamos manter nosso trabalho
completamente transparente para o governo brasileiro e os cidadãos interessados
em seguir o projeto. Para lidar com esses casos, usamos um conjunto de
ferramentas de comunicação e outras para gerenciar o projeto.

Quando um aluno tinha que trabalhar em par com um sênior, normalmente, eles
usavam o hangout do Google para a comunicação e eles compartilhavam uma sessão
de terminal GNU/Linux com o tmate, o que lhes permitia compartilhar o mesmo
editor, com ambos digitando e vendo a tela. Para perguntas e discussão rápida,
usamos o IRC. Para a notificação geral, usamos as listas de discussão.

Para a gestão do projeto utilizávamos o próprio Portal SPB; Primeiro para
validá-lo por nós mesmos, e também porque ele tem todas as ferramentas
necessárias para o nosso projeto. Basicamente, criamos uma página Wiki, no
Gitlab integrado ao SPB, com um mapeamento entre as visões estratégica, tática
e operacional. Do ponto de vista prático, um ``milestone'' no GitLab era uma
``História de Usuário" (funcionalidade) e um ou mais ``issues'' no GitLab era
as tarefas para o desenvolvimento da funcionalidade em questão. Com essa
abordagem, conseguimos dois objetivos importantes: manter toda a gestão o mais
próximo possível do código-fonte e acompanhar cada funcionalidade desenvolvida
durante o projeto (uma vez que nós mesmo nos tornamos usuários reais da
plataforma).

\subsection{Acompanhamento e gerenciamento de projeto de alto nível}

O governo brasileiro costuma trabalhar com o desenvolvimento de software de uma
forma mais tradicional, diferentemente de nós com métodos ágeis e software
livre. Essa dissonância nos causou um ruído de comunicação com o governo. Foi
especialmente difícil convencê-los a aceitar a ideia de escopo aberto e
desenvolvimento ágil. Entretanto, depois de meses de trabalho e mostrando
resultados, eles deixaram de resistir aos métodos empíricos.

Definimos algum nível de granularidade de reunião para evitar gerar demasiada
sobrecarga para os desenvolvedores. Tínhamos reuniões estratégica mensal e
reuniões planejamento e revisão a cada 15 dias. Na reunião estratégica,
geralmente, definimos as prioridades e as funcionalidades importantes para o
governo. Normalmente, os professores, os \textit{coaches} de cada equipe, os
\textit{meta-coaches} e alguns analistas do Ministério do Planejamento
participavam dessa reunião. Em geral, discutíamos o que a equipe já produziu
desde nossa última reunião e definíamos as funcionalidades para a próxima
versão. Observe que apenas parte da equipe participava dessas reuniões
estratégicas, mas todos os estudantes interessados estavam convidados a
participar (pois muitos estudantes quiseram essa experiência durante o
projeto).

Depois dos encontros estratégicos com os principais atores envolvidos do
governo, tínhamos um turno de planejamento com todas as equipes juntas. Nessa
parte, cada equipe trabalhava junto para converter os requisitos em partes
menores (histórias de usuário) que era representadas como ``Épicos'' da
``release'' em desenvolvimento. Cada \textit{coach} era responsável pela
condução do planejamento, e depois a equipe toda a registrava na página wiki do
projeto (wiki fornecido pelo Gitlab do SPB). Baseado nos ``épicos'', a cada 15
dias a equipe gerava um o planejamento da iteração/ciclo de desenvolvimento
(com os pequenos passos dos problemas mapeados). Para manter o governo
brasileiro sempre atualizado, convidávamos-os a trabalhar conosco para validar
as funcionalidades em desenvolvimento. Para isso, tínhamos uma reunião a cada
15 dia. E para manter nosso fluxo de gestão de tarefas, usando a própria
plataforma do SPB, especialmente o Gitlab, tínhamos:

\begin{enumerate}

\item Temos uma organização com muitos repositórios para cada ferramenta
integrada e sub-sistema;

\item Cada \textit{milestone} foi usado para registrar uma história de usuário;

\item Cada \textit{release} tem uma página no wiki com a compilação da reunião
estratégica e o mapeamento sistemático das funcionalidades planejadas;

\item Para cada \textit{milestone} (história de usuário) tem um conjunto de
\textit{issues} (tarefas) específicas, que também são mapeadas na  wiki da
\textit{release}, indicando qual dupla de desenvolvedores está trabalhando na
\textit{issue} em questão.

\end{enumerate}

Em suma, esse fluxo de trabalho proporcionou a nós e aos participantes pelo
governo brasileiro uma rastreabilidade completa e uma visão de alto nível de
cada funcionalidade (requisito) até para o nível mais baixo (código).