Commit 17c59db25df385f477790a9480c017e0898fcd1e

Authored by Melissa Wen
1 parent f2771370

[oss-2018] more fixes and reinsert conclusion and subsections

oss2018/content/01-introduction.tex
... ... @@ -32,8 +32,7 @@ project modularity, the community of users, and fast response to problems are
32 32 just a few of the FLOSS ecosystem practices \cite{capiluppi, warsta}.
33 33 Individuals and interactions, working software, customer collaboration,
34 34 responding to change \cite{beck} are the values agile development. With this in
35   -mind, FLOSS and agile practices may improve the process management and the
36   -cooperation of distinct teams.
  35 +mind, FLOSS and agile practices may improve the cooperation of distinct teams.
37 36  
38 37 In this work, we investigate the empirical method developed during 30 months of a
39 38 government-academia project that helped to harmonize the differences between
... ...
oss2018/content/04-results.tex
... ... @@ -10,27 +10,26 @@ telephone calls. Therefore, the quantitative data found for this period
10 10 are not conclusive or have little expressiveness, and we do not examine them.
11 11  
12 12 The second phase, from April 2015 to the end of the project (June 2016), has
13   -meaningful data. Much of the management and communication
14   -activities were recorded and published on online channels and tools. During
15   -this period, several FLOSS practices and agile values were applied to the
16   -development process to harmonize the cultural and organizational divergences of
17   -the institutions involved. At the end of the project, an empirical approach to
18   -communication and management was built using the development leaders'
19   -experiences in FLOSS and agile projects to meet the government bureaucracies.
20   -
21   -\textit{\textbf{Use of the system under development to develop the system itself}}.
  13 +meaningful data. Much of the management and communication activities were
  14 +recorded and published on online channels and tools. During this period, the
  15 +development leaders' employed several FLOSS practices and agile values in the
  16 +development process. At the end of the project, the academic team had an
  17 +empirical management approach for meeting the government bureaucracies.
  18 +
  19 +\subsection{Use of the system under development to develop the system itself}
  20 +
22 21 Due to the platform features for software development and
23 22 social network, the development coordinators decided to use the platform under
24 23 construction to develop the system itself. Gradually, in addition to development
25 24 activities, government and academia migrated the project management and the
26   -communication between teams to the portal environment.
  25 +communication between teams to the portal environment.
  26 +
27 27 In short, the wiki feature was used for logging meetings, defining
28 28 goals, planning sprints, documenting deployment procedures and user guides. The
29 29 issue tracker was used for discussing requirements, monitoring features under
30 30 development, requesting and recording changes, and validating the delivered
31   -functionalities. Finally, the mailing list was used by the entire team for
32   -collaborative construction of requirements, defining schedules, and scheduling
33   -meetings between institutions.
  31 +functionalities. Finally, the mailing list was used for collaborative construction
  32 +of requirements, defining schedules, and scheduling meetings between institutions.
34 33  
35 34 Our surveys report Mailing list (100\%) and Issue Tracker (62.5\%) as the main
36 35 means of interaction between senior developers and interns. Developers and MPOG
... ... @@ -40,40 +39,40 @@ staff also interacted mostly via Mailing List (87.5\%) and Issue tracker
40 39 that \textit{``Communicating well goes far beyond the speed. It means enabling
41 40 someone to tell everyone about everything that is happening in the project. We
42 41 did not use emails, we use more mailing list and avoid emails. This usage
43   -helped us a lot because everything was public and did not pollute our email
44   -box. So, when you wanted to know something, you could access the SPB list to
45   -see everything that was happening.''}.
  42 +helped us considerably. Everything was public and did not pollute our email
  43 +box. So, when you wanted to know something, you could access the SPB list and
  44 +see everything''}.
46 45  
47 46 Migrating to the SPB platform also \textbf{easied monitoring of activities and
48 47 increased interactions between developers and public servants}. The data
49   -collected from the repository highlight the frequent use of the platform by the
50   -academic and the government teams. In the last 15 months of the project, the
51   -central repository issues were opened by 59 different authors, 8 of them MPOG
52   -agents. These issues received comments from 64 distinct users, 9 of them from
53   -MPOG. When we consider the issues with more interactions, those which had ten
  48 +collected from the repository highlight the frequent use of the platform by both
  49 +sides teams. In the last 15 months of the project, 59 different authors opened the
  50 +central repository issues, 8 of them were MPOG agents. These issues received comments
  51 +from 64 distinct users, 9 of them from MPOG. When we consider the issues with more interactions, those which had ten
