Hi all I just wanted to ask the wider Spira user community if they had experiences of maintaining multiple, concurrent Projects (PRs) as part of a common package-of-work, and what constraints and solutions they were aware of. At our company, we have PRs for each of our products as we have a continuous development culture which means RQs, INs and TCs must persist across many Releases (or "work-packages"). This is great for when a product is being developed and enhanced in isolation. However , some of our products are (directly or indirectly) integrated, and hence there is a need for integrated regressi on testing. Tracking these work-packages is more tricky. We have previously adopted a couple of different models: where we created a fresh PR for the work-package, with it's own finite Requirements, Releases, Tests and Defects. The PR was then decommissioned at the end of the work-package. Some of the re-usable assets or outstanding incidents were then migrated to another PR to continue the pattern etc etc etc. The problems here were duplications (eg proliferation of id# for artefacts which were the same thing) and reporting. We have dropped this as a model now. where we deliberately duplicate artefacts (eg RQs) in both PRs and progress them uniquely. For instance, an integration requirement is logged in both PRs. We then treat one PR as the "master", because it is the product which is most active/complex, and store all the integration TCs/TXs in there and run everything in there. This gives us a single place for test results. But we still log Defects in the correct product PR so that we keep a proper record, which means managing bugs in two places. The biggest problem with this is keeping the "junior" PR in synch with the "master". Considering that these work-packages are quite regular, and that we don't want to end up with a massive list of short-lived PRs, what model could we adopt that gives us the flexibility, maintainability and searchability that we need? If you've ever been in a similar dilemma, how did you resolve it? Cheers. en-US(C) Copyright 2006-2026 Inflectra Corporation.support@inflectra.com/Computers/Software/Project_Management//Computers/Software/Quality_Assurance/KronoDesksupport@inflectra.comhttp://www.inflectra.com/kronodesk/forums/threads120/Support/Forum/spirateam/issues-questions/580.aspxthreadId=580Andy Smith (andy.smith@infoterra-global.com) Hi all I just wanted to ask the wider Spira user community if they had experiences of maintaining multiple, concurrent Projects (PRs) as part of a common package-of-work, and what constraints and solutions they were aware of. At our company, we have PRs for each of our products as we have a continuous development culture which means RQs, INs and TCs must persist across many Releases (or "work-packages"). This is great for when a product is being developed and enhanced in isolation. However , some of our products are (directly or indirectly) integrated, and hence there is a need for integrated regressi on testing. Tracking these work-packages is more tricky. We have previously adopted a couple of different models: where we created a fresh PR for the work-package, with it's own finite Requirements, Releases, Tests and Defects. The PR was then decommissioned at the end of the work-package. Some of the re-usable assets or outstanding incidents were then migrated to another PR to continue the pattern etc etc etc. The problems here were duplications (eg proliferation of id# for artefacts which were the same thing) and reporting. We have dropped this as a model now. where we deliberately duplicate artefacts (eg RQs) in both PRs and progress them uniquely. For instance, an integration requirement is logged in both PRs. We then treat one PR as the "master", because it is the product which is most active/complex, and store all the integration TCs/TXs in there and run everything in there. This gives us a single place for test results. But we still log Defects in the correct product PR so that we keep a proper record, which means managing bugs in two places. The biggest problem with this is keeping the "junior" PR in synch with the "master". Considering that these work-packages are quite regular, and that we don't want to end up with a massive list of short-lived PRs, what model could we adopt that gives us the flexibility, maintainability and searchability that we need? If you've ever been in a similar dilemma, how did you resolve it? Cheers. Fri, 10 May 2013 12:42:16 -04002013-07-03T07:34:15-04:00/Support/Forum/spirateam/issues-questions/580.aspxmessageId=1082David J (adam.sandman+support@inflectra.com) Anyone have any ideas for Andy? Tue, 14 May 2013 14:48:28 -04002013-05-14T14:48:28-04:00/Support/Forum/spirateam/issues-questions/580.aspx#reply1082messageId=1103Vanessa Smith (vanessa.smith@flhosp.org) We are using what you call Model 1. I am interested in any other solutions others may have. Model 2 would require too much SpiraTeam Administration for us to handle at this point. Fri, 24 May 2013 15:33:12 -04002013-05-24T15:33:12-04:00/Support/Forum/spirateam/issues-questions/580.aspx#reply1103messageId=1152David Bentham (david.bentham@se.consafelogistics.com) Hi Sad to say I don't have a solution but exactly the same dilemma, I now have multiple projects for the same product but for different customer implementations. My initial approach was to keep the base line artifacts in a generic project and instruct the customer projects to create specific artifacts for just that customer then use the artifacts in the generic project for all other purposes, this was a bit naive and the projects have exported artifacts from the generic to their own, I don't need to say what the subsequent problems are. On top of this the number of new projects is growing continually, I'm heading into chaos to put it mildly. The only solution I can see is that Inflectra make it possible to be able to cross project link and not copy artifacts and I have suggested this. /David Wed, 03 Jul 2013 07:34:15 -04002013-07-03T07:34:15-04:00/Support/Forum/spirateam/issues-questions/580.aspx#reply1152