Download as
Browse Code »

Commit 541711f2acec80bcb0e7b78e9dbf885d6e426e80

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

[oss-2018] applying Carla's review

Showing 7 changed files with 249 additions and 187 deletions   Show diff stats
oss2018/content/00-abstract.tex
  Diff comments   View file @541711f
1 1 \begin{abstract}
2 2  
3   -Government and academia can collaborate on bringing innovation and filling design-reality gaps in e-government projects. However, differences in project management methods employed by the organizations is often a challenge for collaborative works. Bearing that in mind, we investigated a 30-month government-academia partnership to find appropriate ways to get around this obstacle. From the analysis of \textit{post-mortem} data as well as the results of questionnaires and interviews with project participants, we present a set of best practices based on FLOSS and agile software development approaches that favors team management in government-academia collaborations in e-government development projects.
  3 +Government and academia can collaborate on bringing innovation and filling
  4 +design-reality gaps in e-government projects. However, differences in project
  5 +management methods employed by the organizations is often a challenge for
  6 +collaborative works. Bearing that in mind, we investigated a 30-month
  7 +government-academia partnership to find appropriate ways to get around this
  8 +obstacle. From the analysis of \textit{post-mortem} data as well as the results
  9 +of questionnaires and interviews with project participants, we present a set of
  10 +best practices based on FLOSS and agile software development approaches that
  11 +favors team management in government-academia collaborations in e-government
  12 +development projects.
4 13  
5 14 \end{abstract}
6 15  
7   -\keywords{Open Source Software, Free Software, Agile Methods, Best Practices, Project Management, E-Government.}
  16 +\keywords{Open Source Software, Free Software, Agile Methods, Best Practices,
  17 +Project Management, E-Government.}
... ...
oss2018/content/01-introduction.tex
  Diff comments   View file @541711f
... ... @@ -12,9 +12,11 @@ the collaboration project, aligning goals, synchronizing the pace of between
12 12 government and academia \cite{anthopoulos2016egovernment}, and overcoming the
13 13 failure trend of e-government projects \cite{goldfinch2007pessimism}.
14 14  
15   -Poor project management is one of the causes of e-government projects failure
16   -\cite{anthopoulos2016egovernment} which, in turn, grows into a critical issue
17   -when government and academia combine efforts to develop an e-gov solution.
  15 +One of the main causes of e-government project failure is poor project
  16 +management \cite{anthopoulos2016egovernment}. When government and academia
  17 +combine efforts to develop an e-gov solution, it becomes a critical issue.
  18 +
  19 +
18 20 Academia commonly works on cutting edge technology while the government
19 21 still relies on traditional techniques. Changing the development process in
20 22 large-size institutions represents an organizational disturbance with impacts
... ... @@ -22,7 +24,7 @@ on structure, culture, and management practices \cite{nerur2015challenges}. As
22 24 a result, government and academia have to harmonize their view to increase
23 25 the chances of success in projects with tight deadlines and short budgets.
24 26  
25   -We believe that procedures from Free/Libre and Open Source Software (FLOSS) and
  27 +We believe that recommended community standards from Free/Libre and Open Source Software (FLOSS) and
26 28 agile values may be an option for harmonizing different management approaches,
27 29 due to the plurality of FLOSS ecosystems and the diversity favored by agile
28 30 methodologies. Open communication, project modularity, the community of users,
... ... @@ -34,8 +36,12 @@ process management and the cooperation of distinct teams.
34 36  
35 37 In this work, we investigate the empirical method developed during 30 months of a
36 38 government-academia project that helped to harmonize the differences between
37   -both organization management cultures. We trace the best practices based on
38   -FLOSS ecosystems and agile methodology. Finally, we collect data from the
39   -project repository and survey the project participants points of view to
40   -extract a set of best practices to conduct effective government-academia
41   -collaboration.
  39 +both organization management cultures. We present both quantitative and
  40 +qualitative analyses of the benefits of FLOSS and agile practices in an
  41 +e-government project. We identify and trace the best practices based on FLOSS
  42 +ecossystems and agile methodology. We collect and analyse data from the project
  43 +repository. Finally, we conducted a survey target at projects participants to
  44 +find their perception around the set of best practices, and which of them are
  45 +effective to government-academia collaboration. In doing so, our aim is to help
  46 +academia better understand key issues they will be confronted with when engaging
  47 +in a government-academia software project.
... ...
oss2018/content/02-relatedwork.tex
  Diff comments   View file @541711f
