I have a meeting tomorrow
morning that is scheduled to go to noon, so I suggest we have
an abbreviated meeting from noon to 1300. Does this work for
people?
Please review the minutes
from 6 Dec 2017 because I seem to recall some of us were
supposed to augment what Rex captured. I sent in some edits.
Check if you want to make some contributions.
Finally, some thoughts to
consider. I
submit the following as a thought piece on something I’ve been
kicking around. It may have value or be a rathole. I’ll
leave that up to you to decide.
There are a couple weak
spots that always show up in discussions of Agile, mostly
brought up by people with Waterfall experience who are not
convinced Agile should take over the world. The issues are
really carryovers where the Agile approaches don’t adequately
address a known Waterfall need. The areas of interest here
are requirements at the front end and documentation as we
approach the back end.
From a Waterfall
perspective, requirements are the starting point of what the
system needs to accomplish. Traditional problems are (1) how
well do we know at the start what the system is supposed to
do, (2) do we really know the system in the detail to which
the requirements (we believe) need to be specified, and (3)
how likely are we to keep the official requirements up to date
as we learn more about the system and how our vision of the
system really meets the user needs.
For our second issue, in
Waterfall, documentation is often done at the project end when
staff is exhausted and lack patience. Depending on how the
project went, there may not be adequate resources left to
create quality documentation. If documentation is to be
delivered throughout the project, then we run into the same
problem as with requirements where we need attention and
resources for updates to capture changes or learning along the
way. The Agile emphasis on avoiding documentation that will
never be updated and never be read is often interpreted as an
excuse to avoid documentation altogether rather than improving
the documentation as a whole (where sometimes less is an
improvement).
Agile and devOps
approaches emphasize “continuous”, whether that be continuous
testing, continuous integration, or continuous … DevOps also
emphasizes automation to consistently and efficiently perform
the enabling processes. We can look at “Continuous
Requirements” as the collection of user
stories/features/epics, but there are numerous complaints that
user stories can become a collection of special cases, missing
the common thread that would be revealed through the
traditional requirements analysis. Agile development counts
on refactoring as a way to address this, but refactoring can
be time consuming and still leaves us with how do we collect
the stories (and eventually the refactored versions) in a
useful way that provides an informative whole? The real
problem is these tasks still tend to be manual, essentially
not continuous, and sometimes just not done.
What fundamental artifacts
and enablers do we have to consistently address these issues?
My thought is this should be approachable as part of
Continuous Testing. The capability delivered by a feature is
not really the user stories ticked off the backlog but what
has been tested and proven to work. The requirements
satisfied are the collection of what tests prove the system
can do and why we want the system to do the tested things and
not a list of nice to haves. Can we aggregate information
that defines our tests to assemble our documentation? To what
extent can this be automated? Can we create the idea of
Continuous Documentation?
Have you seen this done
(attempted) before? What do we know about doing something
like this and what do we need to find out? How many of you
have been involved with Continuous Testing? How were tests
specified? How were tests documented? How were the tests
configuration controlled? What do we do to spit out
microservices and containers at the output end?
In summary, think of
Continuous Requirements as the capture of our evolving
thinking of what user stories/features/epics we implement and
what is the rationale for our capability decisions? Think of
Continuous Documentation as the capture of what the system can
actually accomplish. Can we do this better than we typically
do?
Ken
------------------------------------------------------------------------------
Dr. Kenneth
Laskey
MITRE
Corporation, M/S H330
phone: 703-983-7934
7515
Colshire Drive fax: 703-983-7996
McLean VA
22102-7508