That was using an earlier version of the principles when Tom and Mary had 10 or so of them. Now they've narrowed it doesnt to seven, so I figured I'd take another stab at it:
- Eliminate Waste – Eliminate avoidable merge-propagation (multiple maintenance), duplication (long-lived variant branches), and stale code in infrequently synchronized workspaces (partially completed work)
- Build Quality In – Maintain codeline integrity with (preferably automated) unit & integration tests and a Codeline Policy to establish a set of invariant conditions that all checkins/commits to the codeline must preserve (e.g., running and passing all the tests :-)
- Amplify Learning – Facilitate frequent feedback via frequent/continuous integration and workspace update
- Defer Commitment (Decide as late as possible) -- Branch as late as possible! Create a label to take a "snapshot" of where you MIGHT have to branch off from, but don't actually create the branch until parallelism is needed.
- Deliver Fast (Deliver as fast as possible) -- complete and commit change-tasks and short-lived branches (such as task-branches, private-branches, and release-prep branches) as early as possible
- Respect People (Decide as low as possible) -- let developers reconcile merges and commit their own changes (as opposed to some "dedicated integrator/builder")
- Optimize the "Whole" -- when/if branches are created, use the Mainline pattern to maintain a "leaner" and more manageable branching structure
Did I get it right? Did I miss anything?
4 comments:
Re build quality in I think you should reference test suites, test drive development explicitly as they are probably the biggest drivers to maintaining quality I have seen.
Good point Robert! I'll go add that right now (many thanks!)
As worded, 'Eliminate Waste' is something of a catch-all for the other points.
From the Poppendieck link principles of lean thinking, I got the idea to suggest instead 'Add Nothing But Value', as the other side of eliminate waste.
In other words, only add items and labels that are necessary - it's so easy to create "cruft" by adding stuff just in case.
Use a simple teamwide convention for tag names. eg. a convention like "TAGNAME_ABC_checkin" flags to all others that developer ABC believes the code at that point should compile & run.
Have an automated background process that pulls each _checkin out into a fresh empty directory, compiles for all platforms and product variants, runs a static analysis tool like splint, links and runs the unit tests and any automated functional tests. CPU time is cheap, developer time exhorbitant.
Report the failures to a warm body that will facilitate a return to a clean build in the fastest, productive and blame free manner.
Post a Comment