Download as
Browse Code »

Commit ae483700f44886e41de81a5a42317d00a41bbddf

Authored by Paulo Meireles
1 parent c54bac8b
Exists in master and in 3 other branches oss_2018, oss_2018_siqueira, rework_case_study

[opensym] reviewing the 'process' section

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