Download as
Browse Code »

Commit 689325b73bb2e3d5121da5a5dfe53ed2c7185fcb

Authored by Leonardo Leite
1 parent beca6124
Exists in master and in 3 other branches oss_2018, oss_2018_siqueira, rework_case_study

revisando Development Organization and Process

Showing 1 changed file with 81 additions and 81 deletions   Show diff stats
opensym2017/content/08-process.tex
  Diff comments   View file @689325b
... ... @@ -2,113 +2,112 @@
2 2 \label{sec:process}
3 3  
4 4 The SPB team was composed of a variety of professionals with different levels
5   -and skills, where most of them were undergraduate students with major in
6   -software engineering (from 4th semester or upper). Since the students could
7   -not dedicate many hours per week to the project, they always had the
  5 +and skills, where most of them were undergraduate students of
  6 +software engineering. Since students could
  7 +not dedicate many hours per week to the project, they had the
8 8 flexibility to negotiate their work schedule during the semester in
9   -order to not harm their classes and coursework. Their daily work routine
  9 +order to not harm their classes and coursework. Their work routine
10 10 in the project included programming and DevOps tasks.
11 11  
12   -The development of SPB project required a vast experience and background that
13   -usually undergraduate students do not have yet. For this reason, a few senior
14   -developers have joined to the project to help with the more difficult issues
  12 +The project required a vast experience and background that
  13 +usually undergraduate students do not have. For this reason, a few senior
  14 +developers have joined the project to help with the more difficult issues
15 15 and to transfer knowledge to the students. Their main task was to provide
16   -solutions for complex problems, in other words, they worked as developers. As
17   -these professionals are very skillful and the project could not fund a full
18   -time work for them, some of them worked partially on the project. In addition,
19   -they lived in a different states spread around Brazil which led much of the
  16 +solutions for complex problems, working as developers. As
  17 +these professionals are very skillful and the project could not fund full-time
  18 +work for all of them, some of them worked partially on the project. In addition,
  19 +they lived in different Brazilian states, which led much of the
20 20 communication to be online.
21 21  
22 22 In short, our work process was based on open and collaborative software
23   -development practices. The development process was defined based on the
24   -adaptation of different agile and FLOSS communities practices, highlighting the
  23 +development practices. The development process was based on the
  24 +adaptation of different agile and FLOSS communities practices, with a
25 25 high degree of automation resulting from DevOps practices. Thus, the work
26 26 process was executed in a cadenced and continuous way.
27 27  
28 28 Finally, the last group of actors of this project was composed of employees
29   -formally working for the Brazilian government, in the Ministry of Planning,
  29 +of the Brazilian Ministry of Planning,
30 30 Development, and Management (MP is the Brazilian acronym). All the project
31   -decisions, validations, and scope definitions were made by them. In this way we
32   -developed software product incrementally, with releases aligned to business
33   -strategic objectives. As one can see, the project had many different
34   -sort of stakeholders that had to be organized and synchronized.
  31 +decisions, validations, and scope definitions were made by them. In this way, we
  32 +incrementally developed a software product with releases aligned to
  33 +strategic business objectives. As one can see, the project had a wide range
  34 +of different stakeholders that had to be organized and synchronized.
35 35  
36 36 \subsection{Team organization}
37 37  
38   -Approximately 70\% of the development teams were composed of software
  38 +Approximately 70\% of the development team was composed of software
39 39 engineering undergraduate students from UnB and they worked physically
40 40 in the same laboratory. Each student had their own schedule based on
41   -their classes, what complicates the implementation of pair programming.
42   -The senior developers tried to synchronize their schedule with the
43   -students on their sub-team. To cope with this environment, we had a few
44   -basic rules which guided the project organization:
  41 +her classes, what complicates the implementation of pair programming.
  42 +The senior developers tried to synchronize their schedule with
  43 +students schedules. To cope with this scenario, we had a few
  44 +basic rules guiding the project organization:
45 45  
46 46 \begin{enumerate}
47 47 \item Classes have high priority for undergraduate students;
48   - \item Work in pairs whenever possible (locally or remotely);
49   - \item There must be one morning or afternoon per week when
50   - \emph{everyone} should be together physically in the laboratory
51   - (except of course the remote team members);
52   - \item Every 3 to 4 months, the senior developers would fly in and work
  48 + \item Pairing whenever possible (locally or remotely);
  49 + \item We had one morning or afternoon per week when
  50 + \emph{everyone}, but the remote members,
  51 + should be together physically in the laboratory;
  52 + \item Every 3 to 4 months the senior developers would travel to work
