Software Público Brasileiro

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

We divided the case study into two phases, according to the traceability of the
project management activities. We consider the first phase, between January
2014 and March 2015, as non-traceable. In this period, only UnB managed the
development activities. The inter-institutional monitoring of the project was
reduced to the definition of strategic goals in meetings between coordinators,
and the communication between government and academia was dispersed in private
channels, such as professional e-mails, personal meetings, and telephone calls.
Because of this, the quantitative data found for this period are inconclusive or
have little expressiveness, and we did not examine them.

The second phase, from April 2015 to the end of the project (June 2016), has a
more considerable wealth of data. Much of the management and communication
activities were recorded and published on online channels and tools. During
this period, several open source practices were applied to the development
process to harmonize the cultural and organizational divergences of the
institutions involved. At the end of the project, an empirical model of
communication and management was built using experiments in free software
ecosystems to cater to government bureaucracies.

In this section, we list the macro-decisions taken intuitively during the
project and the practices that made these decisions concrete. We use data
collected from the main repository to map best practices and, with the
respondents' answers, we analyzed how each decision benefited the project
collaboration.

\subsection{Use of system under development to develop the system itself}

The first version of the new SPB portal was released in production nine months
after the project beginning. Due to the platform features for software
development and social network, the UnB coordinators decided to use the system
under construction to develop the system itself. Gradually, in addition to
development activities, government and academia migrated the project management
and communication between teams to the portal environment. In short, the wiki
feature was used for logging meetings, defining goals, planning sprints,
documenting deployment procedures and user guides. The issue tracker was used
for discussing requirements, monitoring features under development, requesting
and recording changes, and validating the delivered funcionalities. Finally, the
mailing list was used by the entire team for collaboratively constructing
requirements, defining schedules, and scheduling meetings between institutions.

Our surveys report Mailing list (100\%) and Issue Tracker (62.5\%) as the main
means of interaction between senior developers and interns. Developers
and MPOG staff also interacted mostly via Mailing List (87.5\%) and Issue
tracker (50\%).  According to answers, this movement made the
\textbf{communication more transparent and efficient}. An MPOG analyst said
that \textit{``Communicating well goes far beyond the speed. It means enabling
someone to tell everyone about everything that is happening in the project. We
did not use emails, we use more mailing list and avoid emails. This usage helped
us a lot because everything was public and did not pollute our email box. So,
when you wanted to know something, you could access the SPB list to see
everything that was happening''}.

Migration to the SPB platform also \textbf{easied coordinator monitoring
activities and increased interactions between developers and public servants}.
The data collected from the repository evidence the frequent use of the platform
by the academic team and the government team. In the last 15 months of the
project, the main project issues were opened by 59 different authors, 8 of them
MPOG agents. These issues received comments from 64 distinct users, 9 of them
from MPOG. When we consider the issues with much interaction, those who had ten
comments or more, we realized that the government team also felt more
comfortable using the tool to interact directly with the development team. In a
set of 102 issues with much interaction, MPOG staff created 43 of them (this
represents 42\% of the most active issues). An 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 in developed code}: \textit{``Everything was
validated, we tested the features and we developed the project 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''}.

%Morri aqui (Melissa)

One of the main concerns of traditional approaches 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{Bring together government staff and development team}

The MPOG analysts observed communication noise in the dialogue between them and
their superiors and in dialogues with the development team,
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 undergraduates
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 the
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 the 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 professionals}

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''}.