Hallo Sibylle,
thanks a lot for your proposal. As the process should be put to work as soon as possible I suggest to refine it due to the following aspects:
-
Introduction of a status chain for requirements to reflect decisions ans responsibilities with respect to requirements. This way a transparent
process could be carried out for the requirements, depending on the process (spontaneous contrib., planned project)
-
Description of the minimum things to define for each requirement (owner, stakeholders, etc.) -> requirement’s template
-
The term “user story” is very good, do you mean by that a certain set of use cases which have to relate more or less to the standard processes
defined and covered by the openMDM® concepts? It would be very helpful to structure requirements, concepts, components, use cases and last not least test cases by that.
With respect to the product manager my opinion is that this role is carried out
-
On the Tooulkit level by the steering committee
-
On component level by the Patron of the corresponding project
Both are necessary.
The steering committee has to take care of the requirements management service, which consolidates requirements in packages, which can be decided by
the steering committee. After assigning those packages to patrons/projects, the product ownership is represented by the patron until he delivers the result to the community.
The product of the community is the toolkit (which consists of components and concepts), the product of the projects are components and concepts. As
written in my former mails, the components can be composed to applications, the applications can be deployed in Systems.
Thanks a lot, best regards,
Sven.
Von: open-measured-data-wg-bounces@xxxxxxxxxxx [mailto:open-measured-data-wg-bounces@xxxxxxxxxxx]
Im Auftrag von Sibylle Peter
Gesendet: Freitag, 19. Dezember 2014 10:28
An: open-measured-data-wg@xxxxxxxxxxx
Betreff: [open-measured-data-wg] Summary of Requirements Management workshop from 8.12.2014
Hi all
before the holidays I at least want to send you some documentation info, attached to this email (unzip the zip file and click on the html file). I will also create an issue in bugzilla to implement a documentation repository, which the will host the the src
of this (and other documentation) and deploys it on the eclipse web site.
Short Summary:
Canoo provided a suggestion of a requirements management process. The suggestion builds on an iterative approach, because we experienced the best success in delivering software by delivering small pieces early and often.
A central point in the suggestion was the establishing of a so called product manager. This product manager should be independent, best somehow paid from the working group itself. This person would report to the Steering committee, and thus represent the Steering
committee and have the competence and power to make certain decisions (of course in accordance to the goals of the steering committee) to provide a fast feedback cycle.
However -this suggestion led to quite a long discussion of what this role should do:
A. Only collect, evaluate the requirements/requerst from the community and prepare them to bundles/packages, which can be ordered by a sponsor.
versus
B: doing A., but also accompanying the implementation of this packages to make sure that they are in accordance with the goals of the steering committee.
(more in the attached document - TODOS: I will provide adapted pictures after the holidays, which also visualize the different approaches regarding product management responsibilities and delivery blackboxes - til january 9th)
Another important question was raised - what exactly is product? What does the community expect? A mere set of building blocks which then have to be put together to a system on own efforts or a set of building blocks with an executable system which covers the
basic use cases (tbd).
IMO these questions should be discussed and clarified in the steering committee as this is essential.
Another discussion went around the tooling. Most of the service provider know and like JIRA and since JIRA provides a free license for open source projects, JIRA is a valid option against Bugzilla (which has a lot of shortcomings), provided it is hosted in
a way that the content is publicly available. Alexander Nehmer (S+C) will follow this, also with regard to the offer of being a pilot of Tuleap (early january)
That said, I wish all of you a merry christmas and a happy, successful and exciting 2015
Sibylle
---
Sibylle Peter
Head Customer Solutions
Canoo Engineering AG
Kirschgartenstrasse 5
4051 Basel
+41 61 228 94 41
+41 76 315 25 63
sibylle.peter@xxxxxxxxx
