I am attempting to move to JIRA from a simple task list that we have out grown.
- We are an internal software house developing for the .net, ios and android platforms
- We have a single .net solution that contains a Web API, 11 Web applications, a console app and a BLL and DAL projects. All Web Apps and Web API share the BLL and DAL.
- We have 2 ios projects and 3 android projects which use the Web API
- Small team of devs that work across all the projects in their respective platforms. There is no management layer over this we are autonomous.
Current Project Structure is:
- Tasks stored in Mantis Bug Tracker
- Use Categories to divide up projects
- Tasks are allocated to developers, based on their workload.
- Tasks are worked on and checked into Environment branches of a SVN repository
Current Problems I am hoping to resolve
- It is hard to get visibility of what issues were fixed in which resleases
- A feature may span the web API, 1 or more of the web apps and one for more of the mobile apps. I currently have no systematic way of knowing that all the tasks are complete across all these projects to allow the feature to be moved into production. At the moment it is done via simple conversations and naming conventions in the task titles.
- No real way of saying 70% of feature x is completed
- There is no simple way to tell what code was changed to fix a particular issue which makes tracking down bugs tougher then it should be.
Proposed New Structure
Based on my reading of documentation and a brief play with a ondemand JIRA instance I have come up with the following structure and want to get a second opion on it:
- One generic Project to Hold Epics so that stories can span multi projects. Would also allow for an associate Confluence page to store the specifications for features that span multiple projects.
- A separate project for each of the .net web Applications
- A separate project for the Mobile application <= debating here if both the ios and android apps sit within this one project or to split them to separate ones. If I used one project was going to have the different platforms setup as components. Thoughts???
- I would track the versions which would be the releases at the project level, which I believe is the only way to track versions. Can you tie versions across projects?
- Bug fixes that come in would be alloacted to a particular version withing the project they affect. <= What if the bug affects multi-projects, eg a ios mobile app needs to change along with the Web API for the same bug.
- Moving code control over to BitBucket ondemand to allow for the JIRA task integration.
- If I have a bug that affects multiple projects what is the best way to try and tie the individual project tasks together?
- What about components, could you consider each web app as a component or many be just the BLL and DAL so that you see see what projects are affecting the BLL and DAL.
- If your in Melbourne, happy to buy a few beers to help the disucssion along.
Thanks in advance for anyone that responds.
The answer depends heavily on how many people are on your team. Reading your description somehow implies to me that you may have many web apps / components, but that in a sense there are less developers than components. People shift around between the different components all the time and to some degree everyone is allowed to work on every component.
If that's the correct description of your team, I suggest to only have a single project and use components to distinguish between the web apps / components. Unless you have at least 15 developers, I would also question the use of epics. It might be enough to just have stories and create sub-tasks for each component which needs to be touched.
I'm proposing this to minimize the administration overhead. Unless you have someone working fulltime on product management, it would be almost impossible for every developer to know what's hanging around in the various projects. Also, as a rule of thumb, always start with the simplest structure possible. You can still make it more complicated later.
Do you release components on their own? Otherwise, it is probably the best to release everything together and have a single version for all of them. Or maybe you use the Sprint as the version so that you release everything at the end of the sprint. If components have internal version numbers, you might also want to introduce a custom field to keep track of it.
We would release the various web apps at different times as they are not really connected other than sharing a BLL and DAL. Eg think of it as a consumer facing web app and a Business facing web app. We could do an update to functionality for the Business app without having to touch the consumer app.
I am assuming you could filter on custom fields for reporting?
A major factor in deciding to divide by Components or Projects is if the products release together or separately. If together then you have one set of version numbers and you use one project with several components. If the products release separately then you divide into separate projects.
In both cases, you can have the same people and the same boards for both projects. If it is possible to release one part of a large project before the other parts (and this is planned for) then you should use separate projects.
Hey Community mates! Claire here from the Software Product Marketing team. We all know software development changes rapidly, and it's often tough to keep up. But from our research, we've found the h...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs