Tuesday, January 19, 2010

Software Development Practices from the Real World; On Repeat

On Saturday February 27th, the Dutch DotNED user group, Aviva Solutions and Oosterkamp Training & Consultancy will be hosting a full day session on software quality. The session will be mostly held by myself, but I will be accompanied by my colleagues Jonne Kats and Peter Hesseling.

Unfortunately, due to popular demand, the session was fully booked within 24 hours. But now, we are seriously considering repeating the session in the beginning of April. So if you’re still interested, go to the DotNED registration page and click the link at the bottom of the page to send us an email.

Friday, January 08, 2010

Storyotypes in Visual Studio 2010

Storyotypes are stereotypes for user stories that can help to define the right scope for your user stories. You can read more about these in the article Using Storyotypes to Split Bloated XP Stories and these slides. Team Foundation Server 2010 includes a new VSTS for Agile process template closely following the Scrum practices and supporting a user story WIT. However, Storyotypes are not supported, so I decided to change the standard work item template to add that field.
You can download the modified WIT template from here. You can install them into an existing project using the witadmin.exe tool (available if you open a Visual Studio 2010 Command Prompt), but it’s much easier to use the TFS Power Tools.

Updated on November 2nd, 2010 with a WIT template compatible with Visual Studio 2010 RTM.

Monday, January 04, 2010

ALM Development Practices Part 1: An Introduction

As part of my many assignments, I’m compiling a bunch of Application Lifecycle Management practices into a set of development guidelines for bootstrapping our internal projects using Team Foundation Server. I’ve decided to share these with the community so that others may benefit from it as well. Beware that these practices are not new nor in any way invented by myself. I'm merely trying to get some good resources together in a nice compact format.

So what are my goals?

  • To provide insight into the benefits of applying well known best practices on software development projects.
  • To provide examples of applying those practices on new and ongoing projects and explain how to gain the most of out them.
  • To help you jumpstart a new project or professionalize running projects.

And what do you gain?

The goal of these posts is to end up with a set of development practices that provide the following benefits:

  • Allows you to more quickly and accurately assess the impact of new requirements.
  • Promotes building well designed software that allows changing functionality with lesser risks (even during a running project).
  • Promotes a consistent code-base that solves similar problems using similar solutions, everywhere.
  • Strives for a functionally consistent software system. For instance, ensuring that date fields look the same all over the application).
  • Attempts to prevent code duplication so that you never have to make changes at multiple locations if you change a particular piece of behavior or logic.
  • Eases the effort for deploying a new release by removing as many human actions as possible.
  • Provides traceability on where a particular piece of functionality has been realized technically.
  • Improves the developer experience when working on an existing or shared code-base (e.g. readability, purpose and goal of a block of code).
  • Provides a safety net that reduces and possible prevents the chance of running into regression problems.
  • Attempts to prevent common mistakes or misinterpretations by introducing common rules and recommendations.
  • Strives to a situation where each and every member of the team is aware of the project’s affairs.
  • Promotes any endeavors that improve the self-education and self-organization of teams.