[almighty] Idea: modelling iterations

[Michael Kleinhenz]

I think iterations as a data model are more of an intrinsic concept as
well, BUT I am not sure that this holds true with operations and/or
associations on iterations. For example: there may be complex metadata
associated with iterations or iterations may be more that 1:n
associations to WIs. This may impose complex operations on iterations
(think filter/search/associate). To model iterations seperately from
the WIT/WI model may impose doing very similar things twice. Do we
need that stuff? I don't know, but I from the PDD, I think the generic
goal is to be open to any PM concept possible, even ones that we don't
know about yet.

What we have to do here is to balance the "genericness" of the model:
be as specific as necessary to keep the complexity low while be as
generic as possible to keep the usecases as open as possible. That is
the challenge.

Considering that, I see massive advantages in modelling iterations as
WITs, but I think that total "generic" approach will impose a lot of
complexity when working with iterations (like, deleting them possibly
will require complex graph traversing). So I would go for a "glorified
Todd approach" like Max sketched: a sperate hierarchical,
metatdata-containing tag-like system. In my opinion that balances the
complexity against openess pretty well.




On Mon, Sep 26, 2016 at 3:50 PM, Todd Mancini <tmancini at redhat.com> wrote:
>
> IMHO, iterations are 'intrinsic'. Moreover, when I think of the kinds of
> operations that happen with iterations, those operations 'feel different'
> than typical WI operations. For example:
>
> 1. I create a new 'user story' WI. It has no iteration.
> 2. A product owner 'approves'' the WI. Perhaps at this point in time,
> assigns it to a release (where Release == parent iteration in a hierarchy of
> iterations.)
>
> E.g.
> Release 23
>    Sprint 165
>    Sprint 166
>    Sprint 167
>    Sprint 168
> Release 24
>    Sprint 169
>    Sprint 170
>    ...
>
> 3. During sprint planning, WI gets pulled into a sprint (Say 166). Iteration
> has changed again.
> 4. User story is NOT accepted at end of sprint, and, due to a new stack
> ranking, is no longer considered for the release. Iteration is removed from
> the WI.
>
> All the while, many of those operations above will be done in a very fluid
> way -- e.g., using a touch screen, the user story is dragged onto and off of
> the various sprints.
>
> As such, to me , that feels like an intrinsic operation on the user story
> itself, and not some overly engineered technique to express iterations as
> WI.
>
> The agilista in me says "do it the simplest way possible to make it work.
> Demo that. If future features require your initial implementation to change,
> refactor." As such, my gut says: iterations are just a field on a WI
> (probably all WIs, in fact). The data type of the field is 'iteration', it's
> hierarchical in nature, and the permissible values are both end-user
> definable and unique for every project.
>
> On Mon, Sep 26, 2016 at 6:31 AM, Max Rydahl Andersen <manderse at redhat.com>
> wrote:
>>
>> On 26 Sep 2016, at 11:53, Thomas Mäder wrote:
>>
>>> On 09/26/2016 11:07 AM, Max Rydahl Andersen wrote:
>>>>
>>>> Yes, they could eventually grow into be generically defined but I think
>>>> to start with we could start very basic - I for one do not think they should
>>>> be munged into being work item/work item types at our API level. Not
>>>> everything is a java.lang.Object either ;)
>>>
>>> Actually, you're making my point: everything IS an instance of
>>> java.lang.Object. so you can write
>>>
>>> Object foo= new Iteration();
>>> foo.hashCode();
>>
>>
>> integers are not objects - they can be auto-casted in later versions.
>>
>> :)
>>
>> /max
>> http://about.me/maxandersen
>>
>>
>> _______________________________________________
>> almighty-public mailing list
>> almighty-public at redhat.com
>> https://www.redhat.com/mailman/listinfo/almighty-public
>
>



-- 
Michael Kleinhenz
Principal Software Engineer

Red Hat Deutschland GmbH
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany

RED HAT | TRIED. TESTED. TRUSTED.
Red Hat GmbH, www.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht München,
HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
Michael O'Neill