diff --git a/opensym2017/content/09-lessons.tex b/opensym2017/content/09-lessons.tex index 1e2eec0..76bc0ee 100644 --- a/opensym2017/content/09-lessons.tex +++ b/opensym2017/content/09-lessons.tex @@ -1,77 +1,85 @@ \section{Lessons Learned} \label{sec:lessons} -The multidisciplinary composition of the development teams, mainly software -engineers and designers, is necessary for the development of good software -products, which naturally aim to meet the users needs. In the context of the -SPB project, there were also stakeholders from different areas who composed the -team of technicians and managers of the MP, as well as the administrative teams -of UnB. This interaction with different professionals brought a great learning -opportunity for the students, who had their first professional experience, even -during their graduation course. On the other hand, the different perceptions of -stakeholders generated high complexity of communications and expectations -management, burdening too much the professors who were responsible for project -management. +The multidisciplinary of the development teams - mainly composed of software +engineers and designers - it is necessary for the development of a software +product that naturally fit the user requirements and consequently achieve a +high quality. In the context of the SPB project, there was a stakeholders team +of technicians and managers of the MP, as well as the administrative team of +the UnB. The interaction with different professionals contributed as a great +learning opportunity for the students, which had their first professional +experience during their graduation course. On the other hand, the different +perceptions of the stakeholders generated a high complex communication and +management environment. All of this complication generated a lot of overhead +for the professors because they were responsible for the project management. -The use of the Colab tool was a requirement required by the MP. They argueed -that this tool presented functionalities that would allow MP managers to -stimulate the participation of SPB service providers with gamefication -practices. As we said, in order for Colab to perform the expected behavior in -SPB its architecture had to be completely redefined and this caused in -practice, (i) the considerable increase in the architectural complexity of the -SPB and (ii) it was the subsystem that consumed the most effort and budget -during development. +At the initial phases of the project, MP imposed the integration of Colab to +the platform by the claim that it had gamification features, which would +encourage MP managers to be active on the platform. Since the first moment that +MP demands it to us, we were totally against the idea because we already knew +that Colab was a very experimental project and its adoption could dramatically +increase the project complexity. Even though we provided technical reasons to +not utilize Colab, MP enforces it to us and we had to manage this problem. As +explained in section \ref{sec:architecture} we did a massive change in it, and +at the end of the project we completely rewrite Colab and made it stable. It is +important to notice that the MP compelled us to accept a technical issue based +only on political interests, without considering all the money they would spend +with their decision. At the end of the project, we verified that Colab consumed +a vast amount of the budget and indeed increased the project complexity. In the +end of the project and after our analyses on the decisions made by the MP, we +understand that MP's managers are capable of ignoring technical reasons in +favor to a political decision. -Due to the computational complexity related to the SPB deployment, associated -with the Brazilian government needs for product support, we made an effort to -provide complete automation of the entire deployment procedure, a result of -DevOps activities. In this way, we encapsulate all this complexity and enable -the deployment of new SPB releases through the execution of few commands, as -registered in the project documentation. Although we have provided a high -degree of automation, training workshops for the MP technical team, and a -meticulous description of the procedures in the documentation, we observed that -the MP technical staff invariably depended on our support to perform these -procedures. +In the process of deploying the SPB platform in the MP structure, we had to +interact with the MP's technicians. We did several workshops, training and a +meticulous documentation describing all the required procedures to update the +platform, however, we realized that the MP's technicians constantly avoid the +responsibility. After notice the aforementioned situation, we organized a +specific team to start a DevOps activities and interacts with all the UnB +teams. After a year of work, we completely automated all the deployment +procedure. We simplified all the platform implantation to a few steps: (1) +initial configurations (just ssh configuration) and (2) the execution of simple +commands to completely update the platform. In the end of the project, we +observed that the MP technical invariably depends on our support to update the +platform even with all the automation provided by us. From the point of view of management and development processes, we had to -develop management strategies that would accommodate different organizational -cultures. As reported, the MP has a functional hierarchical organizational -culture, strongly supported by process management, typical of the traditional -development paradigm. The UnB teams use a process based on agile manifest -values and FOSS and agile community practices. So we created a process of -"translation" of work done to communicate with MP managers who manage their -portfolio based on the PMBoK processes. On the one hand, in the intermediary -and final project's phases we have matured this process, mainly due to the -perception of the results by MP, on the other hand, in the initial phase we had -a lot of intervention in our work style, which ended up focusing strategic -discussions for operational discussions. Again there was an overload in -professors, who were responsible for maintaining the strategic alignment of the -MP with the day to day development of the UnB team. +develop strategies that would support different organizational cultures. As +reported in Section \ref{sec:process}, the MP is organized in a functional +hierarchical organizational structure, typically, a traditional development +paradigm. The UnB team works based on agile manifest values and FOSS community +practices. Therefore, we had to create a translation process to communicate +with MP managers who manage their project based on the PMBoK ideas. On the one +hand, in the intermediary and final project's phases, we had matured this +process, mainly due to the perception of the results by the MP, on the other +hand, in the initial phase we had a lot of intervention in our work style, +which ended up focusing strategic discussions for operational discussions. The +aforementioned situation created an overload to the professors because they +were responsible for maintaining the strategic alignment of the MP synchronized +with the development team. -Another importance factor for the students and maturing of the software -engineering practices used in the project was the composition of the teams with -the participation of experienced professionals from the FOSS communities. These -professionals together with the professors promoted a work environment where -the students could develop their skills in a didactic and practical way without -being transferred the pressures for them. In addition, these experienced -professionals were responsible for the most relevant technical decisions -related to the SPB software product. +Another important factor for the students was the composition of the teams with +the participation of senior professionals from the FOSS communities. These +professionals and professors promoted a work environment where the students +could develop their skills in a didactic way without transferring any pressure +to the students. Addition, these experienced professionals were responsible for +the most relevant technical decisions related to the SPB software product. % * Gestão dos recursos: Fizemos mais por menos (2.6M de 3.2M) --- sem os dados %% (escopo, custo, tempo e qualidade) bem discutidos é difícil sustentar essa %% afirmação, embora eu e Paulo consigamos perceber isso. -The experience of the SPB project led UnB to develop a model of team -composition and work style that proved to be appropriate to the cararteristics -of an education environment, bringing the academy closer to the industry. The -highest priority from the university's point of view is the students. -Considering this, the activities of the project were never prioritized to the -detriment of the classes and other didactic-pedagogical activities. In short we -had students working at different times, part time, remotely or presential, -always respecting their individual conditions, but doing the work in a -collective, collaborative and open way. At the end of the project we realized -that the skills developed by the students empowered them with the state in the -practice of software engineering. The members of the teams got opportunities to -work in public, private, national and international organizations, in addition -to those students they preferred entrepreneurship, opening their own companies. +The experience of the SPB project led UnB to develop a work style which proved +to be appropriated to the characteristics of an educational environment and +brings the academy closer to the industry. The highest priority from the +university's point of view is the students, considering this, the activities of +the project were never prioritized to the detriment of the classes and other +pedagogical activities. In summary, we had students working at different times, +part time, remotely or locally, always respecting their individual conditions, +but doing the work in a collective, collaborative and open way. At the end of +the project, we realized that the skills developed by the students empowered +them with the state in the practice of software engineering. The members of the +teams got opportunities to work in public, private, national and international +organizations, in addition to those students they preferred entrepreneurship, +opening their own companies. -- libgit2 0.21.2