Download as
Browse Code »

Commit 1928b7fae0836dfc91a0478246b73beb23157c64

Authored by Antonio Terceiro
1 parent 7344b937
Exists in master and in 3 other branches oss_2018, oss_2018_siqueira, rework_case_study

09-lessons.tex: review

Showing 1 changed file with 120 additions and 86 deletions   Show diff stats
opensym2017/content/09-lessons.tex
  Diff comments   View file @1928b7f
1   -\section{Lessons Learned and Conclusion}
  1 +\section{Lessons Learned}
2 2 \label{sec:lessons}
3 3  
4   -%%% Acho que podemos organizar em algo assim, explicitando a lição%%%
5   -%(Lesson 1 -- Students in real-world project interacting with real customers)
6   -
7   -The multidisciplinary of our development team - mainly composed of software
8   -engineers undergraduate students, senior developers, and designers - makes that
9   -naturally fit the project requirements and consequently achieve a high quality.
10   -To collaborate to that, there was a stakeholder team of technicians and
11   -managers from the Brazilian Government, as well as the management team from the
12   -UnB. In particular at the being of the project, the different perceptions of
13   -the Brazilian Government stakeholders generated a high complex communication
14   -and management environment. Once we were practicing an empirical development
15   -approach based on FOSS and agile methods, our development team also interacted
16   -directly with the stakeholders to mitigate several moments of management
17   -overhead, supporting the UnB professors those were responsible for the project
18   -management. The interaction with professionals, that have different expertises,
19   -and the participation in all levels of the software development process
20   -contributed with a great learning opportunity for the students, which majority
21   -have their first professional experience.
22   -
23   -
24   -At the initial phases of the project, by political and personal motivation, the
25   -main stakeholders from the Brazilian government imposed the use of Colab to
26   -guide the development of the new SPB platform. Our team were totally against
27   -the idea because we already knew that Colab was a very experimental project and
28   -its adoption could dramatically increase the project complexity. Even though
29   -we provided technical reasons to not utilize Colab, MP enforces it to us and we
30   -had to manage this problem. As explained in section \ref{sec:architecture} we
31   -did a massive change in it, and at the end of the project we completely rewrite
32   -Colab and made it stable. It is important to notice that the MP compelled us to
33   -accept a technical issue based only on political interests, without considering
34   -all the money they would spend with their decision. At the end of the project,
35   -we verified that Colab consumed a vast amount of the budget and indeed
36   -increased the project complexity. In the end of the project and after our
37   -analyses on the decisions made by the MP, we understand that MP's managers are
38   -capable of ignoring technical reasons in favor to a political decision.
39   -
40   -In the process of deploying the SPB platform in the MP structure, we had to
41   -interact with the MP's technicians. We did several workshops, training and a
42   -meticulous documentation describing all the required procedures to update the
43   -platform, however, we realized that the MP's technicians constantly avoid the
44   -responsibility. After notice the aforementioned situation, we organized a
45   -specific team to start a DevOps activities and interacts with all the UnB
46   -teams. After a year of work, we completely automated all the deployment
47   -procedure. We simplified all the platform implantation to a few steps: (1)
48   -initial configurations (just ssh configuration) and (2) the execution of simple
49   -commands to completely update the platform. In the end of the project, we
50   -observed that the MP technical invariably depends on our support to update the
51   -platform even with all the automation provided by us.
52   -
53   -From the point of view of management and development processes, we had to
54   -develop strategies that would support different organizational cultures. As
55   -reported in Section \ref{sec:process}, the MP is organized in a functional
56   -hierarchical organizational structure, typically, a traditional development
57   -paradigm. The UnB team works based on agile manifest values and FOSS community
58   -practices. Therefore, we had to create a translation process to communicate
59   -with MP managers who manage their project based on the PMBoK ideas. On the one
60   -hand, in the intermediary and final project's phases, we had matured this
61   -process, mainly due to the perception of the results by the MP, on the other
62   -hand, in the initial phase we had a lot of intervention in our work style,
63   -which ended up focusing strategic discussions for operational discussions. The
64   -aforementioned situation created an overload to the professors because they
65   -were responsible for maintaining the strategic alignment of the MP synchronized
66   -with the development team.
67   -
68   -Another important factor for the students was the composition of the teams with
69   -the participation of senior professionals from the FOSS communities. These
70   -professionals and professors promoted a work environment where the students
71   -could develop their skills in a didactic way without transferring any pressure
72   -to the students. Addition, these experienced professionals were responsible for
73   -the most relevant technical decisions related to the SPB software product.
74   -
  4 +\textbf{How to involve students real-world projects, interacting with
  5 +real customers.}
  6 +%
  7 +Our team was mainly composed of software engineering undergraduate
  8 +student, who had the opportunity to interact with senior developers and
  9 +designers inside the team, as well as with the team of technicians and
  10 +managers from the Brazilian Government, and the management team from
  11 +UnB.
  12 +%
  13 +They interacted with professionals that had diverse expertises, and were
  14 +able to participate in all levels of the software development process.
  15 +This contribted to a great learning opportunity, and for a majority of
  16 +them this was their first professional experience.
  17 +
  18 +\textbf{The participation of experienced professionals is crucial to
  19 +success of the project.}
  20 +One important factor for the students was the composition of the teams
  21 +with the participation of experienced professionals.
  22 +%
  23 +On the technical side, the senior developers and designers would handle
  24 +the more difficult technical decisions, creating a work environment
  25 +where the students could develop their skills in a didactic way without
  26 +pressure.
  27 +%
  28 +On the management side, the active participation of professors -- who
  29 +are, in the end, the ones responsible for the project -- is crucial to
  30 +make sure student participation is conducted in a healthy way, and is an
  31 +instance of leading by example.
  32 +
  33 +\textbf{A balanced relationship between academia and industry.}
  34 +The experience of the SPB project led UnB to develop a work style which
  35 +proved to be appropriate for an educational environment that brings
  36 +academia and industry together.
  37 +%
  38 +The highest priority from the university's point of view is the
  39 +students. Considering this, the activities of the project were never
  40 +prioritized to the detriment of classes and other pedagogical
  41 +activities. In summary, we had students working at different times, part
  42 +time, remotely or locally, always respecting their individual
  43 +conditions, but doing the work in a collective, collaborative and open
  44 +way.
  45 +%
  46 +And even under a potentially adverse environment, the project delivered
  47 +the desired solution with success.
  48 +%
  49 +At the end of the project, we noted that the skills developed by the
  50 +students were at the state of art of the software engineering practice.
  51 +After the project ended, we had team members successfully embracing
  52 +opportunities in public, private, national and international
  53 +organizations, in addition to those students that went into
  54 +entrepreneurship and opened their own companies.
  55 +
  56 +\textbf{Managing different organizational cultures.}
  57 +In the beginning of the project, the Brazilian Government stakeholders
  58 +had certain expectations about the development of project that, let's
  59 +say, didn't exactly match our work based on agile and FOSS practices.
  60 +%
  61 +We had to develop strategies that would support different these
  62 +organizational cultures. As reported in Section \ref{sec:process}, the
  63 +MP is organized in a functional hierarchical organizational structure,
  64 +typically, a traditional development paradigm. Therefore, we had to
  65 +create a translation process between our team and the MP managers who
  66 +managed the project on their side assuming a traditional, waterfall
  67 +process.
  68 +
  69 +\textbf{Manage higher-level and lower-level goals separately.}
  70 +During the initial phase of the project the MP team would often bring
  71 +strategic discussions to technical/operational meetings, where we were
  72 +supposed to discuss practical, technical decisions.
  73 +%
  74 +This produced a highly complex communication and management environment,
  75 +overloading the professors because they were supposed to be responsible
  76 +for maintaining the strategic alignment of the MP synchronized with
  77 +implementation plans of the development team, specially in light of the
  78 +aforementioned culture mismatch. Mixing both concerns in the same
  79 +discussions caused confusion on both sides.
  80 +%
  81 +Towards the middle and end of the project we were able to keep those
  82 +concerns separated, what eased the work of everyone involved.
  83 +
  84 +\textbf{Living with ill-advised political decisions.}
  85 +At the initial phases of the project, by political and personal
  86 +motivation, the main stakeholders from the Brazilian government imposed
  87 +the use of Colab to guide the development of the new SPB platform. Our
  88 +team was totally against the idea because we already knew that Colab was
  89 +a very experimental project and its adoption could dramatically increase
  90 +the project complexity. Even though we provided technical reasons to
  91 +not utilize Colab, MP was adamant and we had to manage this problem. As
  92 +explained in section \ref{sec:architecture} we did massive changes to
  93 +it, and at the end of the project we completely rewrote Colab and made
  94 +it stable. It is important to notice that the MP compelled us to accept
  95 +a technical issue based only on political interests, without considering
  96 +all the resources that would be spent due to that decision. At the end
  97 +of the project, we verified that Colab indeed consumed a vast amount of
  98 +the budget and increased the project complexity. In the end of the
  99 +project and after our analysis on the decision made by the MP, we
  100 +understand that MP's managers are capable of ignoring technical reasons
  101 +in favor to a political decision.
  102 +
  103 +\textbf{Consider sustainability from the beginning.}
  104 +In the process of deploying the SPB platform in the MP structure, we had
  105 +to interact with the MP technicians. We did several workshops, training
  106 +and a meticulous documentation describing all the required procedures to
  107 +update the platform, however, we realized that the MP technicians
  108 +constantly avoid the responsibility. After noticing the aforementioned
  109 +situation, we organized a specific DevOps that completely automated all
  110 +the deployment procedure. We simplified all the platform deployment to a
  111 +few steps: (1) initial configurations (just ssh configuration) and (2)
  112 +the execution of simple commands to completely update the platform. By
  113 +the end of the project, we observed that the MP technicians invariably
  114 +still depended on our support to update the platform even with all the
  115 +automation provided by us. We were sadly left with a feeling of
  116 +uncertainty about the future of the platform after the project ended. In
  117 +hindsight, we realize that the MP dedicated systems analysts and
  118 +managers to the project, but not operations technicians. The later
  119 +should have been more involved with the process so they could at least
  120 +comfortable with managing the platform infrastructure.
  121 +