53 53 alongside the students for a few days.
54 54 \end{enumerate}
55 55  
56 56 With the aforementioned rules we divided all the project into four
57   -different teams: Colab, Noosfero, Design, and DevOps. Each team had one
58   -coach responsible for reducing the communication problem with the other
59   -teams and help the members to organize themselves in the best way for
60   -everyone (always respecting their work time). The coach was one of the
61   -students working in some of the teams with the extra duty of registering
62   -the current tasks developed in the sprint and with the responsibility to
63   -talk with other teams. One important thing to notice is the mutability
64   -of the team and the coach, during the project many students changed
65   -between the teams to try different areas.
  57 +different teams: Colab, Noosfero, Design, and DevOps. One student of each team was the
  58 +coach, responsible for reducing the communication problem with other
  59 +teams and helping the members to organize themselves in the best way for
  60 +everyone (always respecting their work time). The coach
  61 +had also the extra duty of registering
  62 +the current tasks developed in the sprint.
  63 +One important thing to notice is the mutability
  64 +of the team and the coach. During the project many students changed
  65 +their teams to try different areas.
66 66  
67 67 One characteristic of the teams was the presence of (at least) one
68 68 senior per team. This was essential, because hard decisions and complex
69   -problems were usually referred to them. This kept having to take
70   -complicated technical decisions from the coach tole, what encouraged
  69 +problems were usually referred to them. So, it was not the coach role
  70 +to deal with complicated technical decisions, what encouraged
71 71 students to be coaches. Lastly, the senior developers worked directly
72   -with the students, and this was important to give the undergraduate the
73   -opportunity to interact with a savvy professional in his area and to
  72 +with the students, and this was important to give to students the
  73 +opportunity to interact with a savvy professional in their areas and to
74 74 keep the knowledge flowing in the project.
75 75  
76   -Finally, we had to add two last elements of the team organization, that
77   -was essential for the project harmony: the meta-coach and professors.
78   -The former was a software engineer recently graduated and which wanted
79   -to keep working on the project, the latter were professors that
  76 +Finally, we had to add two more elements to the team organization that
  77 +were essential for the project harmony: the meta-coach and professors.
  78 +The former was a software engineer recently graduated that wanted
  79 +to keep working on the project. The latter were professors that
80 80 orchestrated all the interactions between all members of the project.
81 81 The meta-coach usually worked in one specific team and had the extra
82   -task of knowing the current status of all teams. Professors and
83   -meta-coaches worked together to reduce the communication problem between
84   -all the teams. Lastly, all the paperwork tasks, such as reporting on the
85   -project progress to the Ministry, was handled by the professors.
  82 +task of knowing the current status of all teams. Professors and the
  83 +meta-coach worked together to reduce the communication problem among
  84 +teams. Lastly, all the paperwork tasks, such as reporting on the
  85 +project progress to the Ministry, was handled by professors.
86 86  
87 87 \subsection{Communication and management}
88 88  
89   -Our team had many people working together, and most of the seniors worked in a
90   -different city remotely. Also, we tried to keep our work completely clear to
  89 +Our team had many people working together, and most of the seniors worked in
  90 +different cities remotely. Also, we tried to keep our work completely clear to
91 91 the Brazilian government and citizens interested in following the project. To
92   -handle those cases, we used a set of tools to communication and other to manage
93   -the project.
  92 +handle these cases, we used a set of communication and management tools.
94 93  
95   -For communication between members in different places, we used: video
  94 +For communication between members in different places we used: video
96 95 conferencing with shared terminal tools, IRC, and mailing lists. For example,
97 96 when one student had to work in pair with a senior, normally, they used video
98 97 conferencing tool for talking and shared a terminal session (both typing and
99   -seeing the screen in real time). For questions and fast discussion, we used
  98 +seeing each other screen in real time). For questions and fast discussion, we used
100 99 IRC. For general notification, we used the mailing lists.
101 100  
102 101 For managing the project we used the SPB Portal itself; first to validate it by
103 102 ourselves, and also because it had all the required tools. We basically created
104 103 one wiki page per release in the SPB Gitlab instance with a mapping between
105   -strategical, tactical, and operational views. In a practical point of view, one
106   -milestone per user history (feature), and one or more issues for addressing
  104 +strategical, tactical, and operational views. We had one
  105 +milestone per user history (feature) and one or more issues for addressing
107 106 each feature. With this approach we achieved two important goals: keeping all
108   -the management as close possible to to the source code, and tracking every
  107 +the management as close as possible to the source code and tracking every