1 1 \section{Related work}
2 2 \label{sec:relatedwork}
3 3  
4   -% TODO: Verificar se não vale a pena citar os fatores que o Strode descobriu.
5   -% Eu acho que deixaria a frase mais completa
6 4 Discussions on how to introduce new management methods into an organization are
7 5 present in several works. Nerur et al. recognized critical issues concerning
8 6 the migration from traditional to agile software development by comparing
... ... @@ -33,10 +31,9 @@ academia.
33 31 Complex and large-scale organizations, such as the public administration, have
34 32 to deal with multiple project variables. Alleman et al. describe a production
35 33 deployment for the US government, focusing on the methodology applied to address
36   -long-term planning and value estimation \cite{alleman2003making}. The application of agile
37   -methods in the Brazilian public sector is approached by Melo et
38   -al. \cite{melo2013agileBr} and De Sousa et al. \cite{de2016using}, both are
39   -experiences limited to pilot projects.
  34 +long-term planning and value estimation \cite{alleman2003making}. The
  35 +application of agile methods in the Brazilian public sector is approached by
  36 +Melo et al. \cite{melo2013agileBr}.\todo{reler essa ref}
40 37  
41 38 Several works tried to highlight the FLOSS practices, while others attempted to
42 39 determine the relationship between FLOSS practices and agile methods.
... ... @@ -52,4 +49,9 @@ Eric Raymond describes many of his experiences and decisions in his work with
52 49 FLOSS communities \cite{raymond}, this report has many intersections with the
53 50 agile manifesto.
54 51  
55   -This paper differs itself from others by studying the development collaboration between government and academia of a production level platform. From questionnaires, interviews, and development activities data. We extracted best practices that helped to harmonize the interactions between two different development process and satisfied the management process of both sides. We analyzed the decisions made from the FLOSS and agile perspectives.
  52 +This paper differs itself from others by studying the government-academia
  53 +collaboration for developing a production-level solution. From questionnaires,
  54 +interviews, and development activities data. We extracted best practices that
  55 +helped to harmonize the interactions between two different development process
  56 +and satisfied the management process of both sides. We analyzed the decisions
  57 +made from the FLOSS and agile perspectives.
... ...
oss2018/content/03-methods.tex
  Diff comments   View file @541711f
1 1 \section{Research Design}
2 2 \label{sec:researchdesign}
3 3  
4   -% TODO (by Siqueira): Tenho a impressão de que esse parágrafo cairia bem no último parágrafo
5   -% da introdução. Pelo menos a ideia dele uma vez que resume bem o trabalho
6   -In this paper, we studied practical alternatives to harmonize different
7   -software development processes. We are interested in the relationship between
8   -government and academia from the project management perspective, without the
9   -enforcement of changing their internal processes. We present two research
10   -questions that guided our work:
  4 +In this paper, we studied practical alternatives to harmonize the software
  5 +project lifecycle when confronting different development processes from crucial
  6 +stakeholders. We are interested in the relationship between government and
  7 +academia from the project management perspective, without the enforcement of
  8 +changing their internal processes. We present two research questions that guided
  9 +our work:
11 10  
12 11 \textbf{RQ1. }\textit{How to introduce open source and agile best practices into
13 12 government-academia collaboration projects?}
... ... @@ -18,7 +17,7 @@ government-academia collaborative projects?}
18 17 To answer these questions, we use the case study as research method. We selected
19 18 as a case the evolution of the Brazilian Public Software portal (SPB)
20 19 \cite{meirelles2017spb}, a government-academia collaborative project based on
21   -FLOSS systems. To validate our answers, we picked three different points of
  20 +FLOSS systems. To validate our answers, we covered three different points of
