September 21, 2010

Intro to Scrum Part 1 : Where the Value is Mightier than the Plan

 

The old way of doing software development just did not work. Projects failed left and right and customers began to believe that developers could not produce the solutions that the developers said they could produce. Something needed to change.

Scrum was one of many answers to the problem. Under the umbrella of agile, scrum focuses on small teams and small time blocks for implementation. In the first part of this series of blog posts, I want to show the differences between the old way of doing things, and the new way, scrum.

Plan Driven vs. Value Driven

Waterfall method (Plan Driven)

The waterfall method (also know as the Plan Driven Method) was the only way to do software development for the longest times but it was not the best way. Using this method meant dealing with high risk and the likelihood of failure. The reason why it was this was way was because of the fact that everything was done up front. Everything that the customer wanted or needed was supposed to be laid out at the beginning and the customer never changed their mind. This led to problems becoming hidden until towards the end of a project because not everything the customer wanted or needed was laid out. Scope creep is rampant because what the customer wanted was always changing. We as developers did not know what the customer wanted and neither did the customers.

What plan driven does is create a list of features that the development team needs to provide to the customer in the given timeframe.

When companies were behind on a project, like they usually were, they would just throw bodies at the projects. Their thinking behind this was that the more people that are on the project the faster it will get done. That rarely happened. Most of the time the project would remain behind schedule and companies trying to get the project completed on time tended to cut scope, cut out testing, or both.

Scrum Method (Value Driven)

Scrum (also known as the Value Driven Method) is a dramatic change over the waterfall method. Instead of trying to gather all requirements, do all the designs, and then code the application, scrum looks at doing iterative, incremental development. Small time blocks where the team can work on a solution for the customer. You can look at each iteration as a mini waterfall in that the team will everything you would do in a waterfall method, except do it at a smaller scale. This is done against small features that solve a problem for the customer, not the whole application. The goal of these iterations is to deliver an increment of the final product that is potentially releasable.

This approach makes problems visible sooner. However, contrary to popular belief, scrum does not fix the problem. It shows you the mud but won’t clean it up.

In scrum, you are not just creating features for sales and marketing teams to show customers, you are creating solutions for the customer. The way this is done is by prioritizing the items that need to be completed based on customer value. Only the things that the customer deems most important are worked on in any given iteration. If the customer does not want something then it is not worth the developer’s time to work on it. Finally, scrum is all about small; small teams, small features, and small iterations.

Fixed vs. Variable

In plan driven, your scope is usually fixed with your resources and time being variable. In this method, your scope dictates your resources and time. Since you cannot change your scope your only how is true try to throw bodies and technology at the project and hope for the best. Usually to varying degrees of success.

In value driven, your resources and time are fixed. You know the size of your teams and you know how roughly how many customer items they can complete in an iteration based on previous iterations. Scope becomes the variable in this equation. Here your resources and time dictate you scope. Since you are able to potentially release workable and valuable software to a customer at the end of each iterations, scope creep becomes near impossible. This is because as new features are presented to the team, they are prioritized. After this prioritization, the “must haves” are at the top with the “would like to haves” at the bottom. Over committing the team goes away.

ValuePlanPic 

Conclusion

This was a brief introduction on the differences between the waterfall method and scrum. In the next article in this series, I will talk about a component of the scrum process, the scrum teams.

September 5, 2010

How to install and run NUnit in .Net

Being new to the agile world, all of these new tools can be overwhelming. One of the first things you may want to do as an developer is write a test. As developers, we are curious about how good our code is, but how do you write a test? What tools do you use in the .Net environment? By the end of this tutorial, I will show you how to install, setup, and use NUnit to write your very first test. Once you learn how to write these tests, you will realize just how easy it is to test your code.

Prerequisites:

In order to follow along in this tutorial, you will need the following
  • Visual C# 2010 Express (any version Visual Studio 2010 should do)
  • NUnit (Please note that in order to get the NUnit client to run, you need to have .Net Framework 2.0 installed. It won’t matter if you are using a different version of the framework for your development.)

