I’ve met with several customers over the last few months who either are, or are looking to, manage their documentation efforts in Team Foundation Server. There’s not much guidance or documentation about the best way to do that. Now my blog is hardly a repository of impactful information; but I hope this post helps to shed some light on practices that can be used to manage documentation in TFS.
In thinking about this, the concept of documentation management is somewhat similar to requirements management: A document format is the ultimate output, consistent capture and management is ideal, and a development workflow is needed. Several years ago (when TFS 2005 was the current release), I blogged a four-part series on requirements management in TFS, a series which many seemed to appreciate. (Since then, a much more robust, prescriptive guidance has been published on CodePlex around TFS 2010 called the “Visual Studio Team Foundation Server Requirements Engineering Guidance” ).
There are two main schools of thought around using TFS to manage documentation efforts:
In the document-centric approach, the document itself is the “version of the truth”. Updates are made to the document directly, and either TFS or the associated SharePoint site manages versioning. Any approval workflows are handled by SharePoint.
The benefit of this approach is that people already know how to edit a document (Word is the most popular requirements management tool, as well!). It’s natural and seemingly convenient to just pop open a document, make some updates, hit “Save”, and close. When the documentation process is finished, you already have your “output” – the document itself. Just convert it to the format that you want (PDF, XPS, whatever), and you’re done.
The drawback however, is in its simplicity. You lose formatting consistency of individual sections of the document, as well lower-level management of those sections. This results in extra scrutiny over a document to check for those inevitable inconsistencies. If you have traceability requirements in your process guidelines, it’s going go be very difficult to accurately relate a specific section within a document to another artifact in TFS. It’s quite near impossible to report on the status of a documentation effort, other than “the document is or isn’t done yet.” There are no metrics around how much effort has been applied to the documentation, how many people have collaborated on it, etc.
The item-centric approach uses the work item tracking system in TFS to manage components/pieces of documentation individually. This is accomplished by creating a work item type designed to support individual pieces of documentation. In this scenario, TFS becomes the “version of truth”, and the actual document is really just an output of that truth. (Think of this as similar to version control, which houses the truth of your code, and the build is the output of that.)
Several of these RM-centric approaches can be applied toward documentation efforts:
Below is just one example how a “Documentation”-like work item type might look in TFS:
You’ll notice there are standard fields such as title, assigned to, state, area, and iteration. In this example, there are a few custom fields added as well:
Target Document allows you to target a specific document that this documentation piece belongs to. In my example, I use a global list for this field, allowing choices of End User Manual, Administrator’s Guide, and Installation Guide.
Document Order is a field I created to help with the ordering of the documentation piece (for sibling work items) when it is finally output into a document.
In TFS 2010, you also have the added advantage of work item hierarchy to better help organize the structure of your documentation. You can use hierarchy to break down sections or areas of the document. Viewing the “structure” of a document (like a document outline in Word) is a matter of constructing a query.
For example, below is a query result that shows a document hierarchy for my “End User Manual”:
There are a few very tangible advantages of using this approach:
Sounds great, right? Oh yeah, but what about actually creating the document itself? (What, you don’t just want to dump the query results to Excel and format from there?)
Well, the first main step is to get your work items exported to a Word document (for any fine tuning) and ultimately converted to your final output format (probably PDF).
If your list of documentation work items is flat (i.e. no hierarchy, parent/child relationships), that simplifies things because you can dump your work items to a file format that can be used as a merge source for Word (like a TSV or Excel file). Then you really just have to worry about formatting your document appropriately.
And there are a couple of 3rd party tools that you may (again, based on your specific needs) be able to leverage. These tools work to integrate Word with TFS, and each carries their own pros and cons:
It gets more complicated as you work with a hierarchy. In my above example, I want my work item hierarchy to reflect a document hierarchy in the output document (i.e. first level gets Heading 1, second level gets Heading 2, etc.). That puts a small wrinkle in things.
So when in doubt, roll your own. I have several customers who have implemented custom utilities to export their documentation work items to a Word document. Given my amateur status as a programmer, I thought I’d give it a shot myself. More on that in a future post, but the basic idea of such a utility is something like this:
Again, more on that later.
So keep in mind that while your mileage may vary in terms of approach and need, it is definitely possible to leverage TFS WIT as repository for your document development needs. My examples above are by no means the only way to attack this topic – I’ve just seen them work with other customers of mine.