Download as
Browse Code »

Commit 3bff9c9230d7fd27e1ae63a570d6aa4f3bd85faf

Authored by Rodrigo Siqueira de Melo
2 parents 3a6b85b7 cf48ee2f
Exists in master and in 3 other branches oss_2018, oss_2018_siqueira, rework_case_study

Merge branch 'update_conclusion'

Showing 1 changed file with 71 additions and 63 deletions   Show diff stats
opensym2017/content/09-lessons.tex
  Diff comments   View file @3bff9c9
1 \section{Lessons Learned} 1 \section{Lessons Learned}
2 \label{sec:lessons} 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. 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 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. 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.
24 32
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. 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 From the point of view of management and development processes, we had to 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. 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.
50 60
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. 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 % * Gestão dos recursos: Fizemos mais por menos (2.6M de 3.2M) --- sem os dados 68 % * Gestão dos recursos: Fizemos mais por menos (2.6M de 3.2M) --- sem os dados
61 %% (escopo, custo, tempo e qualidade) bem discutidos é difícil sustentar essa 69 %% (escopo, custo, tempo e qualidade) bem discutidos é difícil sustentar essa
62 %% afirmação, embora eu e Paulo consigamos perceber isso. 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