22 21 view: developers, government agent, and data collected from the project
23 22 repository.
24 23  
... ... @@ -39,36 +38,50 @@ portal includes social networking, mailing lists, version control system, and
39 38 source code quality monitoring. All of this software is integrated using a
40 39 system-of-systems framework \cite{meirelles2017spb}.
41 40  
42   -The platform development activities happened in the Advanced Laboratory
43   -of Production, Research, and Innovation in Software Engineering (LAPPIS) at
44   -UnB. The laboratory born from a professor that is part of Brazillian FLOSS
45   -community and another one that spreads out agile values. Thus, naturally,
46   -LAPPIS embrace the best practices of both ecosystems. For this project, the
47   -laboratory had a total of 42 undergraduate interns, and two professors engaged
48   -in the development team. Finally, the project hired six senior developers with
49   -significant experience with FLOSS communities, and two designers specialized in
50   -User Experience (UX).
51   -
52   -The government team was composed of one director, one coordinator, and two IT
53   -analysts from MPOG. They were responsible for contracts and collaboration
54   -management, which means they do not produce software. The MPOG analysts had
55   -their background in traditional management approaches, such as RUP, CMMI,
56   -and PMBOK.
57   -
58   -The leaders of LAPPIS and MPOG periodically met in person to manage the project
59   -progress, discussing strategic issues and technical goals. Initially, these
60   -meetings took place at the Ministry's headquarters and, usually, only directors
61   -and professors participated. On the academic side, the management of the
62   -development teams often spent two weeks per sprint and released a new version
63   -every 4 months. During the project progress, this workflow proved to be
64   -inefficient. Conflicts between the internal management processes and
65   -differences in pace and goals of each institution were compromising the
66   -platform development.
67   -
68   -Professors, with the senior developers' collaboration, incrementally employed a
69   -set of best practices based on FLOSS and agile values for improving
  41 +The development of the platform took place at the Advanced Laboratory of
  42 +Production, Research, and Innovation in Software Engineering (LAPPIS/UnB) and
  43 +followed the model of management of sprint of 2 weeks and launches every 4
  44 +months. On the other hand, at the beginning of the project, project management
  45 +and strategic discussions happened only once a month, when Lappis leaders and
  46 +MPOG directors met in person at the ministry's headquarters. The differences
  47 +in organization of the two parties involved in the collaboration are summarized
  48 +by the table\ref{gov-academia-diff-table}.
  49 +
  50 +\vspace*{-.5cm}
  51 +
  52 +\begin{table}[h]
  53 +\centering
  54 +\def\arraystretch{1.2}
  55 +\setlength\tabcolsep{0.2cm}
  56 +\resizebox{\textwidth}{!}{%
  57 +\begin{tabular}{m{4.3cm}!{\color{white}\vrule}m{6cm}!{\color{white}\vrule}m{7cm}}
  58 +\rowcolor[HTML]{c0d6e4}
  59 +\textbf{Collaboration peaces} & \textbf{Academia} & \textbf{Goverment} \\
  60 +\rowcolor[HTML]{f2f2f2}
  61 +\textbf{Responsibilities} & Platform development activites & Contracts and collaboration management \\
  62 +\rowcolor[HTML]{fafafa}
  63 +\textbf{Team size} &
  64 +\begin{tabular}[c]{@{}l@{}} 42 undergraduate interns; \\ 2 professors; \\ 6 senior developers with significant \\ experience in FLOSS projects;\\ 2 User eXperience specialist \end{tabular} &
  65 +\begin{tabular}[c]{@{}l@{}} 1 director; \\ 1 coordinator; \\ 2 requirement analysts \end{tabular} \\
  66 +\rowcolor[HTML]{f2f2f2}
  67 +\textbf{Workplace} & LAPPIS at UnB & MPOG headquarters \\
  68 +\rowcolor[HTML]{fafafa}
  69 +\begin{tabular}[c]{@{}l@{}}\textbf{Management} \textbf{approaches}\end{tabular} & Agile methods and practices from FLOSS development & Traditional methods, such as RUP, CMMI, and PMBOK \\
  70 +\end{tabular}%
  71 +}
  72 +\caption{Differences between academia and government sides}
  73 +\label{gov-academia-diff-table}
  74 +\end{table}
  75 +
  76 +\vspace*{-1cm}
  77 +
  78 +During the project progress, this workflow proved to be inefficient. Conflicts
  79 +between the internal management processes and differences in pace and goals of
  80 +each institution were compromising the platform development. To improve
70 81 the project management process and reducing the conflict between government
71   -and academia. Throughout the project, the LAPPIS team built an experimental
  82 +and academia, professors, with the senior developers' collaboration,
  83 +incrementally employed a set of best practices based on FLOSS and agile values.
  84 +Throughout the project, the LAPPIS team built an experimental
