[almighty] Idea: modelling iterations

Tue Sep 27 08:09:48 UTC 2016

On 26 Sep 2016, at 16:39, Michael Kleinhenz wrote:

> 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.

more metadata - sure, but that is not a big deal.
"more than 1:n associations" - not following ? care to elaborate ?

> 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.

I do not see that necessarily as a bad thing. I'm way more concerned if
we have to wait to have everything in place for the generic WIT model
to actually be able to make something happen.

> 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.

I think we really have to stop thinking the PDD or Almighty is going to 
try
solve *all* problems and all project models from day one. It won't.
And I will argue that trying to do so and be generic everywhere is going
to slow us down way too much.

We have to take a stance and be opinionated around what project models
concept we will include - and just the fact we are talking about 
iterations
as opposed to sprints, phases or similar we already generalised the 
concept.

Generalizing it even more I think we will be watering down our public 
api
and it becomes super hard to use.

> 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.

Yes, but I think with the suggested model that is what we do.

> 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.

+1 :)

What I like about it is that the first initial implementation of this 
could
simply be a text field and we can migrate to more structured as we move 
along.
/max

> 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

/max
http://about.me/maxandersen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160927/8846ab19/attachment.htm>