Commit 1ca16db8f0d875d1209d4213e14c9169ad0dfa8b
1 parent
f7e06b78
Exists in
master
and in
3 other branches
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 | + | ... | ... |