72 85 management model to harmonize the different cultures. The development leaders
73 86 made decisions in a non-systematic way to promote the usage of these best
74 87 practices. In this paper, we analyze and codify these decisions and its
... ... @@ -76,33 +89,44 @@ benefits.
76 89  
77 90 \subsection{Survey, Interview and Data Collection}
78 91  
79   -We divided the development team into two groups of participants according to
80   -their roles during the project: undergraduate interns and IT professionals.
81   -For each set of members, we designed an online questionnaire with topics
82   -related to (1) project organization, (2) development process, (3) communication
83   -and relationship with members, (4) acquired knowledge and (5) experience
84   -with FLOSS projects. We also interviewed two MPOG analysts who directly
85   -interacted with the development team and project development process. The
86   -interview questions had four parts: (1) Professional profile;(2) Organization,
87   -communication and development methodologies (3) Satisfaction with the developed
88   -platform; (4) Lessons learned.
89   -
90   -We sent the online questionnaire to 42 interns and 8 IT professionals. All
91   -interns worked as a developer and received a scholarship. We got a total of 37
92   -interns responses, and all professionals joined on it. On average, interns had
93   -22 years and professionals had 30 years, wherein 8\% and 13\% respectively were
94   -women. About 43\% of the interns had the SPB project as their first contact
95   -with FLOSS. On average, the IT professionals had 11 years of experience, worked
96   -in at least 5 different companies, participated in 4 to 80 distinct projects,
97   -and 86\% of them had some background with FLOSS before the SPB project.
98   -
99   -We also interviewed two MPOG analysts separately. Each interview took an
100   -average of 2 hours with 28 open questions. They are over 30 years old, and they
101   -have more than 7 years working in the government. The analysts said that SPB
102   -project represented their first experience of government-academia
103   -collaboration.
104   -
105   -Finally, we analyzed the data from the principal project repository considering
  92 +We divided the project team into three groups: undergraduate interns, senior
  93 +developers and MPOG analysts. For the first two groups we sent online
  94 +questionnaires and for the last group we conducted, separately, a 2 hour
  95 +interview. The table \ref{survey-table} have more details about these processes.
  96 +
  97 +\vspace*{-.5cm}
  98 +
  99 +\begin{table}[h]
  100 +\centering
  101 +\def\arraystretch{1.2}
  102 +\setlength\tabcolsep{0.2cm}
  103 +\resizebox{\textwidth}{!}{%
  104 +\begin{tabular}{m{4cm}!{\color{white}\vrule}m{4cm}!{\color{white}\vrule}m{5cm}!{\color{white}\vrule}m{5cm}}
  105 +\rowcolor[HTML]{c6b3df}
  106 +\textbf{} & \textbf{\nohyphens{Undergraduate Interns}} & \textbf{Senior Developers} & \textbf{MPOG Analysts} \\
  107 +\rowcolor[HTML]{fafafa}
  108 +\textbf{Research technique} & Online questionnaire & Online questionnaire & Interview \\
  109 +\rowcolor[HTML]{f2f2f2}
  110 +\textbf{Discussed topics} & \multicolumn{2}{l!{\color{white}\vrule}}{\begin{tabular}[c]{@{}l@{}}(1) project organization,\\ (2) the development process,\\ (3) communication and relationship with members,\\ (4) knowledge sharing\\ (5) experience with FLOSS projects\end{tabular}} & \begin{tabular}[c]{@{}l@{}}(1) professional profile;\\ (2) organization, communication \\ and development methodologies;\\ (3) satisfaction with \\ the developed platform;\\ (4) lessons learned\end{tabular} \\
  111 +\rowcolor[HTML]{fafafa}
  112 +\textbf{Number of interviewed} & 42 & 8 & 2 \\
  113 +\rowcolor[HTML]{f2f2f2}
  114 +\textbf{Rate of responses} & 88\% (37) & 100\% & 100\% \\
  115 +\rowcolor[HTML]{fafafa}
  116 +\textbf{Average age at the end of the project} & 22 years old & 30 years old & more than 30 years \\
  117 +\rowcolor[HTML]{f2f2f2}
  118 +\textbf{Gender} & \begin{tabular}[c]{@{}l@{}}8\% women \\ 92\% man\end{tabular} & \begin{tabular}[c]{@{}l@{}}13\% women \\ 87\% man\end{tabular} & 100\% women \\
  119 +\rowcolor[HTML]{fafafa}
  120 +\begin{tabular}[c]{@{}l@{}}\textbf{Experience} \\ \textbf{background}\end{tabular} & 43\% of the interns had the SPB project as their first contact with FLOSS & 11 years of experience; worked in at least 5 companies; participated in 4 to 80 distinct projects; 86\%of them had some background with FLOSS before the SPB project & more than 7 years working in the government; SPB project represented their first experience of government-academia collaboration \\
  121 +\end{tabular}%
  122 +}
  123 +\caption{Surveying the project participants}
  124 +\label{survey-table}
  125 +\end{table}
  126 +
  127 +\vspace*{-1cm}
  128 +
  129 +Finally, we analyzed the data from the central project repository considering
106 130 all the issues and commits. From April 2015 to June 2016, 59 distinct authors
107 131 opened 879 issues, 64 different users made the total of 4,658 comments. The
108   -development team made 3,256 commits in the central project repository.
  132 +development team made 3,256 commits in this abovementioned repository.
... ...
oss2018/content/04-results.tex
  Diff comments   View file @541711f
... ... @@ -9,28 +9,23 @@ private channels, such as professional e-mails, personal meetings, and
9 9 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   -The second phase, from April 2015 to the end of the project (June 2016), has a
13   -more considerable wealth of data. Much of the management and communication
  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 14 activities were recorded and published on online channels and tools. During