NUnit Installation:

To install NUnit click on the “.msi” file from the download page, link above, and double click the file and open the file once it’s been downloaded. The “Complete” setup type will be fine. Everything else is pretty much your standard installation. Once the installation is complete, the necessary DLLs will be on your computer and you will be ready to incorporate them into your test project.

Writing NUnit Tests:

Writing a test with NUnit is fairly straight forward. Lets start with the following method called “AddTwoNumbers”.
namespace NUnitTutorial
{
   public class MathObject
   {
      public int AddTwoNumbers(int num1, int num2)
      {
         int result = num1 + num2;
         return result;
      }
   }
}
What you can see is that the method simply adds two numbers together and returns the result. Lets write an NUnit test to make sure this method is returning what we expect. We need to do the following to write a test:
  1. Add a new class library project to your solution. This new project should have the following naming conventions “ProjectUnderTest_Test” where “ProjectUnderTest” is the name of the project that contains the methods you are writing the tests against. image This project will contain all of your tests. Above you will notice that I have a project called “NUnitTutorial” that contains the “AddTwoNumbers” method and a project called “NUnitTutorial_Tests” that will contain the unit tests for that method.
  2. Next add the following DLL to the test project “nunit.framework” image
  3. Write our test.
To write the test we first need to add a using for the project under test (NUnitTutorial) as well as the NUnit framework (NUnit.Framework).
using NUnit.Framework;
using NUnitTutorial;
Now lets add our test to the MathObject_Tests.cs file. We first need to let NUnit know that this class contains tests that need to be ran. To do this we mark the class with the following attribute “[TestFixture]”.
using NUnit.Framework;
using NUnitTutorial;

namespace NUnitTutorial_Tests
{
     [TestFixture]
     public class MathObject_Tests
     {
     }
}
Now, lets add the test method “AddTwoNumbers_returns_3_when_given_1_and_2”. (I always like to name my test methods this way so that I know what method they are testing as well as what the expected inputs and outputs are.) Once we add this method we need to add the attribute “[Test]” to it so that NUnit knows that this is a test to be ran. Note, that all test methods should be void methods, not return anything.
using NUnit.Framework;
using NUnitTutorial;

namespace NUnitTutorial_Tests
{
  [TestFixture]
  public class MathObject_Tests
  {
       [Test]
       public void AddTwoNumbers_returns_3_when_given_1_and_2()
       {            
       } 
  }
}
All that’s left is to call the method with our two inputs and assert that the result from the method is what we expect.
using NUnit.Framework;
using NUnitTutorial;

namespace NUnitTutorial_Tests
{
  [TestFixture]
  public class MathObject_Tests
  {
    [Test]
    public void AddTwoNumbers_returns_3_when_given_1_and_2()
    {
       MathObject mObject = new MathObject();
       int calculatedResult = mObject.AddTwoNumbers(1, 2);
       int exptResult = 3;
       Assert.AreEqual(exptResult, calculatedResult);
    }
  }
}
The above test simply calls the “AddTwoNumbers” method, giving it a 1 and a 2 and asserts that the result from the method is what we are expecting, which is a 3. Now, that we finished writing the test, we need to run it. Build your solution and generate those DLLs.

Running NUnit:

Start up the NUnit client by going to Program Files –> NUnit x.x.x –> NUnit. Once it is up and running, click on File->Open Project and navigate to where the DLLs generated from the test project are located. You want to load the test project DLL into NUnit. image Once the DLL is loaded, it will show you the tests that are in that DLL. image From here all you need to do is click the “Run” button and NUnit will run your tests and output the results. image As you can see, our test passed. Now what would have happen if the test had failed? Let’s find out. Lets change our expected result to be 4 and see what happens. image There you go all the information you need to get NUnit installed and on your way to creating tests and rock solid code.