revisando Development Organization and Process

Leonardo Leite
1 parent beca6124
Showing 1 changed file with 81 additions and 81 deletions Show diff stats
opensym2017/content/08-process.tex
@@ -2,113 +2,112 @@
 \label{sec:process}
 The SPB team was composed of a variety of professionals with different levels
-and skills, where most of them were undergraduate students with major in
-software engineering (from 4th semester or upper).  Since the students could
-not dedicate many hours per week to the project, they always had the
+and skills, where most of them were undergraduate students of
+software engineering. Since students could
+not dedicate many hours per week to the project, they had the
 flexibility to negotiate their work schedule during the semester in
-order to not harm their classes and coursework. Their daily work routine
+order to not harm their classes and coursework. Their work routine
 in the project included programming and DevOps tasks.
-The development of SPB project required a vast experience and background that
-usually undergraduate students do not have yet. For this reason, a few senior
-developers have joined to the project to help with the more difficult issues
+The project required a vast experience and background that
+usually undergraduate students do not have. For this reason, a few senior
+developers have joined the project to help with the more difficult issues
 and to transfer knowledge to the students. Their main task was to provide
-solutions for complex problems, in other words, they worked as developers. As
-these professionals are very skillful and the project could not fund a full
-time work for them, some of them worked partially on the project. In addition,
-they lived in a different states spread around Brazil which led much of the
+solutions for complex problems, working as developers. As
+these professionals are very skillful and the project could not fund full-time
+work for all of them, some of them worked partially on the project. In addition,
+they lived in different Brazilian states, which led much of the
 communication to be online.
 In short, our work process was based on open and collaborative software
-development practices. The development process was defined based on the
-adaptation of different agile and FLOSS communities practices, highlighting the
+development practices. The development process was based on the
+adaptation of different agile and FLOSS communities practices, with a
 high degree of automation resulting from DevOps practices. Thus, the work
 process was executed in a cadenced and continuous way.
 Finally, the last group of actors of this project was composed of employees
-formally working for the Brazilian government, in the Ministry of Planning,
+of the Brazilian Ministry of Planning,
 Development, and Management (MP is the Brazilian acronym). All the project
-decisions, validations, and scope definitions were made by them. In this way we
-developed software product incrementally, with releases aligned to business
-strategic objectives. As one can see, the project had many different
-sort of stakeholders that had to be organized and synchronized.
+decisions, validations, and scope definitions were made by them. In this way, we
+incrementally developed a software product with releases aligned to 
+strategic business objectives. As one can see, the project had a wide range
+of different stakeholders that had to be organized and synchronized.
 \subsection{Team organization}
-Approximately 70\% of the development teams were composed of software
+Approximately 70\% of the development team was composed of software
 engineering undergraduate students from UnB and they worked physically
 in the same laboratory. Each student had their own schedule based on
-their classes, what complicates the implementation of pair programming.
-The senior developers tried to synchronize their schedule with the
-students on their sub-team. To  cope with this environment, we had a few
-basic rules which guided the project organization:
+her classes, what complicates the implementation of pair programming.
+The senior developers tried to synchronize their schedule with 
+students schedules. To  cope with this scenario, we had a few
+basic rules guiding the project organization:
 \begin{enumerate}
   \item Classes have high priority for undergraduate students;
-  \item Work in pairs whenever possible (locally or remotely);
-  \item There must be one morning or afternoon per week when
-    \emph{everyone} should be together physically in the laboratory
-    (except of course the remote team members);
-  \item Every 3 to 4 months, the senior developers would fly in and work
+  \item Pairing whenever possible (locally or remotely);
+  \item We had one morning or afternoon per week when
+    \emph{everyone}, but the remote members, 
+    should be together physically in the laboratory;
+  \item Every 3 to 4 months the senior developers would travel to work
     alongside the students for a few days.
 \end{enumerate}
 With the aforementioned rules we divided all the project into four
