a couple of weeks ago Jeff langr and Tim Ottinger asked the public at large to contribute a couple more ideas for agile flashcards onto their site Agile in a Flash.
I decided to quickly create a couple which you can find at their site, but I've listed them again here just for reference purposes.
Of course, I probably need to spend a little bit more time on them to polish and clean up the quality of the grammar.
domain driven design(by Eric Evans)
-Agile documentation (by Scott ambler)
-agile modeling (by Scott ambler)
-product oriented development lifecycle
Here are some other ones I hope readers also find useful...
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:
-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
-typical bug fixing
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...