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 <[email protected]> wrote: > > +1 > > On Sun, Oct 25, 2015 at 11:57 PM, Shuai Lin <[email protected]> wrote: > >> +1 >> >> On Wed, Oct 21, 2015 at 12:55 AM, Greg Mann <[email protected]> wrote: >> >>> +1 >>> >>> On Tue, Oct 20, 2015 at 9:50 AM, tommy xiao <[email protected]> wrote: >>> >>>> +1 Yes please! >>>> >>>> 2015-10-19 16:09 GMT+08:00 Alexander Rojas <[email protected]>: >>>> >>>>> +1 Yes please! >>>>> >>>>>> On 15 Oct 2015, at 10:11, Bernd Mathiske <[email protected]> >>> 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 | [email protected] | http://k82.me
signature.asc
Description: Message signed with OpenPGP using GPGMail
