WANTED: Seeking Single Agile Knowledge Development Tool-set

Chicago, USA
August 24-28, 2009
WANTED: Seeking Single Agile
Knowledge Development Tool-set
by Brad Appleton

Chicago, USA
August 24-28, 2009
WANTED: Desperately Seeking Single Agile
Knowledge Development Tool-setBrad Appleton 2
Presenter Information
Brad Appleton
 22 years in industry – last 15 w/large Telecom.
 Leading software development, CM & ALM solution
architecture
 Leading adoption & scaling of Agile development for
large organization since 2000.
 Co-author: Software Configuration Management
Patterns (Addison-Wesley 2002), Agile CM Environments
(column in CM Journal), Reviewer for The Agile Journal

Chicago, USA
August 24-28, 2009
What to expect in this talk?
More questions & challenges than answers
 I don’t have all the answers here!
 Just a perspective to share about “knowledge creation”
for software development and supporting tools
 Lots of “what if” and “why can’t I” questions
 Borne out of a lot of experience in software development
for projects of ALL shapes and sizes and …
 Extensive experience/practice in CM & ALM processes,
tools and their patterns of usage & design
Discussion/brainstorming of possible solutions
 Especially from tool vendors/developers

Chicago, USA
August 24-28, 2009
Making Software == Creating Knowledge
“The hard part about creating software systems is
not creating them, it is in acquiring the knowledge
necessary to create them (correctly).
Therefore:
 Software is not a product, it is a medium for storing
executable knowledge!
 We do not ‘build systems’—we acquire knowledge.
 The systems we ship to our customers are actually the
byproducts of the real activity, which is to learn
 The real product is the knowledge that is in the systems we
ship to the customer.”
— Phil Armour, Software is NOT a Product (CACM, August 2000)

Chicago, USA
August 24-28, 2009
Implications
The previous assertion implies that …
 All artifacts (specs, designs/models, code, tests) are
simply snapshots of our efforts to transcribe our
understanding of the system and of its development.
 Each type of “artifact” is just a different form of
knowledge in a different format and level-of-detail.
 Each artifact update/change embodies some new
discovery, learned via some interaction.
 Software CM/ALM is therefore:
• the medium in which inter-related knowledge artifacts are
stored & maintained, and …
• the environment through which development changes and
collaborative learning must ultimately flow

Chicago, USA
August 24-28, 2009
Knowledge Work / Activities
Types of Knowledge Work (All focused on meeting
needs, solving problems and managing knowledge)
 Software, Process and/Documentation (form of knowledge)
 Development, Enhancement, Repair (points in the lifecycle)
 Engineering, Problem Solving, Scientific Method
(approaches to the work)
Types of Knowledge Activities
 Project Planning & Tracking
 Requirements Development & Analysis
 Design, Modeling & Implementation
 Verification & Validation
 Issue Management

Chicago, USA
August 24-28, 2009
Knowledge Representation
• Types of Knowledge Representation
 Traditional Code
 Traditional Documents (Specs)
 Formal Models
 Test Cases
 Change Requests (backlog-items and/or defect reports)
 Hybrids (e.g. HTML, wiki pages, Mashups, Dashboards, Portals, ....)
 Other usable types/formats:
• Build scripts & configuration info
• Build/test result reports
• Version control history/comments
• Online help & other supporting docs

Chicago, USA
August 24-28, 2009
Agile Knowledge Development?
Shouldn’t Agile values, principles and techniques
apply to ALL the various forms and formats of
knowledge that the project must create &
deliver? (not just code)
 Eliminating duplication and maximizing simplicity,
habitability & navigability applies to the organization of
non-code artifacts too
 Writing “tests” that define what “done” means for non-
code artifacts
 Continuously integrating (& validating) ALL types of
knowledge artifacts (not just code)