54 52 comments or more, we notice that the government team also felt comfortable in
55 53 using the tool to interact directly with the development team. In a set of 102
56   -issues with more interactions, MPOG staff created 43 of them (this represents
57   -42\% of the most active issues). For the MPOG analysts, interaction via
  54 +active issues, MPOG staff created 43 of them (this represents 42\% of the most active issues).
  55 +
  56 +For the MPOG analysts, interaction via
58 57 repository improved communication. \textit{``There was a big evolution, we
59   -increased our communication via Gitlab.''}. Migrating to the platform also led MPOG
  58 +increased our communication via Gitlab''}. Migrating to the platform also led MPOG
60 59 staff to \textbf{trust the developed code}: \textit{``Everything was validated.
61 60 We tested the functionalities and developed the project on the SPB platform
62   -itself. Consequently, the use of the system validated most of its features.
63   -From the moment we began to use it for development, this validation was
64   -constant. We felt confident in the code developed.''}.
  61 +itself. Hence, the use of the system homologated most of its features. From the
  62 +moment we began to use it for developing, this validation was constant. We felt
  63 +confident in the code produced''}.
65 64  
66 65 The abovementioned decision also collaborated to meet the government's demand
67 66 for meticulous documentation of the software design and stages of development
68   -without bureaucratizing or modifying the development process. The team started
69   -to \textbf{produce documentation and records organically} on the platform
70   -itself, as mentioned in one of the MPOG responses: \textit{``For me, it was a
71   -great learning experience. There are a lot of things documented in emails as
72   -well as in the portal itself. We can access the tools at any time and find
73   -out how we develop a solution. Therefore, we can remember the project positive
74   -points.''}.
75   -
76   -\textit{\textbf{Brings together government staff and development team}}.
  67 +without bureaucratizing or modifying the development process. The usage of the
  68 +platform for project team management conducted \textbf{the organic production
  69 +of documentation and records}, as mentioned in one of the MPOG responses: \textit{``It was a great
  70 +learning experience. There are many things documented in emails as well as
  71 +in the portal itself. We can access the tools at any time and find out how we
  72 +develop a solution. We can remember the positive project points''}.
  73 +
  74 +\subsection{Brings together government staff and development team}
  75 +
77 76 In the first phase of the project, the interviewed MPOG
78 77 analysts did not participate in any direct interaction with any university
79 78 representative, even though they were the ones in charge of the government in
... ... @@ -83,29 +82,28 @@ meetings. They reported that there was significant communication noise in the
83 82 internal dialogues with their superiors, as well as between their superiors and
84 83 the development team.
85 84  
86   -In the second phase of the project, these analysts came to represent the
87   -government directly in the dialogues with the academia, and they started to
88   -visit bi-weekly the university's laboratory. One of the analysts believed that
89   -\textit{``at this point, the communication started to change.''}. The new
90   -dynamic \textit{reduced communication misunderstandings and unified both
  85 +In the second phase of the project, these analysts became direct representatives
  86 +of the government and started to visit the university's laboratory bi-weekly.
  87 +One of the analysts believed that
  88 +\textit{``at this point, the communication started to change''}. The new
  89 +dynamics \textit{reduced communication misunderstandings and unified both
91 90 sides}, as reported by another interviewee: \textit{``It was very positive. We
92 91 liked to go there and to interact with the team. I think it brought more unity,
93   -more integration into the project.''}. {73\%} of the interns considered positive
  92 +more integration into the project''}. {73\%} of the interns considered positive
94 93 the direct participation of the MPOG staff, and {81\%} of them believed the
95 94 presence of government staff in sprint ceremonies was relevant for the project
96 95 development. For 76\% of the interns, writing the requirements together with the
97 96 MPOG staff was very important to \textbf{better meet expectations of both
98 97 sides}. According to one of them, \textit{``Joint planning and timely meetings
99   -were very important for understanding the needs of MPOG.''}.
  98 +were very important for understanding the needs of MPOG''}.
100 99  
101 100 The closest dialogue between government and academia generated empathy, as
102 101 reported by one of the interviewees: \textit{``Knowing people in person makes a
103 102 big difference in the relationship because it causes empathy. You know who that
104   -person is, it's not simply a name.''}. This point helped to \textbf{synchronize
105   -the execution pace of activities}: \textit{``When we visited the lab and met
106   -the team, we realized that this encouraged us to validate resources faster and
107   -give faster feedback to the team. In return, they also quickly answered us any
108   -question.''}.
  103 +person is. He's not merly a name''}. Consequently, this empathy helped to \textbf{synchronize
  104 +the execution pace of activities}: \textit{``Visiting the lab and meeting
  105 +the developers encouraged us to validate resources faster and give faster feedback to
  106 +the team. In return, they also quickly answered us any question''}.
