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 to not harm their classes and coursework. 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, a few senior
developers have joined to 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, in other words, they worked as developers. 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 online.

In short, our work process was based on open and collaborative software
development practices. The development process was defined based on the
adaptation of different agile and FOSS communities practices, highlighting the
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
formally working for the Brazilian government, in the 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
developed software product incrementally, with releases aligned to business
strategic objectives. As one can see, the project had many different
kinds of stakeholders that had to be organized and synchronized.

\subsection{Team organization}

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

\begin{enumerate}
  \item Classes have high priority for undergraduate students;
  \item Work in pairs whenever possible (locally or remotely).
  \item There must be one morning or afternoon per week when
    \emph{everyone} should be together physically in the laboratory
    (except of course the remote team members).
  \item Every 3 to 4 months, the senior developers would fly in and 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. Each team had one
coach responsible for reducing the communication problem with the other
teams and help the members to organize themselves in the best way for
everyone (always respecting their work time). The coach was one of the
students working in some of the teams with the extra duty of registering
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 referred to them. This kept having to take
complicated technical decisions from the coach tole, what encouraged
students to be coaches. Lastly, the senior developers worked directly
with the students, and this was important to give the undergraduate the
opportunity to interact with a savvy professional in his area and to
keep the knowledge flowing 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 paperwork tasks, such as reporting on the
project progress to the Ministry, was handled by the professors.

\subsection{Communication and management}

Our team had many people working 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 following 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
handouts with tmate tool, IRC, and mailing lists. When one student had to
work in pair with a senior, normally, they used Google hangout for
communication and they shared a terminal session with tmate which allow
them to share the same terminal, with both typing and seeing the screen.
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. In a practical point of view, 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 possible to to the source code, and tracking every
feature developed during the project.

\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 validating
meeting with MP (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 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 the developers, but
all the students interested to participate were allowed to join (many
students wanted this experience during the project).

After the strategical meeting with Brazilian government agents, we had a
planning turn 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 after
that record 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 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 those 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 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 us and the Brazilian government agents
full traceability from a high level view of each feature to the lowest
level (code).