Re: More Project Structure in JIRA

[Bernd Mathiske <be...@mesosphere.io>]

All,

thanks for upvoting this. AFAICT, we have consensus to go ahead. Let’s do this from now on!

Bernd

> On Oct 28, 2015, at 2:52 AM, Klaus Ma <kl...@gmail.com> wrote:
> 
> +1
> 
> On Sun, Oct 25, 2015 at 11:57 PM, Shuai Lin <li...@gmail.com> wrote:
> 
>> +1
>> 
>> On Wed, Oct 21, 2015 at 12:55 AM, Greg Mann <gr...@mesosphere.io> wrote:
>> 
>>> +1
>>> 
>>> On Tue, Oct 20, 2015 at 9:50 AM, tommy xiao <xi...@gmail.com> wrote:
>>> 
>>>> +1 Yes please!
>>>> 
>>>> 2015-10-19 16:09 GMT+08:00 Alexander Rojas <al...@mesosphere.io>:
>>>> 
>>>>> +1 Yes please!
>>>>> 
>>>>>> On 15 Oct 2015, at 10:11, Bernd Mathiske <be...@mesosphere.io>
>>> wrote:
>>>>>> 
>>>>>> Proposal: in extension of today’s limited two-level (epic, task)
>>>>> approach, make full use of expressive power already available in JIRA
>>> to
>>>>> provide more structure for larger projects to facilitate planning,
>>>>> tracking, and reporting. This will facilitate dynamically planning of
>>>>> sub-projects, which will make us more agile.
>>>>>> 
>>>>>> The general idea is to use links between epics to provide a
>> recursive
>>>>> hierarchical structure, with which one can span trees or DAGs of
>>>>> arbitrarily large projects. This does not mean that we want to plan
>>>>> everything in minute detail before starting to work. On the contrary.
>>>>>> 
>>>>>> You can start anywhere in the eventual tree and express part of the
>>>>> overall effort, maybe say a short epic with a few task tickets. Then
>>> you
>>>>> can LATER make this epic a dependency for a larger effort.
>>>>>> 
>>>>>> Conversely, you can subdivide a task in the epic into subtasks.
>>>> However,
>>>>> this does not mean that you have to literally use the feature
>> “subtask”
>>>> in
>>>>> JIRA for this. Instead, staying recursive in our JIRA grammar, so to
>>>> speak,
>>>>> convert the task to an epic and then create ordinary tasks in it to
>>>>> represent subtasks.
>>>>>> 
>>>>>> Now the task cannot be a task in its parent epic anymore. We fix
>> this
>>>> by
>>>>> putting in a link of type "blocks" to the parent. When you then look
>> at
>>>> the
>>>>> parent, it still holds a number of tasks, and it has one dependency
>> on
>>> an
>>>>> epic (to which you can add more).
>>>>>> 
>>>>>> Thus our dependency tree can grow in all directions. You can also
>>>>> rearrange and update it in any shape or form if necessary.
>>>>>> 
>>>>>> Overall, we only use two JIRA elements: epics and tasks (of
>> different
>>>>> flavors such as bugs, improvements, etc.). Tasks are the leaves,
>>>> everything
>>>>> else is an epic. Review requests only ever happen for tasks.
>>>>>> 
>>>>>> The epics are there to provide a high level view and to allow
>> dynamic
>>>>> (“more agilish”, non-waterfall) planning. Granted, you’d also use a
>>> tree
>>>> if
>>>>> you did waterfall. The difference is that you’d spec it all out at
>>> once.
>>>> My
>>>>> observation is that not too few of us do exactly this - outside JIRA
>> -
>>>> and
>>>>> then try to remember what tickets are where in their tree. Let’s make
>>>> this
>>>>> part of JIRA!
>>>>>> 
>>>>>> Why not use labels? Because they are in a flat name space and we
>> want
>>>> to
>>>>> represent tree structure. How would you know that a label denotes a
>>>>> subproject of another label? By memorizing or by depicting a tree
>>> outside
>>>>> JIRA. Why not use components? Same problem as with labels: flat name
>>>> space.
>>>>> We can use labels and components these for many other purposes.
>>> Separate
>>>>> discussion.
>>>>>> 
>>>>>> Aren’t we doing this already? Probably. I have not checked
>>> thoroughly.
>>>>> There may occasionally be epics that link to other epics. If so, I
>>> would
>>>>> merely like to encourage us to use this powerful expressive means
>> more
>>>>> often.
>>>>>> 
>>>>>> Bernd
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Deshi Xiao
>>>> Twitter: xds2000
>>>> E-mail: xiaods(AT)gmail.com
>>>> 
>>> 
>> 
> 
> 
> 
> --
> Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer
> Platform Symphony/DCOS Development & Support, STG, IBM GCG
> +86-10-8245 4084 | klaus1982.cn@gmail.com | http://k82.me

Re: More Project Structure in JIRA

[Adam Avilla <ad...@avil.la>]

This is great! I am not one of the devs, but the more transparency and ease
of use there is in our tools, the easier it is to focus on the actual work,
and not the process. I really like Martin Fowler's quote from
http://martinfowler.com/articles/newMethodology.html:

"Agile methods are people-oriented rather than process-oriented. The goal
of engineering methods is to define a process that will work well whoever
happens to be using it. Agile methods assert that no process will ever make
up the skill of the development team, so the role of a process is to
support the development team in their work."

