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)
I am sorry, I don’t understand - imo this is answered in the document. I am finishing the version with adopted pictures, may be it gets more clear then.
- Description of the minimum things to define for each requirement (owner, stakeholders, etc.) -> requirement’s template
Since the realisation of a requirement is practically a blackbox and conducted by a sponsor and a service provider, I don’t want to define a general valid requirement template. Which is in my opinion also not really possible and can create a lot of waste, if a lot of detail information is specified and the requirements never gets implemented.
I see two stages, for which we can define requirements for a requirement:
1) the requirement should describe the business value: It therefore should describe for which user (role, persona) which business benefits can be achieved by doing a specific thing. It should remain on the WHAT and not on the HOW. This description should be on a level that the requirements management service is able to package it together with other requirements and that the steering committee or possible sponsors can evaluate if it makes sense to do or not. It should also be possible for service provides to give a very rough estimate for such a requirement.
Depending on which terminlogy we choose it should contain
- the actors (persona)
- szenarios /use case (best described by example)
- some constraints (if already known)
I am currently in the process to refine this definition, but IMO it makes no sense to require more for the work group, as different sponsors/service providers have different ways to treat requirements. A very important consequence to this is that by creating a new Story, the reporter of this story must be willing to give further input for specifications etc, once a sponsor has adopted the requirement. It then is the sponsors (in the role of the product owner) responsibility to refine the requirements and add the detail specifications.
- 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.
The term user story mainly means:
- the requirement should be user centred
- it’s size is restricted to an index card to make clear that one need to communicate with each other in order to fully understand the requirements. That does not mean that at a given point some written specification is done, but not necesseraly at the very beginning of a requirements life.
- there are different forms to complement a user story, use cases is one form, scenarios and examples (which then can be used as test cases) are another. (see above).
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.
As I noted, this is your opinion. Our opinion remain, that at least in the starting period, a community product manager would be a big help to start the process, specially since there are so many dependencies on the different projects started by the community. And currently nobody is coordinating these efforts, mostly because it takes a lot of time. Once the ground is developed, I can fully see the charm of your suggestion.
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.
if the product of the community is the toolkit and concepts only - what about the demonstrator which is on the roadmap of the committee for this year? This is more an application than just components and concepts, right? Or did I understand something very wrong.
Thanks a lot, best regards,
Sven.
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
_______________________________________________
open-measured-data-wg mailing list
open-measured-data-wg@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/open-measured-data-wg