109 107  
110 108 The implementation of a Continuous Delivery pipeline also reinforced the teams'
111 109 synchronization \cite{siqueira2018cd} . For 81\% of the interns and 75\% of the senior
... ... @@ -116,18 +114,19 @@ collaborative projects with academia}, as mentioned by themselves:
116 114 \textit{``Government staff has a bias that universities do not deliver
117 115 products. However, in this project, we made many deliveries with high quality.
118 116 Nowadays, I think if we had paid the same amount for a company, it would not
119   -have done the amount of features we did with the technical quality we have.''}. Additionally, the
  117 +have done the amount of features we did with the technical quality we have''}. Additionally, the
120 118 deployment of each new version also \textbf{share a common understanding of the
121 119 process from one side to the other}, as mentioned by a MPOG analyst: \textit{``We
122   -had a strategic level view. When we went to the technical level, we had
123   -difficulty to plan each four-month release. However, in the final stages of the
124   -project, I realized that this was not a problem because the team made the
125   -deliveries and the results were available in production. The team was
126   -qualified, the code had quality, and the project was well executed. So in
127   -practice, our difficulty interpreting the technical details did not impact
128   -release planning.''}.
129   -
130   -\textit{\textbf{Organized development team into priority fronts, and for each one, hire at least one specialist from the IT market}}.
  120 +had only the strategic vision of the project. When we needed to deal with
  121 +technical issues, we had some difficulty planning the four-month releases.
  122 +However, in the last stages of the project I realized that this was not a
  123 +problem. The team was delivering and the results were available in production.
  124 +The team was qualified, the code had quality, and the project was well executed.
  125 +So in practice, our difficulty in interpreting the technical details did not
  126 +impact the release planning''}.
  127 +
  128 +\subsection{Organized development team into priority fronts, and for each one, hire at least one specialist from the IT market}
  129 +
131 130 The development team had four work areas divided by the main demands of the
132 131 project: User Experience, DevOps, Integration of Systems, and Social
133 132 Networking. For each segment, at least one professional in the IT market was
... ... @@ -139,14 +138,14 @@ The presence of senior developers in the project contributed to
139 138 \textbf{conciliate the development processes of each institution and make
140 139 better technical decisions}, as quoted in one of the answers to the senior
141 140 developer's questionnaire: \textit{``I think my main contribution was to
142   -balance the relations between the MPOG staff and the university team.''}. {63\%} of
  141 +balance the relations between the MPOG staff and the university team''}. {63\%} of
143 142 the senior developers believed they have collaborated to conciliate the management
144 143 and development process between the two institutions and also {63\%} of them
145 144 helped MPOG staff express their requests more clearly. Government
146 145 analysts were also more open to suggestions from these developers:
147   -\textit{``They are developers of the upstream projects of the systems that
  146 +\textit{``They are upstream developers of the systems that
148 147 integrate the platform. They conveyed trust, and then we trust in the developed
149   -code.''}. According to questionnaire responses, they largely agreed with the
  148 +code''}. According to questionnaire responses, senior developers largely agreed with the
150 149 project development process. For 63\%, this process has close similarity to
151 150 their previous experiences. In contrast, {62.5\%} of them did not understand
152 151 the MPOG's project management process and {50\%} believed this process could
... ... @@ -155,17 +154,17 @@ affect their project productivity.
155 154 The senior developers were also responsible for \textbf{improving the management
156 155 and technical knowledge} of the interns about practices from industry and open
157 156 source projects. {91\%} of the interns believed that working with professionals
158   -was essential for learning. Working with senior developers was important during
159   -the project for all of them. {75\%} of the senior developers believed that ``Working
  157 +was essential for learning, and, for all of them, working with senior developers
  158 +was important during the project. {75\%} of the senior developers believed that ``Working
