The DevOps paradigm can be implemented through many different methodologies. The 2 most popular are: Scrum and Kanban.
Scrum
In essence, this is Scrum:
Everything that needs to be done is part of a product backlog. These tasks are then put into the Spring Backlog, and a spring is like a month long. Then anything blocking is reviewed daily for a "stand-up" meeting, and everything should be delivered incrementally with a view to the end of the spring. Then this process starts over again.
You're supposed to have certain roles to ensure this runs effectively: a product master to manage the product/spring backlog, a sprint master so that the Scrum is being followed. Then the sprint backlogs are supposed to be estimated, people are supposed to take ownership of tasks, nothing is supposed to interrupt the sprint, stand-ups are supposed to be useful, multiple people are working on the same project, and tasks are done throughout the sprint so that "burn-down" and "velocity" can be shown in a chart.
In reality from my experiences nothing like that ever happens, there is a great potential for misuse of Scrum mandates, which are arguably out-of-date in today's world. Especially for a small project I would recommend implementing a Scrum-ban (hybrid, or Kanban methodology which is less restrictive, and has a greater allowance for testing in order to help ensure high code quality, instead of having such an importance of deliverables at the end of a sprint. In theory sprints are supposed to be a way for developers to be protected from immediate changes to requirements, but with the flexibility to make changes to your plans as you go along. But in reality a lot of time that doesn't happen that way, and development get interrupted, and medium/long-term vision of projects are not as highly regarded as they should be.
Kanban
It's a method for continuous improvement, that is you add things you want done to the "To Do" list, and prioritize them. Then when you're free, take a couple things to the "Doing" list. Set a conservative limit on how much work you can do at any one time. When they're done, but them across to another "Testing/Waiting" or "Done" list. When you've freed up a slot on the Done list, then pull something from the To Do list. If something bounces back into Doing from Testing, Waiting, or Done, then either move something back to To Do, repiroritise, or just carry on and deal with it, and only pull something new from To Do when you're free and back to a normal workflow. So it's supposed to be a way for "pulling" work instead of "pushing" work, e.g. work being pushed onto you constantly. Rather, you constantly pulling work onto yourself when you have the capacity to is much better. This way if things are taking too long, or if they are problems in the chain from To Do -> Done, then it should be quickly realised where bottlenecks are, and how to overcome them. This is something that Scrum normally fails at doing, what with its Sprints, Velocity, Poker Chips estimation, etc.
No comments:
Post a Comment