There’s not a huge amount of best practice info out there regarding areas and iterations. One interesting place to look at is a blog post that describes how the Visual Studio team uses them (http://blogs.msdn.com/ericlee/archive/2006/08/09/when-to-use-team-projects.aspx)
So here are my 2 cents (you can see how much that's worth these days!) on Areas and Iterations.
To me, areas are ways of tagging or organizing objects within a Team Project. Typically, areas are used to define either logical, physical, or functional boundaries. It’s a way to slice and dice a normally large project effort into more manageable, reportable, and easily identifiable pieces.
For example, let’s say we have a tiered web application managed in a single TFS project called “MySite”. There are 3 major components to this app: the web site, a web service, and a database. If this is a decent-sized application, you might have 1,200 tasks in the system for this project. But how do you know to which component a given task belongs? What if I only wanted to see tasks for the web service piece? Areas are a convenient way to handle this. Set up areas like this:
Now you can specify an area of assignment for each task (work item), making it easy to effectively filter what you want to look at/work on. You can use areas in both queries and reports as well.
You may optionally want to further dissect those major components to be even more specific:
\Layout & Design
One final aspect of Areas to consider is security. You can set security options on each Area node which can dictate not only who can change the areas, but also who can view or edit work items in a particular Area.
So if you think of Areas as slicing and dicing by “space”, think of Iterations as slicing and dicing by “time”. Iterations are like “phases” of a lifecycle, which can dissect the timeline of a project effort into more manageable time-based pieces.
So going back to the “MySite” example, say the project management team wants to split the entire project into 3 cycles, Phase 1, Phase 2, and Phase 3. Thus, your Iterations can mirror that:
These Iterations can be phases within the entire life of a project, or phases within a given release of a project. So if “MySite” is going to have multiple releases over time, my Iterations might look lik this
Now you have categorization options for both space and time (now if only we had a continuum..) for your project, allowing you to assign your tasks or other work items not only to the appropriate functional area (Area), but also to the phase (time cycle) of the project.
As the Visual Studio family of products (Visual Studio, TFS, Test Professional) nears its 2012 release, I thought I’d bring some short hits – tidbits, if you will – to my blog. Some of these are pretty obvious (well-documented, or much-discussed), but some may be less obvious than you’d think. Either way, it’s always good to make sure the word is getting out there. Hope you enjoy!
There’s been great hype about the new built-in code review capabilities in TFS 2012, and for good reason. The process is easy, effective, and most of all, audited.
But did you know that “My Work” is not the only place from where you can kick of a code review? You can also do a review on code that’s already been checked in. Go to the file in Source Control Explorer, then view its history. In the History window, right-click on the changeset/revision and select “Request Review”.
This will load up the New Code Review form in Team Explorer:
Notice that it not only brings in the files from the changeset (5 of them, in this example), but also any work items that were related to this changeset as well. The check-in comments are used to populate the title of the code review, as well as the optional description.
Off ya go!
Microsoft just announced final branding and pricing for the Visual Studio 2010 lineup! Here’s what it looks like (you can call this either the stadium or Lego view):
There are three minor changes to product names, listed below:
Microsoft Visual Studio Test Elements 2010
Microsoft Visual Studio Test Professional 2010
Microsoft Visual Studio Team Lab Management 2010
Microsoft Visual Studio Lab Management 2010
Microsoft Test and Lab Manager*
Microsoft Test Manager 2010*
* Not available as a separate product for purchase.
Below is the suggested pricing (USD) for each of the 2010 products.
* Subscription contents vary by purchased product.
A couple things to note:
Not sure what product has what?
Here’s another angle:
For more details on each feature, you can view a matrix here.
You’ve probably found a few comparisons on the interwebs comparing the “traditional”, on-premise TFS with the new cloud-hosted Team Foundation Service. I get asked about this a lot – as a result, I thought I’d share the slide deck I used to drive this conversation. Please let me know if you have any questions!
Basically, TF Service is a nice way to get up and running quickly, without worrying about infrastructure, backups, etc. What you lose is some customization, lab management, and SSRS reporting.
There are several schools of thought on how to "do RM" ranging from the very lightweight (whiteboards, sticky notes, cocktail napkins, etc) to the robust (formal elicitation, authoring, validation and management of specifications). Chances are your organization falls somewhere in between.
Past dictates future (thanks, Dr. Phil), and the same applies in how teams approach requirements management. Basically, if you're used to managing your requirements using Word documents (and believe me, you're in the majority), most likely that's what you figure to do when starting a new project.
The historically mainstream ways to manage requirements (Word, Excel, email) can be efficient (people know the tools, and again, it's how it's been done before) and satisfactory. But with the application development projects of today becoming increasingly complex and distributed (both architecture and project teams), this process becomes more difficult to manage. Throw in your regulation/compliance package-of-the-day and you quickly realize you need more. Key capabilities around collaboration, audit/history, and traceability rise to the top of the priority list.
As a result, the idea of managing requirements as individual elements (rather than parts of a larger specification document) is becoming increasingly popular.
I hear this quite often: "How does Team System support Requirements Management?" Visual Studio Team System, or more specifically Team Foundation Server, possesses the plumbing needed for the above-mentioned capabilities out of the box as part of its inherent architecture. TFS provides work item tracking to allow items (bugs, tasks, or in this case, requirements) to be treated as individually managed objects with their own workflows, attributes, and traceability. However, while the infrastructure is there, TFS wasn't designed specifically to support a requirements management process.
But if you are looking at Team Foundation Server to manage your development process, I would suggest that you take a peek at how it can be used to support your business analysts from a requirements management perspective as well. Again, although it's not specifically targeted at business analysts (it is on the radar (see: Team System Futures, however) there many of the capabilities of TFS can help support a productive RM process.
This series will take a look at a few different ways that TFS can support requirements management. In Part 2 I'll show a couple of ways to do this using TFS "natively" (without any add-ins/plug-ins); and in Part 3 I'll briefly discuss some 3rd party solutions that support requirements more directly yet still integrate with Team System. And we'll close the loop in Part 4 with a summary.
Next: TFS - Out of the Box
Every organization approaches the concept of "requirements" differently. Factors include general history, skill set, complexity, and agility. Many development organizations are adopting Team Foundation Server to help improve team communication & collaboration, project control & visibility, and generally a more integrated experience across the various actors in the application lifecycle.
The more pervasive TFS becomes in an organization, the more I'm asked about managing requirements within the confines if Team System. Some shops want to know about how to integrate more RM-specific applications into the platform, while others want to leverage TFS as much as possible and wait until Microsoft releases a requirements management solution (I know, I know, Word is the most widely-used requirements tool in the world - but I think you know what I mean by now!).
If you're trying to choose which path to take (TFS-only or a partner integration), here are a few basic considerations:
Some requirements-related resources (other links can be found in the various parts of this series):
Well, I hope you at least found this series worth the time it took you to read it. I welcome any comments and feedback as this topic is always shifting in perception, intention, schools of thought.
This is Part 2 of the series, Requirements Management in TFS. For a brief background, please see Part 1: Overview.
In this part, we'll discuss a couple of the primary ways to support requirements in Team Foundation Server: the Team Portal and Work Item Tracking
Team Portal (SharePoint)
If you use some kind of document format for authoring and tracking your specifications (Word, PDF, etc.), you may already be using something like a SharePoint site to store them. Or some kind of repository, even if it's a network share somewhere. Team Foundation Server creates SharePoint-based (specifically Windows SharePoint Services) web portals automatically when you create a new project. These portals provide an easy, web-based way for interested parties to "check-in" on a project's status, participate in discussions, post announcements, view process guidance documentation, and submit supporting documents and files to a document library.
It's the document library that provides a natural fit for bringing your specifications a little more in line with the rest of the application lifecycle. The document library allows analysts to remain in their comfort application (i.e. Word), but submit changes to requirements to a location that is much more accessible to those that will consume those requirements (architects, developers, testers, etc.). Team Foundation Server users can access the document library from within Visual Studio Team System, TFS Web Access or other interfaces, thereby allowing them to more readily react to new changes and provide feedback as necessary.
And now that the requirements documents are in the document library and managed (indirectly) by TFS, you can easily leverage the linking capabilities of TFS to add traceability between your specifications and source code, defects, tasks, and test results. (How do you link work items to items in the document library? Work items can be linked to hyperlinks, so you can simply link to the URL of the specific file in the document library in SharePoint.) This adds some real tangibility to your reporting in that you can now view reports from TFS that, for example, show all development tasks and their related requirements spec, changed source code, and validated test results.
Easy, right? Well, yes and no. There are some definite drawbacks to this approach (I'm leaving it up to you to decide if the good outweighs the bad), the primary being that you still don't have any more granular control over individual requirements changes than you did before. Changes are still tracked, and linked, at the document level. This can be challenging if you need to track changes to individual requirements (change tracking in Word will only take you so far) for auditing and compliance reasons.
Work Item Tracking
Team Foundation Server's work item tracking feature is a major moving part of the system. Work Item Tracking (WIT) provides a robust yet flexible way to track any item of record throughout a lifecycle. Some work item types provided with TFS include: bug, task, risk, scenario, or (to the point of this article) requirement. Work items are managed in the TFS database alongside code, builds, test results, etc, and provide a proper level of granularity for controlling change and traceability.
In the previous example, using the SharePoint project portal lacked the ability to control changes to individual requirements, nor did it allow linking to those individual elements. Leveraging WIT in TFS addresses both of these shortcomings. You can create and customize your own types of work items, allowing teams to have complete control over what types of work items are used, their fields, workflow, and even UI. Say for example, your team typically leverages three types of requirements: Business, Functional, and Non-Functional. TFS allows you to create custom work item types that represent each of these categories of requirements.
Now that your requirements are managed as work items in TFS, you can take advantage of all the benefits of the work item tracking system (see benefits below)
Requirements work items are accessed in the exact same manner as any other work item:
Since work items are primarily access by way of queries in Team Explorer, teams can easily filter what requirements are displayed and accessed at certain points.
Reporting gets a considerable leg up using the work item tracking approach.
The biggest challenge with this approach (in my opinion) is the shift in mindset. In case you didn't notice, I haven't mentioned using Word in this section. WIT gets more granular than Word does for managing item-level changes, and there is not currently a Microsoft-provided integration to Word from TFS. There is often considerable resistance to change in that, "without the document, what will we do?"
Getting Into the Code
And lastly, if you're really into it, you can tap the Team Foundation Server SDK to get really creative. For example, you can write a custom lightweight interface for business analysts to enter and track requirements work items in TFS. Or create a custom report (although you might be better off creating a custom report via the server's reporting mechanism (SQL Server Reporting Services). I have a little app that creates a "coverage analysis" spreadsheet in Excel that shows coverage (i.e. links) between work item types (for example, I can see if there are any business requirements that have no corresponding functional requirements).
Next: TFS - Partner Integrations
*** UPDATED 4/30/2009 ***
If you attended the Agile & Scrum Essentials event series last fall, then you’ve been expecting this second round! And if you missed it, now you can catch up!
Please join Microsoft and Neudesic for a day in the life of Scrum with Visual Studio Team System 2008 and Team Foundation Server! Agile methods are a set of development processes intended to create software in a lighter, faster, more people-centric way. Many development teams have adopted "agile" methodologies to manage change and to improve software quality. These methodologies promote continuous integration as a practice to build and test software products incrementally as new features are included, bugs are fixed, and code is refactored.
If you missed the first series of Agile & Scrum Essentials last fall; here’s your chance to attend the follow-on event where we’ll briefly revisit the basics of Agile and Scrum and provide a walkthrough of how to configure Visual Studio Team System 2008 and Team Foundation Server for Scrum. Participants will be familiarized with how key artifacts are managed within this popular process template for enacting Scrum in organizations.
Join us for this interactive event as we explore a “day in the life of a Sprint,” that will give you a practical perspective of how Scrum teams leverage Visual Studio Team System for end to end management of the planning, execution and control of Scrum projects. The day will end with an overview of what’s coming in Visual Studio Team System 2010!
Please register today for the event nearest you!
You can also call 1.877.MSEVENT (1.877.673.8368) and provide the appropriate invitation code to register.
I will be at the Denver, Phoenix, and Salt Lake City venues and hope to see you there!
Did I mention this event is FREE?
Join us for a sneak peek of Microsoft® Visual Studio® 2010, which will be a landmark release of the premier development toolset for Windows®, Web and Cloud development. The Ultimate Event is your exclusive opportunity to hear about Visual Studio 2010 from experts before the product is launched this year. Microsoft has made significant investments to and improvements of Modeling and Testing/QA tools in Visual Studio 2010. At this event you’ll get a comprehensive overview of Visual Studio 2010 and Team Foundation Server 2010, which is the Application Lifecycle Management (ALM) core of Visual Studio. We’ll present enhancements in version control, reporting, project management and build management. Spend the day with us to learn how to take software development to the next level with Visual Studio 2010!
I hope to see you there!
San Diego, CA
Los Angeles, CA
Mountain View, CA
Salt Lake City, UT
San Francisco, CA
If you’re not heading to Seattle for the Visual Studio 2012 Launch Event on September 12th, don’t worry: We’re coming to you!
Be our guest and attend in person to experience all of the incredible new capabilities of Visual Studio 2012 first hand.
For those of you who have attended the events so far and are looking for the slides/content, look no further! Everything is here: http://aka.ms/VS2012Roadshow
Discover how Visual Studio 2012 allows you to collaborate better and be more agile. See how it helps you turn big ideas into more compelling apps. Experience how it integrates best practices that accelerate development and deployment. You’ll enjoy several sessions which will take Visual Studio, Team Foundation Server, and Test Professional through their paces to show off what’s possible with this incredible release!
Register today for a city near you (dates and locations listed below), we hope to see you there!
Registration/check-in begins at 8:30. The event runs from 9:00AM to 4:00PM.