-different teams: Colab, Noosfero, Design, and DevOps. Each team had one
-coach responsible for reducing the communication problem with the other
-teams and help the members to organize themselves in the best way for
-everyone (always respecting their work time). The coach was one of the
-students working in some of the teams with the extra duty of registering
-the current tasks developed in the sprint and with the responsibility to
-talk with other teams. One important thing to notice is the mutability
-of the team and the coach, during the project many students changed
-between the teams to try different areas.
+different teams: Colab, Noosfero, Design, and DevOps. One student of each team was the
+coach, responsible for reducing the communication problem with other
+teams and helping the members to organize themselves in the best way for
+everyone (always respecting their work time). The coach
+had also the extra duty of registering
+the current tasks developed in the sprint.
+One important thing to notice is the mutability
+of the team and the coach. During the project many students changed
+their teams to try different areas.
 One characteristic of the teams was the presence of (at least) one
 senior per team. This was essential, because hard decisions and complex
-problems were usually referred to them. This kept having to take
-complicated technical decisions from the coach tole, what encouraged
+problems were usually referred to them. So, it was not the coach role
+to deal with complicated technical decisions, what encouraged
 students to be coaches. Lastly, the senior developers worked directly
-with the students, and this was important to give the undergraduate the
-opportunity to interact with a savvy professional in his area and to
+with the students, and this was important to give to students the
+opportunity to interact with a savvy professional in their areas and to
 keep the knowledge flowing in the project.
-Finally, we had to add two last elements of the team organization, that
-was essential for the project harmony: the meta-coach and professors.
-The former was a software engineer recently graduated and which wanted
-to keep working on the project, the latter were professors that
+Finally, we had to add two more elements to the team organization that
+were essential for the project harmony: the meta-coach and professors.
+The former was a software engineer recently graduated that wanted
+to keep working on the project. The latter were professors that
 orchestrated all the interactions between all members of the project.
 The meta-coach usually worked in one specific team and had the extra
-task of knowing the current status of all teams. Professors and
-meta-coaches worked together to reduce the communication problem between
-all the teams. Lastly, all the paperwork tasks, such as reporting on the
-project progress to the Ministry, was handled by the professors.
+task of knowing the current status of all teams. Professors and the
+meta-coach worked together to reduce the communication problem among
+teams. Lastly, all the paperwork tasks, such as reporting on the
+project progress to the Ministry, was handled by professors.
 \subsection{Communication and management}
-Our team had many people working together, and most of the seniors worked in a
-different city remotely. Also, we tried to keep our work completely clear to
+Our team had many people working together, and most of the seniors worked in
+different cities remotely. Also, we tried to keep our work completely clear to
 the Brazilian government and citizens interested in following the project. To
-handle those cases, we used a set of tools to communication and other to manage
-the project.
+handle these cases, we used a set of communication and management tools.
-For communication between members in different places, we used: video
+For communication between members in different places we used: video
 conferencing with shared terminal tools, IRC, and mailing lists. For example,
 when one student had to work in pair with a senior, normally, they used video
 conferencing tool for talking and shared a terminal session (both typing and
-seeing the screen in real time). For questions and fast discussion, we used
+seeing each other screen in real time). For questions and fast discussion, we used
 IRC. For general notification, we used the mailing lists.
 For managing the project we used the SPB Portal itself; first to validate it by
 ourselves, and also because it had all the required tools. We basically created
 one wiki page per release in the SPB Gitlab instance with a mapping between
-strategical, tactical, and operational views. In a practical point of view, one
-milestone per user history (feature), and one or more issues for addressing
+strategical, tactical, and operational views. We had one
+milestone per user history (feature) and one or more issues for addressing
 each feature. With this approach we achieved two important goals: keeping all
-the management as close possible to to the source code, and tracking every
+the management as close as possible to the source code and tracking every
 feature developed during the project. Our decision to
