New Team System Stuff - 2004-09-08
I meant to include this in yesterday's post, but it slipped through the cracks. Information Week published an article on Monday that discusses development tool support for outsourcing, which mentions Visual Studio Team System (along with a few other tool offerings).
InformationWeek > Offshore Outsourcing > Global Reach > September 6, 2004
Next year, Microsoft plans to include in its Visual Studio 2005 Team System suite of programming tools a new version-control system better suited to teams of distributed workers. Microsoft's current version-control tool, Visual SourceSafe, works only on the LAN where it's installed, which means developers need to be in the same or neighboring buildings to share it. Team System will replace SourceSafe with a version-control system that can be accessed via a browser and used by an internationally distributed team, Microsoft general manager Rick LaPlante says. SourceSafe "was designed for a different era," he says, adding that Microsoft's own developers don't even use it. Team System will include a shared code repository and distributed bug-tracking and -fixing functionality.
Andrew MacNeill had a couple of blog posts this week that address software project management and Team System:
Andrew MacNeill - AKSEL Solutions: Software Project Management: Work Item Database
I, for one, wish that SourceGear would offer more in the way of their collab edition. It sounds like VS Team Edition is going to be way out of the market for many development teams.
UPDATE - I should note that I disagree with Andrew on this. I don't think Team System is going to be "way out of the market for many development teams." For very small teams, say less than 3 - 4 people working on a single project, it might be a bit much. However, organizational complexity (with increasing complexity of communication, metrics, source control, etc.) occurs when you add more people and projects. That's where Team System comes in.
MSDN recently pointed to an article on the approach being taken in the Team system to software project management. What I found to be the best "take away" from this was "Getting crucial metrics about the project is important to track status, and to make decisions."
One of our resident agile gurus, David Anderson, has this post on feature-driven development:
In Feature Driven Development, we use code reviews as a method of quality assurance and team learning. Feature Teams form under a Chief Programmer to develop a batch of Features in a Chief Programmer Work Package. The purpose of batching is to absorb the overhead - what Paul Szego termed "administrivia" - in a Feature.
And this post about Peter Drucker's thoughts on adaptive process vs. plan-driven process from 1985 and their significance to agile software development:
Drucker on Adaptive vs. Plan-Driven
I'd didn't get through my posts on the work of Peter Drucker in August. I simply ran out of energy and fell off the blogcycle. So Drucker month runs over into September. Hey, we're adaptive at agilemanagement.net ;-)