Software Público Brasileiro

\section{Discussion and Final Remarks}
\label{sec:discussion}

In this paper, we examined an empirical model used in a government-academia project, which successfully harmonized differences in their usual development approaches.
We mapped the key decisions to improve the communication and the development process as a whole. We also designed surveys that were conducted separately for three groups
of participants: government analysts, IT market professionals and interns. Finally,
we collected \textit{post-mortem} public data on project management from the
platform developed. The results revealed that nine practices were developed from three
key decisions taken, and these practices brought 11 benefits, as summarized in the Table \ref{practices-table}.

\begin{table}[]
\centering
\resizebox{\textwidth}{!}{%
\begin{tabular}{ | m{4cm} m{10cm} m{10cm} | } 
\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{tabular}%
}
\caption{Empirical SPB management method and its benefits}
\label{practices-table}
\end{table}

\textbf{RQ1.}\textit{What practices based on open source development experiences would
help to combine teams with different management processes in a
government-academia collaboration project?}

We mapped nine practices to reconcile the differences between government and academia in a collaborative project. These practices cover aspects from communication of the project to the delivery process of developed code, as presented in the second column of the table above (Practice Explanation).

\textbf{RQ2.}\textit{How do open source development practices benefit the process of
developing an e-government platform in a government-academia collaboration?}

The results of the surveys revealed the benefits of implementing each set of practices for the case study. The third column of the table (Benefits) shows how the practices adopted impacted on the relationship between members from both sides, on the understanding of project development process, and on the appropriation of the developed platform.

The new evidences corroborate with the lessons learned and reported in our previous work \cite{meirelles2017spb}, adding the point of view of the government and the academia in diverse performed levels. Moreover, our results suggest that many open source practices could be replicated in different contexts in which the diversity and plurality of its stakeholders need to be leveled and reconciled.

This current work also exposed issues that were not overcome during the
project and need to be evaluated for future government-academia collaborations for software development. In the interviews, MPOG analysts reported some difficulties during the project in understanding the idea of collaboration. They said they needed time to realize that the project was not client-executor relationship, but a partnership, and both organizations were ate the same hierarchical level in the work plane. They lacked the role of decision maker in times of deadlock and in the requirements definition. Additionally, the analysts reported they sometimes felt coerced by coordinators when they tried to communicate directly with the interns.

We consider limitations of this work to be the lack of traceable qualitative and quantitative records related to the first phase of the project (about the organization prior to the adoption of the practices mentioned above) and the application of surveys only after project completion, depending on the good memory of the interviewees about 30 months of the project.

As future work, we intend to apply in another government-academia partnership
project the practices evidenced from this case study, and conduct
qualitative and quantitative research throughout its execution. We also intend to
analyze the effectiveness in adopting open source practices to
align the demands and expectations of a G-A collaboration.