\section{Results}
\label{sec:results}

%TODO: Talvez esse paragráfo tem que está no Research Design
%%
The case study was analyzed and divided into two phases according to the project
management model. In the second phase (after one year of execution), several
practices have been applied to harmonize the cultural and organizational
divergences of the institutions involved.
%%
At the end of the project, an empirical
model of management and development process was created by aligning experiences
from the FLOSS universe, academic research and bureaucracies needed by the
government. In this section, we present by context the practices adopted in this
second phase and show the benefits generated by its deployment, as summarized 
in the Table \ref{practices-table}.

%% TODO: explicar a estrutura e cada campo da tabela

\begin{table}[h!]
\resizebox{\textwidth}{!}{%
\begin{tabular}{cc}
\hline
\textbf{Decision} & \textbf{Practice Explanation} & \textbf{Benefits} \\ \hline
\textbf{Project management and communication on the developing platform itself} 
&
\begin{itemize}
\item Migration of project management and communication into 
the platform under development using its integrated software components Gitlab 
and Mailman 
\end{itemize} &
\begin{itemize}
\item Trusting developed code; 
\item Communicating with transparency and efficiency;
\item Easier monitoring and increasing interactions between development team and public servants;
\item Producting organically documentation and records;
\end{itemize} \\ \hline

\textbf{Bring together government staff and development team} &
\begin{itemize} 
\item Biweekly gov staff, senior developers and coaches met to planning and 
review sprint at the UnB headquarters. \item Most of features under development 
were discussed on Gitlab Issue Tracker. \item Only strategic decisions or 
bureaucratic issues involve board directors. \item Continuous Delivery
\end{itemize} &
\begin{itemize} 
\item Reducing communication misunderstood and better meeting expectations of both sides;
\item Overcoming the government bias regarding low productivity of collaboration with academia;
\item Aligning both activities execution pace;
\item Improving the translation of the process from one side to the other;
\end{itemize} \\ \hline

\textbf{Split development team into priority work fronts with IT market specialists} &
\begin{itemize}
\item The development was divided into four fronts (DevOps / UX / Noosfero / Colab) with a certain self-organization of tasks.
\item IT market professionals with recognized experience on each front were hired to work in person or remotely.
\item For each front, there was at least one senior developer and the role of coach.
\item The meta-coach role was also defined to coordinate tasks between teams.
\end{itemize} & 
\begin{itemize}
\item Helping to reconciliate development processes and decision-making;
\item Creating support-points for students, senior developers, and gov staff;
\item Transfering of knowledge from industry and FLOSS community to both academia and government;
\end{itemize}\\ \hline
\end{tabularx}
\caption{Empirical SPB management method and its benefits}
\label{practices-table}
\end{tabular}%}
\end{table}

\subsection{Project management and communication on the developing platform
itself}

After nine months of project activities, the first version of new SPB Portal was
released. From this point, we started to migrate the management and 
communication interactions to the platform under development. In short, Wiki 
feature was used for meeting logging, defining goals, sprint planning, and 
documentation of deployment processes and administration resources guide. Issue 
tracker was used for discussing requirements, monitoring the features under 
development, registering changes, and validating functionalities delivered. Finally, the 
whole team used Mailing list to defining schedules of meetings and deliveries 
and also to collaborative definition of requirements.

Our surveys reports Mailing list (100\%) and Issue Tracker (62.5\%) as the main means
of interaction between senior developers and undergraduates. Developers and MPOG
staff also interacted mostly via Mailing List (87.5\%) and Issue tracker (50\%).
According to research findings, this movement made \textbf{communication more
transparent and efficient}. A MPOG IT analyst said that the
\textit{``Communicating well goes far beyond the speed, it is someone being able
to communicate to everyone everything that is happening in the project. We did
not use emails. We use more mailing list and avoid e-mails. It helped a lot
because everything was public and did not pollute our mailbox. You wanted to
know something, could go there and look at what was happening''}.

Migrating to SPB platform also provided an \textbf{easier monitoring and 
increase interactions between development team and public servants by 
coordinators}. As shown by collected data, in the last 15 months of the project,
775 issues and 4,658 issue comments was registered in the main repository
(without considering the software repositories that integrated the platform)
within the SPB platform. The issues have 59 different authors (8 from MPOG
staff), and commented by 64 different users (9 form MPOG staff and users).
Considering issues with higher level of interaction those that have 10 or more
comments, in a set of 84 issues, MPOG staff authored 36 issues (which represents
about 43\% of these most active issues). A MPOG analyst highlighted that
\textit{``there was a lot of evolution, a lot of communication via Gitlab''}.
This interaction also led MPOG staff to \textbf{trust developed code}:
\textit{``Everything was validated, we tested the features and the project was
developed inside the platform, so that the feature was validated in the
development of the software itself. From the moment we installed it, and
began to use it for development, this validation was constant. We felt confident
in the features''}.

One of the main concerns of traditional approach is meticulous documentation of 
the software designed and the development steps. With this aforementioned
decision, we could meet this government demand without bureaucracies and changes
in our development process, \textbf{producting organically documentation and
records} in the platform itself, as one of the MPOG response evidenced:
\textit{``For me, it was a lot of learning. There is a lot of things documented
in the e-mails and also in the portal itself. At any moment we can go there and
see how it worked, how someone did something. We can recover those good points''}.