75 122 % * Gestão dos recursos: Fizemos mais por menos (2.6M de 3.2M) --- sem os dados
76 123 %% (escopo, custo, tempo e qualidade) bem discutidos é difícil sustentar essa
77 124 %% afirmação, embora eu e Paulo consigamos perceber isso.
78 125  
79   -The experience of the SPB project led UnB to develop a work style which proved
80   -to be appropriated to the characteristics of an educational environment and
81   -brings the academy closer to the industry. The highest priority from the
82   -university's point of view is the students, considering this, the activities of
83   -the project were never prioritized to the detriment of the classes and other
84   -pedagogical activities. In summary, we had students working at different times,
85   -part time, remotely or locally, always respecting their individual conditions,
86   -but doing the work in a collective, collaborative and open way. At the end of
87   -the project, we realized that the skills developed by the students empowered
88   -them with the state in the practice of software engineering. The members of the
89   -teams got opportunities to work in public, private, national and international
90   -organizations, in addition to those students they preferred entrepreneurship,
91   -opening their own companies.
92   -
93 126 %===========
94 127 % Conclusion
95 128 %===========
96 129  
  130 +\textbf{Final remarks.}
97 131 The portal is available at \url{softwarepublico.gov.br}. All
98 132 documentation, including detailed architecture and operation manuals are
99 133 also available\footnote{\url{https://softwarepublico.gov.br/doc/}
... ...