[i3eSW] Reviewing the last 3 benefits

Melissa Wen
1 parent 777dcd13
Showing 1 changed file with 44 additions and 40 deletions Show diff stats
ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md
@@ -222,46 +222,50 @@ to production.
  
 ### Shared Responsibility
  
-When the government technicians were responsible for deploying the project, the
-developers lost track of what happened after code was delivered. After adopting
-CD, they felt more responsible for what was getting into production. CD
-influenced developers on taking ownership of the project. In the end of the
-project, we noticed that the entire team was working to improve the CD pipeline
-since they want to their new features in production.
-
-Interestingly, the CD pipeline also made the government requirements analysts
-feel more responsible for the project. They were an active part of the pipeline
-and that engaged them on the whole process. In the end, they were even actively
-creating issues and discussing them during the development process.
-
-
-[//]: # (TODO - depois deles entrarem de fato no pipeline, ou seja, validar em ambiente de homologação, criando issues e comentando nas issues do repositório é que de nosso processo empírico de desenvolvimento predominou até o fim do processo)
-
-
-### CD pipeline protocol between Government and Development
-
-In the beginning of the CD pipeline use, a bottleneck arose at the acceptance
-tests step due to delays in reviewing new features and starting the next step.
-These delays occured because the government analysts, responsible for
-reviewing, were sometimes busy or didn't have schedule this work. Furthermore,
-after the acceptance of the new code, there was a bureaucracy in the government
-IT infrastructure that often made us to wait until 3 days to get the production
-environment access and then to start the deployment step. This problem was
-softened when we clarify our pipeline for these analysts and they organized
-their schedule to speed up reviews and production access requests.
-
-### Work in small batches developed trust in our relation with government analysts
-
-In the first three releases, government requirements analysts were validating
-all features to be released only at the end of a delivery cycle which often
-took almost four months. However their superintendents requested monthly
-reports about the project progress and this brought pressure on them which in
-turn put it on us. When we started to make continuous deliveries, we really delivered
-intermediate and candidate releases. Thus, the analysts could have validate a
-small set of features, making possible more accurate feedbacks and better
-reports for regular meetings with their superintendents. As a result, we
-gained their trust and they also gained trust of their chiefs about the SPB
-project management.
+Before the adoption of the CD, the developers team could not track what happened to the code
+after its delivery, since government technicians were the only responsibles
+for deploying the project. The implementation of the referred
+approach influenced developers on taking ownership of the project because it
+made them feel equally responsible for what was getting into production. 
+
+Interestingly, the CD pipeline had the same effect on the team of requirements analysts.
+They were an active part of the pipeline and became more engaged on the whole process. 
+
+After the incorporation of the pipeline into the work process, analysts
+became more active in opening and discussing issues during the platform evolution.
+Additionally, developers worked to improve the CD pipeline in
+order to speed up the process of making available, in the production environment,
+new features for the platform.
+
+
+### Synchronicity between Government and Development
+
+Despite the positive impacts that the CD pipeline brought to the project, its
+implementation was not easy at first. The good performance of the CD pipeline
+depended on the synchronicity between the teams of developers and government
+analysts, so that the work of one could be initiated immediately after
+the delivery of the work by the other. Initially this concern was not
+contemplated in the agenda of the governmental team, which generated delays in
+the validation of the new features of the release. This situation combined with
+governmental bureaucracy (up to 3 days) to release access to the production
+environment resulted in additional delays for the deployment step to begin.
+This problem was softened when the analysts realized the impact of
+these delays on the final product and decided to allocate the revisions in its
+scale of work and to request the access to production in time. 
+
+### Strengthening trust in our work relation with the government
+
+Continuous delivery was also a tool that helped to strengthen trust in the
+relationship between developers and government analysts, as well as between the
+latter group and its superiors.Before using CD, analysts had access to the
+features developed only at the end of the release, usually every 4 months.
+However, this periodicity did not meet the requirements of their directors, who
+demanded monthly reports on the progress of the project. With the
+implementation of the CD, intermediate versions became available, allowing
+analysts to perform small validations over time. The constant monitoring of
+the development work brought greater security to the governmental nucleus and
+improved the interactions of these with the team of developers.
+
  
 ## Challenges
...	...	@@ -222,46 +222,50 @@ to production.
222	222
223	223	### Shared Responsibility
224	224
225		-When the government technicians were responsible for deploying the project, the
226		-developers lost track of what happened after code was delivered. After adopting
227		-CD, they felt more responsible for what was getting into production. CD
228		-influenced developers on taking ownership of the project. In the end of the
229		-project, we noticed that the entire team was working to improve the CD pipeline
230		-since they want to their new features in production.
231		-
232		-Interestingly, the CD pipeline also made the government requirements analysts
233		-feel more responsible for the project. They were an active part of the pipeline
234		-and that engaged them on the whole process. In the end, they were even actively
235		-creating issues and discussing them during the development process.
236		-
237		-
238		-[//]: # (TODO - depois deles entrarem de fato no pipeline, ou seja, validar em ambiente de homologação, criando issues e comentando nas issues do repositório é que de nosso processo empírico de desenvolvimento predominou até o fim do processo)
239		-
240		-
241		-### CD pipeline protocol between Government and Development
242		-
243		-In the beginning of the CD pipeline use, a bottleneck arose at the acceptance
244		-tests step due to delays in reviewing new features and starting the next step.
245		-These delays occured because the government analysts, responsible for
246		-reviewing, were sometimes busy or didn't have schedule this work. Furthermore,
247		-after the acceptance of the new code, there was a bureaucracy in the government
248		-IT infrastructure that often made us to wait until 3 days to get the production
249		-environment access and then to start the deployment step. This problem was
250		-softened when we clarify our pipeline for these analysts and they organized
251		-their schedule to speed up reviews and production access requests.
252		-
253		-### Work in small batches developed trust in our relation with government analysts
254		-
255		-In the first three releases, government requirements analysts were validating
256		-all features to be released only at the end of a delivery cycle which often
257		-took almost four months. However their superintendents requested monthly
258		-reports about the project progress and this brought pressure on them which in
259		-turn put it on us. When we started to make continuous deliveries, we really delivered
260		-intermediate and candidate releases. Thus, the analysts could have validate a
261		-small set of features, making possible more accurate feedbacks and better
262		-reports for regular meetings with their superintendents. As a result, we
263		-gained their trust and they also gained trust of their chiefs about the SPB
264		-project management.
	225	+Before the adoption of the CD, the developers team could not track what happened to the code
	226	+after its delivery, since government technicians were the only responsibles
	227	+for deploying the project. The implementation of the referred
	228	+approach influenced developers on taking ownership of the project because it
	229	+made them feel equally responsible for what was getting into production.
	230	+
	231	+Interestingly, the CD pipeline had the same effect on the team of requirements analysts.
	232	+They were an active part of the pipeline and became more engaged on the whole process.
	233	+
	234	+After the incorporation of the pipeline into the work process, analysts
	235	+became more active in opening and discussing issues during the platform evolution.
	236	+Additionally, developers worked to improve the CD pipeline in
	237	+order to speed up the process of making available, in the production environment,
	238	+new features for the platform.
	239	+
	240	+
	241	+### Synchronicity between Government and Development
	242	+
	243	+Despite the positive impacts that the CD pipeline brought to the project, its
	244	+implementation was not easy at first. The good performance of the CD pipeline
	245	+depended on the synchronicity between the teams of developers and government
	246	+analysts, so that the work of one could be initiated immediately after
	247	+the delivery of the work by the other. Initially this concern was not
	248	+contemplated in the agenda of the governmental team, which generated delays in
	249	+the validation of the new features of the release. This situation combined with
	250	+governmental bureaucracy (up to 3 days) to release access to the production
	251	+environment resulted in additional delays for the deployment step to begin.
	252	+This problem was softened when the analysts realized the impact of
	253	+these delays on the final product and decided to allocate the revisions in its
	254	+scale of work and to request the access to production in time.
	255	+
	256	+### Strengthening trust in our work relation with the government
	257	+
	258	+Continuous delivery was also a tool that helped to strengthen trust in the
	259	+relationship between developers and government analysts, as well as between the
	260	+latter group and its superiors.Before using CD, analysts had access to the
	261	+features developed only at the end of the release, usually every 4 months.
	262	+However, this periodicity did not meet the requirements of their directors, who
	263	+demanded monthly reports on the progress of the project. With the
	264	+implementation of the CD, intermediate versions became available, allowing
	265	+analysts to perform small validations over time. The constant monitoring of
	266	+the development work brought greater security to the governmental nucleus and
	267	+improved the interactions of these with the team of developers.
	268	+
265	269
266	270	## Challenges
267	271
...	...