SDLC Progress

I've been spending the last month or two getting the SDLC procedures and infrastructure in place for the Silverlight release of our company's Enterprise Physical Asset Management system.  We were already using Team Foundation Source Control but wanted to adopt SCRUM as our development methodology and improve on some of our development practices such as using Continuous Integration, Test Driven Development, better Work Item Management and enhanced quality through Code Reviews, Check-in procedures and the selective use of Code Metrics. 

We have just completed our first 2 week sprint and the team felt that the processes and tooling worked quite well and enjoyed most of the new structure and discipline introduced.  In our retrospective we identified some process impediments that we want to improve on going forward. In this post I will highlight some of the processes and tooling we are using.

Work Item Management

We are using Conchango's SCRUM for Team System template to assist us with Work Item Management.  The Conchango template and the associated process guidance provides a good starting point.  I highly recommend taking a look at the new Conchango Task Board application to make the daily management of your Product and Sprint Backlog items a breeze.  The task board provides a very nice GUI for managing the essential fields of the work items as well as the state transitions.  The software is currently in Beta2 and still contains one or two frustrating bugs.

Code Reviews

As mentioned in my previous post on code reviews, we are using a lightweight code review process that suites the distributed nature of our team.  We do reviews after all the development tasks for a PBI (business feature) has been completed.  The development tasks are only allowed to move into the Done state once the review has been completed.  The review process is also quite focused as we know all checked-in code adheres to a rigorous check-in procedure.  We also try and automate a lot of the standards compliance checking through the use of tools like FxCop and NDepend.

Check-in Procedure

We try to follow quite a rigorous process for check-in of our code into TFSC.  This idea is to try and ensure a continuous level of quality for the code being committed.  Here are the steps that all code needs to adhere to:

1. Code has been integrated with close to the latest version of the code in the TFSC.
2. Code has been formatted according to our company's ReSharper Cleanup Profile.  This ensures that all code uses the same C# layout structure and formatting standards.
3. Code compiles without warnings in both Debug and Release mode.
4. Code adheres to our coding standards document.  Where possible we try and automate the checking through the use of FxCop and NDepend CQL queries.
5. No ReSharper code analysis violations.  Any violation needs to be identified and agreed upon.
6. No FxCop violations.  Any violation needs to be identified and agreed upon.
7. All unit tests run through successfully in your private workspace.  We've just introduced code coverage and we'll probably include some minimum level of coverage for the future.
8. All functional tests cases run through successfully in your private workspace.  We are in the process of automating our acceptance tests as and we hope to have this running within the next sprint or tow.

Continuous Integration

As I previously mentioned we use the excellent TeamCity for our CI server.  We are very happy with the results.  We have integrated NUnit, NCover, FxCop and NDepend into 3 separate builds configurations:

1. Continuous - Build that currently runs every 2 hours to compile the code and run the NUnit tests.
2. Daily - Build that runs every evening at 22:00 to compile the code, product documentation and build the installer.
3. Metrics - Build that runs every evening at 22:30 to run FxCop, NCover and NDepend to generate the metrics for the day's development.

We have just started using the Microsoft Silverlight Testing framework for our client side UI tests and the idea is to integrate this into the build process for the next sprint that starts tomorrow.  More on all of this at a later stage.