Chicago, USA
August 24-28, 2009
Refactoring for non-code artifacts?
Think of Refactoring as …
• a process of simplifying and consolidating the collection
of knowledge and thoughts that we have attempted to
transfer into written specs/models/code making many
small, successive revisions focused on:
 Preserving correctness (cf. "passes all the tests")
 Removing redundancy (cf. "contains no duplication")
 Revealing thoughts and intentions (cf. "expressly reveals all
our thoughts/intentions about the program")
 And improving clarity and conciseness (cf. "minimizes the
number/size of classes & methods")

Chicago, USA
August 24-28, 2009
Sound crazy? Think again!
Stated this way, refactoring EASILY applies to knowledge
that is transcribed and structured in the form of:
 Requirements / Stories
 Written Tests
 Backlog items / requests
 Wiki-pages?
Corresponding refactorings/patterns of clear & simple prose
have existed for centuries!
 Don’t believe me? Look no further than books like Style: 10 Lessons
in Clarity & Grace (by Joseph Williams) or The Art of Styling
Sentences: 20 Patterns for Success
 So, these basic rules of structure & simplicity are about organizing
many forms of knowledge (not just code)

Chicago, USA
August 24-28, 2009
What about tests/integration?
A "test" is a way of capturing (and then validating) what it
means to be "done" for a particular "chunk" of the
document.
Ways that we do this ...
 Structural patterns: templates, outlines, checklists
 Content/message "tests": I am done with this section when the
reader understand how/that/when ...(key take-aways)
 Spelling and grammar checks are like "compilation" and/or checking
for "smells"
 Cross-reference (links) building & checking
 Suggesting corrections, or alternative (shorter) phrases are kind of
like suggesting refactoring
 Web 2.0 and XML give us things like semantic web and ontologies
whose structure can be automatically executed.

Chicago, USA
August 24-28, 2009
Agile Doc Development?
Agile development of a document would be kind of like
outline format…
 Initial, hi-level outline is like the backlog.
 The user stories are the "key take-aways" you want the target
audience to retain
 The initial topics in the outline get prioritized, and …
 The hi-er priority topics get elaborated first, iterating in
recursive/hierarchical fashion.
 Each time I elaborate more detail, I refactor the overall
structure.
 My backlog grows into a hierarchically structured outline.
 Unit-Tests are like the "tests" for a given (sub)section whereas
"feature tests" are whether or not the "key take-away" or
"learning objective" has been realized.

Chicago, USA
August 24-28, 2009
Traceability?
• Testing == Traceability (Agile Style)
• Some tests we may write manually can't be easily
executed, so we instead do things like
 "cannibalize" them. The original "test" doesn't stay in its original
form, it simply "evolves" into the text that satisfies the test
 when developing training materials, we may have to write outlines,
highlights/summaries, learning objectives. These form the "tests"
 Sometimes we write software documentation and the examples in
the text define test-cases whose expected inputs/outputs are written
in the text and must be verified via execution
• (in fact some people try to make their "tests" serve double-duty as
sample input/output in user-guides)
 Cross-references and Wiki-like links are really just forms of
traceability

Chicago, USA
August 24-28, 2009
Why Can’t We Do This Easily?
Why can’t we use the same basic tools (or
something darn close to it!)
 Why can’t I have an Eclipse-like IDE for viewing and editing the
structure of a document (or requirements or backlog-items)
• E.g. as multiple pages in a wiki
 Why can’t I easily to labeling/tagging or “task-based commit” of
multiple wiki-pages at a time? (or even branching?)
 Why can’t I easily browse/refactor and navigating ALL the
knowledge of the system? (not just code, but stories, tests,
build/config data, CI reports, backlog, retrospective lessons)?

Chicago, USA
August 24-28, 2009
What Tools CAN Do This?
• The following can do parts of it:
 Eclipse, Confluence, Twiki, Mashups
 FIT, Fitnesse, Contour
 Doxygen / Javadoc
 Trac / Agile-Trac?
 Jira / Remedy
 Jazz?
 zAgile wikidsmart
 Web 2.0 technologies like XML schema & ontologies
• Note the lack of basic version-control functionality (of
groups of elements – not just single items) in most of the
above – why is that?

Chicago, USA
August 24-28, 2009
Is there a better way?
How to get the best of version control, Wiki/CMS and
issue/item management all together without too much
duplication/overlap and complexity?
 zAgile comes close with wikidsmart that works on top of Jira and
Confluence
 But missing version control capabilities like Subversion or Accurev
 Capable of integrating with Eclipse
 What about extending (Mash-Ups?) to use (or at least appear to use)
a single repository for all a project’s knowledge?
 How many tools does it have to be?
 If doneright, traceability comes practically for free with wiki
hyperlinks, automated event logging, and ubiquitous language with
Google-like Search!

Chicago, USA
August 24-28, 2009
Let’s Brainstorm & Discuss!
How would you do it?
What would you recommend?

Chicago, USA
August 24-28, 2009
Conclusions?
• How did we do?

Chicago, USA
August 24-28, 2009
Thank You!
Mahalo
XiexieYumboticSalamat
Arigato

WANTED: Seeking Single Agile Knowledge Development Tool-set

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to WANTED: Seeking Single Agile Knowledge Development Tool-set (20)

Recently uploaded (20)

WANTED: Seeking Single Agile Knowledge Development Tool-set