[opensym] reviewing the 'process' section

Paulo Meireles
1 parent c54bac8b
Showing 1 changed file with 129 additions and 135 deletions Show diff stats
opensym2017/content/08-process.tex
@@ -2,46 +2,43 @@
 \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 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 work routine
+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 work routine
 in the project included programming and DevOps tasks.
-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, 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.
+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, working as developers. As these professionals are very skillful and
+the project could not fund full-time work for all of them, they worked
+partially on the project. In addition, they lived in either different Brazilian
+states or other countries, 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 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
-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
-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 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
-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:
+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 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 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 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 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;
@@ -49,83 +46,72 @@ basic rules guiding the project organization:
   \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
+  \item Every 2 to 3 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. 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. 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 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 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 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}
+With the aforementioned rules, we divided all the project into four 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. Thus, 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 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 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 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 Brazilian Government, was handled by
+professors.
+
+\subsection{Communication and Management}
 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
+the Brazilian Government and citizens interested in following the project. To
 handle these cases, we used a set of communication and management tools.
 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 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. 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 as possible to the source code and tracking every
-feature developed during the project. Our decision to
-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}
-
-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
-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 a validating
-meeting with MP (the former once in a month and the latter each 15th
-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.
+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. 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 as possible to the source code and tracking every feature developed
+during the project. Our decision to 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}
+
+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 the Government, because they would 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.
 \begin{figure}[hbt]
   \centering
@@ -134,48 +120,56 @@ diagram that represents our meeting organization.
   \label{fig:meeting}
 \end{figure}
-In the strategical meeting we usually defined the priorities and new
-features with the Brazilian government. Normally the professors, the
-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 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
+We defined some level of meeting granularity to avoid generating too much
+overhead to the developers. We had a strategical and a validating meeting with
+the Brazilian Government (the former once in a month and the latter each 15th
+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.
+
+In the strategical meeting we usually defined the priorities and new features
+with the Brazilian Government. Normally the professors, the coach of each team,
+the meta-coach, and some employees of the Federal Government 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 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 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 
-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
-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 these things we used the SPB itself,
+to convert the Government wishes into smaller parts which were represented by
+the epics of the release. Each coach was responsible for conducting the
+planning and recording it on the project Wiki. With this epic, each 15th 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 everything
+extremely open to the Government (our way of working, and the one often used by
+FLOSS projects) and to the team.
+
+To keep the track of all of these things we used the SPB Portal 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 wiki page with the compilation of the
+  \item Wiki: each release has one Wiki page with the compilation of the
     strategical meeting;
+  \item Milestones: each milestone was used to register a user history (feature);
   \item Issues: each sprint planning generated issues, which we associated to
-    the related milestone and registered on the related wiki page.
+    the related milestone (feature as user history) 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 converged to this workflow after many
-experiments. For example, we used a tool named Redmine for organizing our tasks
-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 was the best option for our case.
+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 (source
+code).  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 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 was the best option for
+our case.