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 \textit{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 \textit{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 iteração/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} teve 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/épico), a uma visão de grão
menor dos requisitos(história de usuário) até o código-fonte.