8

In our company several teams will work on different components of several projects at the same time. For example, one team might make make specific kinds of software (or hardware) for some project(s), another team another specific kind of software. We use Jira projects to host issues for specific projects and Jira boards for sprints for different teams.

We face the issue of avoiding code duplication across projects, and have developed a set of core libraries which we use in those projects. While working on a project, some developer will realize that a piece of code they have written is of greater interest and should be extracted into a core library, or that some core code they are using has a bug, needs some more parametrization, or a new feature... you name it.

So they create a core library issue that goes into the core project's backlog. All these issues are reviewed, prioritized, and estimated in a core library meeting (once a week), and will be tackled according to their priority (alongside project-specific issues) in some future sprints.

Prioritization is done by sorting issues, and we put a sorted label on sorted issues (so we can search for non-sorted ones). Then we manually put one issue per core component to the top of the backlog in order for them to be tackled first. When some team puts such an issue into their sprint, they have to manually drag another item to the top of the backlog instead.

This is quite error-prone. Basically, what we have is the additional issue statuses "sorted" and "estimated" between "open" and "in progress". Reflecting this through the sorted label and their position in the board is rather cumbersome and error-prone. (For example, if someone moves an issue in some sprint up and down, this will be reflected in the core board, silently scrambling the order of issues the team might have had decided about in an extensive discussion weeks earlier.)

So what would be a better way to implement this?

sbi
  • 9,992
  • 6
  • 37
  • 56
  • 2
    Seems like way too much diplomatic overhead just to add a function to a lib. At our company of 50 devs (medical software) we still allow devs to just push code to each of our in-house libraries if they think its appropriate. Its reviewed afterwards of course. You can maybe consider working with a pullrequest flow but a meeting? No. That's never going to work. – Teimpz Nov 28 '16 at 07:49
  • @Teimpz: Of course, everybody will push to the in-house libraries, and, of course, every code is reviewed. However, the order in which core issues are tackled (which are not necessary for some current project) is decided by all teams. That works pretty well, only Jira doesn't seem to support it well. – sbi Dec 12 '16 at 08:51
  • The overhead does look like quite a bit, but given that the core is so widely used, I would be willing to accept a bit of overhead to make sure nothing goes wrong. A meeting seems like a lot though. I would see it as any other task, but extra communication - reviews, conversations - would be important. – Erdrik Ironrose Jan 30 '17 at 13:05

3 Answers3

2

If you want to track this in JIRA I would follow it through as if it were a new task.

So for example:

Let's say you have the story CORE-75: Foo the Bar.

Once it is decided which team will take the task, they can then create a new task: SUPPORT-123: Foo the Bar in Core.

You can then block CORE-75 with SUPPORT-123. Once SUPPORT-123 is finished, you can then go back to CORE-75. Either you can have the reviews merged, or review the code twice (once by the designated team, once by a more core-specific team).

This is really what you are doing anyway: Consider the core library as its own product/customer, don't go half way.

Erdrik Ironrose
  • 4,806
  • 3
  • 13
  • 25
0

One approach is for the team to create a new issue for their sprint that links back to the core library issue. It's kinda like you're making a sub-task for a task but across the boards/backlogs.

Another approach is just to track this separately outside of JIRA. Export the existing backlog as CSV or spreadsheet and organize that.

By separating the issues from JIRA, you have flexibility to define the priority in the planning meeting and don't have to worry about JIRA's sorting algorithm on the boards and you won't have to use labels either.

In the prioritization planning meeting for the core library you can create a shortlist of tasks to complete for the core library and whoever is responsible/accountable for the core library can make sure these tasks are started by the different project teams and completed.

-1

There is a view that Core Libraries which encapsulate a lot of common, but unrelated functionality are a 'bad thing'(tm)

There are a few reasons for this

  • They pull in dependencies and code that you don't need
  • Changing them causes changes to all applications
  • No single 'owner'

In your case I think your division of tasks by the application the change would be made to is the root of the problem. A kind of reverse Conway's law.

I think the best solution for you would be to move away from having 'Core Libraries' Libraries should have a specific (small) set of logically grouped functionality. It should be possible to complete them. ie JsonParser, LogWriter etc it should rarely make sense to add a new feature.

However, assuming this would be a long and difficult task, as a secondary solution I would simply keep the core library tasks with the team that needs the functionality. ie.

Task : add feature X to product Y

Dev : hmm some of the code for feature X should go in a corelibrary.. I will put it there as part of this task

Ewan
  • 70,664
  • 5
  • 76
  • 161
  • This seems odd. For starters: What do you think is the difference between what you call "libraries with a specific small set of logically grouped functionality" and what we call "core libraries"? (BTW: It seems I have missed the notification for this answer. Sorry for replying so late.) – sbi Dec 12 '16 at 08:47
  • I think this is the stand out quote for me : "a piece of code they have written is of greater interest and should be extracted into a core library". If your shared projects are feature complete 'libraries', then you never need to add a feature to them. – Ewan Dec 12 '16 at 08:53
  • I fail to understand your argument. Why would any code not benefit from maintenance? And do your customers never request new features, leading to new code to be written? And how do you know code is of common interest, other than by getting assigned another project with a requirement already interested? – sbi Dec 12 '16 at 09:04
  • Say you library is Json.Net. it has one purpose serialise objects to json and reverse. sure you might need to fix a bug, or add support for generics but the overall feature set never changes. You are never in the position where for example a customer asks you to implement 'the ability to cancel orders' or whatever and you think, 'I'll add that to Json.Net' – Ewan Dec 12 '16 at 09:09