I'll be presenting at Agile2009 in Chicago on the Tools for Agility stage on Tuesday 25 August, 4:45pm-5:30pm.
Here is my session description from the Agile2009 conference website (download PDF here)
WANTED: Seeking Single Agile Knowledge Development Tool-set
Aren’t code, backlog-items, tests, designs & documents all just different forms of system knowledge at different levels of detail? Why can’t the same tools help refactor, browse, search, and provide build/test automation for non-code forms of knowledge without requiring a separate tool/repository for each format? This talk is intended as a challenge to tool vendors/developers to see how this simple treatment of all non-code items as part of a single, unified project knowledge-base can be at once both immensely powerful, and imminently practical, without requiring too much added complexity.
Process/Mechanics
Approximately ~30 minutes of slides/presentation to “make the case” for why this approach is useful and desirable, followed by discussion of challenges (to and from tool developers/vendors, as well as the rest of the audience) as to its usefulness and benefits, and why their current tools can’t easily do so and why the should or should not be easy to enhancement them to do it.
What makes it easy/hard for these and other tools like any of the following to do this, or to be simple “skins” or plug-ins on top of only a handful of tools instead of a whole kitchen sink full of separate tools and repositories.
Outline
Software development as knowledge development
- Source-Code as knowledge
- Requirements (Stories) and Tests as knowledge
- Other usable forms of project knowledge (e.g., build scripts & configuration, build/test result reports version control history/comments, online help & other supporting docs)
How would I do this?
- Refactoring Knowledge (thinking about the rest of the “knowledge” the way we think about the code, and its habitability, navigability, and structure/refactoring)
- Applying other agile-practices (like TDD, Continuous Integration, etc.) to non-code knowledge development
- Wiki-based skins, DSLs, and use-cases/design as domain-driven Wiki-word definitions
- Patterns (giving things names), Retrospectives results and lessons learned
- Viewing, searching EVERYTHING (even the code) via wiki?
- The “Wu-Wei” of Traceability (Tracing without Tracing)
- Versioning and operating on wiki-like entities, just like with code (e.g., making “working copies”, branches and tags)
DISCUSSION & CHALLENGE: Why can’t (or how can) YOUR tools do this!
Begin audience discussion/dialogue: Why can’t a tool like Eclipse or a Wiki-based CMS (such as Confluence) be used as a front-end to browsing/refactoring and navigating ALL the knowledge of the system? (not just code, but stories, tests, build/config data, CI reports, backlog, retrospective lessons).What makes it easy/hard for these and other tools like any of the following to do this, or to be simple “skins” or plug-ins on top of only a handful of tools instead of a whole kitchen sink full of separate tools and repositories.
- Eclipse, Confluence, Twiki?
- FIT, Fitnesse, Contour
- Doxygen / Javadoc
- Trac / Agile-Trac?
- Jira / Remedy
Learning outcomes
- Thinking about Agile development as knowledge management & creation
- Current barriers to using agile techniques and supporting tools for non-code artifacts
- What do refactoring, TDD, continuous integration, etc. mean for non-code artifacts (and why you should care)
- Use of wikis for organizing, structuring and refactoring ALL system knowledge
- Why manual traceability is unnecessary (and even comes for free) when using such an approach
Primary target persona
- Tomas Tool-smith/Tool-vendor
Other target personas
(download PDF here)
2 comments:
It appears on the surface that you're not making a distinction between knowledge and the artifacts of knowledge, or the encoding of knowledge, which isn't knowledge itself until it's held in consciousness.
I can refactor knowledge often quite easily by just changing my mind.
Hi Scott! I'm basically using Phil Armour's definition of software as a *medium* for storing executable knowledge.
So yes - I am referring to storage & media of knowledge at various stages throughout development. I typically use what I call the '3-Cs': container, content, context.
In order for those contents to be transcribed into their container and context, they must necessarily have first been held in consciousness (so that criteria was met long before they were transcribed). At issue is not whether or not they've been held into consciousness, but how effectively the knowledge is transferred/consumed and subsequently applied.
Technically , you are right that these are forms of knowledge "capture". I actually do make the distinction, I just eventually drop the extra verbal baggage after a while once Ive defined my terms & context (as I do in the slides).
(Sort of like how "iteration" in an agile context typically implies a fixed-length, time-boxed iteration :-)
Post a Comment