-use Wiki initially was empirical, but later reinforced by a research conducted
-by Joseph Chao showing the advantage of using Wikis \cite{chao2007student,
+use the Wiki initially was empirical, but later reinforced by a research conducted
+by Joseph Chao showing the advantage of using Wikis~\cite{chao2007student,
 opensourcestyle}.
 \subsection{High-level project management and reporting}
@@ -117,14 +116,14 @@ The Brazilian government used to work with software development in a
 very traditional way. They would frequently focus on documents and not
 on what was, in our opinion, what really matters: working software. This
 dissonance caused us a communication noise with MP, because they would
-often question our work style.  It was especially hard to convince them
+often question our work style. It was especially hard to convince them
 to accept the idea of open scope and agile development, but after months
 of labor and showing results they stopped resisting.
 We defined some level of meeting granularity to avoid generating too
-much overhead to the developers. We had a strategical and validating
+much overhead to the developers. We had a strategical and a validating
 meeting with MP (the former once in a month and the latter each 15th
-day), release plaining with the entire team (one per month), and finally
+day), a release planning with the entire team (one per month), and finally
 a sprint planning (one each 15th day).  Figure \ref{fig:meeting} is a
 diagram that represents our meeting organization.
@@ -141,41 +140,42 @@ coach of each team, the meta-coach, and some employees of the MP would
 participate in this meeting. We usually discussed what the team already
 produced since our last meeting, and established the new features for
 the next release.  Notice that just part of the team would join this
-meeting to avoid generating unnecessary overhead to the developers, but
-all the students interested to participate were allowed to join (many
-students wanted this experience during the project).
+meeting to avoid generating unnecessary overhead to developers, but
+all the students interested to participate were allowed to join, since many
+students wanted this experience during the project.
 After the strategical meeting with Brazilian government agents, we had a
-planning turn with all teams together. In this part, each team worked together
+planning phase with all teams together. In this part, each team worked together
 to convert the MP wishes into smaller parts which were represented by the epics of
-the release. Each coach was responsible for conducting the planning, and after
-that record it on the project wiki (the wiki provided by Gitlab). With this
-epic, each 14th day the team have generated their sprint scheduler (with small
+the release. Each coach was responsible for conducting the planning and 
+recording it on the project wiki (the wiki provided by Gitlab). With this
+epic, each 14th day the team have documented their sprint schedule (with small
 achievements mapped to issues).
 To keep the Brazilian government always updated, we invited them to work
 with us to validate the new features in progress. Normally we had a
-meeting each 15th day. Basically, this was our work flow, we always kept
+meeting each 15th day. Basically, this was our work flow. We always kept
 everything extremely open to the MP (our way of working, and the one
 often used by open source projects) and to the team.
-To keep the track of all of those things we used the SPB itself,
+To keep the track of all of these things we used the SPB itself,
 especially Gitlab. Basically, we had:
 \begin{enumerate}
-  \item Project repository: We have one organization with many repositories;
-  \item Milestones: Each milestone was used to register a release;
-  \item Wiki: Each release has one page on wiki with the compilation of
+  \item Project repository: we have one organization with many repositories;
+  \item Milestones: each milestone was used to register a release;
+  \item Wiki: each release has one wiki page with the compilation of the
     strategical meeting;
-  \item Issues: Each sprint planning generated issues, which we associated to
-    the specific milestone and updated the wiki with the issue number related
-    with them. Finally each developer assigned the issue to itself.
+  \item Issues: each sprint planning generated issues, which we associated to
+    the related milestone and registered on the related wiki page.
+    Finally, each developer assigned the issue to herself.
 \end{enumerate}
 Notice that this workflow gave us and the Brazilian government agents full
 traceability from a high level view of each feature to the lowest level (code).
-It is important to highlight that we converge to this workflow after many
+It is important to highlight that we converged to this workflow after many
 experiments. For example, we used a tool named Redmine for organizing our tasks
-during the sprints, however, this tool revealed inefficient for our case since
+during some sprints. However, this tool revealed to be inefficient for our case since
 the government agents lost part of the project traceability. We realized that
-centralize all the work in the SPB portal is the best option for our case.
+centralize all the work in the SPB portal was the best option for our case.
+