I used to really dislike Mercedes. I didn't care for the way they looked, and I thought they were, well, stupid. I swore I would never drive a Mercedes and I would ridicule them when I saw one on the road or in a parking lot or a driveway. But I was at a used car dealer looking at cars recently, and a Mercedes caught my eye. After taking it for a test drive I now have a Mercedes-Benz sitting in my garage. Somehow my distaste in Mercedes changed. I'm not sure what happened really, though I'm sure the low price and better gas mileage helped. And it is really fun to drive!
I also used to seriously detest writing documentation. I would think about what a useless waste of developer resources it was to have to write down how to perform the task it was I just performed. I would avoid it whenever possible. But as you may have guessed, something switched inside of me. I don't harbor the inner feeling of annoyance to documentation anymore. In fact, I rather enjoy it. Well, most of the time.
Lastly, and this is hard to admin (I'm bearing my soul here), but when the first version of .NET was released, I hated it. I was so appalled that Microsoft would go and change the very thing that gave me a paycheck. Sure, ASP.OLD and VB6 were a pain to work with, but the prospect of learning another seemingly brand new language was overwhelming and frightening. Of course, I don't think I need to go to great lengths to detail how this has changed. For starters, there is a possibility you may have gotten to this page through my second domain name: www.dotneticated.com. And I am. I speak at regional user groups and code camps, and I have even been called an unofficial .NET Evangelist by my peers. I now advocate that .NET is the greatest thing to happen to Windows since it got a GUI.
I don't know what causes these changes. Maybe it's because I'm getting older, maybe they are a result of certain experiences in my life, or maybe I'm just going a little goofy, which is the most likely conclusion. I mean, who wants to write documentation and drive a Benz? Write .NET certainly, but write documentation? Whatever the reason though, it is hard to deny that as we look around at our environment and ourselves, things are always changing. If they weren't, we might still be wearing diapers. And in the case of .NET, what a welcome change it turned out to be.
So it strikes me as somewhat odd now when I hear developers complain about how requirements for one project or another have changed. Why is it that we so readily accept the changes around us, the changes in our environment, yet when they occur in the course of software development we are astounded? If I had to hypothesize, I might guess that maybe it is just a facet of how the developer mind works. Or maybe it is because we deem ourselves as creative folks whose work is made perfect merely by virtue of its existence. Of course we are still getting paid to make the change, but that doesn't enter the equation. No, if I had to give a rational answer, I might say the problem lies in the notion that we now have to do more work, and that more than the work itself, in the arduous process we have to follow to do the actual work.
To me, the concept of process used to be as exciting as getting underwear for Christmas. Even worse, it felt like a giant, maniacal, overbearing monster whose sole purpose was to make my life as difficult, tedious, and boringly repetitive as possible. I could never understand why it had to take an hour to change a static copyright on the bottom of an HTML page. And yet, the very thing I used to despise most about software development is now the very thing I find myself advocating for.
This change took place a little while ago when I studied for, and subsequently passed the IBM 839 test and became an "IBM Certified Solution Designer - IBM Rational Unified Process V7.0" (ICSD RUP7), which is way too long of a title. I like to call it my ICSOO certification (IBM Certified Something Or Other). But what I discovered is that I don't hate process, I hate bad process. In fact, I found that I regularly use and subsequently appreciate good process. Let me emphasize that, I appreciate GOOD process. While I was studying for the RUP exam, I found myself realizing two similar, yet distinct concepts:
- A good, well planned process is beneficial to an organization beyond the scope of micromanagement.
- A good process can actually improve a developer's performance, quality, and job satisfaction.
Through my continuing study into process and process frameworks, one concept keep coming back to me – a unified tool for process enablement. Part of any good process is the right tools to enable the process, and what I've found is that Team Foundation Server is just that tool; an integrated, flexible and easy-to-use Application Lifecycle Management (ALM) platform. Team Foundation Server is what I like to call process agnostic, a process enabler, and a process integrator.
Process Agnostic
While many tools force users to conform to a set, out-of-the-box SDLC, Team Foundation Server is based on the Microsoft Solutions Framework (MSF), which is a "defined set of principles, models, disciplines, concepts, guidelines, and proven practices from Microsoft"1. Out-of-the-box, Team Foundation Server comes with two MSF process templates: Agile and CMMI, which provide process frameworks for both high-ceremony and low-ceremony environments.
These are only meant to be templates, however. Through the free Team Foundation Server Power Tools add-in from Microsoft it is possible to modify an existing process or even create your own from scratch. No longer is one required to use tools which enforce an arbitrary process the manufacturer thought was a good idea. The Process Editor tool allows you to define default users and groups, areas and iterations, source control properties, and even work item workflows and forms for your process template. By creating your own process template, you can also ensure that business and project management knowledge is not lost when the next project comes around.
Process Enabler
For many companies, their processes leave a lot to be desired. While they may have a process, those processes often leave out important facets of the development lifecycle, such as document management, use cases, and appropriate testing. For instance, how many times has a project gone awry because of discrepancies and subsequent mis-development due to a lack of versioning of the requirements documents? To help alleviate this problem, Team Foundation Server has strong integration with Microsoft Windows SharePoint Services, and consequently Microsoft Office Word, thereby providing document storage, management, and versioning capabilities. Process templates contain work items specifically for creating and tracking use cases and scenarios to aid in the understanding and design of an application or system. And the Team Suite products contain strong testing capabilities.
Working remotely, whether working at home one day a week or as part of a distributed or outsourced project team, can be more challenging due to domain, bandwidth, communication limitations, and other restrictions. To support communication and productivity for distributed teams, Team Foundation Version Control supports HTTP communication, and Team Foundation Server includes a caching proxy, which caches file content at the remote location, and is optimized for high-latency, low-bandwidth, and cross-domain environments. Team communication is enhanced through work item tracking, Visual Studio Team System Web Access, and the project's SharePoint portal.
Process Integrator
By and large, most processes use a whole host of disparate and disconnected tools which invariably leads to a loss of performance for the project team. These include tools for documentation, defect and enhancement tracking, source control, and the development environment itself. Team Foundation Server was built to integrate the various aspects of the SDLC under one platform, including project management, stakeholder management, testing, architecture, software and database development, auditing, build management and deployment. By doing so, some of the most costly aspects of process and change management are removed.
Through a project's SharePoint portal, Team Explorer, and the newly released Visual Studio Team System Web Access, project and product managers, stakeholders, business analysts, auditors, and other members of the project team can view and add work items, download, upload, check-in and check-out documents from the project's SharePoint portal, view reports, view change sets, differences, and histories, and even start and stop builds. There are also utilities to support synchronization with project server and creating work item from Microsoft Office Outlook, and reports for auditing purposes can be created.
In the Visual Studio Team Suite 2008 Architecture Edition, project management, architects, business analysts and subject matter experts can model the logical datacenter, applications (including SOA) and application systems, the settings and constraints on those applications, and finally how those systems deploy into the logical datacenter. A Visual Studio solution stub can then be implemented which is infused with that knowledge via process guidance and solution policies. If you are developing multiple applications, custom prototypes can be saved to expedite the creation of future distributed systems.
The Visual Studio Team System 2008 Development Edition provides a plethora of resources for the application developer. An integrated environment means a developer doesn't have to leave the environment in order to view and update work items, check-in or check-out code, or perform tests, static code analysis, run code metrics, or test application performance. In addition, a feature called shelving lets you store work-in-progress that is checked out on the server without affecting the existing checked-in code, and makes it available to other developers for code reviews and testing.
In the Visual Studio Team Suite 2008 Tester Edition, testers can author, execute, and manage tests and related work items – all from within Visual Studio. Testers can create unit tests, web tests, performance and load tests, test lists, and even evaluate code coverage. During the development process, developers can create unit tests, which can then be integrated into a testers test portfolio.
I have only covered a few of the many integration features built into Team Foundation Server and Visual Studio Team Suite. For more in depth coverage, check out the Visual Studio 2008 Product Comparison and Visual Studio Team System 2008 Team Foundation Server on the Microsoft Web site.
Conclusion
For any organization who is stuck in the mire of a bad process, there is much to be excited about with Team Foundation Server and Visual Studio Team Suite. Change is almost never easy, and process can be a real project killer if it is not designed correctly. Now with Team Foundation Server you can create the right level of process for change and development, as well as integrate and streamline that process across your entire organization. Change happens, be ready.
Additional Information
- The Visual Studio Team System includes many new and enhanced features, which are summarized in this topic.
- Team Foundation is a set of tools and technologies that enable a team to collaborate and coordinate their efforts on building a product or completing a project. Team Foundation enhances team communication, tracks work status, supports team roles, enacts the team process, and integrates team tools.
- Visual Studio 2005 Team System is a platform for productive, integrated, and extensible software development life-cycle tools that helps software teams by improving communication and collaboration throughout the software development process.
1
http://www.microsoft.com/technet/solutionaccelerators/msf/default.mspx