Agile methodologies and BDD/TDD
This article will be taking a look at the main Agile methodologies and principles/routines they outline.
It will also cover the difference between BDD and TDD, both of which are key parts of being Agile.
In the past decade there has been a real surgence of Agile. They are a fantastic development tool as well as lean.
We will be taking a look at 3 of the most prominent including Scrum, Kanban and XP.
- Visualise workflow (Items on cards on wall inside state column e.g. Todo, dev, test, release, done)
- Limit how many can be in each column at once. The work-in-progress.
- Measurr time to complete 1 and optimise process to make this time as small and predictable as possible.
- No time-boxed iterations
- Morr adaptive. Less rules.
- No roles.
- Limited how much in progress directly by rules.
- Limit WIP (work in progress) of all workflow states. Velocity here is WIP.
- Is a persistent board, never reset, things bought into todo column.
- Items from backlog taken when some1 available
- Split org into self organised teams
- Split work up, estimate and prioritise
- Split time up into short sprints (1-4 weeks).
- Daily standup routines
- Optimise process with retro after each iteration
- Small team spending short time building something small, but integrate regularly.
- More prescriptive (more rules to follow)
- Has roles. Product owner, team, scrum master.
- Combines 3 activities per iteration. Planning (& commit). Process improvement. Release.
- START – team pulls items from backlog (based on propriety) and estimates what can get done.
- MIDDLE – focus on what committed to. Scope of the iteration.
- END – demo (potentially ship able) and retro.
- Scrum board with tasks on and state columns. Gd when this becomes kanban board.
- Limited how much in progress due to iteration length.
- Measure velocity (How much we can get done each sprint). Story points per sprint. Becomes amount estimate on.
- Burndown chart. Hours of work left vs days left of iteration.
- Ideally all items broken down small so nothing left at end of sprint
- More prescriptive than Scrum.
- Includes most of scrums rules
- Includes TDD and pair programming
From personal experience I would recomming mix and matching the methodologies until you come up with the best in between mark for your team. It is important to be empirical as they are not strict rules, they are there as a set of guidelines expected to be experimented with. Take feedback from your retrospects and decide as you move along what needs to be tweaked. One piece of advice is to start with less and build up routines and practices as you go along.
TDD vs BDD:
Something which is very important to any agile team or code base is testing. Incorporating testing into devleopment is crucial and is best done in the manner of BDD and TDD. Some of the agile methodologies incorporate them already. There is no greater reassurance when writing software than than having max code coverage. How can any refactoring or improving take place without the assurance that you have not broken something somewhere. So what are they?
Behaviour DD (is more like BTDD):
- Acceptance tests (written from Acceptance Criteria of story)
- What is required for functionality
- Help communicate what overall functionality is of story
- Black box tests
- Coverage of code written
- Check logic of internals
- Help communicate what internal logic is
- White box tests
When it comes to BDD and TDD definitely using both in conjunction together is a recipe for success. They should both be written at the start before any other code is written as they help focus and outline tasks for everyone in the team. They also force devs to really understand the problem they are trying to solve so that when they come to implementing it for real they have 100% understanding as the unit tests cover it already.
There is more to come in the future on agile methodologies and testing inside of web apps in general.