DevOps - that wonderful name that brings developer and operations processes together to support continuous delivery of software updates. It's a different discipline to managing infrastructure or monitoring servers, though Infrastructure as Code has a place in DevOps processes.
Today's blog is provided by Microsoft MVP Takashi Takebayashi, explaining why developers use Azure DevOps Services and how it solves the problems they have working together as a team.
In this post, I will introduce trial and error and its consequences as a Scrum Master and developer to improve the efficiency of project management and the quality of output.
Since development efficiency is poor with Backlog, which does not have CI (continuous integration) / CD (continuous delivery) function, I proposed to use Azure DevOps Services, but it is not translated into Japanese. Was rejected because of this.
Similarly, Azure DevOps Services was rejected because it had to be operated and maintained by itself.
We chose GitHub Actions because the version control used in the project is Git, and if the scope of influence is GitHub Actions, it is limited to developers. I have fixed this issue by synchronizing the Git repository on Backlog with the Git repository on GitHub.
We were using Backlog didn't have "priority". As a result, we couldn't sort the user stories in order of priority, and we had to use some other tool to sort the user stories in order of priority. Excel was the one that product owners were accustomed to.
However, it was difficult to change the priority easily in Excel. Specifically, the product owner needs to take the following steps when changing the priority of the user story.
This task was more troublesome than the product owner had imagined. As a result, there were many problems such as, the user story that the product owner forgot to delete remains, the product owner intended to add the user story but accidentally deletes the user story, Backlog or Excel user stories has not been updated.
As a result, the entire Scrum team was confused, with missing user stories to do in the sprint and user stories that didn't have to be done, and the velocity remained low.
As a result of each product owner and developer solving the problem at hand, it became necessary to use multiple tools properly for the team as a whole. Also, since it is troublesome for each member to see all of the multiple tools, some members work without looking at the information contained in the tools.
Specifically, the following happened frequently:
There was an error in the resolution of the image created by the designer. The developer had incorporated Danger into CI conducted by GitHub Actions.
Danger acting as CI pointed out that the resolution of the image created by the designer is incorrect. However, the designer did not see the results or suggestions of GitHub Actions, so the error was not resolved. Our team followed the rule not to merge the changes if a warning occurred in CI. As a result, images with incorrect resolutions were not merged until the errors were corrected.
The team took the following steps to correct the mistake.
As a result, it happened that no user story was done within the sprint.
The whole team understood that even if each of them did what they thought was good for the team, it was only a partial optimization, not an overall optimization. So, in the situation where we are now on a zero basis, we discussed in retrospect what should be prioritized to solve.
Despite various opinions, in summary, we agreed that "everyone would use a common tool."
The tool chosen was the initially rejected Azure DevOps Services.
Haste makes waste.
By adopting Azure DevOps Services, we have been in front of us until now. All the issues that existed have been resolved.
At the same time, there were no new challenges.
And with the adoption of Azure DevOps Services, our velocity has increased tenfold!!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.