Software Product Lines
|
Florian Weber wrote:
''a lot of my projects are very very small ones. mostly in the range of between one and three weeks. well, now i wonder, what would you guys recommend concerning writing stories? how long should one story take?''
Every small project has a large project inside waiting to come out.
Strike that.
Every group of small projects have a large project inside, waiting to come out. ;-)
Each project you likely don't start by re-writing the low level functions, like 'split()', from scratch. You probably have grown some lite libraries around your favorite database, GUI, etc.
So, after satisfying Customer A, don't just push all their code aside. When you start your project for Customer B, each time you hit The Test Button, all the tests for Customer A still run and pass.
This technique gives you extraordinary freedom to refactor a common core of opportunity out of projects for A, B, C, etc.
Don't say "if Customer == A" in any of the source. Split out the configurations on things by naming features. Then put configuration lists into common files that everyone shares. (Don't switch from one customer to another by changing the configurations back and forth manually!)
Next, make sure you can add a new customer, D, by adding their name to a brand table, turning their configurations on or off there, and recompiling. D should now join the test suite that covered A thru C.
Grow a star topology, where the core code, with its configurations, is the star, and custom code for A thru D are the planets around the star. But any duplicated code in the planets is a candidate for refactoring into the core.
This technique is called "Software Product Lines", and the SEI recommends it to companies big enough to hire them for a lecture. But SPL doesn't itself only work for large scale situations.
Describing SPL in XP terms (such as "fold duplication") might reduce several posts to one Wiki page. ;-)
With Software Product Lines, a big company splits out
a core group, and assigns each product line's source
to a product line group co-located with an
OnsiteCustomer?.
On a small project, that's all you. ;-)
So user stories in this context are requests to change
The System. You have new freedom to mingle requests
from many customers in your input stream. Your
customers don't need to "wait until you finish another
project". If they vote (with money) that their feature
request is higher priority, you can add it to your
input stream, and finish it sooner.
But one problem here is executives who allocate your
time, per week, to individual customers, to pay your
salary, and can't let you mix your behaviors together.