EuroPython 2009: Agile Development - mrtopf.demrtopf.de

EuroPython 2009: Agile Development

Bea Düring's agile Talk

Bea Düring was presenting how she helped OpenEnd to become an agile company.

Before that they were activity oriented based on the development tasks at hand. They also had long iterations and only tested at the end (6 month iteration cycles) with lots of cases they wanted to implement at one iteration.

So the first thing was to become feature driven, because features is what drives the development. Also making the whole development test-driven was one of the tasks.

They also introduced pair programming but in fact promiscious pair programming which means even if a task is not finished you regularly replace one partner from the pair. That way everybody has more knowledge about the code base.

Of course also they started with unittests based on py.test and they are also deploying more often, like once or twice a week.

Tools they are using is a mix between scrum and eXtreme Programming because there is no size that fits it all and Bea took here experience from the PyPy project and developed on that.

Examples

„Simple Design“ is a concept from XP. One of the core things which provides working software. But sometimes you really have to know how to fail quickly which does not necessarily mean simple design first.

„User Stories“ are stories which are not requirements but the base for requirement. They do not work that way though because they want to be feature driven which are usually larger. They drafted their own view on how they see features. They didn’t want to use the word feature so they used the word „gummybear“ (build the „timeline gummybear“).

What do you also do if you cannot go fully agile? Sometimes you have resource problems and you have customers who want different stuff than you are focusing right now on your development plan. They have 1-3 pipelines for different uses. The sprint backlogs also come from different projects. There is not a separate sprint backlog for each project. The team will pick their tasks from this one backlog in the daily meetings. This gives you more flexibility if you have a small team.

Another thing you do in scrum is you work on a lot of paper. You have everything on a wall. That works well if you are colocated but not if you are all over the world. If you then don’t allow them to use digital planning system then you are lost. And what they are actually working on is such a coordination system for groups so they also want to eat their own dogfood.

The main point here is that you need to know when and why you want to leave the given concepts of e.g. scrum or XP. Hybrid usually is more often found.

The paper-agile tradeoff and gummy bears

The PyPy project and other projects had the problem that they wanted to use agile but still of course had to create a lot of paper for making their contractional partners (in this case the EU) happy.

When they wanted to build a web client for OpenEnd they invited Aza Raskin from (back then) humanized.com and did a more python like sprint which means 1 week of intense work, in this case just design work, no code was written. There have been some requirements as input and mockups have been the output. They had back then no clue though if they could actually implement this into a browser.

But only after that they started implementing. Back then they still were in the case oriented testing and they had to change it to a fully feature driven approach. She showed an example of a gummy bear form (I guess slides will be available).

a Gummy Bear

A gummy bear template is created and then it lives as long as the feature lives. If the feature changes the gummybear is updated. One thing is that you also add where your inspiration for certain ideas come from. Better voice it.

Requirements are also noted, not just the user stories, in IEEE terms like capabilities, conditions and constraints.

A gummy bear also contains an acceptance test. It’s not completed once this is passed.

So in one and a half page you have all information contained you need. It’s designed to have everything in there from development to test. It’s not that much used by the developers but later mainly by the testers.

The main point is probably that you need to be agile in finding your agile approach. There is no space for fundamentalism where you are not allowed to write down certain things simply because the agile methodoly does not allow for it.

Technorati-Tags: , , , , , ,

Kommentare sind geschlossen.