mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Klaus Ma <klaus1982...@gmail.com>
Subject Re: More Project Structure in JIRA
Date Wed, 28 Oct 2015 01:52:06 GMT
+1

On Sun, Oct 25, 2015 at 11:57 PM, Shuai Lin <linshuai2012@gmail.com> wrote:

> +1
>
> On Wed, Oct 21, 2015 at 12:55 AM, Greg Mann <greg@mesosphere.io> wrote:
>
> > +1
> >
> > On Tue, Oct 20, 2015 at 9:50 AM, tommy xiao <xiaods@gmail.com> wrote:
> >
> > > +1 Yes please!
> > >
> > > 2015-10-19 16:09 GMT+08:00 Alexander Rojas <alexander@mesosphere.io>:
> > >
> > > > +1 Yes please!
> > > >
> > > > > On 15 Oct 2015, at 10:11, Bernd Mathiske <bernd@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message