15 15 this period, several FLOSS practices and agile values were applied to the
16 16 development process to harmonize the cultural and organizational divergences of
17 17 the institutions involved. At the end of the project, an empirical approach to
18 18 communication and management was built using the development leaders'
19   -experiences in FLOSS and agile projects to cater to government bureaucracies.
20   -
21   -In this section, we list the macro-decisions taken during the project and the
22   -practices that made these decisions concrete. We use data collected from the
23   -central repository to map best practices and, with the respondents' answers, we
24   -analyzed how each decision benefited the project collaboration.
25   -
26   -The development team decided to \textbf{use of the system under development to
27   -develop the system itself}. The team released the first version of the new SPB
28   -portal nine months after the project beginning. Due to the platform features
29   -for software development and social network, the development coordinators decided to
30   -use the platform under construction to develop the system itself. Gradually, in
31   -addition to development activities, government and academia migrated the
32   -project management and the communication between teams to the portal
33   -environment. In short, the wiki feature was used for logging meetings, defining
  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}}.
  22 +The first version of the new SPB portal was released nine months after the
  23 +project beginning. Due to the platform features for software development and
  24 +social network, the development coordinators decided to use the platform under
  25 +construction to develop the system itself. Gradually, in addition to development
  26 +activities, government and academia migrated the project management and the
  27 +communication between teams to the portal environment.
  28 +In short, the wiki feature was used for logging meetings, defining
34 29 goals, planning sprints, documenting deployment procedures and user guides. The
35 30 issue tracker was used for discussing requirements, monitoring features under
36 31 development, requesting and recording changes, and validating the delivered
... ... @@ -52,20 +47,20 @@ see everything that was happening.''}.
52 47  
53 48 Migrating to the SPB platform also \textbf{easied monitoring of activities and
54 49 increased interactions between developers and public servants}. The data
55   -collected from the repository evidence the frequent use of the platform by the
  50 +collected from the repository highlight the frequent use of the platform by the
56 51 academic and the government teams. In the last 15 months of the project, the
57 52 central repository issues were opened by 59 different authors, 8 of them MPOG
58 53 agents. These issues received comments from 64 distinct users, 9 of them from
59   -MPOG. When we consider the issues with much interaction, those who had ten
60   -comments or more, we notice that the government team also felt comfortable with
  54 +MPOG. When we consider the issues with more interactions, those which had ten
  55 +comments or more, we notice that the government team also felt comfortable in
61 56 using the tool to interact directly with the development team. In a set of 102
62   -issues with much interaction, MPOG staff created 43 of them (this represents
  57 +issues with more interactions, MPOG staff created 43 of them (this represents
63 58 42\% of the most active issues). For the MPOG analysts, interaction via
64   -repository improved communication. \textit{``There was a lot of evolution, a
65   -lot of communication via Gitlab.''}. Migrating to the platform also led MPOG
  59 +repository improved communication. \textit{``There was a big evolution, we
  60 +increased our communication via Gitlab.''}. Migrating to the platform also led MPOG
66 61 staff to \textbf{trust the developed code}: \textit{``Everything was validated.
67 62 We tested the functionalities and developed the project on the SPB platform
68   -itself. Consequently, the use of the system validated most of the features.
  63 +itself. Consequently, the use of the system validated most of its features.
69 64 From the moment we began to use it for development, this validation was
70 65 constant. We felt confident in the code developed.''}.
71 66  
... ... @@ -75,12 +70,12 @@ without bureaucratizing or modifying the development process. The team started
75 70 to \textbf{produce documentation and records organically} on the platform
76 71 itself, as mentioned in one of the MPOG responses: \textit{``For me, it was a
77 72 great learning experience. There are a lot of things documented in emails as
78   -well as in the portal itself. When necessary, we can access the tools and find
79   -out how we develop a solution. We can recover these positive points.''}.
80   -
  73 +well as in the portal itself. We can access the tools at any time and find
  74 +out how we develop a solution. Therefore, we can remember the project positive
  75 +points.''}.
81 76  
82   -The development coordinators worked to \textbf{brings together government staff
83   -and development team}. At the beginning of the project, the interviewed MPOG
  77 +\textit{\textbf{Brings together government staff and development team}}.
  78 +In the first phase of the project, the interviewed MPOG
