Download as
Browse Code »

Commit 8c330652d7a24d6c8fe2c44202b6d0d1e04ee200

Authored by Paulo Meireles
2 parents 2f7001ce 455d1bbd
Exists in master and in 3 other branches oss_2018, oss_2018_siqueira, rework_case_study

Merge branch 'master' of softwarepublico.gov.br:softwarepublico/articles

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