Download as
Browse Code »

Commit ca6a25b5c531dbad35f7ac2198e2210393a73cb0

Authored by Melissa Wen
1 parent 138cfa55
Exists in master and in 2 other branches oss_2018, rework_case_study

[oss-2018] discussion

Showing 2 changed files with 73 additions and 85 deletions   Show diff stats
oss2018/content/04-results.tex
  Diff comments   View file @ca6a25b
... ... @@ -53,7 +53,7 @@ us a lot because everything was public and did not pollute our email box. So,
53 53 when you wanted to know something, you could access the SPB list to see
54 54 everything that was happening''}.
55 55  
56   -Migrating to the SPB platform also \textbf{easied coordinator monitoring
  56 +Migrating to the SPB platform also \textbf{easied monitoring of
57 57 activities and increased interactions between developers and public servants}.
58 58 The data collected from the repository evidence the frequent use of the platform
59 59 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
96 96 government directly in the dialogues with the academia, and they started to
97 97 visit bi-weekly the university's laboratory. One of the analysts believes that
98 98 \textit{``at this point, the communication started to change.''} The new dynamic
99   -reduced communication misunderstandings and unified the two sides, as reported
  99 +\textit{reduced communication misunderstandings and unified the two sides}, as reported
100 100 by another interviewee: \textit{``It was very positive. We liked to go there and
101 101 to interact with the team. I think it brought more unity, more integration into
102 102 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
137 137 practice, our difficulty interpreting the technical details did not impact the
138 138 releases planning.''}.
139 139  
140   -\subsection{Split development team into priority work fronts with IT
141   -professionals}
  140 +\subsection{Divide the development team into priority fronts, and for each one, hire at least one specialist from the IT market}
142 141  
143 142 The development team was divided into four work areas defined by the main
144 143 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
148 147 the project or in visual works for large scale organizations.
149 148  
150 149 The participation of senior developers in the project contributed to
151   -\textit{conciliate the development processes of institutions and make better
  150 +\textbf{conciliate the development processes of each institutions and make better
152 151 technical decisions}, as quoted in one of the answers to the senior developers
153 152 questionnaire: \textit{``I think my main contribution was to balance the
154 153 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
164 163 MPOG's project management process and {50\%} believe their project productivity
165 164 was affected by MPOG's project management process.
166 165  
167   -Senior developers were also responsible for improving the management and technical
168   -knowledge of the interns about practices from industry and open source projects.
  166 +Senior developers were also responsible for \textbf{improving the management and technical
  167 +knowledge} of the interns about practices from industry and open source projects.
169 168 {91\%} of the interns believe that working with professionals was important for
170 169 learning. Working with senior developers was important during the project for all
171 170 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
192 191 interact more with coaches because they are more accessible than senior
193 192 developers. Sometimes the coach would take our question to the senior
194 193 developer''}.
  194 +
  195 +%TODO: talvez encaixar aqui a troca de papéis
... ...
oss2018/content/05-discussion.tex
  Diff comments   View file @ca6a25b
1   -\section{Discussion and Final Remarks}
  1 +\section{Discussion}
2 2 \label{sec:discussion}
3 3  
4   -In this paper, we examined an empirical model used in a government-academia
5   -project, which successfully harmonized differences in their usual development
6   -approaches. We mapped the key decisions to improve the communication and the
7   -development process as a whole. We designed also surveys and conducted them
8   -separately for three groups of participants: government analysts, IT market
9   -professionals, and interns. Finally, we collected \textit{post-mortem} public
10   -data on project management from the platform developed. The results revealed
11   -nine practices from three key decisions taken, and these practices brought 11
12   -benefits, as summarized in the Table \ref{practices-table}.
  4 +The results presented in this paper reveal a set of nine best management
  5 +practices from the agile and free software development methods that were
  6 +successfully employed in a government-academia collaboration to develop an
  7 +e-government platform. Around a case study, we analyzed unsystematic decisions
  8 +made by the coordinators in a 30-month collaborative project and identified
  9 +three macro-decisions that harmonized the differences of the management
  10 +processes of each organization. We evidenced from data collection, and responses
  11 +of the members of both sides to the questionnaires and interviews, the benefits
  12 +obtained through the adoption of this empirical method. As a result of our
  13 +research, macro-decisions, practices, and benefits are listed and related in the
  14 +table \cite{practices-table}
13 15  
14 16 \begin{table}[]
15 17 \centering
... ... @@ -17,45 +19,45 @@ benefits, as summarized in the Table \ref{practices-table}.
17 19 \begin{tabular}{ | m{4cm} m{10cm} m{10cm} | }
18 20 \hline
19 21 \textbf{Decision} & \textbf{Practice Explanation} & \textbf{Benefits} \\ \hline
20   -\textbf{Project management and communication on the developing platform itself}
21   -&
  22 +\textbf{Use of system under development to develop the system itself} &
22 23 \begin{itemize}
23   -\item Migration of project management and communication into
24   -the platform under development using its integrated software components Gitlab
25   -and Mailman
  24 +\item The features and tools of the platform under development supported the project management and communication activities.
26 25 \end{itemize} &
27 26 \begin{itemize}
28   -\item Trusting developed code;
29   -\item Communicating with transparency and efficiency;
30   -\item Easier monitoring and increasing interactions between development team and public servants;
31   -\item Producting organically documentation and records;
  27 +\item Communicating with transparency and efficiency;
  28 +\item Monitoring of activities;
  29 +\item More interactions between developers and public servants;
  30 +\item Confidence in the code;
  31 +\item Organic documentation;
32 32 \end{itemize} \\ \hline
33 33  
34 34 \textbf{Bring together government staff and development team} &
35 35 \begin{itemize}
36   -\item Biweekly gov staff, senior developers and coaches met to planning and
37   -review sprint at the UnB headquarters. \item Most of features under development
38   -were discussed on Gitlab Issue Tracker. \item Only strategic decisions or
39   -bureaucratic issues involve board directors. \item Continuous Delivery
  36 +\item Government staff, academic coordinators, senior developers and team coaches biweekly meet at the UnB's lab, academia headquarters, for sprint planning and review.
  37 +\item Conduct on the platform the technical discussions between government staff and the development team.
  38 +\item Involve government board directors only in strategic planning of the project.
  39 +\item Build a continuous delivery pipeline with steps involving both sides.
40 40 \end{itemize} &
41 41 \begin{itemize}
42   -\item Reducing communication misunderstood and better meeting expectations of both sides;
43   -\item Overcoming the government bias regarding low productivity of collaboration with academia;
44   -\item Aligning both activities execution pace;
45   -\item Improving the translation of the process from one side to the other;
  42 +\item Reducing communication misunderstanding;
  43 +\item Better meeting expectations of both sides;
  44 +\item Improvement of decision-making process;
  45 +\item Overcoming the government bias regarding low productivity of collaborative projects with academia;
  46 +\item Synchronizing the execution pace of activities;
  47 +\item Improve the translation of the process from one side to the other;
46 48 \end{itemize} \\ \hline
47 49  
48   -\textbf{Split development team into priority work fronts with IT market specialists} &
  50 +\textbf{Divide the development team into priority fronts, and for each one, hire at least one specialist from the IT market} &
49 51 \begin{itemize}
50   -\item The development was divided into four fronts (DevOps / UX / Noosfero / Colab) with a certain self-organization of tasks.
  52 +\item The coordinators separated the development team into priority work areas considering the main demands of the project.
51 53 \item IT market professionals with recognized experience on each front were hired to work in person or remotely.
52   -\item For each front, there was at least one senior developer and the role of coach.
53   -\item The meta-coach role was also defined to coordinate tasks between teams.
  54 +\item Define among the interns the leadership roles: a coach for each front, and a meta-coach of the entire development team.
  55 +\item Each team has certain self-organization, being guided by one intern-coach and at least one senior developer.
54 56 \end{itemize} &
55 57 \begin{itemize}
56   -\item Helping to reconciliate development processes and decision-making;
57   -\item Creating support-points for students, senior developers, and gov staff;
58   -\item Transfering of knowledge from industry and FLOSS community to both academia and government;
  58 +\item Conciliating the development processes of each institution, taking better technical decisions;
  59 +\item Improving the management and technical knowledge;
  60 +\item Self-organizing and gaining autonomy in the management of their tasks;
59 61 \end{itemize}\\ \hline
60 62 \end{tabular}%
61 63 }
... ... @@ -63,49 +65,34 @@ bureaucratic issues involve board directors. \item Continuous Delivery
63 65 \label{practices-table}
64 66 \end{table}
65 67  
66   -Regarding our first question,\textit{What practices based on open source
67   -development experiences would help to combine teams with different management
68   -processes in a government-academia collaboration project?}, we mapped practices
69   -covering aspects from communication of the project to the delivery process of
70   -developed code, as presented in the second column of the Table
71   -\ref{practices-table} (Practice Explanation).
  68 +The results of this current work corroborate the lessons learned in our previous
  69 +work on studying the SPB project case \cite{meirelles2017spb}. Evidence from the
  70 +data collected and responses of questionnaires and interviews reinforces what
  71 +has been reported by the academic coordination of the project, adding point of
  72 +views of government and other roles involved on the academic side. In this work,
  73 +the new evidence also reveals conflicts not overcame during the project and that
  74 +should be evaluated for future software development partnerships between
  75 +government and academia. Among the problems faced, the government staff had
  76 +difficult to understand how collaboration works, that is, they took a time to
  77 +realize that the project was not a client-executor relationship and that both
  78 +organizations were at the same hierarchical level in the work plan. They also
  79 +felt the project needed a decision-maker role to resolve impasses between
  80 +organizations. Finally, they said that at times they felt intimidated by the
  81 +coordinator in some attempts to communicate directly with the UnB interns.
72 82  
73   -The results of the surveys revealed the benefits of implementing each set of
74   -practices for the case study, answering our second question: \textit{How do
75   -open source development practices benefit the process of 74 developing an
76   -e-government platform in a government-academia collaboration?}. The third
77   -column of the Table \ref{practices-table} (Benefits) shows how the practices
78   -adopted impacted on the relationship between members from both sides, on the
79   -understanding of project development process, and on the appropriation of the
80   -developed platform.
  83 +\textit{Limitations}. We consider that the results found in this work are valid
  84 +for the project studied, but may not have the same effectiveness for another
  85 +government-academia collaboration. However, based on the benefits presented in
  86 +the Table \ref{practices-table}, we believe that the abovementioned practices
  87 +and other OSS practices should be evaluated and used in contexts with plurality
  88 +and diversity of stakeholders, such as collaborations.
81 89  
82   -The fruits of this current work corroborate with the lessons learned and reported in our
83   -previous work \cite{meirelles2017spb}, adding the point of view of the
84   -government and the academia in diverse performed levels. Moreover, our results
85   -suggest that many open source practices could be replicated in different
86   -contexts in which the diversity and plurality of its stakeholders need to be
87   -leveled and reconciled.
88   -
89   -This work also exposed issues that were not overcome during the project
90   -and need to be evaluated for future government-academia collaborations for
91   -software development. In the interviews, MPOG analysts reported some
92   -difficulties during the project in understanding the idea of collaboration.
93   -They said they needed time to realize that the project was not a client-executor
94   -relationship, but a partnership and both organizations were in the same
95   -hierarchical level in the work plane. They lacked the role of decision maker in
96   -times of deadlock and in the requirements definition. Additionally, the
97   -analysts reported they sometimes felt coerced by coordinators when they tried
98   -to communicate directly with the interns.
99   -
100   -As threats to validity of this work, we can point the lack of traceable
101   -qualitative and quantitative records related to the first phase of the project
102   -(about the organization prior to the adoption of the practices mentioned above)
103   -and the application of surveys after project completion, depending on the
104   -memory of the interviewees about 30 months of the project.
105   -
106   -Finally, the project investigated in this paper was also an important experience
107   -in teaching open source ecosystems dynamics and agile methodologies applied a
108   -real-work development project. A large amount of data and testimonies were
109   -collected in this work related to the educational context. As future work, we
110   -intend to analyze this information to propose improvements in the teaching of
111   -information technology for undergraduates.
  90 +As threats to the validity of this work, we point out the lack of
  91 +communication records and lack of treceability of the management data referring
  92 +to the first phase of the project. We also consider as a threat the hiatus
  93 +between the completion of the project and the conduction of interviews and
  94 +questionnaires with the former team members, since we rely on the memory of the
  95 +interviewees to rescue the events. Also, the new work experiences of the
  96 +respondents after the project and their current working mindset may also modify
  97 +their interpretation of the topics addressed in the questionnaire and
  98 +consequently their responses.
... ...