Use of Blueprints + Blueprint Template

[James Page]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Team

I've spent some time with various members of the Ubuntu Server Team
over the last few weeks reviewing how we use blueprints to track
progress during the development cycle.

This was really with the objective of trying to resolve a few
challenges that we have with current usage:

1) It's often hard to evaluate exactly when a blueprint has been
completed.

2) We sometimes have challenges with understanding the use cases for
work.

3) What the overall goal is for a blueprint is not always clear.

4) Endeavouring to bake QA into all work we do.

When I first started contributing to Ubuntu we did try to write
specifications associated with each blueprint (see [0] for the
template).

I think that this approach did not work that well - often the spec did
not get updated throughout the cycle as the primary focus is normally
on work item tracking in the blueprint - so they age and become pretty
useless very quickly.

That said there are a few concepts in the specification template that
I think would still benefit our use of blueprints.  So I'd like to
propose bringing in some of the concepts we had in specs to the
blueprint summary and whiteboard.

1) Blueprint Summary

Rationale:

One or two paragraph statement about why we are doing this blueprint.

Goal:

Overall goal for the blueprint.

2) Blueprint Whiteboard

User Stories:

User stories really help thrash our what the requirements are and why
we are actually doing the work.  They should try and encompass how you
think the output of the blueprint will be used by real people.

There may of course be multiple stories for more complicated work.

Assumptions:

What assumptions are being made about the delivery of the blueprint.

Test Plans:

This is really about validating user stories; I find its helpful to
think about these as high level processes - then they can either be
hand cranked by people who want to try stuff out or do manual QA OR
they can be automated.

..or they might even be covered by existing automated test cases.

Release Note:

One or more suitable statements that could be included in the release
note for the release associated with the blueprint.

I've worked this into one of the blueprints that I will be driving
this release which is a) simple and b) already well defined - see [1].

So a few comments about the above:

1) Its not going to fit every blueprint we write - but I think it
should cover most of them!

2) I think that having everything in the blueprint will help with
keeping it up-to-date as its the place we all go to see what needs to
be done.

3) Interested people only have to subscribe in one place and they can
then see when stuff is updated.  Has anyone ever subscribed to a spec
in the wiki?

4) The original Specification template also included a section for
'Design' - I personally think that Design should really live past the
 lifetime of a single blueprint and should be delivered as
documentation  - probably in the wiki - and referenced from the blueprint.

I will be doing this for my blueprints this cycle - it would be great
if other people could try this out as well as they write up their
blueprints from sessions at UDS.

One feature that is currently lacking in the whiteboard is the ability
to track changes over time (although you could do this through
diligent monitoring of blueprint email spam).  Its possible that we
might start managing the whiteboard content in a bzr branch and
updating the blueprint periodically - but that's still work in progress.

Cheers

James

[0] https://wiki.ubuntu.com/SpecSpec
[1] https://blueprints.launchpad.net/ubuntu/+spec/servercloud-q-tomcat7
- -- 
James Page
Ubuntu Core Developer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJPs2aUAAoJEL/srsug59jDg2wQALfgoz/9BX7WrT7mDqexXDbY
4XA9aMjuVrbMIOgh4/qGN0eGPrGdbxBpOWCYeGphoXdYeaEp9D9VXsH/bywVYjHn
VVlfgo2ewar/wRIOHNXG+JWDLrHLhDUxLSywEof4g/5UPl3ybRjyr72U3eTZ2RCv
VS6OHd4MchBfl/CF+ZyyIaraFQxLBskXxh8AsLDj4eBrpiwopaYnTddcOLvAUkXH
jxhHbXeLX6I6RgUIbVpVHhnnWBSf72EvXue39g4+pxy/rjgBY9LIxUk6iBAMiRIN
Wo6sLUHG+Ibg/k8w50sCPPSMpObHbqVStWGb5gcejUrScpsSsv//u8tYYtYkLtJi
owcIjzj8pDLIdQY0L0NWpzs/+KN3jXRYJATX9/5eLc1Dm9qWnv5gW6iF/0GqHMs0
tgB1rxq5mMIDyG35e7SLedB/mZkV6/OO/vZl6dw0FtPGyuxFf4bEeUR+49AkORUR
63tch+nNoRkjPMe93SKZrhiSIvcf5837Q6kWu9ZLlvUDgpv0xmwSoDcPjs+6hdZJ
uMyUYlRTtdRBsHiVLEYC3EJCYES+AGjnb2hJmEz7PDxvyJITwPLqRnxotTSY4FKl
WqOBCU2v18VA4IEjLOM+kYq022Sh+Pco+JUk0BNL6TzaI0TzZml7mGkhzP9tnIE1
cverNrgeB8j05pM7BVaX
=I+IH
-----END PGP SIGNATURE-----