|
|
-
-
There are many types of individuals who will perform the oh so glamorous role of team foundation administrator. Who are these individuals who seek such fame and fortune? What are their primary issues and concerns? For team foundation, I have defined three administrator types. Are you one of these people? Do these descriptions ring true to you? What am I missing? -Brian • ToolSmith (part-time, part of a software development team) – Examples: Visual Source Safe, ClearCase Administrator – Responsibilities: Build mgmt, Integration Mgmt, Informal tool support – Concerns: migration support (tools to convert data, SCM process/terminology mapping, training users) – Want: easy deployment, low administrative overhead – Knowledge: no IIS/SQL knowledge, deep application knowledge • Group/Department IT (full-time, part of a software development organization) – Examples: Lab administrators, tools groups, ClearQuest Administrators – Responsibilities: Maintaining hardware and software systems that support a software development team, formal tools support, internal helpdesk – Concerns: Server sizing, performance, security model (typically do not have control over the network, domain users/groups, e-mail, internet infrastructure), backup and restore – Want: low administrative overhead, good performance, control of security independent of corporate IT – Knowledge: basic IIS/SQL knowledge, basic application knowledge • Enterprise/Datacenter IT (full-time, part of a corporate IT organization) – Examples: Corporate IT – Responsibilities: Maintaining corporate infrastructure, e-mail, network, user accounts – Concerns: Reliability, availability, performance – Want: Conformance to existing disaster recovery procedures, conformance to security and software requirements, support for sophisticated deployments (e.g. high availability) – Knowledge: deep IIS/SQL knowledge, limited application knowledge
|
-
-
I’m going to let the discussions drive my direction for this post. In here I cover Team Foundation Deployment Topologies. Again, I’m interested in your early feedback to help validate our assumptions. The primary team system server is the Team Foundation Server (TFS) which delivers version control, work item tracking, team build, team project web site, reporting, and project management capabilities. A logical TFS is made up of two components an application server (made up of web services) and a database server (made up primarily SQL Server 2005 databases). The application server and database server can be deployed on one machine or two machines (note: this is not true of the existing December CTP which requires a two machine deployment). In the two machine configuration, one machine is said to be the application tier the other the data tier. In either case, the machine(s) should be dedicated to team foundation server functionality. That is, they do not serve any other purpose such as mail servers, file servers, or database servers for other applications. The Team Foundation Server will ship with a version of SQL Server 2005 Standard in-the-box. SQL Server 2005 is a pre-requisite to installing the team foundation data-tier. Larger enterprises may have investments in other editions of SQL Server 2005 such as Enterprise, DataCenter, or 64-bit editions. Customers may install a single instance of TFS using these editions of SQL Server 2005. The only constraint on V1 will be that TFS installs into the default instance of SQL Server with default database names. We believe most folks can live with this limitation. Team foundation servers will operate properly on a Virtual PC or Virtual Server. This configuration is not recommended for production environments, but will be primarily used in testing, evaluation, or demonstration scenarios. Unsupported Deployment Topologies • NLDB clustering for the application tier • Splitting application tier web services across separate machines • Multiple TFS instances on the same physical machine • Storing individual TF databases on separate database machines Next post - Authentication and Authorization Model This posting is provided "AS IS" with no warranties, and confers no rights.
|
-
This is a continuation of my post Using Blogs to Drive Product Direction and is an experiment in getting customer feedback on product decisions through blogs. I’d like you to keep two things in mind. 1) Anything I post here is likely to change before we ship. 2) Please provide some context for your feedback, the reason why you, your clients, and/or your company feel a change is important. In this post, we will deal with Visual Studio Team System Operating System Requirements. I am assuming you are already familiar with Visual Studio Team System, if not start here. Client Side Visual Studio Team System Clients will run on the following operating systems and require the following service packs: Windows 2000 (SP4 or greater) Windows XP Home (SP2 or greater) Windows XP Professional (SP2 or greater) Windows Server 2003 (RTM or greater) Windows Server 2003 64-bit (SP1 or greater) (WOW mode only) Windows XP 64 bit (Second Release, no code name yet) (WOW mode only) VSTS clients will not be support on Windows 95, Windows NT 4.0, Windows 98, Windows 98 SE, or Windows ME. Server Side The Team Foundation Server may only be installed on a Windows 2003 operating system. The following table outlines our POR for operating system support. Note: Dates on future releases of Win2k3 are outside my project’s immediate control, more information can be found here. | Versions\Flavors | WebEdition | Standard | Enterprise | Datacenter | 64-bit Std | 64-bit Ent | 64-bit DC | | Current RTM | no | yes | Yes | yes | n/a | yes | yes | | SP1 (March 2005) | no | yes | Yes | yes | n/a | n/a | n/a | | 64-bit (1st half 2005) | n/a | n/a | n/a | n/a | Yes | yes | yes | | R2 (end of 2005) | no | yes | Yes | yes | Yes | yes | yes | This posting is provided "AS IS" with no warranties, and confers no rights.
|
-
Part of the job of a program manager is to make the tough calls balancing features, time-to-market, and available resources. Blogging seems to offer the potential for gathering near real-time feedback on trade-offs without conduct a survey, producing a prototype, sending e-mail, or traveling. However, getting feedback through a blog would seem to require two critical things. First, a willingness to share early information and to address the inevitable changes post-blog. Second, your blog needs a readership that is representative of the customer you are targeting otherwise how do you screen the feedback. This seems to be the most challenging hurdle in trying to use blogs to help drive product decisions. Be that as it may, I will be posting several blogs over the coming weeks that outline the plan of record for Visual Studio Team System deployment requirements. My desire is for you to send me feedback on these requirements before they can’t be changed :-). I’m just as interested in things we could cut as well as add. To address issue #1, I ask your patience and understanding of the fact that what I post today will not be what we ultimately deliver. To address issue #2, I would ask you give me some background on your company and the reason why any changes you are requesting is important to you, your clients, or your company.
|
-
Last week I presented at Visual Studio Connections in rainy Las Vegas (Yes, rainy. Sadly, yet not surprising I can also report moderate losses). Several of you asked me for copies of these presentations and thanks to the help of Rob Caron you'll find the presentations (below) downloadable here. - VMS352 - Visual Studio 2005 Team System: Software Project Management
In this session you will learn how to take advantage of the combined power of Visual Studio, the Microsoft Office System, and industry proven practices to successfully manage software projects—from conception to deployment.
- VMS355 - Visual Studio 2005 Team System: Enterprise Class Source Control & Work Item Tracking
This session introduces the new Team Foundation Server in Visual Studio 2005, including the new Source Code Control, Work Item Tracking and Team Portal. See how an integrated and extensible server-based system will boost your team’s productivity by significantly streamlining your development processes.
|
-
The Visual Studio Connections conference is being held next week in Las Vegas, NV. There will be overviews and demos of the latest Visual Studio Team Foundation capabilities and other Visual Studio Team System capabilites next. You can find me presenting on: Monday, November 8 10:45-11:45am VMS352: Visual Studio 2005 Team System: Software Project Management 4:15-5:15pm VMS355: Visual Studio 2005 Team System: Enterprise Class Source Control and Work Item Tracking You can also also see a complete overview of Visual Studio Team System given by Kevin Kelly 9:30am-10:30am VMS351: Managing the Software Lifecycle with Visual Studio 2005 Team System If you're there look me up, particularly if you've tried out the Visual Studio 2005 Beta 1 Refresh and have feedback.
|
-
Visual Studio Team System is extensible. For work item tracking that means you have the ability to define your own work item types. One person’s bug is another person’s defect, requirement, feature, risk, issue, change request, or task. In doing the design, we decided to first be capable of defining work item types in XML and then using that XML definition to instantiate a work item type in the team system database.
The design goals of the work item type definition language (WITD) were:
· Extensible - to accommodate future functionality
· Simple – the basic language should be simple to understand and produce
· Human readable – users should be able to type in simple WITDs and have them work without having to resort to specific design tools
And, of course, the fact that the information can be stored in an XML file makes the WITD shareable and versionable as well.
So, what are the core elements that make up a work item type?
First you need to identify the work item type from others. This leads to the obvious name and description:
<WORKITEMTYPE name=’bug’>
<DESCRIPTION>Bug work item types are used to track software defects.</DESCRIPTION>
Secondly, you need to define what kinds of data you want to collect. This is done by specifying a set of fields.
<FIELDS>
<FIELD refname=”System.Title” name=”Title” type=”String” >
</FIELDS>
Thirdly, you need to define the workflow. That is, the states and legal transitions between those states. This example shows the simplest state transition model we support one state, one way in, with one reason for being.
<WORKFLOW>
<STATES>
<STATE value=”EXISTS” />
</STATES>
<TRANSITIONS>
<TRANSITION from=”” to=”EXISTS” />
<REASONS>
<DEFAULTREASON value=”New”>
</REASONS>
</TRANSITIONS>
</WORKFLOW>
And finally, you need to define how this information is presented to the user. This is done in the form layout section of the WIT definition language.
<FORM>
</FORM>
</WORKITEMTYPE>
And that is about it. You may wonder, how do I define the business or rules of behavior for a work item type. These are also defined in the work item type definition language as rules associated with fields and scoped by state and transition. But I will leave that for another post.
As always, thoughts, comments, concerns, and especially improvement ideas are very welcome.
|
-
Korby Parnell blogs that the checkin/checkout paradigm is broken here.
“In the same way, I think that changing checkout to edit would lead us to reevaluate CHECKIN. Together, checkin and checkout are a dynamic and self-documenting duo. They are the cornerstones of a library metaphor that has helped countless users, including me, understand source control, albeit partially and incorrectly. And that, my friends, is just it. The library metaphor is Broken with a capital 'B'.”
While I don’t believe the checkout/checkin model is broken, I do believe it is incredibly antiquated. You can see the winds of change in development environments like Visual Studio where as a developer you can simply start working on a source file and it is automatically checked out for you. So long and good riddance to checkout.
Assuming the model in the future is silent checkout, this leaves two operations up for grabs. In my opinion, we should replace checkout and checkin with the following operations:
1) Submit Change
2) Checkpoint Change
The key thing a developer does when they are done is to follow some work submission process. Typically the goal is to somehow get their changes into the team’s nightly build. For most solutions today this is a multi-step and multi-tool process. Checkin the changes, send some e-mail, resolve some bugs, update a plan, etc. It would be G-R-E-A-T if integrated source code control and work item tracking would make this one unified gesture “Submit”. The need to individually checkin files is in my opinion an edge condition. Typically, I am checking in one change which is comprised of edits to multiple files. In fact, forgetting to checkin one file from a set is probably on the top 10 list of reasons you broke the build.
The second operation perhaps is optional, but I think it is a needed and often overlooked feature that should be delivered by the source code control system. Imagine my work has reached some stable point, but it is not yet done. I’m about to try a radical change to an algorithm and I want a way back. I want to keep a snapshot of the versions I have right now, but I don’t want it to go into the team’s nightly build. Often, SCM tools or the way SCM tools are used require developers to work around the system like copy backup files locally. That is because, if they checkin, the changes will be immediately exposed to the team even though they are not ready.
So out with checkout and checkin and in with submit and checkpoint.
|
-
The day I loose my linguistic nimbility will be the day I leave the software industry. You might ask what is linguistic nimbility? or LN for short. Well, linguistic nimbility consists off two skills. First, is the ability to determining the meaning of something given a short series of capital letters. Second, is the ability to understand what someone is referring two when the name for the thing has changed 3 or 4 times over the last 6 months.
After working in any industry for quite a while you start to notice certain peculiarities. A peculiarity in the software industry is the extensive use of acronyms and code names resulting in the need for LN.
First let’s look at the acronym talent. We in the software industry use acronyms because we are too lazy to type the same descriptive words over and over. Since much of our communication is through the written word, one can see the argument for the use of code letters to assist us. For example, the project I am working on right now is Visual Studio Team System (quite a mouthful). This shows up time and again in specs and e-mail as VSTS. There is also Visual Studio Team Foundation (VSTF) and Team Foundation Core Services (TFCS). Suppose I said “TFCS is part of the VSTF which is made up of the TFC and TFS. TFC is the client side of TFS and is included in all VSTS clients”. Now, if you have LN then you will be able to tell me what TFC and TFS stand for. Can you?
Another thing worth noting about acronyms is there are two types. Those you can pronounce and those you can’t. Thankfully (for me) VSTF is not one of the prononceable kinds. The curse of software acronyms are those that can be pronounced. These drift across from lazy writing and into the vernacular and the original meaning is soon lost. One of my favorites is ‘misskee’. Misskee is used often in the Windows SCM (software configuration management) arena when discussing Microsoft’s source code control interface. Ok, if you’re linguistically nimble you have now astutely determined that misskee is MSCCI.
The second peculiarity that leads to a need for LN is the code name problem. Everything in software has to have a code name. Why is that, you might ask? The reason is that no-one is allowed to name a software product or component except for marketing. And marketing is not willing (and rightfully so) to name a software product until the very last minute before it comes out. So, software teams come up with code names to refer to the product or feature they are working on.
This leads me to the real problem with code names. Software teams want cool code names. I mean hip and groovy ones that they can show off on T-shirts. They also like to pick names of things that there are a lot of and that everyone knows about so they can start a trend and not run out. For example, mountains, rivers, streets, parks, and yes even beers. I’m still waiting to work on the project that uses Tequila code names. I really want to say “I’m working on the Cuervo project”. Code names are never picked that could be misconstrued, whose reputation could be soured during the life of the project, or would make the team look silly. For example, you don’t find software code names like Mickey, Donald, Goofy, Clinton, JLo, BackStreetBoys, Dumass, Barney, or The Wiggles.
Visual Studio Team System used to have the code name Burton (before marketing picked VSTS). This may seem pretty dull unless you are in the ‘NO’. Burton is a major line of snowboarding gear and that means hip, groovy, cool, and r-a-d rad. The project I’m working directly on is called Currituck. This kind of code name should really be banned all together. I’d tell you what it was named after, but then you could guess all our other code names and I’d have to kill you.
This leads me to the other problem with code names that requires the up-most of linguistic nimbility and that is code name churn. Code names change and sometimes frequently. This can happen due to re-orgs, new management, or just because an old code name has gone out of style. When this happens you find old presentations and specs using old code names or even mixed code names if someone updates only part of a spec. There are confusing transition periods where new code names are being picked up while old code names are being used. You also find that things like web site URLs and e-mail aliases take on a retro flair as they are often left untouched as code names change leading people to wonder why these alias/sites have such weird acronyms. My favorite right now is a sub-project of Burton which delivers a set of core services to the whole of VSTS. These were originally called FlexCore. Rumor has it that this is a certain technology that makes up the center of Burton snowboards (clever eh?). This changed to BIS at some point. Right, Burton Integration Services. Later this moved to TFCS or team foundation core services.
So, this leads me back to my original point, if you find yourself unable to navigate the whitewater of acronyms, have trouble maintaining two or three names for the same thing in your head, or just can’t think up a cool and groovy name for your next software project, maybe you have lost your linguistic nimbility. Maybe it is time for your second career. Just don’t pick something in defense or aerospace.
|
-
The software industries ability to produce acronyms and talk in jargon may only be matched by the military. One of our other abilities is using the same word to mean hundreds of different things. My favorites are object and project, closely followed by component. However, today, I am thinking about the word “workflow”.
The Merriam-Webster’s Online Dictionary doesn’t contain this word. It instead suggests that I was looking for the word “workfolk” defined as “working people, especially farm workers”. You have to admit that this is funny (or perhaps you had to be there). So, if workfolk are following a process are they doing workflow? I turned to the Oxford English Dictionary and I quote “The definitive record of the English language” with no luck. This clearly illustrates my previous point that software developers do not speak English.
In desperation I turned to our trusted companion Google and got 3,000,000 hits. Top on the list was “Need a Workflow system? www.savvion.com Use our enterprise-class solution for workgroup to enterprise process”. This proved to be an interesting site if you are looking for a business process modeling tool. However, our friend Google along with the 3,000,000 hits also had a link to “definition” right at the top. Aren’t those guys great? This link takes me to dictionary.com (obviously not the definitive record) with this definition:
Workflow
- The flow or progress of work done by a company, industry, department, or person.
- The rate at which such flow or progress takes place.
Ok, now we’re getting somewhere. In my opinion, workflow for software development is about defining the processes by which individuals on a software team accomplish a larger goal and then being able to instantiate process tasks in a way that people can use them to determine what work need to do, when it needs to be done, and indicate progress which can then be tracked. Workflow as opposed to managing a todo list is aso focused on the interrelationships between tasks and the automated generation of tasks to drive a defined process. Most workflow tools on the market have failed to be wildly successful primarily because they were not tightly integrated into the everyday tasks of the people who were doing the actual work. Process in my mind should disappear into the tools you are using to get a job done.
The Visual Studio Team Foundation will include a work item tracking component (there is that word again). You may hear that it supports workflow and even I am guilty of using tags like <WORKFLOW>… </WORKFLOW> in the work item type definition language to describes the state transition diagram for work items. In reality, however, we are introducing in VSTF only the basic elements that will later enable true workflow support. These are work item types which define the work performed by an individual. Each work item type has a state transition diagram composed of states and legal transitions that drive the process for that specific work item. More on states and transitions later...
If you’re wondering about the term “work item”, visit my colleague Kevin Kelly.
|
-
I’ve been in the software tools industry for the majority of my career. It has been utterly amazing to me to see the rise of the importance of software development tools. In fact, when people ask me what I do, I say “software tools for software developers”. Typically this stops the conversation right there.
The interesting thing is that in all those years, the capabilities offered by the tools have been only marginally improving. Take SCCS to RCS to CVS. These are great examples of freeware version control advances, but not break-through innovation. Most software applications today require several if not hundreds of individuals to pull off. We are also seeing increases in geographically distributed teams, from broadband access at Starbucks to major outsourcing initiatives with a global reach. All of these things have greatly increased the importance of tools to help software teams collaborate and be more productive.
There are only a few advanced software lifecycle tool sets on the market today, yet none have been architected and built from the ground up. I feel incredibly lucky to have become deeply involved in what is now publicly called the Visual Studio Team System. In particular, my focus is on the Visual Studio Team Foundation. The Team Foundation is a server product with client-side functionality that is designed to support all roles on a software development team. The Team Foundation includes source code control, work item tracking, metrics and reporting, MS project and Excel integrations, and a rich integration infrastructure that delivers such services as artifact linking, events and notification, authorization, and tool configuration.
It is rare when you have the chance to do something that has a positive impact on millions of individuals on software teams. As Brian Harry said in his first ever blog post, we won't get everything done in V1. However, we are committed to improving and innovating as we move forward. I’m looking forward to those of you who would be so bold as to help me and our team shape the direction of the Visual Studio Team Foundation through this new medium of the blog.
-Brian
|
-
What an exciting day! Head to Visual Studio Team System for more information on the announcement at TechEd today. Microsoft will be releasing an extensible set of software development life-cycle tools that help software teams collaborate to reduce the complexity of delivering modern service-oriented solutions. This solution includes brand new source code control and work item tracking components.
If you are attending TechEd and interested in work item tracking, defect tracking, bug tracking, requirements management, or software project management, try the following sessions:
Tuesday 10:45am DEV200 An in-depth demo of the entire Visual Studio Team System
Tuesday 1:30pm DEV300 A drill down on the project management aspects of VSTS
Thursday 3:15pm DEV303 A drill down on source code control and work item tracking
I myself will be presenting a cabana session on extensibility and customization of the work item tracking component on Thursday 5-6:15pm DEVC39. I’ll also be available at the Visual Studio booth in the pavilion. If not me, you might try to find Kevin Kelly another program manager or Amit Ghosh who is one of the developers working on the work item tracking component.
You may be asking yourself, why is Microsoft developing a bug tracking solution? Aren’t there enough of these out there already? The answer is yes and no. Yes, there are several bug tracking tools out there, but if you think too narrowly about just bug tracking you’re missing the point. The intention is to deliver an extensible infrastructure that can be configured and extended to support all work item types that are important to software teams. These could be tasks, features, requirements, scenarios, bugs, etc. The second difference is we want to support deep integrations with other aspects of the software development lifecycle like source code control and project management without (and this is key) compromising ease-of-use .
More soon on what makes up a Visual Studio Team System work item type…
|
-
Software development continues to increase in complexity with results being of higher quality and produced in less time. It is a recipe for disfunctional teams and stressed out individuals. To establish successful track records software teams turn to various means of define the work that needs to be done and track its progress. There are a significant number of similarities between the management disciplines involved and I would argue that a common infrastructure to support these disciplines is key to taking the next steps in software process automation and software team collaboration.
The “management“ disciplines I'm referring to are: requirements management, bug and defect tracking, project management, risk and issue tracking. I'm going to take some broad brushes here so bear with me. Requirements management focuses on defining the “what”. What are we trying to build? Bug tracking focuses on identifying and resolving the things in the current “what” which deviate from the defined “what”. Project management focuses on the “how“. What is the work required to achieve the “what” and emphasizes who is doing that work, what is the ordering of that work, and when will it be done. Risk and issue tracking focuses on reducing project risk by identifying risks and issues and tracking the work needed to reduce or eliminate these risks and issues.
What do these things have in common? First, they are all lists that software development teams want to keep track of. What will the system do? How high a priority is feature A? Don't forget to fix bug 20303! Hey Joey did you finish implementing that performance improvement yet? Items in the list have a name or identity, they typically have someone assigned to them, they have state (e.g. Active, Complete, Deferred), and they have relationships between them and in fact interdependencies. For example, a high-level requirement such as “The system must support e-mail notification” may produce bunch of lower level features such as “Implement Notification API”, “Add e-mail event listner”, and “E-mail template deisgner”. To implement these features, developers get assigned tasks (coding work) and testers get assigned tasks (test case development and execution). All this work is tracked by the project manager as tasks with a result being as schedule for delivery of the “what“. As testers start testing, bugs or defects are found and identified. This produces additional work to be done along the way.
It is all a web of work trying to produce the right what.
With the state of practice today, I believe there are significant gaps between the team member tooling causing inefficiencies in communication and collaboration. Each member of the team uses different, but poorly integrated tools to get their particular job done. The analysts defining the what, the project managers defining the plan, and developers and testers who attempt to build the what by following the how. The difficulty is for a developer or tester in the trenches is to determine what a project's real requirements are and for a project leader to keep a schedule up to date with what is really happening on a project. Both of these are key symptoms of these gaps.
I would assert that a common infrastructure that delivers a way to manage lists of items and their interelationships and yet supports the unique needs of each member on the team will signficiantly improving communication, support more sophisticated automation, and generally help teams achieve their goals more efficiently.
I'm keenly intersted in what people are doing to address these problems on their own teams. I'll be at Tech Ed next week so feel free to drop me an e-mail and we'll find time to chat. You can find me in the TechEd RIO system at http://rio.crgevents.com/TechEd2004/Rio/
+++++++++++++++++++++++++++++++++++++
This posting is provided "AS IS" with no warranties, and confers no rights.
|
|
|
|