On Mon, Nov 9, 2015 at 4:51 AM, Bernd Mathiske <be...@mesosphere.io> wrote:

> All,
>
> thanks for upvoting this. AFAICT, we have consensus to go ahead. Let’s do
> this from now on!
>
> Bernd
>
> > On Oct 28, 2015, at 2:52 AM, Klaus Ma <kl...@gmail.com> wrote:
> >
> > +1
> >
> > On Sun, Oct 25, 2015 at 11:57 PM, Shuai Lin <li...@gmail.com>
> wrote:
> >
> >> +1
> >>
> >> On Wed, Oct 21, 2015 at 12:55 AM, Greg Mann <gr...@mesosphere.io> wrote:
> >>
> >>> +1
> >>>
> >>> On Tue, Oct 20, 2015 at 9:50 AM, tommy xiao <xi...@gmail.com> wrote:
> >>>
> >>>> +1 Yes please!
> >>>>
> >>>> 2015-10-19 16:09 GMT+08:00 Alexander Rojas <al...@mesosphere.io>:
> >>>>
> >>>>> +1 Yes please!
> >>>>>
> >>>>>> On 15 Oct 2015, at 10:11, Bernd Mathiske <be...@mesosphere.io>
> >>> wrote:
> >>>>>>
> >>>>>> Proposal: in extension of today’s limited two-level (epic, task)
> >>>>> approach, make full use of expressive power already available in JIRA
> >>> to
> >>>>> provide more structure for larger projects to facilitate planning,
> >>>>> tracking, and reporting. This will facilitate dynamically planning of
> >>>>> sub-projects, which will make us more agile.
> >>>>>>
> >>>>>> The general idea is to use links between epics to provide a
> >> recursive
> >>>>> hierarchical structure, with which one can span trees or DAGs of
> >>>>> arbitrarily large projects. This does not mean that we want to plan
> >>>>> everything in minute detail before starting to work. On the contrary.
> >>>>>>
> >>>>>> You can start anywhere in the eventual tree and express part of the
> >>>>> overall effort, maybe say a short epic with a few task tickets. Then
> >>> you
> >>>>> can LATER make this epic a dependency for a larger effort.
> >>>>>>
> >>>>>> Conversely, you can subdivide a task in the epic into subtasks.
> >>>> However,
> >>>>> this does not mean that you have to literally use the feature
> >> “subtask”
> >>>> in
> >>>>> JIRA for this. Instead, staying recursive in our JIRA grammar, so to
> >>>> speak,
> >>>>> convert the task to an epic and then create ordinary tasks in it to
> >>>>> represent subtasks.
> >>>>>>
> >>>>>> Now the task cannot be a task in its parent epic anymore. We fix
> >> this
> >>>> by
> >>>>> putting in a link of type "blocks" to the parent. When you then look
> >> at
> >>>> the
> >>>>> parent, it still holds a number of tasks, and it has one dependency
> >> on
> >>> an
> >>>>> epic (to which you can add more).
> >>>>>>
> >>>>>> Thus our dependency tree can grow in all directions. You can also
> >>>>> rearrange and update it in any shape or form if necessary.
> >>>>>>
> >>>>>> Overall, we only use two JIRA elements: epics and tasks (of
> >> different
> >>>>> flavors such as bugs, improvements, etc.). Tasks are the leaves,
> >>>> everything
> >>>>> else is an epic. Review requests only ever happen for tasks.
> >>>>>>
> >>>>>> The epics are there to provide a high level view and to allow
> >> dynamic
> >>>>> (“more agilish”, non-waterfall) planning. Granted, you’d also use a
> >>> tree
> >>>> if
> >>>>> you did waterfall. The difference is that you’d spec it all out at
> >>> once.
> >>>> My
> >>>>> observation is that not too few of us do exactly this - outside JIRA
> >> -
> >>>> and
> >>>>> then try to remember what tickets are where in their tree. Let’s make
> >>>> this
> >>>>> part of JIRA!
> >>>>>>
> >>>>>> Why not use labels? Because they are in a flat name space and we
> >> want
> >>>> to
> >>>>> represent tree structure. How would you know that a label denotes a
> >>>>> subproject of another label? By memorizing or by depicting a tree
> >>> outside
> >>>>> JIRA. Why not use components? Same problem as with labels: flat name
> >>>> space.
> >>>>> We can use labels and components these for many other purposes.
> >>> Separate
> >>>>> discussion.
> >>>>>>
> >>>>>> Aren’t we doing this already? Probably. I have not checked
> >>> thoroughly.
> >>>>> There may occasionally be epics that link to other epics. If so, I
> >>> would
> >>>>> merely like to encourage us to use this powerful expressive means
> >> more
> >>>>> often.
> >>>>>>
> >>>>>> Bernd
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Deshi Xiao
> >>>> Twitter: xds2000
> >>>> E-mail: xiaods(AT)gmail.com
> >>>>
> >>>
> >>
> >
> >
> >
> > --
> > Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer
> > Platform Symphony/DCOS Development & Support, STG, IBM GCG
> > +86-10-8245 4084 | klaus1982.cn@gmail.com | http://k82.me
>
>


-- 
/adam