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, they worked
part-time on the project. In addition, they lived in either different Brazilian
states or other countries, 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.
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 2 to 3 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. Thus, 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 Brazilian Government, 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. Initially, our decision to use the Wiki was empirical, but
later such decision was 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 the Government, 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.

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

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
the Brazilian Government (the former once in month and the latter biweekly), a
release planning with the entire team (one per month), and finally a sprint
planning (biweekly).  Figure \ref{fig:meeting} is a diagram that represents our
meeting organization.

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 Federal Government 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 Government 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. With this epic, biweekly 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
biweekly. Basically, this was our work flow. We always kept everything
extremely open to the Government (our way of working, and the one often used by
FLOSS projects) and to the team.

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

\begin{enumerate}
  \item Project repository: we have one organization with many repositories;
  \item Wiki: each release has one Wiki page with the compilation of the
    strategical meeting;
  \item Milestones: each milestone was used to register a user story (feature);
  \item Issues: each sprint planning generated issues, which we associated to
    the related milestone (feature as user story) 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 (source
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 centralizing all the work in the SPB Portal was the best option
for our case.