Commit 2845ae0bf66e0f4018a2e099d7eead0806153c97
1 parent
27faac11
Exists in
master
and in
3 other branches
[i3eSW] Last challenge
Showing
1 changed file
with
9 additions
and
9 deletions
Show diff stats
ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md
... | ... | @@ -304,15 +304,15 @@ in a high turnover scenario. |
304 | 304 | |
305 | 305 | ### Overcoming Mistrust |
306 | 306 | |
307 | -In the project's beginning we struggled with deployment issues in the government | |
308 | -structure. We were in a paradoxical situation. The government demanded fast | |
309 | -deliveries but would not give access to their production infrastructure. After | |
310 | -some interactions with government agents, they created the VE as an isolated | |
311 | -replica of the PE in their own infrastructure. The government agents then | |
312 | -realised that it could be beneficial for the project if they granted us access | |
313 | -to part of the infrastructure. More research is required on development protocols and | |
314 | -policies to improve the relation between industry and government, specially | |
315 | -regarding CD. | |
307 | +Taking an unfamiliar approach requires trust. In the Ministry of Planning, software is the product delivered at the end of a development contract. They expected and were prepared to validate and deploy a single delivery. Because the SPB portal is a system of systems, the steady growth of its complexity made large deliveries unsustainable. In addition, long time for homologation of developed features gave government room to change requirements and priorities. The CD approach was necessary, but how to build trust and gain autonomy to implement a process that was not yet part of the dynamics of the Ministry? | |
308 | + | |
309 | +\begin{enumerate} | |
310 | + \item \textit{Demonstrate actual results, do not simply tell.} Since we did not have access to government infrastructure, we decided to create our own validation environment. We advance on CD pipeline to the release validation stage when we were faced two problems: the volume of intermediate deliveries was greater than the ability of government technicians to deploy in production, and features validated by government analysts in our environment did not work as expected in production (due to specific issues of government infrastructure we had neither access nor control). We reinforced to them that we needed to have access to a real environment.} | |
311 | +\item \textit{Make our project management transparent and collaborative for analysts.} Allowing the analysts to follow our dynamics of version generation, bug fixes and requirements adjustments, we showed them we were meeting our commitments. They started to interact more strongly in the generation of a version and also wanted to see the result of their validation works in production. With this, after some interactions with government agents, they created a VE as an isolated replica of PE and gave us access. | |
312 | +\item \textit{Gain the confidence of government agents.} In the created environment, we showed the development of the entire pipeline and won the trust of the government agents involved in the process. On the one hand, analysts saw the mobilization and responsiviness of the team to generate a new version package. On the other hand, government technicians recognized the quality of our packages and our deployment process. | |
313 | +\end{enumerate} | |
314 | + | |
315 | +Finally, the government agents then realised that it could be beneficial for the project if they granted us access to part of the infrastructure. More research is required on development protocols and policies to improve the relation between industry and government, specially regarding CD. | |
316 | 316 | |
317 | 317 | ## Acknowledgements |
318 | 318 | ... | ... |