Are you a TFS user or interested in using this product? In the past, it was necessary to install TFS onto a central server or virtual machine before using it. No more. Now, Team Foundation Services allows you to access a TFS server hosted by Microsoft.

The service is free for small teams (<5 people) while it is in Preview, but I have not seen any future pricing announcements.

Get started by navigating to visualstudio.com and signing up for an account. Note the URL, up to ".visualstudio.com". This is the server name. You will need this to integrate with Visual Studio solutions. In my case, it is "https://giard.visualstudio.com".

At the home page, click the [New Team Project] button (Fig. 1)

The "Create Team Project" dialog displays (Fig. 2). Enter a project name and description;

Next, select a Process template. The choices are:

Microsoft Visual Studio Scrum 3.0 - Preview

MSF for Agile Software Development 7.0 - Preview

MSF for CMMI Process Improvement 7.0 - Preview

Finally, select a Version Control repository. Currently, TFS and Git are supported. Click [Create Project] and you will be ready to start using TFS within a few seconds.

The navigation is simple and intuitive.

You can add and remove team members by clicking the Manage All Members link.

You can enter a new Task, Bug, Issue, Feature, or Test Case using dialogues similar to those found in the Visual Studio Team Explorer.

The source control repository can be seen by clicking the "Code" link on the top menu. From here, you can download files but not upload them.

TFS source control is easiest to use when you integrate it with Visual Studio. Open a solution in Visual Studio and select File | Source Control | Add Solution to Source Control

You may be prompted to add a TFS server. If so, use the URL ending in ".visualstudio.com" that you noted from above. (Fig. 3)

Select the Team project to which this solution belongs (Fig. 4) and click the [Connect] button.cl

i

From here you check-in, check-out, branch, merge, and get latest in the same way that you would use a TFS server within your enterprise.

Team Foundation Service allows you to manage projects on your own or with organizations that don't have the hardware and/or time to set up their own TFS server. It can be a simple solution to integrating your project with Application Lifecycle Management tools.

What I liked about "Continuous Integration in .NET" by Marcin Kawalerowicz and Craig Berntson is that it does not assume any prior knowledge of continuous integration (CI) by the reader. It begins by discuss CI - its theory, goals, and tools - and it moves on from there.

It's often difficult for an organization to achieve CI all at once, so this book walks the reader through the various pieces of CI - source control, automated build, unit testing, continuous feedback, analysis, deployment. They go into detail on each concept, showing step-by-step how to get there with a variety of tools.

Kawalerowicz and Berntson take care not to focus on a single tool. The implementation of each concept is shown using Cruise Control .NET, Team City, and Team Foundation Server.

Continuous Integration in .NET is a very good book to get you up and running with automated build and deployment processes and moving into continuous integration, even if you have no experience with these concepts.

We can all agree that some code is better than others. But if you write code that compiles and meets all the user's requirements, is it possible to improve this code?

Robert C. Martin's answer is an emphatic "Yes". Although sloppy code can meet short-term requirements, it quickly becomes difficult to maintain. Clean Code, Martin argues, is easier to read, understand, and test; and safer to change. Our goal should be to write Clean Code.

Robert's C. Martin (sometimes affectionately referred to as "Uncle Bob") has compiled some guidance on writing clean code into a book with the self-describing title "Clean Code".

Martin did not write the entire book- he enlisted other software developers active in the Software Craftsmanship movement to contribute. Tim Ottinger, Michael Feathers, James Gremming, Jeff Langr, Kevin Wampler, and Brett Schuchert each contributed at least one chapter, outlining a specific idea of Clean Code.

Among the key concepts: Keep classes and methods small and narrowly focused, give meaningful names to variables; don't use comments as a replacement for difficult to read code; and avoid output parameters and an excessive number of parameters.

He follows up advice on craftsmanship with a set of case studies in which he describes the refactoring of existing code bases.

Although most of the examples are in Java and I am primarily a .NET developer, I found this book very useful and applicable to any language - particularly an object-oriented language, such as C#.

Code Complete was a good book for me to read when I did. I am in the process of refactoring some code that is very difficult to maintain. I knew that it is not clean, but found myself unable to articulate exactly why.

The book is not for beginners. You should have a solid understanding of your language and of OOP concepts before tackling it. But it provides excellent guidance on writing readable, maintainable and testable code.

These are some of the lessons from Tom and Mary Poppendieck’s book Lean Software Development – An Agile Toolkit.

The Poppendiecks take what they learned from Lean Manufacturing (many of which were originated with the pioneering work of Toyota Motor Company) and apply these lessons to software development.

They deliver advice in the form of 22 “tools” that can make a team or project more lean. Related tools are grouped together into chapters.

