Commit 3c84d052041e549adc5ca1ca345d1b54c6b91b0f
1 parent
c89935f3
Exists in
master
and in
3 other branches
[oss-2018] refactoring case study
Showing
2 changed files
with
58 additions
and
78 deletions
Show diff stats
icse2018/content/01-introduction.tex
| @@ -40,7 +40,7 @@ However, neither culture nor values can be easily change and the effort for this | @@ -40,7 +40,7 @@ However, neither culture nor values can be easily change and the effort for this | ||
| 40 | kind of movement does not seem feasible for development projects with tight | 40 | kind of movement does not seem feasible for development projects with tight |
| 41 | deadlines and budgets. | 41 | deadlines and budgets. |
| 42 | 42 | ||
| 43 | -This paper present practical ways to harmonize the traditional and agile | 43 | +This paper present practical ways to harmonize the project management traditional and agile |
| 44 | approach in the management of a partnership project between government and | 44 | approach in the management of a partnership project between government and |
| 45 | academia. For this, we interviewed members involved in the project with distinct | 45 | academia. For this, we interviewed members involved in the project with distinct |
| 46 | roles: requirement analysts and stakeholders of the Brazilian Ministry of | 46 | roles: requirement analysts and stakeholders of the Brazilian Ministry of |
icse2018/content/04-case.tex
| 1 | -\section{The Case Study} | ||
| 2 | -\label{sec:casestudy} | 1 | +The project to evolve the Brazilian Public Software Portal |
| 2 | +\cite{meirelles2017spb} was a partnership between government and academia held | ||
| 3 | +between 2014 and 2016. In order to solve maintenance problems and fill | ||
| 4 | +design-reality gaps in the portal, the Ministry of Planning (MPOG) joined the | ||
| 5 | +University of Brasília (UnB) and the University of São Paulo (USP) to develop a | ||
| 6 | +platform with features and technologies novelties in the government context. | ||
| 3 | 7 | ||
| 4 | -%TODO Repensar a escrita | 8 | +The academic team carried out development activities in the Advanced Laboratory |
| 9 | +of Production, Research and Innovation in Software Engineering of UnB. The | ||
| 10 | +project management and development process in this laboratory is usually | ||
| 11 | +executed adopting agile methodologies, such as Extreme Programming (XP), Scrum | ||
| 12 | +and Kanban. For this project, a total of 42 undergraduate students, two master's | ||
| 13 | +students and two coordinator-professors participated in the development team. | ||
| 14 | +Six IT professionals were also hired as senior developers due their vast | ||
| 15 | +experiences in Front-end/UX or in one of the softwares integrated to the | ||
| 16 | +platform. | ||
| 5 | 17 | ||
| 18 | +The government team was composed of a director, a coordinator, and two IT | ||
| 19 | +analysts from a department of MPOG. Although it was responsible for the | ||
| 20 | +execution of this collaboration project, this department generally does not | ||
| 21 | +execute development of ministry's software. This department is responsible for | ||
| 22 | +contracting and homologating software development services and follows | ||
| 23 | +traditional management approaches, such as the RUP. | ||
| 6 | 24 | ||
| 7 | -The Brazilian Public Software portal is an e-government project for sharing | ||
| 8 | -public software projects, specific type of systems that meets the needs of | ||
| 9 | -modernization of the Brazilian public administration. The vailability of this | ||
| 10 | -software in electronic via aims at saving public resources, benefiting the | ||
| 11 | -State and society. | 25 | +In order to manage the project progress, these two aforementioned teams |
| 26 | +periodically met in person. These meetings initially only took place at the | ||
| 27 | +ministry's headquarters to discuss strategic/political and technical goals. | ||
| 28 | +These meetings were held monthly with the presence of two UnB professors, the | ||
| 29 | +executive-secretary of the Presidency (project supporter) and all MPOG members | ||
| 30 | +responsible for the project. The management of the development team was | ||
| 31 | +concentrated in the academia side. The workflow was organized in Redmine in | ||
| 32 | +biweekly sprints and 4-month releases, with intermediate deliveries hosted in | ||
| 33 | +university environment. However, with the progress of the project, this format | ||
| 34 | +proved to be inefficient. Conflicts between the internal management processes | ||
| 35 | +and differences in pace and goals of each institution were compromising the | ||
| 36 | +platform development. | ||
| 12 | 37 | ||
| 13 | -The first version of the portal was released in 2007 but the lack of new | ||
| 14 | -development and sustainability projects made the platform obsolete with | ||
| 15 | -uncontrollable crashes. With approximately 145 requirements mapped out in | ||
| 16 | -dialogues with public agencies and society, a new platform needed to be | ||
| 17 | -created. | ||
| 18 | -%TODOc: refazer e avaliar se basta citarmos o nosso paper da OSS | 38 | +In this case study, we focus on analyzing the dynamics between government and |
| 39 | +academia for collaborative development. We aim to map the practices adopted in | ||
| 40 | +the project management and development process to harmonize the cultural and | ||
| 41 | +organizational differences of the institutions involved. Our analysis was guided | ||
| 42 | +by the following research questions: | ||
| 19 | 43 | ||
| 44 | +\textbf{Q1.} {How to combine different teams with different management processes | ||
| 45 | +in a government-academia collaboration project?} | ||
| 20 | 46 | ||
| 21 | -The evolution of the Brazilian Public Software platform was a partnership | ||
| 22 | -project between the Brazilian government and Brazilian public universities | ||
| 23 | -between the years 2014 and 2016. The management and development team was made | ||
| 24 | -up of staff from the Ministry of Planning (MPOG), professors from the | ||
| 25 | -University of Brasília (UnB), professionals of the IT market, MSc students in | ||
| 26 | -Computer Science at the University of São Paulo (USP), and undergraduate | ||
| 27 | -students in Software Engineering at the University of Brasília. The project was | ||
| 28 | -developed physically in the Advanced Laboratory of Production, Research and | ||
| 29 | -Innovation in Software of UnB. In Brasília, capital of Brazil, the federal | ||
| 30 | -government is the most important customer and the largest bidder of software | ||
| 31 | -development contracts. Understanding the particularities of projects with the | ||
| 32 | -government and being prepared to meet your goals and pace of production is | ||
| 33 | -important for students professionally. Thus, this collaborative project was an | ||
| 34 | -opportunity for the transfer of knowledge between academia and government and | ||
| 35 | -for the practical application of the project management methods taught in the | ||
| 36 | -undergraduate course in Software Engineering. | ||
| 37 | -%TODO:Muita informação/detalhe desnessário | 47 | +In this first moment, we describe what changes in the management model and the |
| 48 | +development process have improved interactions between institutions, as well as | ||
| 49 | +internally. To map the benefits obtained by these movements, we use evidence | ||
| 50 | +obtained from interviews and online surveys with members on both sides, after | ||
| 51 | +project closure. We also collect data from management and communication tools | ||
| 52 | +used throughout the project. | ||
| 38 | 53 | ||
| 54 | +In a second moment, we address our analysis to issues related to organizational | ||
| 55 | +differences and diversity of project members in terms of maturity and experience | ||
| 56 | +in collaborative development. The harmony between teams sought not only to | ||
| 57 | +approximate the mind-set and culture of teams but also to delimitate the | ||
| 58 | +interactions between different roles and responsibilities. Evaluating this | ||
| 59 | +synergy generates the second research question: | ||
| 39 | 60 | ||
| 40 | -Differences in the organizational and managerial structure of the institutions | ||
| 41 | -to which each member belonged generated differences in goals, requirements and | ||
| 42 | -pace of execution. On the MPOG side, the requirements analysts were ministry | ||
| 43 | -staff who interacted most actively with the development team, their | ||
| 44 | -productivity was reported to their coordinator, and their coordinator reported | ||
| 45 | -to the board of directors. The director of the department responsible for | ||
| 46 | -software development had no autonomy over the deployment infrastructure. As the | ||
| 47 | -development and deployment of the ministry followed a traditional approach, | ||
| 48 | -opening a window of dialogue between these two departments for software | ||
| 49 | -deployment in production was usually not costly. Thus, the development of a | ||
| 50 | -software solution basically passed through the following steps: mapping | ||
| 51 | -requirements, prepararing a contract of licitation, hiring of contract | ||
| 52 | -executor, homologation of the product, delivery and deployment of the software, | ||
| 53 | -and payment. | 61 | +\textbf{Q2.} \textit{Which boundaries should be established between government |
| 62 | +and academia teams in collaboration interactions?} | ||
| 54 | 63 | ||
| 55 | -On the UnB side, the agile approach was used for development. | ||
| 56 | -% | ||
| 57 | -Due to the amount | ||
| 58 | -and maturity of the requirements demanded and the novelty, in the governmental | ||
| 59 | -context, of several features, the traditional methodologies was unsuitable for | ||
| 60 | -the development of complex integrated software platform. | ||
| 61 | -% TODO: bem truncado ^ | ||
| 62 | -The coordinator led | ||
| 63 | -the dialogue with board of directors as well as managbed the interactions | ||
| 64 | -between MPOG staff and dedveloper team. The development team was divided into | ||
| 65 | -specific groups for the main contexts and there was self-coordination among | ||
| 66 | -team members. The activities were organized by sprints of 15 days and the epics | ||
| 67 | -in 4 months. The development was incremental, with intermediate deliveries. | ||
| 68 | -% | ||
| 69 | -Due | ||
| 70 | -to differences in deployment pace between MPOG and UnB and other bureaucratic | ||
| 71 | -issues, the first version of the portal was launched on the university | ||
| 72 | -infrastructure and later migrated to the ministry infrastructure. | ||
| 73 | -% TODO: podemos citar nosso paper aceito na IEEE e não citar este último detalhes | ||
| 74 | - | ||
| 75 | - | ||
| 76 | -The main conflicts in the development process of the platform arose from the | ||
| 77 | -very nature of traditional and agile approaches: the government expected fully | ||
| 78 | -specified functionalities before implementation, a large volume of | ||
| 79 | -documentation, formalization of reports with full functionality deliveries, | ||
| 80 | -function point calculations for changes in requirements; the academy understood | ||
| 81 | -that features should be broken down into small functionalities with short-term | ||
| 82 | -deliverables for validation, decisions about what would be developed and how it | ||
| 83 | -would be developed should be collaboratively taken between client and | ||
| 84 | -developers, roles were flexible and organized organically. | ||
| 85 | - | ||
| 86 | -%TODO: ainda falta fechar com algo | 64 | +We highlight positive and negative effects of boundaries created among project |
| 65 | +member using evidences from interview responses and open field responses from | ||
| 66 | +online surveys. |