109 108 feature developed during the project. Our decision to
110   -use Wiki initially was empirical, but later reinforced by a research conducted
111   -by Joseph Chao showing the advantage of using Wikis \cite{chao2007student,
  109 +use the Wiki initially was empirical, but later reinforced by a research conducted
  110 +by Joseph Chao showing the advantage of using Wikis~\cite{chao2007student,
112 111 opensourcestyle}.
113 112  
114 113 \subsection{High-level project management and reporting}
... ... @@ -117,14 +116,14 @@ The Brazilian government used to work with software development in a
117 116 very traditional way. They would frequently focus on documents and not
118 117 on what was, in our opinion, what really matters: working software. This
119 118 dissonance caused us a communication noise with MP, because they would
120   -often question our work style. It was especially hard to convince them
  119 +often question our work style. It was especially hard to convince them
121 120 to accept the idea of open scope and agile development, but after months
122 121 of labor and showing results they stopped resisting.
123 122  
124 123 We defined some level of meeting granularity to avoid generating too
125   -much overhead to the developers. We had a strategical and validating
  124 +much overhead to the developers. We had a strategical and a validating
126 125 meeting with MP (the former once in a month and the latter each 15th
127   -day), release plaining with the entire team (one per month), and finally
  126 +day), a release planning with the entire team (one per month), and finally
128 127 a sprint planning (one each 15th day). Figure \ref{fig:meeting} is a
129 128 diagram that represents our meeting organization.
130 129  
... ... @@ -141,41 +140,42 @@ coach of each team, the meta-coach, and some employees of the MP would
141 140 participate in this meeting. We usually discussed what the team already
142 141 produced since our last meeting, and established the new features for
143 142 the next release. Notice that just part of the team would join this
144   -meeting to avoid generating unnecessary overhead to the developers, but
145   -all the students interested to participate were allowed to join (many
146   -students wanted this experience during the project).
  143 +meeting to avoid generating unnecessary overhead to developers, but
  144 +all the students interested to participate were allowed to join, since many
  145 +students wanted this experience during the project.
147 146  
148 147 After the strategical meeting with Brazilian government agents, we had a
149   -planning turn with all teams together. In this part, each team worked together
  148 +planning phase with all teams together. In this part, each team worked together
150 149 to convert the MP wishes into smaller parts which were represented by the epics of
151   -the release. Each coach was responsible for conducting the planning, and after
152   -that record it on the project wiki (the wiki provided by Gitlab). With this
153   -epic, each 14th day the team have generated their sprint scheduler (with small
  150 +the release. Each coach was responsible for conducting the planning and
  151 +recording it on the project wiki (the wiki provided by Gitlab). With this
  152 +epic, each 14th day the team have documented their sprint schedule (with small
154 153 achievements mapped to issues).
155 154  
156 155 To keep the Brazilian government always updated, we invited them to work
157 156 with us to validate the new features in progress. Normally we had a
158   -meeting each 15th day. Basically, this was our work flow, we always kept
  157 +meeting each 15th day. Basically, this was our work flow. We always kept
159 158 everything extremely open to the MP (our way of working, and the one
160 159 often used by open source projects) and to the team.
161 160  
162   -To keep the track of all of those things we used the SPB itself,
  161 +To keep the track of all of these things we used the SPB itself,
163 162 especially Gitlab. Basically, we had:
164 163  
165 164 \begin{enumerate}
166   - \item Project repository: We have one organization with many repositories;
167   - \item Milestones: Each milestone was used to register a release;
168   - \item Wiki: Each release has one page on wiki with the compilation of
  165 + \item Project repository: we have one organization with many repositories;
  166 + \item Milestones: each milestone was used to register a release;
  167 + \item Wiki: each release has one wiki page with the compilation of the
169 168 strategical meeting;
170   - \item Issues: Each sprint planning generated issues, which we associated to
171   - the specific milestone and updated the wiki with the issue number related
172   - with them. Finally each developer assigned the issue to itself.
  169 + \item Issues: each sprint planning generated issues, which we associated to
  170 + the related milestone and registered on the related wiki page.
  171 + Finally, each developer assigned the issue to herself.
173 172 \end{enumerate}
174 173  
175 174 Notice that this workflow gave us and the Brazilian government agents full
176 175 traceability from a high level view of each feature to the lowest level (code).
177   -It is important to highlight that we converge to this workflow after many
  176 +It is important to highlight that we converged to this workflow after many
178 177 experiments. For example, we used a tool named Redmine for organizing our tasks
179   -during the sprints, however, this tool revealed inefficient for our case since
  178 +during some sprints. However, this tool revealed to be inefficient for our case since
180 179 the government agents lost part of the project traceability. We realized that
181   -centralize all the work in the SPB portal is the best option for our case.
  180 +centralize all the work in the SPB portal was the best option for our case.
  181 +
... ...