We already use tfs for managing defects in code etc, etc. We additionally need a way to "understand the domain & requirements of the products". Normally, without tfs we exchange emails with the consultants and have the questions/queries answered. If it is a feature implementation we sometimes "find" conflicts in the implementation itself. And when that happens the userstory is modified and the enhancement/bug as per that is raised in TFS.
Sometimes it is critical we come back to decisions we made or questions we wanted answers to. Hence we need to be able to track how that "requirement idea" or that "query in concern" evolved.
Hence how is it that we can use TFS to track all of this? Do we raise an "issue" item for this? Or do we raise a "bug" item?
The main things we'd ideally look in a query tracking system are as follows:
- Area: Can be a module, submodule, domain. Sometimes this may be "General" – to address domain related stuff, or, event more granular to address modules, sub-modules. Take the case for the latter, if we were tracking this in excel sheets, we'd just write
module1,submodule2; i.e. in a comma separated fashion. The things I would like here is to be able search for all queries relating tosubmodule2sometime in the future. - Responses: This is a record of conversations between the consultant and any other stakeholder. For a simple case, it would just be paragraphs. Each para would start with a name and date enclosed in brackets and the response following that…each para would be like a thread – much like a forum thread
- Action taken: We'd want to know how the query was closed, what was the input given, what were the changes that took place because of that, etc etc.
These are fields I think I would need in such a system apart from some obvious ones like status, address to, resovled by, etc. I am open for any other fields which are sort of important. To summarise my question: how can we manage "queries" in the system? Where should we ideally store data pertaining to those three fields I have mentioned above (for e.g. is it wise to store responses in the history tag assuming we are opening a bug for the query)?
Best Answer
I have almost been there, implementing the solution that I am about to describe. The reason I am not currently using that is... well, besides my personal preference for other version control systems rather than TFS, is that the company using it found a more suited software for this.
In TFS, this is easy to implement. Whether you want to use "bug", "task" or any other element is really irrelevant. I would suggest Task on TFS OOB, but you can redefine and create more work item types as you want. (Which is actually useful to set up predefined fields.)
Areas: As for the areas, you can defined them in TFS and each of these. The problem with TFS is that you may not have an item mapped to several areas. If you wish to defined areas as modules, submodules, funcionalities, etc. Anything that works for you.
As for searches, you can use TFS queries to define custom searches that will return tables or trees of work items. These are very customizable, useful and even exportable to different formats (Outlook, Excel with linked tables, Project, etc.) I've done so plenty of times, and event programmed burn down charts in Excel with linked queries from TFS.
Responses: If you wish to define a custom work item type, you may create a text field for this, and force it to be completed before it can be assigned a finished state. The problem here is that you cannot anticipate what number of responses you may have. In here you may defined your set as a one-question and then one-response. Or comments/discussion and one response.
If you wish to have multiple responses (i.e., a discussion) I do not know how to accommodate TFS for that. What I have done so far is to have everyone log their responses in the very same way you described: date, name and text. If someone would mess up with the previous responses, you still have the history of the work item. Sometimes, rewriting the whole text is even desirable, to sum things up.
Action taken: For this specific case I would recommend the addition of a custom field, in case every single of these items need it. Also, you could make it the last response, which makes sense when the action later needs to be verified by someone else or may even spawn further comments and corrections.
Personal view:
I know this sounds quite hacky, and yes, it is. TFS can be widely customized, but sometimes the workflow you've got does not correctly fit the way that the system works. I think this is one of these cases. As I have described, we had made it work, but as I said in the beginning of my response, another system which fits your needs better is always a better option.