The authors recommend that organizations define, find and eliminate waste wherever it occurs in a process. Examples of waste in software development include defects, waiting, extra features or processes, and any non-essential activity. To assist finding waste, they recommend Value Stream Mapping - a technique in which one lists in sequences all the steps from customer request to delivery and estimates the time to completion of each step and the wait time between each step. This technique often makes bottlenecks obvious so that they can be reduced or eliminated.

Many of the tools in this book overlap. For example, iterations and feedback are listed as separate tools, but shorter iterations allow for more frequent feedback to the development team. Short iterations also expose design problems more quickly sot that the can be corrected early in the development cycle at a lower cost.

Much of the authors’ advice seems counter-intuitive. For example, they recommend against detailed planning at the start of a project and attempting to optimize every part of a multi-part project.

A popular approach among software project managers is to create in advance a detailed plan of every step in the design, development and deployment process and to estimate each step. To do so, you need to know a specific scope of everything you will build. This makes sense as a risk-reduction strategy, until you consider that environments, requirements, priorities and people often change while software is being developed. A rigid plan created up front often requires an aggressive change control process to alter that plan in any way. And for long-term projects, the changing landscape almost always forces changes to the design. Also, when users know they will only get one chance to request features, they tend to ask for far more, so scope tends to get bloated when projects are planned in this way. A better approach is to re-evaluate priorities periodically throughout the development process and keep focused on the top priority features that have not yet been implemented.

Complex project can and often should be split into a number of smaller phases or tasks. This helps to simplify the complexity. Many managers then strive to optimize each phase of the project, assuming that this goal will lead to overall optimization of the project. The Poppendiecks advise against this goal because optimizing some phases may cause a bottleneck in your overall project, thus slowing down the project as a whole. A buildup of code waiting to be tested, for example, represents waste that should be eliminated. It is best to look at the system as a whole when setting optimization goals. Optimizing each part ignores the interaction between these parts.

The book finishes with practical advice to get started making your team and process more lean.

Lean Software Development - An Agile Toolkit is a clearly-written, thoughtful book and anyone involved in software development projects can benefit from reading it.

Kirstin Juhl came to software development from a career in manufacturing, where she learned about Lean principles. Now she sees those same principles being applied to software development. In this interview, she describes Lean in both worlds and compares the two.

Until last year, I worked for a large consulting company that had established a solid reputation using a waterfall approach to deliver solutions.

My current employer is committed to the agile methodology SCRUM. They have developed their own variation of SCRUM and several consultants here have even made a name for themselves delivering presentations on this methodology to customers and at conferences.

So it's only natural that I have been engrossed in SCRUM since joining. Nine months of agile software development have sold me on its benefits.

The biggest advantage I see to SCRUM is the short delivery schedule pushed by the sprints. For those who don’t know, a sprint is a set of features scheduled for delivery in a short period of time (typically 1-4 weeks). A sprint forces (or at least encourages) frequent delivery of working software and provides a great feedback loop to the development team.

When users can actually see, touch and use functioning software, they don't just get value more quickly - they are able to evaluate it more quickly and provide valuable feedback. That feedback might be a rethinking of original assumptions; it might be new ideas sparked by using the software; it might be a reshuffling of priorities, or it might be a clarification of some miscommunication between the users and the developers. It will probably be several of these things. That miscommunication issue is one that occurs far too often on software projects. Catching these misunderstandings early in the life of an application can save a huge amount of time and money. We all know that the cost of making a change to software goes up exponentially the later that change is made.

By delivering something useable to the customer several times a month, we are providing value to the customer in a timely manner. At best, this value comes in the form of software that enhances their ability to perform their job. At worst, we provide something they didn't ask for. But this worst-case scenario also adds value because we can use the delivery to clarify the misunderstandings and poor assumptions that leaked through the design.

I think back to the last waterfall project in which I was involved. Our team was charged with designing and building an integration layer between an e-commerce web application (that was being designed at the same time) and dozens of backend systems (that were in a state of constant flux). We spent months designing this integration layer. During these months, the systems with which we planned to integrate changed dozens of times. These changes included adding or removing fields; placing a web service in front of an existing interface; and completely redesigning and rewriting backend systems.

Each of these changes forced us to re-examine all the design work we had done and to modify all our documents to match the changed requirements. In some cases, we had to start our design over from scratch.

An agile approach would have helped immensely. Instead of designing everything completely before we started building anything, we could have minimized changes by designing, building, and deploying the integration service to one back-end system at a time. By selecting a single integration point, we might have been able to quickly deliver a single piece of functionality while other backend systems to stabilize.

I'm not going to suggest that agile is the appropriate methodology for every software project or that no other methodologies have value. My former employer delivered countless successful projects using waterfall techniques.

But it pays to recognize when agile will help your project and it is definitely a useful tool for any developer, architect or project manager to have in his or her toolbox.