From db4810a248c190845821d098c7e891a7418dd038 Mon Sep 17 00:00:00 2001 From: Paulo Meirelles Date: Tue, 25 Jul 2017 18:33:04 -0300 Subject: [PATCH] [opensym] Reviewing the conclusion --- opensym2017/content/01-introduction.tex | 2 +- opensym2017/content/04-researchdesign.tex | 6 +++--- opensym2017/content/06-architecture.tex | 2 +- opensym2017/content/08-process.tex | 4 ++-- opensym2017/content/09-conclusion.tex | 108 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------------------------------------------------- 5 files changed, 63 insertions(+), 59 deletions(-) diff --git a/opensym2017/content/01-introduction.tex b/opensym2017/content/01-introduction.tex index eaf1994..d73c9d3 100644 --- a/opensym2017/content/01-introduction.tex +++ b/opensym2017/content/01-introduction.tex @@ -41,7 +41,7 @@ Approximately five years later from the first problems, a new platform for the SPB Portal was planned and funded. Between January 2014 and June 2016, the University of Brasília (UnB) and the University of São Paulo (USP) in a partnership with the Brazilian Ministry of Planning, Budget, and Management -(MP) designed an integrated platform for collaborative software development +designed an integrated platform for collaborative software development \cite{bobr2003}, including social networking, mailing lists, version control system, and source code quality monitoring. To coordinate and develop this project during 30 months, UnB was funded by a grant of 2,619,965.00 BRL (about diff --git a/opensym2017/content/04-researchdesign.tex b/opensym2017/content/04-researchdesign.tex index 0c4fa12..943423e 100644 --- a/opensym2017/content/04-researchdesign.tex +++ b/opensym2017/content/04-researchdesign.tex @@ -6,7 +6,7 @@ Portal by reporting the technical efforts carried out, our empirical work process, and the lessons learned. The new SPB Portal project presented three main challenges, related to the open questions described below. -\textbf{Q1:} \textit{Which strategy could be used to integrate several existing +\textbf{Q1.} \textit{Which strategy could be used to integrate several existing FLOSS tools to promote a collaborative software development?} % Based on an extensive list of functional requirements defined by the Brazilian @@ -17,7 +17,7 @@ were fully aware that we would need to improve those systems in order to satisfy the remaining requirements. We were also convinced that it would be impossible to satisfy all of those requirements with a single tool. -\textbf{Q2:} \textit{How to involve students in real-world projects interacting +\textbf{Q2.} \textit{How to involve students in real-world projects interacting with real customers?} % Our team was mainly composed of software engineering undergraduate students, @@ -27,7 +27,7 @@ Government. For the majority of the students, this was a first professional experience. Even though, our development process defined a central role on students participation. -\textbf{Q3:} \textit{How to introduce typical FLOSS collaborative and agile practices in the governmental development process?} +\textbf{Q3.} \textit{How to introduce typical FLOSS collaborative and agile practices in the governmental development process?} % The software development in Brazilian government is based on a very traditional way, frequently focusing documentation deliveries. We had to convince them to diff --git a/opensym2017/content/06-architecture.tex b/opensym2017/content/06-architecture.tex index a9c121e..82e55d9 100644 --- a/opensym2017/content/06-architecture.tex +++ b/opensym2017/content/06-architecture.tex @@ -159,7 +159,7 @@ network created between them. \begin{figure*}[hbt] \centering - \includegraphics[width=\linewidth]{figures/arch3.png} + \includegraphics[width=.85\linewidth]{figures/arch3.png} \caption{Instanciation view of the SPB architecture.} \label{fig:architecture2} \end{figure*} diff --git a/opensym2017/content/08-process.tex b/opensym2017/content/08-process.tex index 3ea56a7..b1c0487 100644 --- a/opensym2017/content/08-process.tex +++ b/opensym2017/content/08-process.tex @@ -24,8 +24,8 @@ automation resulting from DevOps practices. Thus, the work process was executed in a cadenced and continuous way. Finally, the last group of actors of this project was composed of employees of -the Brazilian Ministry of Planning, Development, and Management (MP is the -Brazilian acronym). All the project decisions, validations, and scope +the Brazilian Ministry of Planning, Development, and Management. +All the project decisions, validations, and scope definitions were made by them. In this way, we incrementally developed a software product with releases aligned to strategic business objectives. As one can see, the project had a wide range of different stakeholders that had to be diff --git a/opensym2017/content/09-conclusion.tex b/opensym2017/content/09-conclusion.tex index b295979..9b9c52a 100644 --- a/opensym2017/content/09-conclusion.tex +++ b/opensym2017/content/09-conclusion.tex @@ -4,20 +4,20 @@ In this work, we presented and discussed issues experienced during a government-funded project, in partnership with the University of Brasilia and the University of São Paulo, to evolve the Brazilian Public Software Portal. -Its contributions are twofold. First, we present the strategy used to develop +Our contributions are twofold. First, we present the strategy used to develop and to deliver an unprecedented platform to Brazilian government. Second, based on the results of the SPB Portal project, we point out that it is possible to mitigate conflicts experienced in the development environment and to conciliate governmental and academy cultures. To summarize our main contributions, we answered in this section the three open questions those guided this paper. -\textbf{Which strategy could be used to integrate several existing -FLOSS tools to promote a collaborative software development?} +\textbf{Which strategy could be used to integrate several existing FLOSS tools +to promote a collaborative software development?} % -The SPB portal integrates more than 10 FLOSS tools and provides several +The SPB portal integrates more than ten FLOSS tools and provides several features, such as social network, mailing list, version control, content management and source code quality monitoring. Concerned with the platform -sustainability and maintainability, the aforementioned 10 FLOSS tools were +sustainability and maintainability, the aforementioned FLOSS tools were integrated with minimum differences from their official versions and the new developed features were sent upstream to ensure an alignment between the portal systems and their respective official versions. In the integration process, the @@ -25,8 +25,8 @@ main softwares were identified, specific teams were formed to work with each one of them and each team was composed of students with different levels of skills and at least one senior professional. -\textbf{How to involve students in real-world projects interacting with -real customers?} +\textbf{How to involve students in real-world projects interacting with real +customers?} % In terms of mitigating conflicts, we tried to show that, as long as the university can provide a healthy and challenging environment to its students, @@ -42,29 +42,31 @@ professionals to solve development issues. % Among the students, we have defined coaches for each team and a meta-coach (coach of whole project). All coaches, together with professors, have -intermediated the communication between client (Ministry of Planning of Brazil) +intermediated the communication between client (the Brazilian Government) and the rest of the group. After the end of the project, some students successfully embraced opportunities in public and private sectors, within national borders and abroad. Some other students went further and started their own companies. -\textbf{How to introduce collaborative and agile -practices typical in FLOSS environments in the governmental development process?} +\textbf{How to introduce typical FLOSS collaborative and agile practices in the +governmental development process?} % -With some adaptations, what we called the ``translation processes'', it is +With some adaptations, it is feasible to conciliate agile methodologies and FLOSS practices to develop software to governmental organizations with functional hierarchical structures that use traditional development paradigm. % -Aiming at reducing client questions about workconclusion, a DevOps front was +Aiming at reducing client questions about workconclusion, a DevOps team was created to automate all deploy process and also to work in continuous -delivery. The government was brought to our work environment and interacted +delivery. The Government was brought to our work environment and interacted with our management and communication tools. For the project success, we focused on providing a friendly working environment as well as on showing to governmental agents another way to interact with the FLOSS community and the university. -From the answers of our initial open questions, we can also highlighted six +\subsection{Lessons Learned} + +From the answers of our initial open questions, we also can highlighted six lessons learned to make easier to share our experience during the development of the new SPB Portal. @@ -104,21 +106,22 @@ certain expectations about the project development that, let's say, did not exactly match our work style based on agile and FLOSS practices. % We had to develop strategies that would support these different organizational -cultures. Therefore, we have created ``translation processes'' between our team -and the MP managers who managed the project on their side, assuming a +cultures. Therefore, we have adapted the process between our team +and the Government managers who managed the project on their side, assuming a traditional waterfall process. \textbf{Managing higher-level and lower-level goals separately.} % -During the initial phase of the project, the MP team has brought strategic -discussions to technical/operational meetings that were supposed to be about -practical technical decisions. +During the initial phase of the project, the Brazilian Government team has +brought strategic discussions to technical/operational meetings that were +supposed to be about practical technical decisions. % This produced a highly complex communication and management environment, -overloading the professors because they were supposed for maintaining the MP -strategy synchronized with the implementation plans of the development team. -This was hard, especially because the aforementioned cultural mismatch. Mixing -both concerns in the same discussions caused confusion on both sides. +overloading the professors because they were supposed for maintaining the +Government strategy synchronized with the implementation plans of the +development team. This was hard, especially because the aforementioned +cultural mismatch. Mixing both concerns in the same discussions caused +confusion on both sides. % From the middle of the project we were able to keep those concerns separated, what eased the work of everyone involved. @@ -126,40 +129,41 @@ 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 +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, the MP was adamant and we had -to manage this problem. We did massive changes to Colab, and at the end of the -project we have completely rewritten it to make it stable. It is important to -notice that the MP compelled us to accept a technical decision 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. At -the end of the project and after our analysis on the decision made by the MP, -we understand that MP managers are capable of ignoring technical reasons in -favor of political decisions. +adoption could dramatically increase the project complexity. Even though, we +provided technical reasons to not utilize Colab, the Government was adamant and +we had to manage this problem. We did massive changes to Colab, and at the end +of the project we have completely rewritten it to make it stable. It is +important to notice that the Government compelled us to accept a technical +decision 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. After our analysis on the decision made by +the Government, we understand that some Brazilian Government managers are +capable of ignoring technical reasons in favor of political decisions. \textbf{Consider sustainability from the beginning.} % -In the process of deploying the SPB platform in the MP infrastructure 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 -DevOps team 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 system 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 be comfortable -in managing the platform infrastructure. - +In the process of deploying the SPB platform in the Brazilian Government +infrastructure we had to interact with the Government technicians. We did +several workshops, training and a meticulous documentation describing all the +required procedures to update the platform, however, we realized that they +constantly avoid the responsibility. After noticing the aforementioned +situation, we organized a DevOps team that completely automated all the +deployment procedure. We simplified all the platform deployment to a few steps: +(i) initial configurations (just ssh configuration) and (ii) the execution of +simple commands to completely update the platform. By the end of the project, +we observed that the Government 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 Brazilian Government +dedicated system 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 be comfortable in managing the platform infrastructure. + +\subsection{Final Remarks and Future Work} Ultimately, the SPB portal is in production\footnote{\url{https://softwarepublico.gov.br}} and its full -- libgit2 0.21.2