Commit cfc06e6a50ec6637d3059acf9926cd4f043d90ae
1 parent
e6f5e016
Exists in
master
and in
3 other branches
Added first draft of the process
Showing
1 changed file
with
38 additions
and
10 deletions
Show diff stats
opensym2017/content/04-process.tex
| 1 | \section{Development Organization and Process} | 1 | \section{Development Organization and Process} |
| 2 | \label{sec:process} | 2 | \label{sec:process} |
| 3 | 3 | ||
| 4 | -%TODO: Siqueira e Hilmer | 4 | +The SPB members were composed of a variety of professionals with different levels and skills. Most of them were undergraduate students with major in software engineering (from 4th semester or upper), hence they could not dedicate many hours in the project per week. In their daily lives in the project, they had programming and devops tasks. It is important to highlight that the students always had the flexibility to negotiate their work hours during the semester, because we tried to not cause any damage to their grades. |
| 5 | 5 | ||
| 6 | -* Estratégico, Tático e Operacional | 6 | +The development of SPB project required a vast experience and background that usually undergraduate students do not have yet, because of this, some senior developer joined to the project to help with hard issues and to transfer knowledge to the students. Their tasks were technical and provide solution to hard problems, in other words, they worked as a developer. All the senior lived in a different states spread around Brazil, and all the communication was made via internet. Finally, those professionals are very skilful and the project could not afford a full time work for them and as a result, some of them worked partially on the project. |
| 7 | 7 | ||
| 8 | -* Reuniões estratégicas 1 vez por mês | 8 | +Finally, the last group of actors of this project was composed of employees formally work for the Brazilian Government, in the Ministery of Planning, development and Management (MPOG is the Brazilian acronyms). All the project decisions, validations, and scope definitions were made by them. |
| 9 | 9 | ||
| 10 | -* Revisões a cada 15 dias | 10 | +\subsection{Teams organizations} |
| 11 | 11 | ||
| 12 | -* Planejamento geral (Wiki), Histórias como Milestones e Atividades como Issues | 12 | +More than X\% of the teams was composed of undergraduate students and they worked physically in the same laboratory in opposite of the senior. Each student had their own scheduler based on their class, it made hard to implement pair programming. Also, they had a different area of interests. To cope with all this diversity we had two basic rules which guided the project organization: |
| 13 | 13 | ||
| 14 | -* Professores, Sêniors, Plenos, Alunos | 14 | +\begin{enumerate} |
| 15 | + \item Classes have to be the top priority for undergraduate students; | ||
| 16 | + \item Always work in pair (locally or remotely). | ||
| 17 | +\end{enumerate} | ||
| 15 | 18 | ||
| 16 | -* horários não padronizados dos alunos | 19 | +With the aforementioned ideas 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 itself in the best way for everyone (always respecting the work time). 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. |
| 17 | 20 | ||
| 18 | -* coach e meta-coach | 21 | +One important characteristic in the team organization was the presence of (at least) one senior per team. This was essential, once hard decisions and complex problems were usually addressed to them, this relieved the coach of the duty to take a complicated technical decisions (this encouraged students to be a coach). Lastly, the senior had to respect a rule number two and work with some student, this was important to give the undergraduate the opportunity to interact with a savvy professional in his area and keeping the knowledge flow in the project. |
| 19 | 22 | ||
| 20 | -* "turno sagrado" -> um turno que em todos trabalhavam juntos | 23 | +\subsection{Meetings} |
| 21 | 24 | ||
| 22 | -* "imersão presencial" a cada 2 meses com os sêniors e plenos | 25 | +Brazilian government used to work with software development in a very traditional way, frequently they focused on documents and does not focus on what really matter: running software. This way of thinking caused to us a communication noise with MPOG, because they constantly tried to leverage on our work style. It was especially hard to convince them to work with open scope and agile development, but after months of work and showing results they stopped resisting. |
| 26 | + | ||
| 27 | +After many interactions with MPOG, they started to trust in our work and we defined some level of meeting granularity to avoid to generate overheads to the developers. We had a strategical and validating meeting with MPOG (the former once in a month and the latter each 15th day), release plaining with the entire team (one per month), and finally a sprint planning (one each 15th day). | ||
| 28 | + | ||
| 29 | +In the strategical meeting we usually defined the priorities and new features with MPOG (we always had to negotiate a bunch of things). Normally the professors, the coach of each team, and the employees of MPOG join in this meeting. In this meeting we usually discussed what the team already produced since our last meeting, and we establish the new features for the next release. Notice that just part of the team join in this meeting to avoid generating unnecessary overhead to the developers, but all the students interested to participate was accepts (many students wanted this experience during the project). | ||
| 30 | + | ||
| 31 | +After the strategical meeting with MPOG, we had a planning turn with all teams together. In this part, each team works together to convert the MPOG wishes into small parts which was represented by the epics of the release. Each coach was responsible for conducting the planning, and after that register 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 achievements mapped in issues). | ||
| 32 | + | ||
| 33 | +To keep MPOG always as part of the project, 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 MPOG (our way of work and open source projects) and to the team. | ||
| 34 | + | ||
| 35 | +To keep the track of all of those things we used the SPB, especially the Gitlab. Basically, we had: | ||
| 36 | + | ||
| 37 | +\begin{enumerate} | ||
| 38 | + \item Project repository: We have one organization with many repositories | ||
| 39 | + \item Milestones: Each milestone is used to register a release | ||
| 40 | + \item Wiki: Each release has one page on wiki with the compilation of | ||
| 41 | + strategical meeting | ||
| 42 | + \item Issues: Each sprint planning generated issues, which we associated to | ||
| 43 | + the specific milestone and updated the wiki with the issue number related | ||
| 44 | + with them. Finally each developer assigned the issue to itself. | ||
| 45 | +\end{enumerate} | ||
| 46 | + | ||
| 47 | +Notice that this workflow gave to us and to the MPOG a full traceability from | ||
| 48 | +high view of the feature to the low view (code). This provided a way to MPOG | ||
| 49 | +validated all worked done and proof the concept that work with open source | ||
| 50 | +project can give a proper view to them check. |