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 of
software engineering. Since students could
not dedicate many hours per week to the project, they had the
flexibility to negotiate their work schedule during the semester in
order to not harm their classes and coursework. Their work routine
in the project included programming and DevOps tasks.

The project required a vast experience and background that
usually undergraduate students do not have. For this reason, a few senior
developers have joined the project to help with the more difficult issues
and to transfer knowledge to the students. Their main task was to provide
solutions for complex problems, working as developers. As
these professionals are very skillful and the project could not fund full-time
work for all of them, some of them worked partially on the project. In addition,
they lived in different Brazilian states, which led much of the
communication to be online.

In short, our work process was based on open and collaborative software
development practices. The development process was based on the
adaptation of different agile and FLOSS communities practices, with a
high degree of automation resulting from DevOps practices. Thus, the work
process was executed in a cadenced and continuous way.

Finally, the last group of actors of this project was composed of employees
of the Brazilian Ministry of Planning,
Development, and Management (MP is the Brazilian acronym). All the project
decisions, validations, and scope definitions were made by them. In this way, we
incrementally developed a software product with releases aligned to 
strategic business objectives. As one can see, the project had a wide range
of different stakeholders that had to be organized and synchronized.

\subsection{Team organization}

Approximately 70\% of the development team was composed of software
engineering undergraduate students from UnB and they worked physically
in the same laboratory. Each student had their own schedule based on
her classes, what complicates the implementation of pair programming.
The senior developers tried to synchronize their schedule with 
students schedules. To  cope with this scenario, we had a few
basic rules guiding the project organization:

\begin{enumerate}
  \item Classes have high priority for undergraduate students;
  \item Pairing whenever possible (locally or remotely);
  \item We had one morning or afternoon per week when
    \emph{everyone}, but the remote members, 
    should be together physically in the laboratory;
  \item Every 3 to 4 months the senior developers would travel to work
    alongside the students for a few days.
\end{enumerate}

With the aforementioned rules we divided all the project into four
different teams: Colab, Noosfero, Design, and DevOps. One student of each team was the
coach, responsible for reducing the communication problem with other
teams and helping the members to organize themselves in the best way for
everyone (always respecting their work time). The coach
had also the extra duty of registering
the current tasks developed in the sprint.
One important thing to notice is the mutability
of the team and the coach. During the project many students changed
their 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 referred to them. So, it was not the coach role
to deal with complicated technical decisions, what encouraged
students to be coaches. Lastly, the senior developers worked directly
with the students, and this was important to give to students the
opportunity to interact with a savvy professional in their areas and to
keep the knowledge flowing in the project.

Finally, we had to add two more elements to the team organization that
were essential for the project harmony: the meta-coach and professors.
The former was a software engineer recently graduated that 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 the
meta-coach worked together to reduce the communication problem among
teams. Lastly, all the paperwork tasks, such as reporting on the
project progress to the Ministry, was handled by professors.

\subsection{Communication and management}

Our team had many people working together, and most of the seniors worked in
different cities remotely. Also, we tried to keep our work completely clear to
the Brazilian government and citizens interested in following the project. To
handle these cases, we used a set of communication and management tools.

For communication between members in different places we used: video
conferencing with shared terminal tools, IRC, and mailing lists. For example,
when one student had to work in pair with a senior, normally, they used video
conferencing tool for talking and shared a terminal session (both typing and
seeing each other screen in real time). For questions and fast discussion, we used
IRC. For general notification, we used the mailing lists.

For managing the project we used the SPB Portal itself; first to validate it by
ourselves, and also because it had all the required tools. We basically created
one wiki page per release in the SPB Gitlab instance with a mapping between
strategical, tactical, and operational views. We had one
milestone per user history (feature) and one or more issues for addressing
each feature. With this approach we achieved two important goals: keeping all
the management as close as possible to the source code and tracking every
feature developed during the project. Our decision to
use the Wiki initially was empirical, but later reinforced by a research conducted
by Joseph Chao showing the advantage of using Wikis~\cite{chao2007student,
opensourcestyle}.

\subsection{High-level project management and reporting}

The Brazilian government used to work with software development in a
very traditional way. They would frequently focus on documents and not
on what was, in our opinion, what really matters: working software. This
dissonance caused us a communication noise with MP, because they would
often question 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 generating too
much overhead to the developers. We had a strategical and a validating
meeting with MP (the former once in a month and the latter each 15th
day), a release planning 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 the Brazilian government. Normally the professors, the
coach of each team, the meta-coach, and some employees of the MP would
participate in this meeting. We usually discussed what the team already
produced since our last meeting, and established the new features for
the next release.  Notice that just part of the team would join this
meeting to avoid generating unnecessary overhead to developers, but
all the students interested to participate were allowed to join, since many
students wanted this experience during the project.

After the strategical meeting with Brazilian government agents, we had a
planning phase with all teams together. In this part, each team worked together
to convert the MP wishes into smaller parts which were represented by the epics of
the release. Each coach was responsible for conducting the planning and 
recording it on the project wiki (the wiki provided by Gitlab). With this
epic, each 14th day the team have documented their sprint schedule (with small
achievements mapped to issues).

To keep the Brazilian government 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 MP (our way of working, and the one
often used by open source projects) and to the team.

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

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

Notice that this workflow gave us and the Brazilian government agents full
traceability from a high level view of each feature to the lowest level (code).
It is important to highlight that we converged to this workflow after many
experiments. For example, we used a tool named Redmine for organizing our tasks
during some sprints. However, this tool revealed to be inefficient for our case since
the government agents lost part of the project traceability. We realized that
centralize all the work in the SPB portal was the best option for our case.