Ian,
Thanks for the info - I actually watched the entire thing - Good job on sorting out the real-life "mess" :-) You have obvioulsy put a lot of thought into "what is a project".
I agree with the mindset with which you approached the problem, especially the notion of making the system reflect the way we think. FWIW, we actually have a somewhat similar environment, FW, and other components all coming together (sort of) to form releases.
One of the challenges is that the company/product structure itself is not always consistent, and may not be tomorrow what it is today. One release might have a subset of components and one might have other ones altogether - typically they are similar but it could happen. Additionally, one might be, as in a library, shared across products, but at the same time have customizations for each. The library is released prior to the other releases, and they base their work on that. [[ On a side note, For this reason I shy away from configuring tools in a way that reflects the product too tightly. its simply too heavy of a load to carry. Instead, I try and make everything flat. Anything is an attribute (as in field), including the project. In many cases, it simply removes any "clerical" or administrative tangibles from managing the tool. Of course, YMMV depending on the tool. Also, some exceptions may apply :-) ]]
In the solution you presented, it seems like each discipline (FW/ SW, etc) had their own project in Jira.
If I take this approach I am concerned that, since they all work towards common goal, there are many things that need to be duplicated between the different Jira projects, such as components, flow related items, and so forth (actually I am still working to figure out what 'so forth ' is in this context). Also, when users submit bugs, they don't always know where it goes at first, cuasing a need for some sort of common "front door". Additionally, maintaining the queries, such as the 'mother query' in your presentation appears to require a lot of housekeeping making sure things are inline between projects and a fairly high level of weightlifting involved to kick off a project. Furthermore, I foresee people standing in line to have their own Jira-project created, just so that they can have their own playground, yet another project to maintain and keep in line with the others. Would a single project not solve all of that? I mean I know that it will have advantages, but what are the specific problems and limitations I will face if I do that? Where am I shooting myself in the foot?
Thanks again,
Mike
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.