In specific, I would like to maintain a baseline set of requirement work items but also develop a second subset of slightly modified requirements for a related product without 'copying' them to a second project.
In Polarion 2012 you can actually branch whole document with those workitems. I guess that's feature exactly for you.
See what is new here http://blog.polarion.com/archives/1922
Related
I'm currently using GitLab Enterprise in a team project. I now want to build out a board-based roadmap similar to Pivotal Tracker, Aha or Trello. (For this view, each month would be a "list" or Aha "milestone". We could then drag roadmap items from one month to another and the whole team can see where we are and our Issue priorities visually.)
I'm hoping we can only use GitLab for this and not need to integrate yet another tool.
In the "Boards" section of GitLab, I see I can make lists from GitLab Labels. This is OK, but I'd really like to make lists from GitLab Milestones. (Otherwise, I'd need to make another Milestone just to capture everything in the label.)
Am I missing something? Or is that really the best way to approach this with GitLab?
There is a roadmap feature for GitLab (premium/ultimate only)
It has evolved with GitLab 14.8 (February 2022)
Additional display options for roadmaps
In this release, we have introduced additional progress tracking capabilities to roadmaps. You can now view the percentage of completed epics based on issue count instead of issue weight. This functionality is useful for organizations that are using Kanban or other methodologies that don’t require their teams to set a weight on issues.
You can now also customize the level of milestones to include in your roadmap, allowing you to tailor your view to meet the needs of your audience.
See Documentation and Issue.
Milestones weren't designed with this use case in mind. Generally, once an issue is assigned to a Milestone, it doesn't change.
A common use case for milestones is to track Sprints or Iterations as milestones. The milestone's start and due dates would be the sprint start/end date respectively. During planning. issues would be tied to the appropriate milestone based on the sprint. If the work isn't finished by the due date (within the sprint period) the milestone stays the same.
Another use case is to use a milestone to track a scheduled release. In this case the start date can be empty, and the due date would be the release date. With this, if the release is missed the milestone still stays the same (ie, the issues are still attached the same) but it's completed after the due date.
Milestones do give some useful views about the attached issues, but not a board to move issues between them. Like you mentioned the only way to do that is with Labels, but they should work fine. You can customize the Labels you want to show up on a Board, and they order they're in. The only annoying (to me) thing about boards is that you can't get rid of the Open/Close lists, you can only collapse them. Looking at this issue (https://gitlab.com/gitlab-org/gitlab-foss/-/issues/37747) I doubt it will ever happen.
If you use gitlab.com, https://gitboard.co/ has the milestone or epic board which could help your case. The auto sprint could create and close the regular scheduled milestone/sprint or whatever you call it.
How can I get a list of linked work item IDs for a set of work items?
Excel-hosted queries preferred. API Sample is acceptable.
Direct DB table query is acceptable (read-only and unsupported of course!)
Many thanks in advance! -Zephan
MORE INFORMATION
UPDATE: No answers for my original Q so broadening scope of acceptable answers as follows:
Answer for TFS2015 (migrating very shortly) or TFS2013 (potentially useful for TFS2015) is preferred over TFS2010
Coding acceptable if there are any APIs or PowerShell cmdlets (MS or community).
Connecting directly (read-only!) to TFS DB tables is acceptable (source tables and related relationship link table names). Yes, directly referencing TFS DB tables is VERY unsupported, read-only, and "AT YOUR OWN RISK." Still beats having to manually copy/paste data or reconstruct list of links in Excel.
ORIGINAL QUESTION & DETAILS
My team uses TFS2010 (soon 2013 or hoping 2015) and VS2010-2015. I need to support traceability reports and analyze/quantify our coverage of ~300 Test Case work items linked to ~400 Requirement work items. Direct Link and Tree queries are close but don't give me related links on the same row as parent work item. Many thanks in advance for your suggestions and any related code fragments.
Example:
3 test cases (Test1, Test2, Test3)
4 Requirements (Req1, Req2, Req3, Req4)
For simplicity let's just use TFS work item IDs to represent each TestN and ReqN. In actuality, I have a keyword to identify my validation requirements (separate from the 1,000's of other requirements in this Team Project). The only Test Case WI I care about for this problem are those linked to one or more Validation Requirement trace-ability.
Scenarios:
1:1 (simple) Test1 is linked to Req1
1:2 (1:n) Test2 is linked to Req2 and Req3
2:1 (n:1) Test3 (and Test2) are both linked to Req3
0:1 (Requirement missing Test coverage) Req4 has no test case links
I have a good coverage gap query by creating a Direct Link query for all Requirements then set "linking filters" to Only return items that do not have the specified links.
Desired output (all tests with list of related work items):
|Test1 | Req1 |
|Test2 | Req2, Req3 |
|Test3 | Req3 |
For row #2 I am OK with other separators or even entire list using same separator (.CSV or TAB delimited).
Skip right to answer now if you have a tidy answer. If not then I added considerable RELATED RESEARCH info below to help kick-start an idea that fits the need! Especially since this hasn't been discoverably solved in the last 5 years :-).
RELATED RESEARCH (loooong but may be useful)
1. Visual Studio Queries
Flat Queries should support a list of linked items out-of-the-box... but it does not. RelatedLinkCount field is handy for knowing if there are any links to chase, but that's it for flat queries.
Direct Link queries give a list of all direct links, but the related IDs are on rows below the parent work item. I am seriously considering creating a formula to look on the next X rows to build a list of IDs, but this would be fragile especially when over 3 requirements are linked to same test. Still might solve 80% of my tracing needs.
Tree Queries also show links, but on different rows. Additionally they tend to follow just one link type. Ideally I will need list of User Requirements linked to Functional Requirements linked to Test Case(s).
2. Tools / Plug-ins
SmartExcel4TFS (eDEVTech, http://www.modernrequirements.com/smartexcel4tfs/) has 3 reports it supports, but none get me the core data I need in easily used format. At least it is FREE if you have an MSDN Premium subscription.
Requirements to Tests Trace Matrix is super-interesting. Alass, right now I need to go the other way (Requirements linked to a given test case). Also it merges cells and has sub-sections that are hard to manipulate I think. (I may revisit this option though.)
Intersection Traceability Matrix report is WAY too wide for a full 300 x 400 grid :-O.
Work Item Decomposition Matrix also didn't give me desired contents. (though frankly I've forgotten this report layout from when I checked ~1 month ago.)
3. TFS API calls
I have actually avoided this route in favor of native Excel solution... but if I can get an example of Excel VBA code (or other code with link to calling within Excel) I may go this route. At this point I don't have time to dig into rolling my own... but this would be cool assuming performance is acceptable.
Relevant API/code fragments:
Retrieving TFS Results from a Tree Query (Blogs.msdn.com 2012.02.22) - Looks like this would get me the data I need, but it is not in Excel so I'd need a bridge example of some sort calling this within Excel.
Retrieving work items and their linked work items in a single query using the TFS APIs (stackoverflow.com 2012.01.12) - Also looks very promising, but not connected to Excel. Gives hints for 2 level and 3 level nested links and performance consideration (don't make second call for each item returned!)
Retrieving work items using the Team Foundation Server API (pwee167.github.io 2012.09.18) - Excellently written introductory walkthrough blog posting to learn how to build an (ASP.Net MVC3) app that calls TFS APIs to run Flat or Tree queries. Start here if writing C# (which I could do but don't have time/justification unless easy example to integrate with Excel).
How can I query work items and their linked changesets in TFS? (stackoverflow.com 2011.05.10) - I don't need changesets but this has VB code to instantiate new TfsTeamProjectCollection which might work directly in Excel VBA (assuming proper reference is found and added)
var projectCollection = new TfsTeamProjectCollection(
new Uri("http://localhost:8080/tfs"),
new UICredentialsProvider());
OK, that's everything I have gathered on this problem. Please help contribute with the missing magic tool/snippet or follow the info above to build that last bit I have not had time to prototype & debug. Many thanks in advance!! -Zephan
We are currently in the process of upgrading from TFS 2008 to TFS 2012. When TFS 2008 was set up, the people involved didn't understand a lot of what the work item fields were for, and we ended up with very heavily customised templates and in fact lost a lot of default fields. As part of the upgrade to 2012 we are trying to return to the out of the box templates as much as possible to ensure we get to use as many of the features as possible, however there are a small number of custom fields that we need to include for reporting purposes.
Our product development process involves a roadmap for upcoming releases which includes new work as well as bug fixes. When a bug is assigned to be worked on by the developers we would like to be able to choose which release we're targeting the fix for - as far as I can see, Iteration is best suited for this. At the point the bug is closed though, we would also like to track what release it was actually fixed in, since things often get bumped from one release to the next if higher priority bugs or change requests come in, but this is where we come unstuck since I can't seem to assign Iteration to both fields such that the two show different values.
If possible we would prefer not to have global lists that have to be constantly updated with release numbers across our product range (we have around 8 different products which are constantly in development, each with their own release numbers), and leaving one of them as a text field leaves open the possibility that we will get inconsistencies in what people enter, eg 1.01 versus 1.1 which will show up in reporting as 2 different releases. As the fields are just looking up a set of values in the background, is there no way that the iteration list can be used twice? Or does someone have an alternative suggestion as to how we get round this?
What I think I'd suggest in this case is using a COPY rule on a state change event, so that when you move your work item into the Closed state, it would populate your custom field with the value currently in your Iteration field.
This would give you a snapshot of the value at the right point in time which then wouldn't be altered if the iteration was later changed, along with a history entry if it was opened & closed multiple times over its lifetime.
As iteration is time limited and release is perpetual there is an inherent mismatch of purpose with using iteration here. Iteration is for planning.
You would be better creating a release list with the version that you release.
If you are sprinting for example you may not know up front which release you will end up on before you start. If you are not sprinting then you are just kidding yourself that your know.
We are a software product company and our product codebase naturally gets branched for different projects. We currently use TFS2008 configured to store documents in SharePoint 2007. Both of these will be updated to 2010 versions, starting with TFS.
We'd like to branch - and not just version - our specifications so that any release from any code branch can be tested against a matching version of the spec.
It seems to me that we can either:
Keep our specs in SharePoint, using SharePoint search and versioning, and fake the branching issue by use of naming conventions or subdirectories
Move our documents from SharePoint into TFS proper. Enjoy the free versioning and branching, and quietly mourn our lost SharePoint document management goodness
Find some magic plug-in that gives us the best of both worlds?
Does anyone have any experience of any of these options?
Using SharePoint is a big advantage because it is easy to access\
Having the documents in TFS is a big advantage because the code and documentation are synced per version
It really depends on what your real needs are. If you have a shop where you have many people who have to access the documents only once in a while, probably the SharePoint advantage wins over the sync feature in TFS.
If you only have a few business analists, then probably the sync feature wins over SharePoint.
Be aware that when you store the documents in TFS, you need a CAL for every user that accesses the documentation.
I think I would go for alternative 1 by considering this: If your documentation is e.g. in MS Word, branching will give you nothing in terms of merging. That will never work with binary files.
If your documentation actually are text-based documents, I think I'd still go for 1, considering search capabilities, views etc. that you get in Sharepoint.
Here's what I've proposed as a solution, based on the answers here and on further experimentation.
First, some more background:
You can do very usable comparisons [1] between versions of a Word 2007 document held in SharePoint from inside Word (menu:Review > Compare > Compare > Specific Version...) and [2] between different versions of a Word document as separate files (menu:Review > Compare > Compare > Compare...) but you can't do version comparisons directly in TFS because it barfs on binaries.
This leaves you with an easy work-round for comparing the same document between TFS branches because both versions of the document are there on your file system (since TFS 2008 implements branching via directories) so you just use option [2] above. It also gives you a less easy work-round for comparing different versions in the same branch (or non-current versions generally) - you download the non-current versions as re-named files, then do the file comparison as before.
Now the proposal:
So I'm simply proposing we do all our specification creation in SharePoint, and create a branch folder-tree there to mirror the branch folders in TFS.
If the requirement arises, we can copy a snapshot of the related specs into TFS when the branch is released, but I'm hoping that either the branched specs won't change post-release date, or that if they do, SharePoint versioning will handle it well enough for us.
On a particular project we're working with a total of 10 team members.
After about a year working on the project (and using Mantis as a bug-/feature-tracker eversince), the bugtracker gets more and more difficult to use, as no standard has been setup that explains how to create new tasks, how to comment tasks etc. This leads to multiple entries for the same bugs, inability to easily find bugs when searching for them etc.
How do you organize your bugtracker? Do you use a lot of (sub)categories for different portions of your application (GUI, Backend etc), do you use tags in the title of tasks (i.e. "[GUI][OptionPage] The error")?
Is anyone in your team allowed to introduce new tasks or is this step channeled through a single "Mantis-master" (who would then know whether a new report is a duplicate or an entirely new entry)?
Always link a version control system commit to an issue and back so that you know which commits were made do solve which issue and why a certain commit was done.
What we did is to introduce a role for approve entries to the bug tracker. This role can be shared by different people. The process is either to approve, to approve with a small edit, or to reject the entry with the request for further editing or clarification.
It is better for the general understanding if the role is not given to people working in the (core) team.
In a "large" mantis system on the open web, I've seen the rules go something like
New: Anyone can enter a bug.
Acknowledged: A select few people can upgrade it to this level. These people have seen every new bug for a while, and thus they'll know if it's a duplicate. Or they can pass it back to the reporter for clarification until they understand it well enough to do this job.
Confirmed: Set by decision makers who basically say "We will be doing this".
I don't actually remember where it was, and more importantly I don't know how well it worked.