[oss-2018] discussion

Melissa Wen
1 parent 138cfa55
Showing 2 changed files with 73 additions and 85 deletions Show diff stats
oss2018/content/04-results.tex
oss2018/content/05-discussion.tex
@@ -53,7 +53,7 @@ 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''}.
-Migrating to the SPB platform also \textbf{easied coordinator monitoring
+Migrating to the SPB platform also \textbf{easied monitoring of
 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
@@ -96,7 +96,7 @@ In the second phase of the project, these analysts came to represent the
 government directly in the dialogues with the academia, and they started to
 visit bi-weekly the university's laboratory. One of the analysts believes that
 \textit{``at this point, the communication started to change.''} The new dynamic
-reduced communication misunderstandings and unified the two sides, as reported
+\textit{reduced communication misunderstandings and unified the two sides}, as reported
 by another interviewee: \textit{``It was very positive. We liked to go there and
 to interact with the team. I think it brought more unity, more integration into
 the project''}. {73\%} of the interns consider positive the direct
@@ -137,8 +137,7 @@ qualified, the code had quality and the project was well executed. So in
 practice, our difficulty interpreting the technical details did not impact the
 releases planning.''}.
-\subsection{Split development team into priority work fronts with IT
-professionals}
+\subsection{Divide the development team into priority fronts, and for each one, hire at least one specialist from the IT market}
 The development team was divided into four work areas defined by the main
 demands of the project: user eXperience, devOps, integration of systems, and
@@ -148,7 +147,7 @@ selected due to their experience in the open source systems and tools used in
 the project or in visual works for large scale organizations.
 The participation of senior developers in the project contributed to
-\textit{conciliate the development processes of institutions and make better
+\textbf{conciliate the development processes of each institutions and make better
 technical decisions}, as quoted in one of the answers to the senior developers
 questionnaire: \textit{``I think my main contribution was to balance the
 relations between the MPOG staff and the UnB team''}. {63\%} of senior
@@ -164,8 +163,8 @@ their previous experiences. In contrast, {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.
-Senior developers were also responsible for improving the management and technical
-knowledge of the interns about practices from industry and open source projects.
+Senior developers were also responsible for \textbf{improving the management and technical
+knowledge} of the interns about practices from industry and open source projects.
 {91\%} of the interns believe that working with professionals was important for
 learning. Working with senior developers was important during the project for all
 of them. {75\%} of senior developers believe that 'Working in pairs with a
@@ -192,3 +191,5 @@ contact a coach to clarify some requirements or to understand some feature. We
 interact more with coaches because they are more accessible than senior
 developers. Sometimes the coach would take our question to the senior
 developer''}.
+
+%TODO: talvez encaixar aqui a troca de papéis
-\section{Discussion and Final Remarks}
+\section{Discussion}
 \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 designed also surveys and conducted them
-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
-nine practices from three key decisions taken, and these practices brought 11
-benefits, as summarized in the Table \ref{practices-table}.
+The results presented in this paper reveal a set of nine best management
+practices from the agile and free software development methods that were
+successfully employed in a government-academia collaboration to develop an
+e-government platform. Around a case study, we analyzed unsystematic decisions
+made by the coordinators in a 30-month collaborative project and identified
+three macro-decisions that harmonized the differences of the management
+processes of each organization. We evidenced from data collection, and responses
+of the members of both sides to the questionnaires and interviews, the benefits
+obtained through the adoption of this empirical method. As a result of our
+research, macro-decisions, practices, and benefits are listed and related in the
+table \cite{practices-table}
 \begin{table}[]
 \centering
@@ -17,45 +19,45 @@ benefits, as summarized in the Table \ref{practices-table}.
 \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} 
-&
+\textbf{Use of system under development to develop the system itself} &
 \begin{itemize}
-\item Migration of project management and communication into 
-the platform under development using its integrated software components Gitlab 
-and Mailman 
+\item The features and tools of the platform under development supported the project management and communication activities.
 \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;
+\item Communicating with transparency and efficiency; 
+\item Monitoring of activities;
+\item More interactions between developers and public servants;
+\item Confidence in the code;
+\item Organic documentation;
 \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
+\item Government staff, academic coordinators, senior developers and team coaches biweekly meet at the UnB's lab, academia headquarters, for sprint planning and review.
+\item Conduct on the platform the technical discussions between government staff and the development team.
+\item Involve government board directors only in strategic planning of the project.
+\item Build a continuous delivery pipeline with steps involving both sides.
 \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;
+\item Reducing communication misunderstanding;
+\item Better meeting expectations of both sides;
+\item Improvement of decision-making process;
+\item Overcoming the government bias regarding low productivity of collaborative projects with academia;
+\item Synchronizing the execution pace of activities;
+\item Improve 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} &
+\textbf{Divide the development team into priority fronts, and for each one, hire at least one specialist from the IT market} &
 \begin{itemize}
