I just attended the 2007 Jolt Awards at the SD West Expo in Santa Clara.
In case you haven’t already seen it, Microsoft had quite a few nominations and received two “Productivity Awards” (honorable mentions), and one Jolt Award! See below:
Jolt Award Winner:
There were other tools that won or were mentioned that complement, integrate, or support either Visual Studio or the .NET platform.
For a complete list of nominees (and soon-to-be-posted winners): http://www.joltawards.com/2007/
In case you haven't seen this yet..
Team Foundation Server is happy to announce the release of version 1.2 of Team Foundation Power Tools (formerly known as Power Toys). In this release we’ve added 2 new command line tools for the developer and 3 non-command line tools. This version includes some bug fixes to previous Power Tools, support for Vista, and adds the following new functionality:
Please note that the Process Template Editor has some additional pre-requisites, they are identified on the download page.
You can locate the Team Foundation Power Tools V1.2 release here and you can get help on the forums for these tools here.
I get asked this question a lot. You download the latest and greatest version of the guide, open it, and you can't access any of the help items!
This is because the .chm file (the installation guide help file) is "blocked" for security reasons. To resolve this, simply right-click on the file and select Properties. You'll notice that there is an "Unblock" button at the bottom.
Click that button, and click Ok to close the Properties dialog. Lastly, re-open the installation guide and you should be set!
To download the TFS installation guide, go here: http://go.microsoft.com/fwlink/?linkid=40042
The TFS install guide is quite comprehensive. It covers walkthroughs & checklists for both single- and dual-server deployments, system requirements, security, and install guides for the Build Server, Proxy, and Team Explorer.
Are you kidding me? People are using blogging, this great communications medium, to play TAG? So let me get this straight: I mind my own business, don't over-blog because I try to only post meaningful stuff here, and now because I've been "tagged" I need to reveal 5 things about myself. All thanks to Grace Francisco.
In the interest of keeping my friends my friends, I’ll end the madness with me and not tag anyone else (at least for now).
I think the folks at Borland have finally removed my StarTeam blog. With the inception of CodeGear, CG seemed to take over the blog server, and removed me.
I honestly haven't touched it since leaving Borland, but several former colleagues and customers have emailed me wondering if the content is still available somewhere (I had a lot of how-to's and SDK samples posted). I honestly don't think it's archived anywhere, but I've asked the CodeGear folks via email, and will post the URL if it's still posted somewhere.
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.
Take a look to find the closest of the 23 cities hosting a launch event!
I would like to invite you to a webcast designed specifically for our customers in the West Region. This event, presented by William Salazar – Microsoft will cover Microsoft Visual Studio Team System and will include technical and solution overviews.
Microsoft® Visual Studio® 2005 Team System is the best integrated software development platform to build the mission-critical applications that businesses depend on. It extends Visual Studio’s integrated and productive experience from the developer to the entire development team by delivering powerful new role-based tools for software architects, developers, testers and project managers. It also includes an integrated team server and customizable processes to help teams drive predictability, visibility, and control into their software development process.
Overview of ‘Data Dude’ aka Visual Studio Team Edition for Database Professionals11/29/06, Wednesday, 10:00 a.m. – 11:30 a.m., LiveMeetingVisual Studio Team Edition for Database Professionals delivers a market-shifting database development product designed to manage database change, improve software quality through database testing and bring the benefits of Visual Studio Team System and life cycle development to the database professional. This webcast will cover the main features of the Database Professionals product like:- Schema Management - Controlling Database Change- Data Generation for Tests- Database Unit Testing - Improving Collaboration and CommunicationPresented by: William Salazar, MicrosoftAudience: IT Managers and Professional Developers, DBAs, Architects and TestersPrerequisites: Previous experience with Microsoft Visual Studio Tools and technologiesRegistration URL: http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032316244 Event ID: 1032316244
There isn't a lot of documentation out there that covers deploying Team Foundation Server across two non-trusted domains. This is not to say that TFS simply won't work this, but that there is simply not a lot of deployment documentation to support this scenario. There is an MSDN forum post (http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=177844&SiteID=1) that discusses it, but no formal guidance.
The below is a diagram outlines a deployment configuration that should support this scenario. Again, it's not formal documentation, but rather a visualization of a workable scenario.
The full-size image is attached to this post.
Login to your MSDN Subscribers area. Go to downloads. Expand the tree to:Developer Tools->Visual Studio 2005->English->Visual Studio 2005 Team Foundation Server Workgroup Edition (English)
Now, to keep the download size somewhat manageable, you will also need to download SQL Server 2005 Standard Edition (also on MSDN). The actual media for TFS should include this install.
Yep, we actually do consider database developers first-class citizens in the SDLC!
We've launched the SoCal Team System Community site (http://www.SoCalTeamSystem.com/). Our goal is to provide a more centralized area for Team System-related information that's specific to Southern California.
In the interest of time, the initial site leverages Office Live Beta (http://officelive.microsoft.com/). We are planning to create a custom site to eventually replace it (with much more content, discussion forums, etc); but for now, you can still find general Team System information, SoCal events, and information about MS office locations.
The Team Foundation Server bits which you can download from MSDN (find it here) represent the full product - complete functionality and connectivity. The only difference is that there is a evaluation time limit of 180-days. Once you obtain your product key, you can simply enter your product key and remove the time limit.
ogin to your MSDN Subscribers area. Go to downloads. Expand the tree to:Developer Tools->Visual Studio 2005->English->Visual Studio 2005 Team Foundation Server Trial Edition (English)
If you're looking for a quick way to "sandbox" Team System and Team Foundation Server, you can download a fully-configured VPC image from the MSDN Subscribers download area.
Login to your MSDN Subscribers area. Go to downloads. Expand the tree to:Developer Tools->Visual Studio 2005->English->Visual Studio 2005 Team Suite Trial Edition (For Evaluation Only) Get the downloads for: Visual Studio 2005 Team System VPC – Part 1 of 2 (English) Visual Studio 2005 Team System VPC – Part 2 of 2 (English)
That will give you a full Virtual PC image with TFS already installed and configured, and the Team Suite edition of Team System installed.
The western region DPE team is hosting twice-a-month webcasts from March through June. The first Friday of each month will cover a general platform overview, and the third Friday of each month will feature a specific topic area.
March 17th (10AM PST) – Deep Dive on TFS Source Control - https://www.livemeeting.com/cc/microsoft/join?id=XST7PM&role=attend&pw=w%3D%3AjNFP5dApril 7th – Team System Platform Overview - https://www.livemeeting.com/cc/microsoft/join?id=DKCD6B&role=attend&pw=x%3FM5%7EM%26GtApril 21st – Team Build - https://livemeeting.microsoft.com/cc/microsoft/join?id=3JSJ46&role=attend&pw=Q%5Dm6Cn4%5BDMay 5th - Team System Platform Overview - https://www.livemeeting.com/cc/microsoft/join?id=QM2NMQ&role=attend&pw=zGfj%7B7%3D%3AX
As Live Meeting information becomes available, I will try to update this post.
Grace Francisco consolidates the most notable adoption case studies into a blog post:
Borland announced this morning two big moves:
The purchase of Segue should help them better round out their ALM/SDO offering by being able to tout their own QA toolset.
Borland is looking for a buyer of their IDE products, one that will keep the business unit intact and allow the tools to be further developed. While this is sad news for those with Borland nostalgia, I think it'll be great for developers in the long run. Borland admittedly lost some of their focus on developers (which was the main focus when the company was founded) over the past couple years. A new infusion of attention and funds into the IDE's (C++Builder, C#Builder, JBuilder, and Delphi) should give the loyal followers something to cheer about.
This is a bold, but positive move for Borland. The biggest challenge now is getting all of these products tightly integrated together - no clunky import/export or field-created utilities. If that can get done in the short-term, along with Tempo, their story will be pretty compelling.
Now, how does this affect Microsoft's Team System offering? Not too much, actually. VSTS is, and will continue to be, the premier offering for .NET development environments. For one-stop, end-to-end SDLC solutions, Team System can satisfy all the major roles of the lifecycle. Borland may still push a "Developer" role in their offering, but now it will be by way of integrating with 3rd parties (Microsoft, Eclipse, or wherever their IDE's land).
(this is a post moved from my old blog. My old blog post now links to this one)
I've been asked this a few times now: "If I have a functional or technical requirement, why do I need tasks? The requirement IS my task, right?"
The answer is, as is the case for most topics of debate in the world of PM/RM/CM/SCM (enough already!), it depends!
(NOTE: Before reading further, try to dissassociate these terms from actual physical entities in a tool. By this I mean, don't think of MS Project whan I mention a "task", and don't think of a Word document when I discuss "requirements.")
Requirements and tasks, while they both can be interpreted as instructions for work, inherently have attributes unique to themselves. To explore and identify these attributes, let's look at the definition of each.
A requirement, defined by our friends at dictionary.com is:
Does this definition mention that this is an instruction for work? Yes and no. While a requirement doesn't necessarily state "Go do this," it does have that implication. For example:
FR 101: The system shall provide a search mechanism.
All vagueness aside, this requirement doesn't actually directly say, "Build a search mechanism". It more simply states that in order for this project to be successful, there needs to be a search mechanism. But the task itself is implied: "The system shall provide a search mechanism[, so go make one]."
Requirements are success criteria, answering "Why are we doing this?", and "What exactly is this thing going to be?"
If you have a relatively small team, detailed requirements, and don't see the need to record work done against requirements implementation in much detail, then simply using requirements as "assignments of work" may be perfectly feasible.
A task is defined as:
Tasks, by definition, are much more explicit in their direction to a particular consumer. They specifically attribute themselves to a consumer as a unit of work to be done.
Tasks are work criteria, answering "What exactly am I supposed to do?"
If you have a need for more granular work tracking, or your requirements are defined in a way that it may take multiple consumers or efforts to implement them, I'd recommend using tasks to at least some degree.
Using Requirements and Tasks Together
The easiest way to see a marriage between requirements and tasks is by admitting that some requirements may need multiple things to be done to be implemented. Take our earlier sample requirement:
Simple enough, right? Well, to implement this requirement, perhaps a search dialog needs to be created. A database query needs to be established. The actual search operation itself may need to be threaded to minimize impact to the foreground application. If you're a PM managing your development team, you may want to know more specifically what your developer is working on today than, "I worked 5 hours on FR 101". You will see better reporting metrics if instead you can see, "I worked 2 hours on the search dialog, and 3 hours on the database query."
So what? Why does all this matter? Whether or not you use both requirements and tasks, or just one type of artifact, is ultimately up to you. But take a gander at user scenarios/needs that I've experienced, and you might get a better idea of what to do in your environment:
Well, that's my 2 cents. I know there are many opinions out there (I'm sure there are even more approaches!) about this topic. The beauty of having multiple solutions to an issue such as is this that it allows us PM's and SCM guys to keep jobs!
Two scenarios will be discussed in this post: Single Hat and Multiple Hats.
You have 3 people: Joe, Sally, and Dave
You have 3 main roles: Developer, Tester, Reviewer
You also have 3 projects: Project A, Project B, and Project C
Scenario #1: Single Hats
Team members wear only one hat in the enterprise. A Developer for one project is a developer for all projects – the same for Tester and Reviewer.
The roles that Joe, Sally and Dave play are the same for every project:
The simple setup for this in Team Foundation Server is to use generic role-based groups:
Team Foundation Server
When configuring your Team Project’s permissions, simply grant each group the desired rights. This will allow any subsequent users to be added to the environment with ease (just add them to the group that fits their role).
Scenario #2: Multiple Hats
Your team may have roles that vary by project. A good way to support this in Team Foundation Server is to create role-based groups on a per-project basis.
The roles that Joe, Sally and Dave play vary with each project:
The inherent problem with using generic role-based groups (as in Scenario #1) is that in this scenario, everyone would have full rights to each of the three projects because each person belongs to each group:
A more practical approach is to use project-specific, role-specific groups. This adds several extra groups, but more effectively manages access control at the project level:
\Project A - Developers
\Project A - Testers
\Project A - Reviewers
\Project B - Developers
\Project B - Testers
\Project B - Reviewers
\Project C - Developers
\Project C - Testers
\ Project C - Reviewers