 |
What We Have Learned
|
|
|---|
|
Values
  You will know you are
in harmony with your values when you are happy with your work.A
simple design is always easier to build and maintain. The problem is
simplicity comes from an in depth knowledge of the system. Refactor and
re-design as you gain knowledge and understanding.I
have been surprised many times by how efficient a simple design can be.
Simple designs often out perform highly complex yet theoretically
optimized designs.The system metaphor is
just a metaphor for using good names for things.Face to face
communication is faster and more reliable than anything else.Having a
software
tool is not the same as having a process. The tool can enable
but it can not replace the process.Coding
XP and Databases.Useful Pair Programming idioms.Some rules
of thumb for pairing.Experimental evidence
for pairing. Code reviews considered
hurtful.Egoless
programming never works. You should be proud of good code. So
instead
be proud of everyone's code by working together to make it so.Analysis,
design, code, and test are all on going and simultaneous activities
that are not explicitly managed. You allow your team to decide what
needs to be done by whom.
|
Planning
Treat iteration end as
a serious dead line and create working, finished software to
demonstrate.Tear
up unwanted user stories as soon as they become low value. If you dread
tearing one up then you spent too much time creating it.When user stories are
consistently small in scope you can skip turning them into tasks.When your team finishes
numerous user stories per iteration try a shorter iteration. One week
is considered optimal.When
a manager asks to change an estimate or a customer refuses to
prioritize stories it seems like they have taken control, but in
reality they
have lost control by refusing an important decision.Trying
to catch up is the fastest way to get further behind. Instead call for
a planning meeting, accept how far you have come and create a new plan.Automatic
Tests
Could have saved
us some time.Testing first
makes the code testable.Acceptance tests give a
feeling of stability.Download a tool (FIT)
or create a tool to help manage the huge amounts of data that is
created as part of your acceptance tests.Next
we should look at when Extreme Programming (XP) should
be used. |
|
ExtremeProgramming.org home | When should I use Extreme Programming? | About the Author |
|
|
Copyright 1999, 2009 Don Wells all rights reserved |
|