| Michael,
Your experience shows much more discipline than what I have seen. Basically, even well-meaning dev teams, including architects, run out of steam before keeping requirements, architecture, and other items accurately and completely documented. My question is what can we automate so it is only the few that need to be done manually.
As far as when does Continuous start, I think the automated processes use their update processes as the bootstrap. Even if specialized Cycle 1 is necessary, I don’t think that invalidates Continuous after that.
Ken
------------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S H330 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-7996
McLean VA 22102-7508
Hi Gents,
I am unlucky - I can participate in the conf. call exactly in those days when the meeting is cancelled...
As of "Continuous”, I think that as many things in DevOps and even Agile, the subject is taken out of the context, which is a big problem. I also think that this is done almost deliberately because otherwise it would be necessary to consider the context changes and this would make a nice "theory" not that noce after all. Rex referred an article titled "The Death of Big Software" - well, this is an opinion of a digger, not of a skyscraper builder. We know that before CORBA and now SOA is everywhere in software, but they are renamed on the development desks (it is difficult to milk the same idea for a long time in spite of this is a fundamental idea). A Big Software remains though via different forms such as Dynamic and Agile Capabilities. In implementation od those capabilities, developers are moving more and more from development to assembly type of work. An assembly at the development level comparises of moini- and micro- thisngs, and developers continuously lose the perspective of reality.
So, it seems that “Continuous” misses the beginning - the initial state where “Continuous” starts. If this is correct, “Continuous” exists in isolation; we do not know kow the execution context impacts (if at all) the “Continuous”. Does it make sense to continue in such case?
A problem of Continuous Documentation can be solved via 2 means: 1) documentation of High- and Low-level architectural solutions/decisions, and 2) strong and strict architectural governance ove the implementation b DevOps. At the end of the day, if architects keep proper fine-grained level of Low-level architectural solutions/decisions and enforce this objectives/requirements over implementation, it is still possible to identify a point of failure (quite lcalised point) and replace the implementation without finding the implementation problem - like in old TVs we changes bulbs. Architect must document the designs anyway. Plus, they have time to update the documentation id some elements of the design should re-designed for implementation. DevOps/Agile teams should produce the documentation that whoiuld allow effective management and control of thier progress and delivery (nobody expects DevOps/Agile teams to understand and solve the big problems, they are not of their business - nothing has changed in here).
The same relate to Continuous Requirements. I do not believe that any business would risk its organisation by losing a view on what will be delivered/available when and where. This beaches a concept of Small Scope Continuous Requirements. In order to answer mentioned business questions, a lot of requirements, design and decisions have to be made long before the DevOps/Agile teams are even mentioned. This is the work of architects as well. I do recognise a Top-Down Continuous Requirements that could be enriched and refined based on the bottom-up requirements. Anyway, in Services, this is only one way to and in the market.
Regards,
- Michael
Hi Ken,
I do think that the “missing Continuous’s” (by whatever name … “missing Continui”? 😊 ) deserve attention. I think I’d encompass them in a notion of “Continuous Systems Engineering” that spanned the full INCOSE process and lifecycle model space:
<Mail Attachment.png>
Bob,
Catching up on my reading. I found the Continuous * focus of the scalare.org article to be consistent with much of the Agile-devOps paradigm, but what was missing was Continuous Requirements and Continuous Documentation. In a way, Continuous Planning might lead to Continuous but I don’t think the authors made that leap. Documentation wasn’t touched.
Do the missing Continuous’s deserve some attention (like as a MIP at MITRE)?
Ken
------------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S H330 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-7996
McLean VA 22102-7508
What you recommend below seems necessary to me; however, I recommend considering it in the context of Continuous Engineering, as that concept was originally (?) envisioned, dating back to at least 1999 (https://rd.springer.com/chapter/10.1007/978-3-540-49020-3_2) and more recently (2014) as in Continuous Software Engineering and Beyond: Trends and Challenges (https://scalare.org/wp-content/uploads/2015/06/rcose20141.pdf). More concerted adaptation of that thinking to the contemporary [and note the “temporary” part of that word!] Agile thrust would definitely benefit a lot of individuals and organizations.
(The Continuous Engineering term has been somewhat coopted and possibly distorted by its use in the IoT domain, especially as marketed by IBM. I’m not criticizing that initiative, but it’s something “smaller” than the original conceptualizations.)
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?
------------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S H330 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-7996
McLean VA 22102-7508
|