diff --git a/opensym2017/content/08-process.tex b/opensym2017/content/08-process.tex index e1535e8..3ea56a7 100644 --- a/opensym2017/content/08-process.tex +++ b/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. -- libgit2 0.21.2