Hi there
On Wed, 28 Sep 2005, Laura Creighton wrote:
One thing that is rareley mentioned but rather important for agile
development is the measurement of how often you _get it wrong_. (Or
at least, throw it out.) This is because the results run counter to
traditional metrics of software development. Agility means the
ability to get it wrong. So -- within limits -- more wrong is better.
In traditional, completely non-agile, development, there is only time
to build one implementation. You must get it correct the first time.
Therefore you spend forever sitting down and planning 'the correct way
to do something'. And then you do it. Of course, fairly soon it
becomes obvious that the very best plan you could come up with
overlooked certain very important things. And this is just too bad,
because you don't have time to do things except the one way, so you
have to make as few changes to the master plan as possible ... and so
it goes. Eventually, over time, the software can no longer stand the
new demands that are put on it, and it is time to rewrite from scratch.
You just cannot patch it up any more.
In agile development you rewrite a lot of small things a lot. Instead
of discussing what is the best way to implement feature Q, you can
just go off and _build_ 3 ways to implement feature Q, and then look
at them and measure them, if it is appropriate, and see what is
better. But because you have the ability to persue different ways of
doing things, you end up throwing out a lot of code.
You also need language support for this -- you can talk all you like
about agile development, but some languages are so hard to write code
in that you really will not have time to try 3 or 5 or 7
implementations of an idea. Plus having sweated bricks to make one,
you are in love with your own code, and find it hard to toss it when
the opportunity arises.
So if you aren't throwing out a lot of code, then you aren't being
very agile. I'd say we're excellent on that score.
So the infrastructure for being able to do that (our entire test suite) is
a key component for "throwing away"? How does our automated test suites
fare in comparison with other OSS/agile projects?
(Relax Holger ;-)
Also -- while traditional agile methodolgies talk about _responding_
to change -- generally from the customer -- we don't have any. So we
make change just because we think it would be a good -- or interesting
thing to do. We're not responding to outside pressures. Indeed, we
would like it if the EU was a bit more flexible, and we could make
some changes to our proposal on the basis of what we have learned by
doing. But the EU is not very agile, and poor at responding to
changes desired by funded project consortia.
I agree - so to summarize - within the community and the boundary of the
PyPy project we are really fullfilling agile thoughts and values - but the
EU boundaries of the projects is "dampening" our "Ability to continuously
learn" and "Responsibly responding to change" - more?
Thanks for your thoughts on this Laura!
Cheers
Bea
Laura
In a message of Tue, 27 Sep 2005 22:20:52 +0200, Beatrice During writes:
--8323328-2105496072-1127852452=:25960
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT
Hi there
I am working on documenting PyPy (the project) as a showcase of agile
development. In order to be able to do this I would love to get some
thoughts and reflections from you who are working on /following PyPy and
the question is of course - how agile are we?
Here is some short notes on success factors of agile approaches (from an
eworkshop in 2002 - Cockburn, Beck etc,
http://fc-md.umd.edu/projects/Agile/Summary/SummaryPF.htm):
-------------------------------------------------------------------------
In general, the group agreed that the following are the success factors
for agile development:
§ Negotiation: If people are willing to keep talking and learning,
you are, almost by definition, agile.
§ Ability to continuously learn
§ Responsibly responding to change.
§ Environment where rapid communication is enabled.
§ Team reasonably in charge of its own destiny (being allowed to
succeed).
§ People are valued over other factors
§ The team needs to be more than just able, it needs to actually
succeed. There needs to be a support network for each
individual in the
team to make a contribution however small.
------------------------------------------------------------------------
How does these factors apply to PyPy and this community? Are we doing
other things that is not mentioned here that is working well for us? Thin
gs we could do better?
Your responses will be part of documentation about PyPy/agile dev
(sprints) that will be distributed to the EU, Universities, various
companies and other Open Source projects who have stated a clear interest
in the PyPy showcase.....
If you feel that answering this email doesnt really fit the purpose of
this mailinglist - please answer to me specifically.
Thank you for your contribution!
Cheers
Bea
Beatrice Düring Change Maker
Tel: 031- 7750940 Järntorget 3
Mobil: 0734- 22 89 06 413 04 Göteborg
E-post: [EMAIL PROTECTED] www.changemaker.nu
"Alla dessa måsten och alldaglighet.
Allt detta som binder vår verklighet
i bojor av skam och rep utav tvång.
Alla dessa kedjor som binder vår sång.
Jag skall slita dem alla i små, små stycken
och möjligtvis av resterna göra mig smycken."
- hemlig
--8323328-2105496072-1127852452=:25960
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
[email protected]
http://codespeak.net/mailman/listinfo/pypy-dev
--8323328-2105496072-1127852452=:25960--
Beatrice Düring Change Maker
Tel: 031- 7750940 Järntorget 3
Mobil: 0734- 22 89 06 413 04 Göteborg
E-post: [EMAIL PROTECTED] www.changemaker.nu
"Alla dessa måsten och alldaglighet.
Allt detta som binder vår verklighet
i bojor av skam och rep utav tvång.
Alla dessa kedjor som binder vår sång.
Jag skall slita dem alla i små, små stycken
och möjligtvis av resterna göra mig smycken."
- hemlig
_______________________________________________
[email protected]
http://codespeak.net/mailman/listinfo/pypy-dev
