WANTED: Seeking Single Agile Knowledge Development Tool-set

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.

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)

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.

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.

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 :-)