-\item The development was divided into four fronts (DevOps / UX / Noosfero / Colab) with a certain self-organization of tasks.
+\item The coordinators separated the development team into priority work areas considering the main demands of the project.
 \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.
+\item Define among the interns the leadership roles: a coach for each front, and a meta-coach of the entire development team.
+\item Each team has certain self-organization, being guided by one intern-coach and at least one senior developer.
 \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;
+\item Conciliating the development processes of each institution, taking better technical decisions;
+\item Improving the management and technical knowledge;
+\item Self-organizing and gaining autonomy in the management of their tasks;
 \end{itemize}\\ \hline
 \end{tabular}%
 }
@@ -63,49 +65,34 @@ bureaucratic issues involve board directors. \item Continuous Delivery
 \label{practices-table}
 \end{table}
-Regarding our first question,\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 practices
-covering aspects from communication of the project to the delivery process of
-developed code, as presented in the second column of the Table
-\ref{practices-table} (Practice Explanation).
+The results of this current work corroborate the lessons learned in our previous
+work on studying the SPB project case \cite{meirelles2017spb}. Evidence from the
+data collected and responses of questionnaires and interviews reinforces what
+has been reported by the academic coordination of the project, adding point of
+views of government and other roles involved on the academic side. In this work,
+the new evidence also reveals conflicts not overcame during the project and that
+should be evaluated for future software development partnerships between
+government and academia. Among the problems faced, the government staff had
+difficult to understand how collaboration works, that is, they took a time to
+realize that the project was not a client-executor relationship and that both
+organizations were at the same hierarchical level in the work plan. They also
+felt the project needed a decision-maker role to resolve impasses between
+organizations. Finally, they said that at times they felt intimidated by the
+coordinator in some attempts to communicate directly with the UnB interns.
-The results of the surveys revealed the benefits of implementing each set of
-practices for the case study, answering our second question: \textit{How do
-open source development practices benefit the process of 74 developing an
-e-government platform in a government-academia collaboration?}. The third
-column of the Table \ref{practices-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.
+\textit{Limitations}. We consider that the results found in this work are valid
+for the project studied, but may not have the same effectiveness for another
+government-academia collaboration. However, based on the benefits presented in
+the Table \ref{practices-table}, we believe that the abovementioned practices
+and other OSS practices should be evaluated and used in contexts with plurality
+and diversity of stakeholders, such as collaborations. 
-The fruits of this current work 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 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 a client-executor
-relationship, but a partnership and both organizations were in 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.
-
-As threats to validity of this work, we can point 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 after project completion, depending on the
-memory of the interviewees about 30 months of the project.
-
-Finally, the project investigated in this paper was also an important experience
-in teaching open source ecosystems dynamics and agile methodologies applied a
-real-work development project. A large amount of data and testimonies were
-collected in this work related to the educational context. As future work, we
-intend to analyze this information to propose improvements in the teaching of
-information technology for undergraduates. 
+As threats to the validity of this work, we point out the lack of
+communication records and lack of treceability of the management data referring
+to the first phase of the project. We also consider as a threat the hiatus
+between the completion of the project and the conduction of interviews and
+questionnaires with the former team members, since we rely on the memory of the
+interviewees to rescue the events. Also, the new work experiences of the
+respondents after the project and their current working mindset may also modify
+their interpretation of the topics addressed in the questionnaire and
+consequently their responses.