Download as
Browse Code »

Commit 7de3a40a99dbcf2e1ea4fd7f16b5578344eb9170

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

[opensym] Applying the Athos' review on the 'process' section

Showing 1 changed file with 17 additions and 17 deletions   Show diff stats
opensym2017/content/08-process.tex
  Diff comments   View file @7de3a40
... ... @@ -14,7 +14,7 @@ have joined the project to help with the more difficult issues and to transfer
14 14 knowledge to the students. Their main task was to provide solutions for complex
15 15 problems, working as developers. As these professionals are very skillful and
16 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
  17 +part-time on the project. In addition, they lived in either different Brazilian
18 18 states or other countries, which led much of the communication to be online.
19 19  
20 20 In short, our work process was based on open and collaborative software
... ... @@ -99,9 +99,9 @@ between strategical, tactical, and operational views. We had one milestone per
99 99 user history (feature) and one or more issues for addressing each feature. With
100 100 this approach we achieved two important goals: keeping all the management as
101 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}.
  102 +during the project. Initially, our decision to use the Wiki was empirical, but
  103 +later such decision was reinforced by a research conducted by Joseph Chao
  104 +showing the advantage of using Wikis~\cite{chao2007student, opensourcestyle}.
105 105  
106 106 \subsection{High-level Project Management and Reporting}
107 107  
... ... @@ -122,10 +122,10 @@ they stopped resisting.
122 122  
123 123 We defined some level of meeting granularity to avoid generating too much
124 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.
  125 +the Brazilian Government (the former once in month and the latter biweekly), a
  126 +release planning with the entire team (one per month), and finally a sprint
  127 +planning (biweekly). Figure \ref{fig:meeting} is a diagram that represents our
  128 +meeting organization.
129 129  
130 130 In the strategical meeting we usually defined the priorities and new features
131 131 with the Brazilian Government. Normally the professors, the coach of each team,
... ... @@ -141,13 +141,13 @@ After the strategical meeting with Brazilian Government agents, we had a
141 141 planning phase with all teams together. In this part, each team worked together
142 142 to convert the Government wishes into smaller parts which were represented by
143 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).
  144 +planning and recording it on the project Wiki. With this epic, biweekly the
  145 +team have documented their sprint schedule (with small achievements mapped to
  146 +issues).
147 147  
148 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
  149 +us to validate the new features in progress. Normally we had a meeting
  150 +biweekly. Basically, this was our work flow. We always kept everything
151 151 extremely open to the Government (our way of working, and the one often used by
152 152 FLOSS projects) and to the team.
153 153  
... ... @@ -158,9 +158,9 @@ especially Gitlab. Basically, we had:
158 158 \item Project repository: we have one organization with many repositories;
159 159 \item Wiki: each release has one Wiki page with the compilation of the
160 160 strategical meeting;
161   - \item Milestones: each milestone was used to register a user history (feature);
  161 + \item Milestones: each milestone was used to register a user story (feature);
162 162 \item Issues: each sprint planning generated issues, which we associated to
163   - the related milestone (feature as user history) and registered on the related Wiki page.
  163 + the related milestone (feature as user story) and registered on the related Wiki page.
164 164 Finally, each developer assigned the issue to herself.
165 165 \end{enumerate}
166 166  
... ... @@ -170,6 +170,6 @@ code). It is important to highlight that we converged to this workflow after
170 170 many experiments. For example, we used a tool named Redmine for organizing our
171 171 tasks during some sprints. However, this tool revealed to be inefficient for
172 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.
  173 +realized that centralizing all the work in the SPB Portal was the best option
  174 +for our case.
175 175  
... ...