[p4] Agile with Perforce

[Jeff Younker]

Sally Page writes:
>
>
> I'm just trying to gather some implementation ideas, issues that this
> causes and get a better understanding of this "technique".



First off, it's worth watching Elisabeth Hendrickson's tech talk
about QA in an agile development environment:

http://www.youtube.com/watch?v=bqrOnIECCSg

> Does anyone have some good usecases or models of working "Agile" with
> Perforce, and what do you believe this really means when it comes to
> access control, branch management, and CM planning etc.


Sooooo.... ok.  This touches on so much.  I'm writing in a hurry,
so this may be a little abrupt.  Feel free to ask more.

An important thing to keep in mind is that agile development
techniques aren't about cowboy coding.  They're about ridged
discipline, and constant feedback.

Release cycles are very short, on the order of two weeks to a
month at the outside, so there isn't too much divergence from
the trunk.   Changes are distributed throughout the code due
to collective code ownership.   Extensive unit tests let people
do more code-cleanup.  This results in more churn across the
repository.

Two days for an integration is 1/5 of your development cycle.
Project branches don't work well in this sort of environment, so
the team works together in a single codeline.  Your your
branching structure tends to be simpler.

Collective code ownership means that every has access to
all the code.  You don't worry so much about protections.  If
somebody goofs it will be caught by the CI system.

CM becomes more of a process of triage.   Features should be
scoped at a fairly small granularity, so triage is less about adjusting
or re-characterizing features.  It is more about about prioritizing
them and slipping the low priority tasks to the next release.

Since you have another release coming up in two weeks slipping
a feature isn't such a big deal.  There's also less drive to shoe-horn
things in because there's less of a sense that the this is the last
chance the customer will have.  The rapid feedback on estimates
means that you have more information to support scheduling
decisions.

The short release cycles mean that you have to focus intensely
on automation.   The same automation that's used for production
needs to be used for development.  This ensures that the automation
is being tested along with the code.  You're not going to have time
for a separate automation phase.

Do you do deployment by hand?  Not any more. You can't spare
a day for deployment.

Do you do database upgrades by hand?   Not any more.  You have
to be able to roll them forward and backward in QA every single
day.  Look at something like rails migration.  Your DBAs need to
become *much* more a part of the development group.

There is no separate QA phase.   QA needs to be performed on a
feature-by-feature basis *as the features are completed.*   You need
to automate regressions.  They must be run every day.  Your QA
people are sitting with your developers.

Documentation:  Use less of it.   Use active documentation sources
when possible.  You don't have time for a lengthly specification
process.

Consider using a tool like FIT.  FIT documents (written in pretty
much anything that outputs tables) can be written by non-techies.
They are bound to test fixtures, and the produce non-techie output.
They serve as product spec, design doc, and test plan.  They
can be used to communicate sprint status.

Make this documentation part of the codeline.  Stuff your
automation into the codeline too.  It's part of the project and it
should travel with it.

- Jeff Younker - jeff at drinktomi.com -