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 de experiência 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, testes e tarefas de DevOps (contabilizando 16
horas-semanais).

O desenvolvimento do projeto SPB exigiu experiência avançada, 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, além de 
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é em outros países, o que levou muito 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
servidores públicos do 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. O projeto
tinha muitos perfis 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êniores (residentes no Brasil) trabalharia presencialmente 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 organizarem 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. É importante salientar sobre a alta rotatividade da equipe e do \textit{coach}, pois durante o projeto
muitos alunos mudaram de equipe para tentar ter diferentes experiências em
diversas áreas/tecnologias, além daqueles alunos que naturalmente foram se formando.

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
incentivou os demais alunos a terem o mesmo compartamento do \textit{coach}
mesmo sem serem. Por fim, os desenvolvedores sêniores trabalharam diretamente
com os alunos, e isso foi importante para dar ao graduando a oportunidade de
interagir com profissionais experientes em sua área, além de manter o conhecimento no projeto compartilhado entre as equipes.

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 os 
professores. O primeiro era um engenheiro de software recentemente graduado, egresso, e que queria continuar trabalhando no projeto; esses últimos
eram professores que orquestraram todas as interações entre todos os membros do
projeto, inclusive do MP. 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
tornou-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êniores 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 tinha 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 eram
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 que utilizamos métodos ágeis e software
livre. Essa dissonância nos causou um ruído de comunicação com o MP. Foi
especialmente difícil convencê-los a aceitar a ideia de escopo aberto e
desenvolvimento ágil. Entretanto, depois de meses de trabalho e na medida em que os resultados foram se concretizando, em especial a entrega e implantação frequente de releases, a resistência foi gradualmente diminuindo.

Definimos níveis de granularidade das reuniões para evitar gerar demasiada
sobrecarga para os membros das equipes, em especial para os alunos. Tínhamos reuniões de caráter estratégico, com periodicidade mensal, e
reuniões planejamento e revisão de sprints a cada 15 dias. Na reunião estratégica,
geralmente, eram definidas as prioridades estratégicas do MP, e com isso o conjunto de funcionalidades importantes para atender àquelas prioridades estratégicas. Normalmente, os professores, os \textit{coaches} de cada equipe, os
\textit{meta-coaches} e alguns analistas do MP
participavam dessa reunião. Em geral, discutíamos o que a equipe já produziu
desde nossa última reunião e priorizámos 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 passar por essa experiência durante o
projeto).

Depois dos encontros estratégicos com os principais atores envolvidos do
MP, tínhamos um turno de planejamento com todas as equipes juntas. Nessa
parte, cada equipe trabalhava junto para converter a representação dos requisitos em ``Épicos'' da ``release'' em desenvolvimento,  em requisitos 
menores (histórias de usuário). 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 sprint/ciclo de desenvolvimento
(com os pequenos passos dos problemas mapeados). Para manter o MP 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 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} tevw uma página na wiki com a compilação da reunião
estratégica e o mapeamento 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 envolvidos do MP uma rastreabilidade completa do alinhamento estratégico do negócio, a uma visão de alto nível de cada funcionalidade (requisito/\'epico), a uma visão de grão menor dos requisitos(história de usuário) até o código-fonte.