84 79 analysts did not participate in any direct interaction with any university
85 80 representative, even though they were the ones in charge of the government in
86 81 ensuring the collaboration agreement and the delivery of the products. Because
... ... @@ -93,7 +88,7 @@ In the second phase of the project, these analysts came to represent the
93 88 government directly in the dialogues with the academia, and they started to
94 89 visit bi-weekly the university's laboratory. One of the analysts believed that
95 90 \textit{``at this point, the communication started to change.''}. The new
96   -dynamic \textit{reduced communication misunderstandings and unified the two
  91 +dynamic \textit{reduced communication misunderstandings and unified both
97 92 sides}, as reported by another interviewee: \textit{``It was very positive. We
98 93 liked to go there and to interact with the team. I think it brought more unity,
99 94 more integration into the project.''}. {73\%} of the interns considered positive
... ... @@ -117,13 +112,13 @@ The implementation of a Continuous Delivery pipeline also reinforced the teams'
117 112 synchronization \cite{siqueira2018cd} . For 81\% of the interns and 75\% of the senior
118 113 developers, deploying new versions of the SPB portal in production was a
119 114 motivator during the project. On the government side, this approach helped to
120   -\textbf{overcome the government bias regarding the low productivity of
  115 +\textbf{overcome the government bias toward low productivity of
121 116 collaborative projects with academia}, as mentioned by themselves:
122 117 \textit{``Government staff has a bias that universities do not deliver
123 118 products. However, in this project, we made many deliveries with high quality.
124   -Nowadays I think if we had paid the same amount for a company, it would not
125   -have done what we did with the quality we delivered.''}. Additionally, the
126   -deployment of each new version also \textbf{improve the translation of the
  119 +Nowadays, I think if we had paid the same amount for a company, it would not
  120 +have done the amount of features we did with the technical quality we have.''}. Additionally, the
  121 +deployment of each new version also \textbf{share a common understanding of the
127 122 process from one side to the other}, as mentioned by a MPOG analyst: \textit{``We
128 123 had a strategic level view. When we went to the technical level, we had
129 124 difficulty to plan each four-month release. However, in the final stages of the
... ... @@ -133,15 +128,15 @@ qualified, the code had quality, and the project was well executed. So in
133 128 practice, our difficulty interpreting the technical details did not impact
134 129 release planning.''}.
135 130  
136   -The project leaders \textbf{divided the development team into priority fronts,
137   -and for each one, hire at least one specialist from the IT market}. The
138   -development team had four work areas divided by the main demands of the
  131 +\textit{\textbf{Organized development team into priority fronts, and for each one, hire at least one specialist from the IT market}}.
  132 +The development team had four work areas divided by the main demands of the
139 133 project: User Experience, DevOps, Integration of Systems, and Social
140   -Networking. For each of them, at least one professional in the IT market was
141   -hired to raise the quality of the product. Senior developers have a vast
142   -experience in the FLOSS systems and tools used in the project.
  134 +Networking. For each segment, at least one professional in the IT market was
  135 +hired to raise the quality of the product. Senior developers have been selected
  136 +based on their vast experience in FLOSS systems and their knowledge on tools
  137 +used in the project.
143 138  
144   -The participation of senior developers in the project contributed to
  139 +The presence of senior developers in the project contributed to
145 140 \textbf{conciliate the development processes of each institution and make
146 141 better technical decisions}, as quoted in one of the answers to the senior
147 142 developer's questionnaire: \textit{``I think my main contribution was to
... ... @@ -166,14 +161,14 @@ the project for all of them. {75\%} of the senior developers believed that ``Wor
166 161 in pairs with a senior'' and 63\% that ``Participate in joint review tasks''
167 162 were the tasks with the involvement of them that most contributed to the
168 163 evolution of university interns in the project. {75\%} believed that the knowledge
169   -taught by them to a intern was widespread among the others in the team.
170   -Government analysts also pointed this acquisition of knowledge: \textit{``On
  164 +shared by them to a intern was widespread among the others in the team.
  165 +Government analysts also pointed this knowledge sharing: \textit{``On
171 166 the side of the universities, what we noticed was a significant improvement in the platform
172 167 with the hiring of the original developers of the systems. They had a guide on
173 168 how to best develop each feature and were able to solve non-trivial problems
174 169 quickly.''}.
175 170  
176   -Dividing the development team and hiring senior developers allowed each team to
  171 +Organizing the development team and hiring senior developers allowed each team to
177 172 \textbf{self-organize and gain more autonomy in the management of their tasks}.
178 173 There was a development coach to lead each team, and a ``meta-coach'' supported
179 174 all of them in their internal management activities. The coaches (most advanced
... ...
oss2018/content/05-discussion.tex
  Diff comments   View file @541711f
... ... @@ -13,88 +13,112 @@ 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   -\begin{table}[hbt]
  16 +We investigated the management method employed at the SPB portal project, a
  17 +partnership between the Brazilian government and universities. The development
  18 +leaders empirically built an approach using FLOSS and agile development
  19 +practices and values. As a result, we identified a set of best practices which
  20 +improves the workflow and relationship between the organizations involved. Our
  21 +results reveal a set of nine management practices successfully employed in
  22 +abovementioned case. We analyzed unsystematic decisions made during a 30-month
  23 +collaborative project and identified three macro-decisions that harmonized the
  24 +differences of the management processes of each organization. We evidenced from
  25 +data collection, and responses of the members of both sides to the
  26 +questionnaires and interviews, the benefits obtained through the adoption of
  27 +this empirical method. The Table \ref{practices-table} summarizes
  28 +macro-decisions, practices, and benefits.
  29 +
  30 +Regarding our first research question \textit{``How to introduce open source and
  31 +agile best practices into government-academia collaboration projects?''}, we
  32 +examined the SPB project and identified three macro-decisions taken by the
  33 +academic coordinators that led them to intuitively and non-systematically adopt
  34 +FLOSS and agile practices in the development process. We extracted nine best
  35 +management practices and verified their efficient use collecting data from the
  36 +management tool and interviewing the project participants.
  37 +
  38 +The interviewed responses allowed us to understand how FLOSS and agile
  39 +practices have benefited the people and project management. Based on that, we
  40 +answered our second research question \textit{``What practices favor
  41 +effective team management in government-academia collaborative projects?''},
  42 +making to explicit in Table \ref{practices-table} eleven benefits obtained from
  43 +the use of the nine best practices.
  44 +
  45 +\vspace*{-.5cm}
  46 +
  47 +\begin{table}[h]
17 48 \centering
  49 +\def\arraystretch{1.2}
  50 +\setlength\tabcolsep{0.2cm}
18 51 \resizebox{\textwidth}{!}{%
19   -\begin{tabular}{ | m{4cm} m{10cm} m{10cm} | }
20   -\hline
21   -\textbf{Decision} & \textbf{Practice Explanation} & \textbf{Benefits} \\ \hline
22   -\textbf{Use of the system under development to develop the system itself} &
  52 +\begin{tabular}{ m{4cm} m{8cm} m{8cm} }
  53 +\rowcolor[HTML]{b7d0b9}
  54 +\textbf{Decision} & \textbf{Practice Explanation} & \textbf{Benefits} \\
  55 +\rowcolor[HTML]{fafafa}
  56 +\begin{flushleft}
  57 +\textbf{Use of the system under development to develop the system itself}
  58 +\end{flushleft} &
  59 +\begin{flushleft}
23 60 \begin{itemize}
  61 +\setlength{\itemsep}{2pt}
24 62 \item The features and tools of the platform under development supported the project management and communication activities.
25   -\end{itemize} &
  63 +\end{itemize}
  64 +\end{flushleft} &
  65 +\begin{flushleft}
26 66 \begin{itemize}
  67 +\setlength{\itemsep}{2pt}
27 68 \item Communicating with transparency and efficiency;
28 69 \item Monitoring of activities;
29 70 \item More interactions between developers and public servants;
30 71 \item Trust the developed code;
31 72 \item Organic documentation;
32   -\end{itemize} \\ \hline
33   -
34   -\textbf{Bring together government staff and development team} &
35   -\begin{itemize}
  73 +\end{itemize}
  74 +\end{flushleft} \\
  75 +\rowcolor[HTML]{f2f2f2}
  76 +\begin{flushleft}
  77 +\textbf{Bring together government staff and development team}
  78 +\end{flushleft} &
  79 +\begin{flushleft}
  80 +\begin{itemize}
  81 +\setlength{\itemsep}{2pt}
36 82 \item Government staff, academic coordinators, senior developers and team coaches biweekly meet at the university lab, academia headquarters, for sprint planning and review.
37 83 \item Conduct on the platform the technical discussions between government staff and the development team.
38 84 \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   -\end{itemize} &
  85 +\item Build a continuous delivery pipeline with stages involving both sides.
  86 +\end{itemize} \end{flushleft} &
  87 +\begin{flushleft}
41 88 \begin{itemize}
  89 +\setlength{\itemsep}{2pt}
42 90 \item Reducing communication misunderstanding;
43 91 \item Better meeting expectations of both sides;
44 92 \item Improvement of decision-making process;
45 93 \item Overcoming the government bias regarding low productivity of collaborative projects with academia;
46 94 \item Synchronizing the execution pace of activities;
47   -\item Improve the translation of the process from one side to the other.
48   -\end{itemize} \\ \hline
49   -
50   -\textbf{Divide the development team into priority fronts, and for each one, hire at least one specialist from the IT market} &
  95 +\item Sharing a common understanding of the process from one side to the other.
  96 +\end{itemize} \end{flushleft} \\
  97 +\rowcolor[HTML]{fafafa}
  98 +\begin{flushleft}
  99 +\textbf{Organize the development team into priority fronts, and for each one, hire at least one specialist from the IT market}
  100 +\end{flushleft} &
51 101 \begin{itemize}
  102 +\setlength{\itemsep}{2pt}
52 103 \item The coordinators separated the development team into priority work areas considering the main demands of the project.
53 104 \item IT market professionals with recognized experience on each front were hired to work in person or remotely.
54 105 \item Define among the interns the leadership roles: a coach for each front, and a meta-coach of the entire development team.
55 106 \item Each team has certain self-organization, being guided by one intern-coach and at least one senior developer.
56 107 \end{itemize} &
57 108 \begin{itemize}
  109 +\setlength{\itemsep}{2pt}
58 110 \item Conciliating the development processes of each institution, taking better technical decisions;
59 111 \item Improving the management and technical knowledge;
60 112 \item Self-organizing and gaining autonomy in the management of their tasks.
61   -\end{itemize}\\ \hline
  113 +\end{itemize}\\
62 114 \end{tabular}%
63 115 }
64 116 \caption{Empirical SPB management decisions and its benefits.}
65 117 \label{practices-table}
66 118 \end{table}
67 119  
68   -\vspace{-.9cm}
  120 +\vspace*{-1cm}
69 121  
70   -We investigated the management method employed at the SPB portal project, a
71   -partnership between the Brazilian government and universities. The development
72   -leaders empirically built an approach using FLOSS and agile development
73   -practices and values. As a result, we identified a set of best practices which
74   -improves the workflow and relationship between the organizations involved. Our
75   -results reveal a set of nine management practices successfully employed in
76   -abovementioned case. We analyzed unsystematic decisions made during a 30-month
77   -collaborative project and identified three macro-decisions that harmonized the
78   -differences of the management processes of each organization. We evidenced from
79   -data collection, and responses of the members of both sides to the
80   -questionnaires and interviews, the benefits obtained through the adoption of
81   -this empirical method. The Table \ref{practices-table} summarizes
82   -macro-decisions, practices, and benefits.
83   -
84   -Regarding our first research question \textit{``How to introduce open source and
85   -agile best practices into government-academia collaboration projects?''}, we
86   -examined the SPB project and identified three macro-decisions taken by the
87   -academic coordinators that led them to intuitively and non-systematically adopt
88   -FLOSS and agile practices in the development process. We extracted nine best
89   -management practices and verified their efficient use collecting data from the
90   -management tool and interviewing the project participants.
91   -
92   -The interviewed responses allowed us to understand how FLOSS and agile
93   -practices have benefited the people and project management. Based on that, we
94   -answered our second research question \textit{``What practices favor
95   -effective team management in government-academia collaborative projects?''},
96   -making to explicit in Table \ref{practices-table} eleven benefits obtained from
97   -the use of the nine best practices.
98 122  
99 123 The results of this current work corroborate the lessons learned in our
100 124 previous work on studying the SPB project case \cite{meirelles2017spb}.
... ... @@ -105,25 +129,24 @@ academic side. In short, the government staff had difficulty to understand how
105 129 collaboration works. They took time to realize that the project was not a
106 130 client-executor relationship and that both organizations were at the same
107 131 hierarchical level in the work plan. Finally, they also felt the project needed
108   -a decision-maker role to resolve impasses between organizations, and the
  132 +a decision-maker role to solve the impasses between organizations, and the
109 133 development coordinators sometimes took on that.
110 134  
111 135 The decisions, practices, and benefits presented in the Table
112 136 \ref{practices-table} should be evaluated and used in contexts with more
113   -substantial plurality and diversity of government stakeholders. As threats to
114   -the validity of this work, we point out the lack of communication records and
  137 +substantial plurality and diversity of government stakeholders. This study has
  138 +a few obvious limitations. Firstly, we point out the lack of communication records and
115 139 low traceability of the management data referring to the first phase of the
116   -project. We also consider as a threat the hiatus between the completion of the
  140 +project. Secondly, we consider a drawback the hiatus between the completion of the
117 141 project and the conduction of interviews and questionnaires, since we rely on
118   -the memory of the interviewees to rescue the events. Furthermore, the new work
  142 +the memory of the interviewees to rescue the events. Lastly, the new work
119 143 experiences of the respondents after the project and their current working
120   -mindset may also modify their interpretation of the topics addressed in the
  144 +mindset may also modify their perceptions on the topics addressed in the
121 145 questionnaire and consequently their responses.
122 146  
123 147 Finally, we collected a significant amount of data and testimonials related to
124   -the teaching of software engineering. We consider that the project studied is
125   -also an educational case. It is an example of how to teach information
126   -technology students FLOSS and agile approaches applied to production-level
127   -software development. As future work, we intend to analyze this collected
128   -information to propose improvements in the teaching of software engineering for
129   -undergraduates.
  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/spb-oss-2018.tex
  Diff comments   View file @541711f
1   -\documentclass{llncs}
2 1  
  2 +\documentclass{llncs}
  3 +\usepackage[table,xcdraw]{xcolor}
3 4 \usepackage{llncsdoc}
4 5 \usepackage{graphicx,url}
5 6 \usepackage[utf8]{inputenc}
6 7 \usepackage{float}
7 8 \usepackage{setspace}
8   -
  9 +\usepackage{hyphenat}
9 10 \usepackage{tabularx}
10 11 \usepackage{cite}
11 12 \usepackage{hyperref}
12 13 \usepackage{comment}
13 14 \usepackage{todonotes}
  15 +\usepackage{colortbl}
14 16 %------------------------------------------------------------------------------
15 17  
16 18 \begin{document}
... ...