Spinning around the web you will see this same type of article written over and over again. QA aficionados have written about the agile and continuous testing topic extensively. My philosophy is that often different people learn with different writing styles. I, for one, like to see things in plain text, not masked by years of lingo and expected knowledge. So this will be a basic explanation how waterfall transitioned to Agile and how it can work for continuous deployment.
Waterfall
Before the internet was so widespread companies that wanted to put out software, we're talking needing-a-disc software, used mostly a software development method called Waterfall. This was a first-of-it's-kind model to introduce some kind of rhyme or reason to developing and delivering a computer based product. It brought law and order to the wild wild west of computer programs. The basic idea is that you do all the planning at once then the implementation then the testing then deployment and finally maintenance. At the end of which is a finalized product ready for mass consumption....until the the next inevitable update.
https://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm
Waterfall worked well for a long time until there was a need for it to improve. The impetus of this being the internet which introduced the concept of constant change. The ability to introduce quick enhancements to existing software.
Along came Agile which takes the waterfall method and adapts it to make it work more iterative and easier to implement change. It’s a way to make improvements or add new features to a product or system by planning small, manageable chunks of work and delivering them to customers or stakeholders on a regular cadence. This is instead of needing long periods of time to deliver...err...anything.
Agile uses the concept of Sprints which is best explained as a period of time when the team starts working on tickets and they are tested and then delivered them to production. The length of the sprint is dictated by the needs of the team.
The Players
In essence the PO makes most of the decisions on what tickets (work) needs to get done. They also work with stakeholders to best achieve goals and missions of the project. They should be ensuring clarity of tickets and expectations to the rest of the team.
This is the taskmaster of the team. They make sure everything is understood by all parties. They also promote process improvement and should be the one person to voice concerns without fear as that is their job.
Note: Upper management is usually left out, this is so the team can focus on the
work and the process.
Agile success is achieved by:
Transparency – Everyone involved in the project sees the tickets that are coming up next. Everyone should have a common understanding of what is happening
Inspection – Involves looking at tickets and making sure they are clear and have all the information needed. This means having a clear objective of the ticket, how to test it and expected outcomes.
Adaptation – This is where we constantly adjust processes based on past failures and successes. What worked and what didn’t work.
Note: Agile also limits (preferably squashes) any unplanned work being dumped on the team which can disrupt flows and cause confusion
The Backlog
The Backlog is comprised of all the tickets/requirements that are needed to be worked on. Some are urgent, some are deemed important but near-future tasks and some are simply nice-to-haves’s which moist likely get kicked down the road.- The backlog ticket list can get extensive – prioritizing is necessary
- PO works with Stakeholders to prioritize what most important areas are to work on at the current time
- PO works with the developers and QA to estimate how long each ticket may take to complete
- Estimating time of a ticket is based on the Fibonacci scale (0, 1, 1, 2, 3, 5, 8, 13, 21, 34, ...)
- This is done because it is a way of comparing a current task to previous tasks
- This takes a while to figure it out as the team finds their footing
- Typically, anything 21 and over needs to be broken up into smaller tickets as it may disrupt the flow of the team
Agile Meeting (or Events/Ceremonies)
These are weekly milestones or temperature checks that the teams do to give some kind of order to the main process.
Planning - Teams meet with PO and discuss the plan for the next week. Doable tickets, any blocking issues and staffing outages.
Estimation - The team talks about each upcoming ticket that is expected to be done next and they assign a number to it. Usually there is a group decision on what that number should be. If there is a disagreement on the number then the disagreeing parties state their reasons until an agreement is made.
Retrospective - This meeting can typically be at the end of the work week where the teams discuss what worked and what didn’t work. If something did not work then there is a discussion about process improvement. The main points of the meeting are to reflect and try to make the team's lives easier going forward.
Pruning - This is primarily done by the PO and team leads to figure out how to prioritize the important upcoming work. Different people may have different knowledge and may speak up here about the importance of certain tickets. If you do not speak up there is a good chance a ticket you feel strongly about may end up getting kicked down the road.
Standups - These happen every morning. Team members meet with their immediate team to let everyone know what they plan on working on that day and if they have anything that may be blocking them. The reason why you standup is to to make sure is is quick and to the point.
Continuous Software Development and Kanban
If your team is bold enough to move to a continuous deploy model then you will probably end up switching to using a Kanban board for ticket organization. At the outset this can appear chaotic but there is a sublime poetry to the way it works. Things just flow. First off here are some definitions.
Kanban board - this is a workflow visualization which enables you to optimize the flow of your
work. It shows the work that is currently happening. At this point the necessary tickets have already been prioritized and estimated and now it is time to work on them.
Continuous Delivery – When developers are regularly getting changes to QA for testingwork. It shows the work that is currently happening. At this point the necessary tickets have already been prioritized and estimated and now it is time to work on them.
Continuous Deployment – When QA completes testing and deploys changes to production
For this to work you need the following:
- Organized deployment tools
- Monitoring of production with alerts
- Automation – this is key to reducing the amount of regression needed and to creating faster feedback loops
- Smaller automation tests at the time of each deployment (non-functional API tests)
- Larger, full scale automation that runs either nightly or several times throughout the day
Summary
That's the nuts and bolts of it. Software development takes planning and Agile is the current go-to organizational tool. As well, transitioning between models can be scary and possibly painful but it just takes time to get into a rhythm and then after that perseverance.
References (sorry if I forgot any)
https://scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf#zoom=100
https://scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf#zoom=100
Comments
Post a Comment