Consider the real productivity gains you can achieve with the upcoming Team System version of Visual Studio 2005.
Everybody talks about collaborative development tools, and heaven knows you can't surf the major developers' for 10 minutes without getting hit by banners trumpeting the latest. We can't fault Microsoft for wanting a piece of that action; but we need more than just a collaborative environment. For most IT shops, collaborative development is something in the future, something not yet being done. What is needed is a collaborative solution that:
- is tightly integrated with tools already in use
- is highly intuitive, and
- offers a new development methodology that doesn't represent abandonment of every process already in place.
Visual Studio Team System is Microsoft's response. The concept is very articulately defined, the up-side being that it will provide all the structure a team might require, all the tracking tools needed to manage the effort, and tools for every collaborative purpose. The downside is that Microsoft is once again going several steps too far in deciding how we should do things. Will it work for your team? It's well worth a look. For myself, I'm hoping it gets a serious audition in my current assignment, since the collaborative tools in place at the moment aren't getting the job done by a long shot.
The concepts driving Team System need some fairly elaborate exposition in and of themselves, and aren't undertaken here: instead, here's an overview of noteworthy features -- some, new and innovative, and some expected but improved -- to stir your thinking on Team System as a possible direction for your shop.
1. Architectural diagrams
IT developers (and managers, and executives), write this word on your foreheads: ARCHITECTURE. The single biggest missing link in IT development today, platform aside, is the lack of proper architectural thinking in application development. This is why the world makes jokes about us involving woodpeckers.
There are far, far too many nuts-and-bolts geniuses out there who can rewrite DaVinci's Codex in T-SQL, but who think two-dimensional client-server architecture is good enough for Internet apps. To build decent apps today, and Internet apps in particular, you need more than an idea, more than good tools, more than an application-level design; you need an application architecture, a high-level framework that carefully addresses your applications' intended functionality within the context of your hardware, network, and data-source infrastructure -- and, worse yet, too many IT managers who know the buzzwords but don't yet really understand this. Too many IT development teams crash and burn, becoming full-time firefighters, because increasing user traffic chokes their database access to nothing, and because their apps simply can't be modified and enhanced within timeframes acceptable to their users.
Team System is addressing this shortfall in its Team Edition for Software Architects with a tool called Application Designer, a graphical workhorse for solution architecture. It enables users to create diagrams of application system solutions including many components of different types (i.e., apps, Web services, interfaces) and generate skeletal code in your language of choice (note that the Team Edition for Software Developers gives you the diagramming capability but not the code-generating capability). The diagram defines the connections between diagram components and allows you to constrain them as needed.
The idea (and it's a good one) is to address the different developmental needs of the architect, as opposed to the needs of managers and developers. The architect's toolkit gets more here than it is usually given, built on the VS/TS concept of "distributed application diagrams." This kit strives to capture all of the process, not just the workflow and coding, and includes architectural diagramming tools for System diagrams, Application diagrams, Deployment diagrams and Logical Datacenter diagrams (more on this last one below).
2. Leveraging the Microsoft Solutions Framework 4.0
The Microsoft Solutions Framework 4.0 (MSF) describes methodologies by which application development can be planned and implemented according to best practices. Version 4.0 is implemented in Team System, and provides you with two ready-to-go system development life cycle (SDLC) models, one for agile development and one for process improvement.
The implementations of these methodologies, Microsoft hastens to point out, are prescriptive; that is, they are not simply generalised methodologies implemented for the sake of giving you general pointers, but are instance-specific, giving your team specific action guidance based on the particulars of the application you are implementing.
Created very much with team activity in mind, MSF 4.0 provides a meta-model mechanism for detailed methodology development and implementation, put into practice by an advocacy group (fancy term for team + interested parties). Such an ambitious jump can't be perfect, and we don't expect it to be, but it's a step in the right direction, especially for an IDE software solutions provider that is notably non-agile.
3. Team role definitions and constraints
The MSF implementation invokes a Team Model that assigns all project participants a role, or combination of roles, upon which a project participant's tasking, privileges, responsibilities and constraints are based. In Team System, these roles include Project Manager, Architect, Developer, Tester, and the optional roles of Release Manager and Business Analyst.
Perhaps the single biggest consequence of a team member's role as defined in Team System is the edition of Team System they will use, which by definition constrains what they physically can and cannot do within a project or development effort. Other consequences of role include project permissions (which also enable and constrain) and advocacy assignment.
4. Project/Excel integration
Not long ago, I tried to argue a project manager into giving Microsoft Project a try. "Show me something Project can do," he replied, "that Excel can't." My response, which was not at all brief, will wait for another day -- because, whether you're a Project manager or an Excel manager, Team System will accommodate you.
The Team Foundation Server communicates directly with Microsoft Project and Excel. Managed add-ins let you launch Excel or Project from Visual Studio 2005 Team Explorer, and pass work item lists between them and the Team Foundation Server. This hand-off occurs within the context of an open project, and allows a manager to pull work item lists from the project and handle them off-line as a matter of convenience, as a spreadsheet or a project plan. (Note that in the case of Project, you need Project 2003 Pro Edition.)
5. Application designer
I've spent lots of time with BizTalk Server 2004 and its orchestration designer, and I'm sure many have spent hours with Visio, scooting shapes around and connecting them as if doodling on a conference room whiteboard. Team System's Application Designer takes it up a notch, with the ability to integrate Windows forms apps, Web services, BizTalk orchestrations (if they're deployed as Web services), databases, ASP.NET Web services and apps, external Web services, and generate code to implement the integration. Designs can be saved and are source-controlled.
1%
2%
It's too bad that after looking at this article and Microsoft's webpage for the product for a good ten minutes I still can't figure out what this product is or what it does for me.
Why are products like this always described in the vaguest possible terms?