Software Público Brasileiro

\section{Development Organization and Process}
\label{sec:process}

The SPB team was composed of a variety of professionals with different levels and skills, where most of them were undergraduate students with major in software engineering (from 4th semester or upper). 
Since the students could not dedicate many hours per week to the project, they always had the flexibility to negotiate their work schedule during the semester in order not to cause any damage to their grades. Their daily work routine in the project included programming and devops tasks. 

The development of SPB project required a vast experience and background that usually undergraduate students do not have yet. For this reason, some senior developers have joined to the project to help with hard issues and to transfer knowledge to the students. Their main task was to provide solutions for complex problems, in other words, they worked as a developer. As these professionals are very skillful and the project could not fund a full time work for them, some of them worked partially on the project. In addition, they lived in a different states spread around Brazil which led much of the communication to be made via Internet.

Finally, the last group of actors of this project was composed of employees
formally working for the Brazilian Government, in the Ministery of Planning,
development and Management (MPOG is the Brazilian acronyms). All the project
decisions, validations, and scope definitions were made by them. As can be
seen, the project had many kinds of profiles that had to be organized and
synchronized.

\subsection{Teams organizations}

More than X\% of the teams was composed of undergraduate students and they
worked physically in the same laboratory in the opposite of the senior. Each
student had their own scheduler based on their class, it made complicated to
implement pair programming. Also, they had a different area of interests. To
cope with those diversity, we had two basic rules which guided the project
organization:

\begin{enumerate}
  \item Classes have to be the top priority for undergraduate students;
  \item Always work in pair (locally or remotely).
\end{enumerate}

With the aforementioned rules we divided all the project into four different
teams: Colab, Noosfero, Design, and DevOps. Each team had one coach responsible
for reducing the communication problem with the other teams and help the
members to organize itself in the best way for everyone (always respecting the
work time). The coach, was a normal student working in some of the teams with
the extra duty of register the current tasks developed in the sprint and with
the responsibility to talk with other teams. One important thing to notice is
the mutability of the team and the coach, during the project many students
changed between the teams to try different areas.

One characteristic of the teams was the presence of (at least) one senior per
team. This was essential, because hard decisions and complex problems were
usually addressed to them, this relieved the coach duty to take a complicated
technical decisions and encouraged students to be a coach. Lastly, the senior
had to respect a rule number two and work with students, this was important to
gave the undergraduate the opportunity to interact with a savvy professional in
his area and keeping the knowledge flow in the project.

Finally, we had to add two last elements of the team organization, that was
essential for the project harmony: the meta-coach and professors. The former
was a software engineer recently graduated and which wanted to keep working on
the project, the latter were professors that orchestrated all the interactions
between all members of the project. The meta-coach usually worked in one
specific team and had the extra task of knowing the current status of all
teams. Professors and meta-coaches worked together to reduce the communication
problem between all the teams. Lastly, all the bureaucracy tasks was
centralized in the professors.

\subsection{Meetings}

Brazilian government used to work with software development in a very
traditional way, frequently they claim on documents and does not focus on what
really matter (running software). This way of thinking caused to us a
communication noise with MPOG, because they constantly tried to leverage on our
work style. It was especially hard to convince them to accept the idea of open
scope and agile development, but after months of labor and showing results they
stopped resisting.

We defined some level of meeting granularity to avoid to generate overheads to
the developers. We had a strategical and validating meeting with MPOG (the
former once in a month and the latter each 15th day), release plaining with the
entire team (one per month), and finally a sprint planning (one each 15th day).
Figure \ref{fig:meeting} is a diagram that represents our meeting organization.

\begin{figure}[hbt]
  \centering
    \includegraphics[width=\linewidth]{figures/meeting_flows.png}
  \caption{Meetings cycles}
  \label{fig:meeting}
\end{figure}

In the strategical meeting we usually defined the priorities and new features
with MPOG (we always had to negotiate next steps with them). Normally the
professors, the coach of each team, the meta-coach, and some employees of MPOG
join in this meeting. We usually discussed what the team already produced since
our last meeting, and we establish the new features for the next release.
Notice that just part of the team join in this meeting to avoid generating
unnecessary overhead to the developers, but all the students interested to
participate was allowed to join (many students wanted this experience during
the project).

After the strategical meeting with MPOG, we had a planning turn with all teams
together. In this part, each team worked together to convert the MPOG wishes
into small parts which was represented by the epics of the release. Each coach
was responsible for conducting the planning, and after that register it on the
project wiki (the wiki provided by Gitlab). With this epic, each 14th day the
team have generated their sprint scheduler (with small achievements mapped in
issues).

To keep MPOG always updated, we invited them to work with us to validate the
new features in progress. Normally we had a meeting each 15th day. Basically,
this was our work flow, we always kept everything extremely open to the MPOG
(our way of work and open source projects) and to the team.

To keep the track of all of those things we used the SPB, especially the
Gitlab. Basically, we had:

\begin{enumerate}
  \item Project repository: We have one organization with many repositories
  \item Milestones: Each milestone is used to register a release
  \item Wiki: Each release has one page on wiki with the compilation of
    strategical meeting
  \item Issues: Each sprint planning generated issues, which we associated to
    the specific milestone and updated the wiki with the issue number related
    with them. Finally each developer assigned the issue to itself.
\end{enumerate}

Notice that this workflow gave to us and to the MPOG a full traceability from
high view of the feature to the low view (code). This provided a way to MPOG
validated all worked done and proof the concept that work with open source
project can give a proper view to them check.

\subsection{Tools for communication and management}

Our team had many people worked together, and most of the seniors worked in a
different city remotely. Also, we tried to keep our work completely clear to
the Brazilian government and citizens interested in follow the project. To
handle those cases, we used a set of tools to communication and other to manage
the project.

For communication between member in different places, we used: google-talk with
tmate, IRC, and mailing-list. When one student had to work in pair with a
senior, normally, they used google-hangout for communication and they shared a
session with tmate which allow them to share the same terminal. For questions
and fast discussion, we used IRC. For general notification, we used the
mailing-list.

For managing the project we used the SPB Portal to validate it by ourselves and
because it had all the required tools. We basically create one wiki page per
release in Gitlab, one milestone per sprint, and one or more issues for address
one user history. With this approach we achieve two important things: keep all
the management close to the source code and tracked every feature developed by
the project.

% Ainda falta adicionar a parte da visita dos seniors e o turno sagrado