- Correctness -- the property that the current configuration of the codeline executes correctly and passes its tests.
- Consistency -- the property that the current configuration of the codeline builds correctly
- Completeness -- the property that the curent configuration contains all that it should, builds all that it should, and tests all that it should
- Cadence -- the property that the codeline has a regular rhythm/heartbeat/pulse that represents a healthy flow of progress (and creates a new resulting "current configuration" every time a new change is commited, integrated, and "promoted")
- Collaboration -- the property that the balance of the above achieves a productive and sustainable degree of collaboration that serves as the source of value-generation
Am I missing anything? What about Concordance (via audits or with stakeholders)? Or Customer? Content? Context? (dare I use the word "Control"?)
2 comments:
Excellent idea! I've thought of a few other ones:
- Constant Change, or Continuous Change
- Collaborative Communication
- "Clockwork Cycles" instead of Cadence
- Clarity of Configurations, or Clear Configurations
Consistency and Completeness may be considered as attributes of Correctness. I propose to make it one.
Completeness is even arguable, as Agile means we strive for minimum, sufficient and necessary functionality
Clarity of Configurations means that it must be simple and understandable which configurations are where, and what is in it. Beit workspaces (sandboxes), test systems, proto rigs or production systems, it must be clear and simple to be Agile.
Hi Frank and Dave! Thanks for the comments.
Dave, I very much like your idea of Continuity. I think it relates to "availability" as I referred to it in a subsequent blog entry on codeline flow, availability and throughput. I think Frank is perhaps getting at the same think when he writes of "Continuous Clarity."
Frank, regarding "complete" being perhaps more "big-up-front" than "agile", I think that's not a problem the way I described it because it's more about being holistic or "whole" as opposed to parts (e.g., preferring full-builds to partial builds, and running all the tests over partial-testing).
Complete in this context means "whole" rather than "done" or "all up-front" (perhaps Completeness is slightly better at indicating the meaning of both "necessary" *and* "sufficient").
Post a Comment