160 159 in pairs with a senior'' and 63\% that ``Participate in joint review tasks''
161 160 were the tasks with the involvement of them that most contributed to the
162 161 evolution of university interns in the project. {75\%} believed that the knowledge
163 162 shared by them to one intern was widespread among the others in the team.
164 163 Government analysts also pointed this knowledge sharing: \textit{``On
165   -the side of the universities, what we noticed was a significant improvement in the platform
166   -with the hiring of the original developers of the systems. They had a guide on
  164 +the university side, we noticed a significant improvement in the platform
  165 +with the hiring of the systems original developers. They had a guide on
167 166 how to best develop each feature and were able to solve non-trivial problems
168   -quickly.''}.
  167 +quickly''}.
169 168  
170 169 Organizing the development team and hiring senior developers allowed each team to
171 170 \textbf{self-organize and gain more autonomy in the management of their tasks}.
... ... @@ -178,8 +177,5 @@ interaction with the team. MPOG analysts saw coaches as facilitators their
178 177 activities and communication with the development team. They said \textit{``I
179 178 interacted more with the project coordinator (professor) and team coaches''},
180 179 \textit{``Usually, we contact a coach to clarify some requirements or to
181   -understand some feature. We interact more with coaches because they are more
182   -accessible than senior developers. Sometimes the coach would take our question
183   -to the senior developer.''}.
184   -
185   -%TODO: talvez encaixar aqui a troca de papéis
  180 +understand some feature. The coaches were more available than senior
  181 +developers and, sometimes, they would take our question to a senior developer''}.
... ...
oss2018/content/05-discussion.tex
1 1 \section{Discussion}
2 2 \label{sec:discussion}
3 3  
4   -Organizational culture is built and reinforced every life year of a large-size
5   -organization. These cultural values reflect on the internal management
6   -processes and the norms of communication among its members. In the context of
7   -software development projects, each institution adopts development methods that
8   -best meet its managerial procedures and organizational routines. When two
9   -large-size organizations decide to develop a solution collaboratively, the
10   -development methods and workflow of one may conflict with the interests of the
11   -other. In a case of government-academia collaboration, conciliating their
12   -different management processes is crucial, since the poor and unadaptable
13   -management could lead the project to fail, resulting in the waste of
14   -population-funded resources.
  4 +Our results reveal a set of nine management practices successfully employed in
  5 +abovementioned case. We analyzed unsystematic decisions made during a 30-month
  6 +collaborative project and identified three macro-decisions that harmonized the
  7 +differences of the management processes of each organization. We evidenced from
  8 +data collection, and responses of the members of both sides to the
  9 +questionnaires and interviews, the benefits obtained through the adoption of
  10 +this empirical method. The Table \ref{practices-table} summarizes
  11 +macro-decisions, practices, and benefits.
15 12  
16 13 \vspace*{-.5cm}
17 14  
... ... @@ -90,47 +87,15 @@ population-funded resources.
90 87  
91 88 \vspace*{-1cm}
92 89  
93   -
94   -We investigated the management method employed at the SPB portal project, a
95   -partnership between the Brazilian government and universities. The development
96   -leaders empirically built an approach using FLOSS and agile development
97   -practices and values. As a result, we identified a set of best practices which
98   -improves the workflow and relationship between the organizations involved. Our
99   -results reveal a set of nine management practices successfully employed in
100   -abovementioned case. We analyzed unsystematic decisions made during a 30-month
101   -collaborative project and identified three macro-decisions that harmonized the
102   -differences of the management processes of each organization. We evidenced from
103   -data collection, and responses of the members of both sides to the
104   -questionnaires and interviews, the benefits obtained through the adoption of
105   -this empirical method. The Table \ref{practices-table} summarizes
106   -macro-decisions, practices, and benefits.
107   -
108   -Regarding our first research question \textit{``How to introduce open source and
109   -agile best practices into government-academia collaboration projects?''}, we
110   -examined the SPB project and identified three macro-decisions taken by the
111   -academic coordinators that led them to intuitively and non-systematically adopt
112   -FLOSS and agile practices in the development process. We extracted nine best
113   -management practices and verified their efficient use collecting data from the
114   -management tool and interviewing the project participants.
115   -
116   -The interviewed responses allowed us to understand how FLOSS and agile
117   -practices have benefited the people and project management. Based on that, we
118   -answered our second research question \textit{``What practices favor
119   -effective team management in government-academia collaborative projects?''},
120   -making to explicit in Table \ref{practices-table} eleven benefits obtained from
121   -the use of the nine best practices.
122   -
123 90 The results of this current work corroborate the lessons learned in our
124 91 previous work on studying the SPB project case \cite{meirelles2017spb}.
125 92 Evidence from the data collected, responses to questionnaires, and interviews
126 93 reinforce what has been reported by the academic coordination of the project,
127 94 adding the point of views of government and other roles involved on the
128   -academic side. In short, the government staff had difficulty to understand how
129   -collaboration works. They took time to realize that the project was not a
130   -client-executor relationship and that both organizations were at the same
131   -hierarchical level in the work plan. Finally, they also felt the project needed
132   -a decision-maker role to solve the impasses between organizations, and the
133   -development coordinators sometimes took on that.
  95 +academic side. In short, the government staff took time to understand how
  96 +collaboration works and to realize that the project was not a client-executor
  97 +relationship and both organizations were at the same hierarchical level
  98 +in the work plan.
