From 1928b7fae0836dfc91a0478246b73beb23157c64 Mon Sep 17 00:00:00 2001 From: Antonio Terceiro Date: Thu, 25 May 2017 12:43:44 -0300 Subject: [PATCH] 09-lessons.tex: review --- opensym2017/content/09-lessons.tex | 206 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------------------------------------------------------------------------------- 1 file changed, 120 insertions(+), 86 deletions(-) diff --git a/opensym2017/content/09-lessons.tex b/opensym2017/content/09-lessons.tex index 2c4b0ad..dd3839d 100644 --- a/opensym2017/content/09-lessons.tex +++ b/opensym2017/content/09-lessons.tex @@ -1,99 +1,133 @@ -\section{Lessons Learned and Conclusion} +\section{Lessons Learned} \label{sec:lessons} -%%% Acho que podemos organizar em algo assim, explicitando a lição%%% -%(Lesson 1 -- Students in real-world project interacting with real customers) - -The multidisciplinary of our development team - mainly composed of software -engineers undergraduate students, senior developers, and designers - makes that -naturally fit the project requirements and consequently achieve a high quality. -To collaborate to that, there was a stakeholder team of technicians and -managers from the Brazilian Government, as well as the management team from the -UnB. In particular at the being of the project, the different perceptions of -the Brazilian Government stakeholders generated a high complex communication -and management environment. Once we were practicing an empirical development -approach based on FOSS and agile methods, our development team also interacted -directly with the stakeholders to mitigate several moments of management -overhead, supporting the UnB professors those were responsible for the project -management. The interaction with professionals, that have different expertises, -and the participation in all levels of the software development process -contributed with a great learning opportunity for the students, which majority -have their first professional experience. - - -At the initial phases of the project, by political and personal motivation, the -main stakeholders from the Brazilian government imposed the use of Colab to -guide the development of the new SPB platform. Our team 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. - -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 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 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. - +\textbf{How to involve students real-world projects, interacting with +real customers.} +% +Our team was mainly composed of software engineering undergraduate +student, who had the opportunity to interact with senior developers and +designers inside the team, as well as with the team of technicians and +managers from the Brazilian Government, and the management team from +UnB. +% +They interacted with professionals that had diverse expertises, and were +able to participate in all levels of the software development process. +This contribted to a great learning opportunity, and for a majority of +them this was their first professional experience. + +\textbf{The participation of experienced professionals is crucial to +success of the project.} +One important factor for the students was the composition of the teams +with the participation of experienced professionals. +% +On the technical side, the senior developers and designers would handle +the more difficult technical decisions, creating a work environment +where the students could develop their skills in a didactic way without +pressure. +% +On the management side, the active participation of professors -- who +are, in the end, the ones responsible for the project -- is crucial to +make sure student participation is conducted in a healthy way, and is an +instance of leading by example. + +\textbf{A balanced relationship between academia and industry.} +The experience of the SPB project led UnB to develop a work style which +proved to be appropriate for an educational environment that brings +academia and industry together. +% +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 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. +% +And even under a potentially adverse environment, the project delivered +the desired solution with success. +% +At the end of the project, we noted that the skills developed by the +students were at the state of art of the software engineering practice. +After the project ended, we had team members successfully embracing +opportunities in public, private, national and international +organizations, in addition to those students that went into +entrepreneurship and opened their own companies. + +\textbf{Managing different organizational cultures.} +In the beginning of the project, the Brazilian Government stakeholders +had certain expectations about the development of project that, let's +say, didn't exactly match our work based on agile and FOSS practices. +% +We had to develop strategies that would support different these +organizational cultures. As reported in Section \ref{sec:process}, the +MP is organized in a functional hierarchical organizational structure, +typically, a traditional development paradigm. Therefore, we had to +create a translation process between our team and the MP managers who +managed the project on their side assuming a traditional, waterfall +process. + +\textbf{Manage higher-level and lower-level goals separately.} +During the initial phase of the project the MP team would often bring +strategic discussions to technical/operational meetings, where we were +supposed to discuss practical, technical decisions. +% +This produced a highly complex communication and management environment, +overloading the professors because they were supposed to be responsible +for maintaining the strategic alignment of the MP synchronized with +implementation plans of the development team, specially in light of the +aforementioned culture mismatch. Mixing both concerns in the same +discussions caused confusion on both sides. +% +Towards the middle and end of the project we were able to keep those +concerns separated, what eased the work of everyone involved. + +\textbf{Living with ill-advised political decisions.} +At the initial phases of the project, by political and personal +motivation, the main stakeholders from the Brazilian government imposed +the use of Colab to guide the development of the new SPB platform. Our +team was 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 was adamant and we had to manage this problem. As +explained in section \ref{sec:architecture} we did massive changes to +it, and at the end of the project we completely rewrote 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 resources that would be spent due to that decision. At the end +of the project, we verified that Colab indeed consumed a vast amount of +the budget and increased the project complexity. In the end of the +project and after our analysis on the decision made by the MP, we +understand that MP's managers are capable of ignoring technical reasons +in favor to a political decision. + +\textbf{Consider sustainability from the beginning.} +In the process of deploying the SPB platform in the MP structure, we had +to interact with the MP 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 technicians +constantly avoid the responsibility. After noticing the aforementioned +situation, we organized a specific DevOps that completely automated all +the deployment procedure. We simplified all the platform deployment to a +few steps: (1) initial configurations (just ssh configuration) and (2) +the execution of simple commands to completely update the platform. By +the end of the project, we observed that the MP technicians invariably +still depended on our support to update the platform even with all the +automation provided by us. We were sadly left with a feeling of +uncertainty about the future of the platform after the project ended. In +hindsight, we realize that the MP dedicated systems analysts and +managers to the project, but not operations technicians. The later +should have been more involved with the process so they could at least +comfortable with managing the platform infrastructure. + % * 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 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. - %=========== % Conclusion %=========== +\textbf{Final remarks.} The portal is available at \url{softwarepublico.gov.br}. All documentation, including detailed architecture and operation manuals are also available\footnote{\url{https://softwarepublico.gov.br/doc/} -- libgit2 0.21.2