Download as
Browse Code »

Commit 12218a558e64ca51b9c3a7fafc7c001e4909cd41

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

[oss-2018] review the first macro-decision

Showing 1 changed file with 64 additions and 40 deletions   Show diff stats
oss2018/content/04-results.tex
  Diff comments   View file @12218a5
1 1 \section{Results}
2 2 \label{sec:results}
3 3  
4   -The case study had two phases according to the project management model. In the
5   -second phase (about one year of execution), several practices have been applied
6   -to harmonize the cultural and organizational divergences of the institutions
7   -involved. At the end of the project, an empirical model of management and
8   -development process was stabilized by aligning experiences from the open source
9   -ecosystem, academic research, and bureaucracies needed by the government. In
10   -this section, we present by context the practices adopted in this second phase
11   -and show the benefits generated by its deployment.
12   -
13   -\subsection{Project management and communication on the developing platform
14   -itself}
15   -
16   -After nine months of project activities, the first version of new SPB Portal
17   -was released. From this point, we started to migrate the management and
18   -communication interactions to the platform under development. In short, Wiki
19   -feature was used for meeting logging, defining goals, sprint planning, and
20   -documentation of deployment processes and administration resources guide. Issue
21   -tracker was used for discussing requirements, monitoring the features under
22   -development, registering changes, and validating functionalities delivered.
23   -Finally, the whole team used the Mailing list to defining schedules of meetings and
24   -deliveries and also to the collaborative definition of requirements.
  4 +We divided the case study into two phases, according to the traceability of the
  5 +project management activities. We consider the first phase, between January
  6 +2014 and March 2015, as non-traceable. In this period, only UnB managed the
  7 +development activities. The inter-institutional monitoring of the project was
  8 +reduced to the definition of strategic goals in meetings between coordinators,
  9 +and the communication between government and academia was dispersed in private
  10 +channels, such as professional e-mails, personal meetings, and telephone calls.
  11 +Because of this, the quantitative data found for this period are inconclusive or
  12 +have little expressiveness, and we did not examine them.
  13 +
  14 +The second phase, from April 2015 to the end of the project (June 2016), has a
  15 +more considerable wealth of data. Much of the management and communication
  16 +activities were recorded and published on online channels and tools. During
  17 +this period, several open source practices were applied to the development
  18 +process to harmonize the cultural and organizational divergences of the
  19 +institutions involved. At the end of the project, an empirical model of
  20 +communication and management was built using experiments in free software
  21 +ecosystems to cater to government bureaucracies.
  22 +
  23 +In this section, we list the macro-decisions taken intuitively during the
  24 +project and the practices that made these decisions concrete. We use data
  25 +collected from the main repository to map best practices and, with the
  26 +respondents' answers, we analyzed how each decision benefited the project
  27 +collaboration.
  28 +
  29 +\subsection{Use of system under development to develop the system itself}
  30 +
  31 +The first version of the new SPB portal was released in production nine months
  32 +after the project beginning. Due to the platform features for software
  33 +development and social network, the UnB coordinators decided to use the system
  34 +under construction to develop the system itself. Gradually, in addition to
  35 +development activities, government and academia migrated the project management
  36 +and communication between teams to the portal environment. In short, the wiki
  37 +feature was used for logging meetings, defining goals, planning sprints,
  38 +documenting deployment procedures and user guides. The issue tracker was used
  39 +for discussing requirements, monitoring features under development, requesting
  40 +and recording changes, and validating the delivered funcionalities. Finally, the
  41 +mailing list was used by the entire team for collaboratively constructing
  42 +requirements, defining schedules, and scheduling meetings between institutions.
25 43  
26 44 Our surveys report Mailing list (100\%) and Issue Tracker (62.5\%) as the main
27   -means of interaction between senior developers and undergraduates. Developers
  45 +means of interaction between senior developers and interns. Developers
28 46 and MPOG staff also interacted mostly via Mailing List (87.5\%) and Issue
29   -tracker (50\%). According to research findings, this movement made
30   -\textbf{communication more transparent and efficient}. An MPOG IT analyst said
31   -that the \textit{``Communicating well goes far beyond the speed, it is someone
32   -being able to communicate to everyone everything that is happening in the
33   -project. We did not use emails. We use more mailing list and avoid e-mails. It
34   -helped a lot because everything was public and did not pollute our mailbox. You
35   -wanted to know something, could go there and look at what was happening''}.
36   -
37   -Migrating to SPB platform also provided an \textbf{easier monitoring and
38   -increase interactions between the development team and public servants by
39   -coordinators}. As shown by collected data, in the last 15 months of the
40   -project, the issues have 59 different authors (8 from MPOG staff) and
41   -commented by 64 different users (9 from MPOG staff and users). Considering
42   -issues with a higher level of interaction those that have 10 or more comments, in
43   -a set of 102 issues, MPOG staff authored 43 issues (which represents 42\% of
44   -these most active issues). An MPOG analyst highlighted that \textit{``there was
  47 +tracker (50\%). According to answers, this movement made the
  48 +\textbf{communication more transparent and efficient}. An MPOG analyst said
  49 +that \textit{``Communicating well goes far beyond the speed. It means enabling
  50 +someone to tell everyone about everything that is happening in the project. We
  51 +did not use emails, we use more mailing list and avoid emails. This usage helped
  52 +us a lot because everything was public and did not pollute our email box. So,
  53 +when you wanted to know something, you could access the SPB list to see
  54 +everything that was happening''}.
  55 +
  56 +Migration to the SPB platform also \textbf{easied coordinator monitoring
  57 +activities and increased interactions between developers and public servants}.
  58 +The data collected from the repository evidence the frequent use of the platform
  59 +by the academic team and the government team. In the last 15 months of the
  60 +project, the main project issues were opened by 59 different authors, 8 of them
  61 +MPOG agents. These issues received comments from 64 distinct users, 9 of them
  62 +from MPOG. When we consider the issues with much interaction, those who had ten
  63 +comments or more, we realized that the government team also felt more
  64 +comfortable using the tool to interact directly with the development team. In a
  65 +set of 102 issues with much interaction, MPOG staff created 43 of them (this
  66 +represents 42\% of the most active issues). An MPOG analyst highlighted that \textit{``there was
45 67 a lot of evolution, a lot of communication via Gitlab''}. This interaction
46   -also led MPOG staff to \textbf{trust developed code}: \textit{``Everything was
  68 +also led MPOG staff to \textbf{trust in developed code}: \textit{``Everything was
47 69 validated, we tested the features and we developed the project inside the
48 70 platform so that the feature was validated in the development of the software
49 71 itself. From the moment we installed it and began to use it for development,
50 72 this validation was constant. We felt confident in the features''}.
51 73  
  74 +%Morri aqui (Melissa)
  75 +
52 76 One of the main concerns of traditional approaches is meticulous documentation of
53 77 the software designed and the development steps. With this aforementioned
54 78 decision, we could meet this government demand without bureaucracies and
... ... @@ -59,7 +83,7 @@ documented in the e-mails and also in the portal itself. At any moment we can
59 83 go there and see how it worked, how someone did something. We can recover those
60 84 good points''}.
61 85  
62   -\subsection{Bringing together government staff and development team}
  86 +\subsection{Bring together government staff and development team}
63 87  
64 88 The MPOG analysts observed communication noise in the dialogue between them and
65 89 their superiors and in dialogues with the development team,
... ...