[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,46 +222,50 @@ to production.
222		222
223	### Shared Responsibility	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	## Challenges	270	## Challenges
267		271