134 99  
135 100 The decisions, practices, and benefits presented in the Table
136 101 \ref{practices-table} should be evaluated and used in contexts with more
... ... @@ -143,10 +108,3 @@ the memory of the interviewees to rescue the events. Lastly, the current
143 108 situation of the respondents, such as their current working midset, may also
144 109 alter their perception on the on the topics addressed in the questionnaire and
145 110 consequently their responses.
146   -
147   -Finally, we collected a significant amount of data and testimonials related to
148   -the teaching of software engineering. We consider the project studied an
149   -educational case, an example of teaching FLOSS and agile techniques applied to
150   -real-world software development. As future work, we intend to analyze this collected
151   -information to propose improvements in software engineering undergraduates
152   -education methodology.
... ...
oss2018/content/06-conclusion.tex
... ... @@ -13,32 +13,29 @@ different management processes is crucial, since the poor and unadaptable
13 13 management could lead the project to fail, resulting in the waste of
14 14 population-funded resources.
15 15  
16   -We investigated the management method employed at the SPB portal project, a
17   -partnership between the Brazilian government and universities. This approach
18   -was empirically built using FLOSS and agile development practices and values.
19   -As a result, we identified a set of best practices which improves the workflow
20   -and relationship between the organizations involved.
  16 +In this study, we investigated the management method employed at the SPB portal
  17 +project, a partnership between the Brazilian government and universities. As a
  18 +result, we identified a set of FLOSS and agile best practices, empirically
  19 +employed by development leaders, which improved the workflow and relationship
  20 +between the organizations involved.
21 21  
22   -Regarding our first research question \textit{How to introduce open source and
23   -agile best practices into government-academia collaboration project?}, we
  22 +Regarding our first research question \textit{``How to introduce open source and
  23 +agile best practices into government-academia collaboration projects?''}, we
24 24 examined the SPB project and identified three macro-decisions taken by the
25   -academic coordinators that led them to intuitively and non-systematically adopt
26   -FLOSS and agile practices in the development process. We extracted nine best
27   -management practices and verified their efficient use collecting data from the
28   -management tool and interviewing the project participants.
  25 +academic coordinators that drove them to intuitively and unsystematically adopt
  26 +nine FLOSS and agile best practices in the development process.
29 27  
30 28 The interviewed responses allowed us to understand how FLOSS and agile
31 29 practices have benefited the people and project management. Based on that, we
32   -answered our second research question \textit{What practices would favor
33   -effective team management in government-academia collaborative project?},
  30 +answered our second research question \textit{``What practices favor
  31 +effective team management in government-academia collaborative projects?''},
34 32 making to explicit in Table \ref{practices-table} eleven benefits obtained from
35   -the use of the nine best practices aforementioned.
  33 +the use of the best practices.
36 34  
37 35 Finally, we collected a significant amount of data and testimonials related to
38   -the teaching of software engineering. We consider that the project studied is
39   -also an educational case. It is an example of how to teach information
40   -technology students FLOSS and agile approaches applied to production-level
41   -software development. As future work, we intend to analyze this collected
42   -information to propose improvements in the teaching of software engineering for
43   -undergraduates.
  36 +the teaching of software engineering. We consider the project studied an
  37 +educational case, an example of teaching FLOSS and agile techniques applied to
  38 +real-world software development. As future work, we intend to analyze this collected
  39 +information to propose improvements in software engineering undergraduates
  40 +education methodology.
44 41  
... ...
oss2018/spb-oss-2018.tex
... ... @@ -42,7 +42,7 @@
42 42 \input{content/03-methods}
43 43 \input{content/04-results}
44 44 \input{content/05-discussion}
45   -%\input{content/06-conclusion}
  45 +\input{content/06-conclusion}
46 46  
47 47 \bibliographystyle{splncs03}
48 48 \bibliography{spb-oss-2018}
... ...