\subsection{Bringing together government staff and development team}

The MPOG analysts observed communication noise in the dialogue between them and
their superiors and in the dialogues with the development team that were
intermediated by the superiors. They said that direct dialogue with the
development team and biweekly visits to the university's lab  \textbf{reduce
communication misunderstood}: \textit{``At this point, the communication started to
change.. started to improve''}. According to another interviewee, this new
dynamic unified the two sides: \textit{``I believe it was very positive, we also liked to
go there, to interact with the team. I think it brought more unity, more
integration into the project''}. The participation of the MPOG staff was also
considered positive by {72.9\%} of the undegraduates and to {81.1\%} of them
think the presence of MPOG staff in sprint ceremonies was important for the
development. In addition, to \textbf{better meet expectations of both sides}
regarding the requirements developed, {75.6\%} of students believe that writing
the requirements together with the MPOG staff was very important. According to
one of them \textit{``Joint planning and timely meetings were very important for
understanding the needs of MPOG''}.

An imported consequence of this direct government-academia interaction in
laboratory was empathy, as reported by one of the interviewees \textit{``You
know people in person and it makes such a big difference because it causes
empathy.  You already know who that person is, it's not just a name''}. This
subjectively helped to \textbf{align both activities execution pace},
\textit{``When we went there, we knew the people and we realized that, on our
side, we also felt more encouraged to validate faster and give faster feedback
to the teams [..] We gave this feedback fast and they also gave quick feedback
for any our questions''}. The teams' synchronization was reinforced with the
implementation of a Continuous Delivery pipeline. The benefits of this approach
were presented in our previous work \cite{siqueira2018cd} and corroborate these research
results. To 81.1\% of students and 75\% of senior developers, deploying new
versions of the SPB portal in production was a motivator during the project.

One of the MPOG analyst interviewed also noted these releases also helped to 
\textbf{overcome the government bias regarding low productivity of collaborative
projects with academia}: \textit{``At first, the government staff had a bias that
universities do not deliver. We overcame that bias in the course of the project.
We deliver a lot and with quality. Today, I think if we had paid the same amount
for a company, it would not have done what was delivered and with the quality
that was delivered with the price that was paid''}. Additionally, the deployment
in production of each new version also \textbf{improve the translation of the
process from one side to the other}, as mentioned by MPOG analyst \textit{``We had an
overview at the strategic level. When we went down to the technical level, plan
the release every four months was difficult. But in the end, I think this has
not been a problem. A project you are delivering, the results are going to
production, the code is quality, the team is qualified/capable and the project
is doing well, it does not impact as much in practice''}.

\subsection{Split development team into priority work fronts with IT market
specialists}

Four teams were formed to dedicated to the main development demands of the
portal: UX, DevOps, System-of-Systems, and Social Networking. External
developers with vast experience in the SPB platform software components and
professionals with experience in front-end and UX were hired. These
professionals also contributed to disseminate practices adopted in the industry
and in the free software communities to other project members. {87.5\%} of
seniors agreed with our project development process. For 62.5\% this process
has a good similarity to their previous experiences. Their experience
\textbf{helped to reconcile development processes and decision making}, as
stated by one of the respondent developers \textit{``I think my main
contribution was to have balanced the relations between the MPOG staff and the
UnB team''}. {62.5\%} of senior developers believe they have collaborated in the
relationship between the management and development processes of the two
institutions and {62.5\%} asserted that helped MPOG staff to more clearly
express their requests. {62.5\%} of them did not understand MPOG's project
management process and {50\%} believe their project productivity was affected
by MPOG's project management process. For the government, these professionals
gave credibility to the development \textit{``You had the reviewers, who were
the original developers of the software, that gave you confidence and
confidence in the code''}.

In addition, with these professionals was possible to \textbf{transferred
knowledge of industry and free software to government and academia}. Working
with senior developers was important for all interns during the
project. {91\%} of them also believe that working with professionals was
important for learning. {75\%} of senior developers believe that 'Working in
pairs with a senior' and 62.5\% that 'Participate in joint review tasks' were
the tasks with the involvement of them that most contributed to the evolution
of students in the project. And, in guiding a students, {75\%} believe that
this knowledge was widespread among the others in the team. This acquisition
of knowledge was also noted by the government, which stated \textit{``On the side of
UnB, what we perceived was that the project was very big leap when the
original software developers were hired in the case of Noosfero and Colab,
because they had a guide on how to develop things in the best way and were
able to solve non-trivial problems and quickly''}.

The fronts also gained more autonomy to manage their activities. The role
of ``meta-coach'' was defined among the students, to coordinate the interactions
between teams and coach to coordinate each front. Coaches have become a \textbf{point
of reference for the development process}. {89.1\%} of students said that the
presence of the coach was essential to the running of sprint, and for {87.5\%}
of senior developers coaches was essential for their interaction with the team.
MPOG analysts saw coaches as facilitators for their activities and for
communication with the development team. One of the interviewees said \textit{``I
interacted more with the project coordinator and team coaches''}, \textit{``The reason
for this was that the coaches were more likely to meet the requirements, to
ask questions about requirements, to understand some features. interaction with
leaders than with senior developers. Sometimes the coaches brought the question
to the senior developers''}.
