Agile is actually more like a philosophy, which „embodiment“ are the Scrum, Kanban, FDD and other methodologies.
Agile methodology
Категория: Workflow management methodologies
Kanban vs. Scrum
They are both Agile methodologies but…
Kanban doesn’t do sprints as Scrum does. There are no sprints, sprint plannings, sprint retrospection etc… The development is continious, like an assembly line. Constantly new and new task are coming in the backlog, the team members take them, do them and so on…
Both Kanban and Scrum are not so much different nor competing, they can be used together. One such example may be if we generally use Scrum’s sprints, planings, retrospectives, but for the part where we do the task, we may use Kanban. A kind of a hybrid – outside Scrum, inside Kanban.
Using Kanban, you as a developer should only pick a task from the Backlog, put it in Doing state, and once completed – move it in Done.
Kanban is more suitable for continiously improving given product, support, bugfixing etc… while Scrum is more suitable for solving more complex problems, usually during the initial development of the product. So, yet another example where these two methodologies may be used together: while we develop the product and deploy on production, maybe Scrum is more suitable. But later on, if the product is operational and needs bugfixing, pathes, updates (and certanly it will)… maybe Kanban would be better.
One feature of Scrum that I personally find as an advantage over Kanban
In some sence Scrum protects the developers from the constant changes and demands from the clients – lets do this too, lets do that too, change this task for it’s not good and we need smth. else…
By starting a sprint with given set of tasks and given time commitment, you actually say to the client „Look, these are the tasks, and they will be done by… some date… That’s it.“
Waterfall methodology
If we divide the entire development proces, from customer request, until product done, this methodology says tha the entire process must be divided into phases and most importantly – no phase should start before the previous is completed.
It’s pretty rigid and linear. The method relies heavily on all the requirements and thinking twice before you begin.
No phase should overlap other and each one fully depends on the previous one.
What we understand by phases? Tasks?
No, phases in general. For example:
Phase 1: Requirements from the Customer – this should be the only phase in which the Customer can take part and intervene. The requirements phase states:
- what the system should do;
- resources required for the project;
- what each team member will work on and at what stage;
- a timeline for the entire project, outlining how long each stage will take;
- details on each stage of the process.
Phase 2: Analysis – make sure that the Project is realistic and applicable in production, financial aspects etc…
Phase 3: Design – analyse the architecture, what technologies will be used, do we have the people for these technologies, the programming languages, the hardware and infrastructure needed…
Phase 4: Implementation – development begins…
Phase 5: Testing and Debugging…
Phase 6: Operation – the products is deployed on production…
Phase 7: Maintenance, debugging, patches, updates and additional functionality…
Waterfall methodology is suitable for cases where:
- we have fixed requirements;
- we have specifications and documentation.
Not suitable for cases where
- frequently changing requirements;
- constant new requirements from the customer;
- when updates are required ASAP.