Subscribe to The Life-long Struggle Against the Console        RSS Feed

Software Development at the BBC

Icon Leave Comment
So I thought I'd write about how things 'get done' in my department at the BBC, and how we write software.

Meet the Team..

The BBC uses 'Scrum' which is 'agile development', and is a variation of XP (Extreme Programming). Team put together for a project, usually include:

1) A 'technical 'project manager' - the scrum master and team facilitator. He is the person you go and talk to if you have any 'blockers', which are problems preventing you doing work on the project.
2) A 'product owner' - this is the person who owns the product the team are developing. He liaises with other 'stakeholders' (people interested in the finished product, for example, the users of the product) and also raises problems that the general public have complained about (an example - on product X the font is too small so I can't read it).
3) A 'team lead' - this is the lead developer. He is responsible for prioritising technical time, making most of the technical architecture decisions, and generally being the development first in charge.
4) A number of software engineers, like myself, who actually do the implementation work.
5) Some 'consultants' who are generally other experienced engineers and/or the department software architects. They do not implement, but can be asked questions about domain knowledge.

The Planning Phase

The project has an initial 'planning phase', where the work for the project is broken down into 'cards' or sections of work. Each card represents a user story, ie: "I am a user of iPlayer version X, I try and click on the BBC Logo and want it to take me to the main website". We will typically have dozens of cards in this planning phase. On each card, the team lead and the software engineers come up with an estimate of how long each card will take to implement, in terms of days or hours. The aggregation of all the card's hourly estimates is used to chart progress when we are in the 'doing' phase, or implementation phase. We log hours against each task, and so we can chart some interesting graphs where we plot the estimated time it takes versus the time we have logged against each task.

The Doing Phase

The task cards get divided into 'sprints' which are usually one week-long chunks of work. Each morning we have a 'stand up' meeting, where each team member answers the following questions: 'Yesterday I was working on X, today I will be working on Y' and brings up any blocking issues that is preventing work on X or Y.

We use an agile planning board to chart the progress of the task cards through the different stages of the project, from "haven't started" to "QA tested and complete". In each standup meeting, the project manager will move these cards around the board after each developer has said what they have done in that particular day.

This process repeats until all sprints are over, and all cards have moved from the left of the board - "haven't started" - to the right of the board - "complete". Then the project is over.

More info

More information about the processes we use:

* We sometimes use pair programming, but I haven't used it yet. It is optional, and is dependant on whether the software engineers want to do it (I don't like it).
* We have QA testers who test the work we do. This is great - QA testers are an amazing help. They are much better at finding bugs in your implementation than you are, because they are not you, and don't have a vested interest in claiming that your code is 100% perfect :)
* We use TDD - Test Driven Development, so on a new project we will write tests before writing code. TDD is used almost everywhere at the BBC, and is very very helpful.
* Some teams have started to use BDD, which is Business Driven Development - that involves making the QA analysts and product owners write tests themselves in a pseudo-language. Developers then turn this pseudo-language into real tests. This has the advantage of making the non-technical team members really think about what they want, before they ask for it, and not requiring the developers to second-guess their intentions. There is much more to explain about BDD, but I have never used BDD yet, and so don't know much about it.

There you go then, hopefully that was interesting to someone. The BBC really is on the cutting edge of software development compared to a lot of companies, and spends a lot of time thinking about how to write software better.

0 Comments On This Entry


Trackbacks for this entry [ Trackback URL ]

There are no Trackbacks for this entry

November 2015

2223242526 27 28


    Recent Entries

    Recent Comments

    Search My Blog

    0 user(s) viewing

    0 Guests
    0 member(s)
    0 anonymous member(s)