What is missing?
We have dozens more cards we can write and post, so were not running short on ideas even though we can be short on time to get them all written up. Still, I wonder, if you could pick the next card for me, what would you want it to be about? Is there an area we've not addressed at all? Topics of interest to you that might be interesting to others? Guest authors we should contact? I'm all ears.
Subscribe to:
Post Comments (Atom)
Now that their are so many it would be nice to one place that just had the cards so that it would be easy to print out.
ReplyDeleteI think the "JEDI" approach is missing (any by that, I don't mean the mantra of "use the source Luke" ;-)
ReplyDeleteI think there is something missing regarding TDD and Design. Uncle Bob's three rules of TDD (and other writings) often mislead people to think that there is ZERO design up-front, as is if NOT doing BDUF implies 0DUF (a.k.a. NoDUF).
This is false, but how do you reconcile it with the three rules of TDD? I can't write test-code without being able to invoke the thing-under-test. I can't invoke a thing if I haven't attempted to design the interface. If I design an interface (even for a single method/subroutine) I have to have some inkling of which class/package/module it would go in, at least INITIALLY!
So there is some initial amount of design I do before writing a test that is both necessary and sufficient to define "just enough" of the interface of what I want my test-case to test.
I suggest two things as a result of this:
1. a corrolary to Uncle Bob's three rules that make some reference to this (and that we arent doing NoDUF)
2. Another card, called "JEDI", for Just Enough Design Initially/In-front
I think the JEDI acronym has been used before by Uncle Bob (in "The Scatology of Agile Architecture") and also by the FDD folks at www.step-10.com and featuredrivendevelopment.com and). Just Google-search on "JEDI" AND "Just Enough Design"
I think there is a relationship between JEDI and Eric Evan's "Supple Deisgn" and DDD, as well as *some* of the so-called "Pre-factoring". But it can be a risky, slippery-slope, so it would be great to have a rule to help us know when we've done "Just Enough Design In-front/Initially)
Hi Brad, thanks for the post! I'm trying to think of what would be useful on a JEDI card itself. I saw Uncle Bob mention the phrase "Iteration 0"--for now, that's the card I want to write. JEDI goes, sure, now I just need to figure out what else goes on it. Here's a quick stab at the bullets:
ReplyDelete- JEDI
* may require domain and architectural spikes
- (re?)estimation of all stories
- establishment of team standards
* coding, build, process, warning, test, etc.
- creation of smoke/tracer bullet tests
- one simple story built
Hm, what am I missing?
So youre looking for examples of JEDI, or instructions?
ReplyDeleteI suppose JEDI is a way of straddling the "appropriate range" of risk between anticipation and adaptation.
On the left-hand side of overanticipating we have "too much too soon" and big/all up-front design.
All the way on the right-hand-side we have too little too late. Here you are faced with legacy-rewrites, system re-engineering, large-scale restructuring, etc.
The problem with both extremes is the creation of technical debt.
* One Extreme does it by adding complex structures and behaviors too early in the cone-of-uncertainty and causes too much rework to rewrite that which was not yet certain and subject to much variability.
* the other extreme does it by sheer entropy/decay/rot that results from inattention and/or negligence
In the middle we have a delicate balance to be struck, which JEDI represents. There is a certain amount of "pay-up-front" and "pay-later" that need to be balanced with "pay-as-you-go".
In the middle of the scale is pure refactoring. It is strictly emergent, JIT pay as you go, by focusing ruthlessly on keeping code clean and simple.
Minor-to-moderate restructurings (too large to be refactorings, too small to be total re-writes) are to the right. Sometimes larger systems and/or systems constructed by multiple-teams can do a great job at refactoring and still not be able to avoid the need for minor-to-moderate restructuring, particular for aspects of the design that cut across teams and architecture and functionality.
Just to the left of refactoring would be so-called "pre-factoring", where you have enough experience refactoring that you are able to apply basic application of encapsulation, DRY, separation of concerns, etc. without adding premature abstraction of inessential complexity. This is hard to get right, and has risk associated with it. But it does get progressively less with the better judgment that comes experience and practice.
To the left of pre-factoring would be the subset of DDD known as Supple Design. And the rest of DDD would be to the left of supple-design.
This also represents a continuum (within the "acceptable" range) that goes from left-to-right of clean code -> simple design -> emergent design -> "supple" design -> incremental design -> evolutionary architecture.
The trick of knowing the "just enough" range lies not just in experience and discipline, but also in understanding your context and your "lead-time". Lead-time in particular dictates how soon in advance you need to be able to think and anticipate (and at what level of detail). The shorter the lead/cycle-time, the less you need to anticipate and prognosticate.
So I would see JEDI as a card that somehow is able to depict this continuum between anticipation and adaptation and where these various techniques fall on it, and the factors/tradeoffs that help you identify the right "range" for yourself.
Of course there is a close relation to technical debt and the cost-of-change curve :-)
I love the JEDI card, I have a few others that I have built for myself...
ReplyDeleteThey are
-domain driven design(by Eric Evans)
-Agile documentation (by Scott ambler)
-agile modeling (by Scott ambler)
-product oriented development lifecycle
-enterprise stakeholders
you can find them@
http://agileconsulting.blogspot.com/2009/04/in-previous-post-i-mentioned-how.html
Also, some other ones that I would find to be interesting (apologies if you already added them by miss them)
========================
Behavior Driven Development:
1) use story driven scenarios to specify the acceptance criteria for an iteration
Given [some State]
And [some more state]...
When [an activity completes]
And [another activity completes]...
Then [an assertion is true]
And [another assertion is true]...
2) wire these acceptance criteria into an automated acceptance testing framework (like fitness)
3) have your developers write code for the iteration into the acceptance criteria pass
-make sure to use the ubiquitous language when defining your stories/tests
-focus your requirements and quality testing efforts on designing these executable requirements at the beginning of an iteration
========================
the Kano model of customer satisfaction
-when creating a backlog for your customers, categorized items into:
-mandatory
-linear
-exciters
-reverse (don't implement these :-))
Do this by developing a questionnaire that asks different stakeholders how they would feel if a specific feature was present or not present
1. I expect it to be this way
2. I like it that way
3. I am neutral
4. I can live with it this way
5. I dislike it this way
both negative and positive answers can be cross-referenced to determine the category of the feature
See http://agilesoftwaredevelopment.com/2006/12/kano-questionnaires for a example...
================================
Value Stream Mapping:
the best way to determine how much agile can help an IT delivery organization is to perform a value Stream mapping analysis.
Measure the ratio of work to wait time/waste for both the current and suggested future development process
Do this for
-larger features
-typical bug fixing
-emergency fixes
(Picture here)
=========================
Web 2.0 Based Documentation:
make sure all documentation, including technical specifications, standards, decisions, etc. are all placed on a web-based collaboration platform.
This collaboration platform must
-allow all participants to modify content
-be available to both internal staff, contractors, and outsourcing
-promote an open, collaborative approach to running projects
Excellent examples are wiki, blogs and user forums...
Hope those are useful
http://agileconsulting.blogspot.com
ReplyDeletehttp://agileconsulting.blogspot.com
INFORMATION RADIATOR
ReplyDelete- highly visible
- understandable at a glance
- current
- relevant
How about something on product documentation? My theory has always been if you need a document to describe how your system works you've made it too complex for the user
ReplyDeleteJust a follow-up (albeit late), at Agile 2009 I attended a session by Neal Ford (www.nealford.com) on "Evolutionary Architecture and Emergent Design" which in turn is based on material from his book "The Productive Programmer" (http://oreilly.com/catalog/9780596519780/)
ReplyDeleteNeal also has a series of articles on the topic @ developerWorks.com and the introductory article has a graph of sorts that I think starts to get close to what I attempted to describe above for JEDI (see Figure 1 "Spectrum of Design" in the section titled "Defining Design" at http://www.ibm.com/developerworks/java/library/j-eaed1/)
Basically the horizontal axis of the timeline shows how much before or after you do the design: all-up-front, incrementally up-front, immediately before (test-first), immediately after (as in refactoring), incrementally after (restructuring), rewriting/reengineering etc.
peppered about that timeline are techniques or practices such as evolutionary architecture, domain-driven-design, incremental design, TDD/BDD, refactoring, restructuring, etc. Each technique tries to place itself in the correct horizontal position on the timeline.
Then "JEDI" itself is basically a "curve" across this horizontal axis (time) and vertical axis (size/complexity) that looks a bit like a bell-curve of sorts, the area under which indicates how much up-front, during, and after-the-fact design is appropriate. Projects of different size/complexity would have slightly different curves acknowledging the need for more up-front work.
The area under the curve would correlate somewhat to technical-debt. Meaning the more you design too-early, the more technical debt you are creating for later, and the more you wait until its too-little-too-late the more you are accumulating without "paying down" your debt.
And that would be the JEDI card. Its sort of like cost-of-change curve accept it is the cost of designing too-much-too-soon versus too-little-too-late with "JEDI" indicating the "sweet spot" (for a projects size/complexity and risk-threshhold [e.g., spaceshuttle launches])
The "techniques" that fall on the appropriate points in the horizontal timeline would likely also correspond to other cards in the tech (TDD, BDD, DDD, Refactoring, Restructuring, Emergent Design, Incremental Design, etc.)