Commit 1ca16db8f0d875d1209d4213e14c9169ad0dfa8b

Authored by Paulo Meireles
1 parent f7e06b78

Reviewing the Process section

Showing 1 changed file with 63 additions and 43 deletions   Show diff stats
opensym2017/content/07-process.tex
1 1 \section{Development Organization and Process}
2 2 \label{sec:process}
3 3  
4   -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).
5   -Since the students could not dedicate many hours per week to the project, they always had the flexibility to negotiate their work schedule during the semester in order not to cause any damage to their grades. Their daily work routine in the project included programming and devops tasks.
6   -
7   -The development of SPB project required a vast experience and background that usually undergraduate students do not have yet. For this reason, some senior developers have joined to the project to help with hard issues and to transfer knowledge to the students. Their main task was to provide solutions for complex problems, in other words, they worked as a developer. 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 communication to be made via Internet.
8   -
9   -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 FOSS communities practices, highlighting the high degree of automation resulting from DevOps practices. Thus, the work process was executed in a cadenced and continuous way.
  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
  8 +flexibility to negotiate their work schedule during the semester in order not
  9 +to cause any damage to their grades. Their daily work routine in the project
  10 +included programming and devops tasks.
  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, some senior
  14 +developers have joined to the project to help with hard issues and to transfer
  15 +knowledge to the students. Their main task was to provide solutions for complex
  16 +problems, in other words, they worked as a developer. As these professionals
  17 +are very skillful and the project could not fund a full time work for them,
  18 +some of them worked partially on the project. In addition, they lived in a
  19 +different states spread around Brazil which led much of the communication to be
  20 +made via Internet.
  21 +
  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 FOSS communities practices, highlighting the
  25 +high degree of automation resulting from DevOps practices. Thus, the work
  26 +process was executed in a cadenced and continuous way.
10 27  
11 28 Finally, the last group of actors of this project was composed of employees
12   -formally working for the Brazilian Government, in the Ministery of Planning,
13   -development and Management (MPOG is the Brazilian acronyms). All the project
14   -decisions, validations, and scope definitions were made by them. In this way we developed software product increments, releases, aligned with business strategic objectives. As can be
15   -seen, the project had many kinds of profiles that had to be organized and
16   -synchronized.
  29 +formally working for the Brazilian government, in the Ministery of Planning,
  30 +Development, and Management (MP is the Brazilian acronyms). All the project
  31 +decisions, validations, and scope definitions were made by them. In this way we
  32 +developed software product increments, releases, aligned with business
  33 +strategic objectives. As can be seen, the project had many kinds of profiles
  34 +that had to be organized and synchronized.
17 35  
18 36 \subsection{Teams organizations}
19 37  
20   -Approximately 70\% of the development teams were composed of software engineering undergraduate students from UnB and they
21   -worked physically in the same laboratory in the opposite of the senior. Each
22   -student had their own scheduler based on their class, it made complicated to
23   -implement pair programming. Also, they had a different area of interests. To
24   -cope with those diversity, we had two basic rules which guided the project
25   -organization:
  38 +Approximately 70\% of the development teams were composed of software
  39 +engineering undergraduate students from UnB and they worked physically in the
  40 +same laboratory in the opposite of the senior. Each student had their own
  41 +scheduler based on their class, it made complicated to implement pair
  42 +programming. Also, they had a different area of interests. To cope with those
  43 +diversity, we had two basic rules which guided the project organization:
26 44  
27 45 \begin{enumerate}
28 46 \item Classes have to be the high priority for undergraduate students;
... ... @@ -81,27 +99,28 @@ Figure \ref{fig:meeting} is a diagram that represents our meeting organization.
81 99 \end{figure}
82 100  
83 101 In the strategical meeting we usually defined the priorities and new features
84   -with MPOG (we always had to negotiate next steps with them). Normally the
85   -professors, the coach of each team, the meta-coach, and some employees of MPOG
86   -join in this meeting. We usually discussed what the team already produced since
87   -our last meeting, and we establish the new features for the next release.
88   -Notice that just part of the team join in this meeting to avoid generating
89   -unnecessary overhead to the developers, but all the students interested to
90   -participate was allowed to join (many students wanted this experience during
91   -the project).
92   -
93   -After the strategical meeting with MPOG, we had a planning turn with all teams
94   -together. In this part, each team worked together to convert the MPOG wishes
95   -into small parts which was represented by the epics of the release. Each coach
96   -was responsible for conducting the planning, and after that register it on the
97   -project wiki (the wiki provided by Gitlab). With this epic, each 14th day the
98   -team have generated their sprint scheduler (with small achievements mapped in
99   -issues).
100   -
101   -To keep MPOG always updated, we invited them to work with us to validate the
102   -new features in progress. Normally we had a meeting each 15th day. Basically,
103   -this was our work flow, we always kept everything extremely open to the MPOG
104   -(our way of work and open source projects) and to the team.
  102 +with the Brazilian government (we always had to negotiate next steps with
  103 +them). Normally the professors, the coach of each team, the meta-coach, and
  104 +some employees of the MP join in this meeting. We usually discussed what the
  105 +team already produced since our last meeting, and we establish the new features
  106 +for the next release. Notice that just part of the team join in this meeting
  107 +to avoid generating unnecessary overhead to the developers, but all the
  108 +students interested to participate was allowed to join (many students wanted
  109 +this experience during the project).
  110 +
  111 +After the strategical meeting with Brazilian government agents, we had a
  112 +planning turn with all teams together. In this part, each team worked together
  113 +to convert the MP wishes into small parts which was represented by the epics of
  114 +the release. Each coach was responsible for conducting the planning, and after
  115 +that register it on the project wiki (the wiki provided by Gitlab). With this
  116 +epic, each 14th day the team have generated their sprint scheduler (with small
  117 +achievements mapped in issues).
  118 +
  119 +To keep the Brazilian government always updated, we invited them to work with
  120 +us to validate the new features in progress. Normally we had a meeting each
  121 +15th day. Basically, this was our work flow, we always kept everything
  122 +extremely open to the MP (our way of work and open source projects) and to the
  123 +team.
105 124  
106 125 To keep the track of all of those things we used the SPB, especially the
107 126 Gitlab. Basically, we had:
... ... @@ -116,10 +135,10 @@ Gitlab. Basically, we had:
116 135 with them. Finally each developer assigned the issue to itself.
117 136 \end{enumerate}
118 137  
119   -Notice that this workflow gave to us and to the MPOG a full traceability from
120   -high view of the feature to the low view (code). This provided a way to MPOG
121   -validated all worked done and proof the concept that work with open source
122   -project can give a proper view to them check.
  138 +Notice that this workflow gave to us and to the Brazilian government agents a
  139 +full traceability from high view of the feature to the low view (code). This
  140 +provided to them a way to validate all worked done and proof the concept that
  141 +work with open source project can give a proper view to them check.
123 142  
124 143 \subsection{Tools for communication and management}
125 144  
... ... @@ -143,4 +162,5 @@ one user history. With this approach we achieve two important things: keep all
143 162 the management close to the source code and tracked every feature developed by
144 163 the project.
145 164  
146   -% Ainda falta adicionar a parte da visita dos seniors e o turno sagrado
  165 +%TODO: Ainda falta adicionar a parte da visita dos seniors e o turno sagrado
  166 +
... ...