\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.

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 Ministery of Planning,
Development, and Management (MP is the Brazilian acronyms). All the project
decisions, validations, and scope definitions were made by them. In this way we
developed software product increments, releases,  aligned with business
strategic objectives. As can be seen, the project had many kinds of profiles
that had to be organized and synchronized.

\subsection{Teams organizations}

Approximately 70\% of the development teams were composed of software
engineering undergraduate students from UnB 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 high 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 MP, 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 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=.75\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 (we always had to negotiate next steps with
them). Normally the professors, the coach of each team, the meta-coach, and
some employees of the MP 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 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 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 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 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 Brazilian government agents a
full traceability from high view of the feature to the low view (code). This
provided to them a way to  validate 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.

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