Steve Lange @ Work

Steve Lange's thoughts on application lifecycle management, Visual Studio, and Team Foundation Server

  • Steve Lange @ Work

    Where can I download Team Foundation Server from MSDN?

    • 0 Comments

    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)

    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.


  • Steve Lange @ Work

    Where can I find the VSTS Virtual PC Image?

    • 0 Comments

    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. 

     

  • Steve Lange @ Work

    Upcoming VSTS Webcasts by the West Region team

    • 1 Comments

    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.

    Upcoming sessions:

    March 17th (10AM PST) – Deep Dive on TFS Source Control - https://www.livemeeting.com/cc/microsoft/join?id=XST7PM&role=attend&pw=w%3D%3AjNFP5d
    April 7th – Team System Platform Overview - https://www.livemeeting.com/cc/microsoft/join?id=DKCD6B&role=attend&pw=x%3FM5%7EM%26Gt
    April 21st – Team Build - https://livemeeting.microsoft.com/cc/microsoft/join?id=3JSJ46&role=attend&pw=Q%5Dm6Cn4%5BD
    May 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.

  • Steve Lange @ Work

    Team Foundation Server: Capacity Planning

    • 0 Comments
    A quite useful post from Buck Hodgeshttp://blogs.msdn.com/buckh/archive/2006/02/22/tfs_size_estimation.aspx
  • Steve Lange @ Work

    Who's using Team System?

    • 0 Comments

    Grace Francisco consolidates the most notable adoption case studies into a blog post:

    http://blogs.msdn.com/graceworld/archive/2006/02/06/526267.aspx

  • Steve Lange @ Work

    Is Team System Right for You?

    • 1 Comments
    Find out:  http://blogs.msdn.com/slange/articles/527711.aspx
  • Steve Lange @ Work

    Big news from Borland

    • 0 Comments

    Borland announced this morning two big moves:

    • The acquisition of Segue Software
    • The divesting of their IDE product lines.

    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.

    http://www.borland.com/us/company/news/Tod_Nielsen_customer_shareholder_letter_02-08-06.html

    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).

     

  • Steve Lange @ Work

    Do I have to use requirements for my project?

    • 0 Comments

    (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.

    Requirements

    A requirement, defined by our friends at dictionary.com is:

    1. Something that is required; a necessity.
    2. Something obligatory; a prerequisite

    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.

    Tasks

    A task is defined as:

    1. A piece of work assigned or done as part of one's duties.
    2. A difficult or tedious undertaking.
    3. A function to be performed; an objective.

    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:

    FR 101:  The system shall provide a search mechanism.

    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:

    Scenario/Need Possible Solution
    Small team, most with multiple roles.  Fast, "crank-it-out" style of develoment, with customer-defined requirements. Requirements.  You may not care about how the customer's needs break down into units of work, and your team is small enough that everyone pretty much knows everyone else's load.
    Medium-sized team, with BA's, PM, and developers.  Quick-churning style, but requirements are more refined, and are managed independently of development effort. Requirements + Tasks.  If requirements are managed separately from development, and are refined "on the fly", breaking requirements down into development tasks will better provide the PM control over the work assignments of his/her team.
    Large-sized team, with BA team, possibly more than one PM, dev leads, and developers. Requirements + Tasks.  A team of substantial size needs to have measures behind different phases of software delivery, for load-balancing, productivity tracking, cost allocating, and often regulatory compliance.  The PM, or even the VP of App Dev, will need metrics to see how requirements are being translated into workload in the development phase.
    Small- to medium-sized team.  Little or no customer-focus ("grassroots" application). Either, not necessarily both.  You can use requirements as elements of work, and capture overall implementation, or use tasks to simply define the work to be done (the task itself will imply the requirement).

    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!

  • Steve Lange @ Work

    Group-based Permissions in Team Foundation Server

    • 1 Comments

    Two scenarios will be discussed in this post:  Single Hat and Multiple Hats.

     

     

    Base Scenario:

    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:

     

    Developer

    Tester

    Reviewer

    Project A

    Joe

    Sally

    Dave

    Project B

    Joe

    Sally

    Dave

    Project C

    Joe

    Sally

    Dave

     

    The simple setup for this in Team Foundation Server is to use generic role-based groups:

     

    Team Foundation Server

          \Developers

                \Joe

          \Testers

                \Sally

          \Reviewers

                \Dave

     

    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:

     

    Developer

    Tester

    Reviewer

    Project A

    Joe

    Sally

    Dave

    Project B

    Dave

    Joe

    Sally

    Project C

    Sally

    Dave

    Joe

     

     

    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:

     

    Team Foundation Server

          \Developers

                \Joe

                \Sally

                \Dave

          \Testers

                \Joe

                \Sally

                \Dave

          \Reviewers

                \Joe

                \Sally

                \Dave

     

    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:

     

    Team Foundation Server

          \Project A - Developers

                \Joe

          \Project A - Testers

                \Sally

          \Project A - Reviewers

                \Dave

          \Project B - Developers

                \Dave

          \Project B - Testers

                \Joe

          \Project B - Reviewers

                \Sally

          \Project C - Developers

                \Sally

          \Project C - Testers

                \Dave

          \ Project C - Reviewers

                \Joe

     

     

  • Steve Lange @ Work

    Integrating Project Server and Team System

    • 0 Comments
    There is a GotDotNet Workspace that is developing an integration between Project Server and TFS:  http://www.gotdotnet.com/workspaces/workspace.aspx?id=b9f69ea5-ace1-4a21-846f-6222a507cc9c
  • Steve Lange @ Work

    Team Foundation Server: Beta 3 Refresh vs. CTP

    • 2 Comments
    Which to use for evaluation?  Well it depends on you ultimately might use the evaluated TFS install as your production server.  Keep this important note in mind.  The Beta 3 Refresh version carries a go-live license, which means that Microsoft will provide a supported migration path to the RTM version of TFS.  The CTP version does NOT carry the same promise.
  • Steve Lange @ Work

    Web Interface to Team Foundation Server

    • 1 Comments
    Here's a promising one in the works:  http://www.devbiz.com/teamplain/default.aspx
  • Steve Lange @ Work

    Timestamps and the Team Foundation Server

    • 0 Comments

    I was recently asked about how date/time stamps are stored in the TFS.  The concern was centered around distributed development that crosses timezones.  If someone in the UK checks in a piece of code to a server in California, how will the stamp be preserved so that a California user knows precisely when the code was modified?

    Well, timestamps are stored in UTC (GMT).  The client (VS or command line, or whatever) converts the UTC time to local time for display.  This allows centrally-stored timestamps to be displayed in a manner most consistent with the requesting client's locale.
     
  • Steve Lange @ Work

    New scalability news regarding Team Foundation Server!

    • 0 Comments

    Gone are the days of the 500 user recommendation:

    http://blogs.msdn.com/bharry/archive/2005/12/09/502190.aspx

  • Steve Lange @ Work

    My first few days..

    • 0 Comments

    I now have a month under my belt at Microsoft as a Technical Specialist for Team System.  For those of you wondering about the substance behind the buzz of VSTS, believe me it's there.  Microsoft is taking a bold new step into the SDLC world with a new enterprise-level source control system, work item tracking & collaboration, and testing (Yes, there's now testing!).

    Stay tuned!

Page 14 of 14 (340 items) «1011121314