All,
With the new release cadence, one of the things we were promised is more
streamlined multi-release use case & requirements management. There is a *LOT*
of overhead in introducing new requirements/use cases. It requires a
requirements & architecture presentations, and many web pages to document the
incremental work … we are moving from 27.5 week releases to now a 19 week
release cycle. Exacerbating the need for a “lighter” process. Furthermore, MOST
of our use cases & requirements are incremental work as ONAP matures; there are
not nearly as many completely new Use Cases now-a-days.
So maybe a compromise that achieves Dave’s objective of per-release
jira-tracking with more stream-lined multi-release U/C&R management is that in
each release we create a jira that documents that release’s deliveries, but we
only have the overall overhead for the U/C&R once when it “hops” onto its
initial release. We would still have the overhead of managing the jira for the
incremental work.
Best regards,
-Ben Cheung, PhD, DMTS, ALTA
ONAP Cloud RAN Architecture Systems Engineer
Mobile Networks, Nokia
Tel +1 (908) 679-6615
Email [email protected]<mailto:[email protected]>
600-700 Mountain Ave, Murray Hill, NJ 07974-0636 USA / #2C-378
From: [email protected] <[email protected]> On Behalf Of David
McBride via lists.onap.org
Sent: Wednesday, December 2, 2020 1:38 PM
To: Rajewski Łukasz - Hurt <[email protected]>
Cc: [email protected]; onap-release <[email protected]>;
[email protected]; Kenny Paul <[email protected]>
Subject: Re: [onap-requirements-sub] [onap-tsc] Continuing a REQ from one
release to the next #guilin #honolulu
Remember that scope affects planning and resource allocation for the release.
It also affects how the TSC evaluates milestone progress and GO/NOGO decisions.
For example, the component impact table documents what components will be
impacted by the defined scope of the requirement. If your scope includes work
that you won't do until subsequent releases, then the component impact table
may imply allocation of resources that isn't necessary.
Also, if your defined scope is broader than what you intend to complete in the
release, then it confuses TSC evaluation of your progress at milestones.
Perhaps a good compromise would be to include two parts in the requirement
description. The first part would document the overall scope of the
requirement, while the second part would document the scope that you intend to
complete for the current release.
David
On Wed, Dec 2, 2020 at 10:21 AM Rajewski Łukasz - Hurt
<[email protected]<mailto:[email protected]>> wrote:
So we mix here scope for release with the scope of the entire requirement what
is not the same. If the requirements can be defined for many releases the scope
for each release is a part of the entire one. Otherwise what we mean by
continuation of requirements by design? There is no such option then and you
consider only continuation for reqs that have some leftovers but the original
plan was to deliver them in one release.
So do we really let requirements to be split into many releases by design? I
have an impression that no because nobody plans non-intentional delays in the
implementation by design.
Regards,
[Logo Orange]
Łukasz Rajewski, R&D Expert
Orange Labs Poland, Advanced Network Solutions Agency
Mob.: +48 519 310 854
Orange Polska, Obrzeżna 7, 02-691 Warsaw
www.orange.pl<http://www.orange.pl/>
From: David McBride
<[email protected]<mailto:[email protected]>>
Sent: Wednesday, December 2, 2020 6:51 PM
To: Rajewski Łukasz - Hurt
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; onap-release
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>; Kenny
Paul <[email protected]<mailto:[email protected]>>
Subject: Re: [onap-requirements-sub] [onap-tsc] Continuing a REQ from one
release to the next #guilin #honolulu
I respectfully disagree.
It's fine to plan implementation of a requirement over multiple releases.
Nothing in this process contradicts that. However, the scope defined in the
Jira issue, should be the scope that you expect to complete for that release,
and not the entire requirement.
David
On Wed, Dec 2, 2020 at 9:45 AM Lukasz Rajewski via
lists.onap.org<http://lists.onap.org>
<[email protected]<mailto:[email protected]>>
wrote:
Hi,
one major remark. I believe this is wrong assumption that REQ by „design” must
be completed in one release. If feature is big and releases are more frequent
it is impossible to deliver bigger changes in one release. In consequence, such
feature by default must be split into several consecutive releases and setting
the scope status “reduced scope” is wrong.
Regards,
[Logo Orange]
Łukasz Rajewski, R&D Expert
Orange Labs Poland, Advanced Network Solutions Agency
Mob.: +48 519 310 854
Orange Polska, Obrzeżna 7, 02-691 Warsaw
www.orange.pl<http://www.orange.pl/>
From: [email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>> On Behalf Of David
McBride
Sent: Wednesday, December 2, 2020 5:58 PM
To: onap-release
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Cc: onap-tsc <[email protected]<mailto:[email protected]>>; Kenny
Paul <[email protected]<mailto:[email protected]>>
Subject: [onap-tsc] Continuing a REQ from one release to the next #guilin
#honolulu
Team,
I've gotten some questions about continuing a requirement from one release to
the next. So, for example, from Guilin to Honolulu.
In order to track history, we decided that it would be better to create a new
issue, rather than change the "fixversion" field on the original field. That
way, the history of the scorecards, tsc approvals, scope, etc. does not get
reset.
Process:
Current Issue:
1. Add a comment:
* What was completed
* What remains to be done
* Assert that the requirement will be continued in the next release
1. Change the "scope status" to "reduced scope"
2. Update the Jira status as "Done"
New Issue
1. Create a new issue with identical summary as the previous issue.
2. Set fixversion to the target release version (e.g., Honolulu Release).
3. In the "Issue Links" field, add a link to the previous issue.
4. Add a comment indicating that this issue is a continuation of a previous
issue (add Jira reference)
Please let me know if you have any questions.
David
--
David McBride
Release Manager
Linux Foundation Networking (LFN)
Mobile: +1.805.276.8018<tel:%2B1.805.276.8018>
Email: [email protected]<mailto:[email protected]>
IRC: dmcbride
--
David McBride
Release Manager
Linux Foundation Networking (LFN)
Mobile: +1.805.276.8018<tel:%2B1.805.276.8018>
Email: [email protected]<mailto:[email protected]>
IRC: dmcbride
--
David McBride
Release Manager
Linux Foundation Networking (LFN)
Mobile: +1.805.276.8018<tel:%2B1.805.276.8018>
Email: [email protected]<mailto:[email protected]>
IRC: dmcbride
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#7342): https://lists.onap.org/g/onap-tsc/message/7342
Mute This Topic: https://lists.onap.org/mt/78665769/21656
Mute #guilin:https://lists.onap.org/g/onap-tsc/mutehashtag/guilin
Mute #honolulu:https://lists.onap.org/g/onap-tsc/mutehashtag/honolulu
Group Owner: [email protected]
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
