Contents tagged with Agile
-
Scrum Room = Fun Room!
I like to have fun at work. Whether it's just messing around (by changing developers desktops to pictures of the Simpsons) or just focusing on a task, I think software development should be a fun thing and thus, be conducted in a fun atmosphere. After all, if you're not having fun then what's the point?
A few months ago, we shifted things around and finally got a large enough room to setup our projects in what we call the Scrum Room (I like to call it the center of the universe, but that's a little egocentric as it doubles as my office). Unfortunately our environment isn't what I would prefer it to be (a large team room for all members to be co-located) but this isn't bad. A single "War Room" where we hold the daily scrums each morning for each project. I personally grind code, print out burndowns, and keep the ship steered in some direction (the direction changes all the time) here every day but besides holding daily scrums, the area is generally regarded as the "drop by and let's talk about [insert design pattern here]" room.
First off, we have the daily scrum rules posted on the wall for everyone to see and for us to refer to from time to time as people forget. As I mentioned last week, if anyone strays from the rules during the daily scrum, the Scrum Witch lets out a Wilhelm scream (and we don't want that to happen). This wall also holds the burn down charts (created from Team System) of each iteration. I forgot to snap a picture of the entire burndown wall but you can catch one of them here. I'll post later a more detailed breakdown of the burndowns from one project as we're in the 6th month and there's been a lot of great activity and challenges with that project.
Next is the start of daily scrum. This is a Japanese character a friend of mine got and I had to barter with to obtain (I traded a broken iMate Jas Jar for it). He's an alarm clock of sorts and when you press the button on his chest, music starts up and he tells you to wake up (in Japanese of course). Press the "snooze" button again and he tells you "thank you for waking up" (or something like that, my Japanese is non-existent) and the music stops. We would get into the habit of starting this guy up just to get everyone pumped for the day, although I haven't activated him for awhile now.
Now we come to "The Wall". This is a large (about 20ft wide) wall in my office that houses 3 projects and their tasks. Each project has a 8-10ft section of the wall and we print out the splash screen for each project to identify it (of course the splash screen is the first thing done for the project, screw the requirements, we need a cool logo!).
Under each project contains 3 sections with tasks. One for "Not Started", one for "In Progress", and one for "Done". The "In Progress" section is broken down with a small post-it showing 0% - 100% which is the completeness of the task. Under the "Not Started" section we break down tasks in an organized fashion so it's easier to find them when you're grabbing a task during your 5 minutes of fame at the morning scrum. Each team groups the tasks differently. One team has it defined by role (BA, QA, Dev, etc.), another has it defined by a feature, still another uses a line of business to collect tasks. Whatever works for each team is fine.
It's the usual routine for task boards (in our case the entire wall is the board). Tasks move from the "Not Started" area to 0% in the "In Progress" area. As team members work on tasks, they move across the wall to 100% then drop into the "Done" area. It really does give a quick overview of where things are at. It's the easiest way to describe and display progress and the entire state of the iteration for anyone looking at it. This is how much we have to do, this is how much we've done. Highly effective and easy to understand.
The banner at the top of the wall is labeled "The New Goodness" and was a phrase someone has mentioned awhile back (more than likely it was over a few shooters at the bar, but that's okay too). We liked it as it represented the new approach to software delivery (agile vs. waterfall) and seemed to reflect the atmosphere we wanted to take. Something new and something good. Sure the grammar is off but again, we're focused on fun here not English. The development manager also printed out a picture of a traditional rugby scrum so we felt it was appropriate for the wall (and some mornings it feels like this).
There's a section over my desk where we've got some fun and motivational type stuff. A printout of a cartoon that Hugh MacLeod created (I'm not cool enough like Scoble to have a hand signed lithograph) that is a bit of a motto when you're in my office. We have the Scrum cartoon about the chicken and pig wanting to open a restaurant, courtesy of Implementing Scrum. Finally, there's the fish. This will take a little explaining.
This fish is the award the team member gets for breaking the build. Originally we were thinking about bringing in a real (ala taxidermy) fish. The dev manager has 3 of these so we would pass out the fish and the team member who broke the build gets to display the fish on his desk all day. This wasn't quite practical (and we felt we would run out of fish and then what! Goats? Sheep? Cats?) so he hunted down a goofy picture of a kid holding a fish. If you break the build, he emails the fish to you and prints out a copy for you to pin up in your cube.
Today we discovered some people were actually collecting their fish so maybe we'll have a contest at the end of the project as to who gathered the most fish. The idea is to spice up your team with ideas and promote fun within the team even when they do something bad like breaking the build.
Well, that's the whirlwind tour of our Scrum Room. It doesn't have to be a stuffy board room or a boring task board, and if you're going to live in it every day (like I do) make it enjoyable!
The message here is to have fun with your projects. Don't get so stressed out. So what, you lost a resource or two. So what, the requirements changed a day before you were supposed to deliver that feature.
Breathe, relax, pick up, and carry on. It's just software.
-
Beware the Scrum Witch!
I'm always happy when I see the Internet spread goodness, or at least what I perceive to be goodness. Last week or so I talked about the Scrum Witch, a horrific little screamer that we introduced to our daily scrums as things were getting out of hand. If a team member strays from our standard routine, we unleash the Scrum Witch on them, screaming and howling for everyone in the office to hear.
The witch has been pretty successful as we're sticking closer to the routine and there's less gossip-talk during the scrum. Scrums end in under 10 minutes now (where they previously would linger for 15, 20 and even 30 minutes) and everyone is focused. I've only had to activate the Witch twice, and both times were with the same PM who charged off asking all kinds of questions (not even related to the current sprint!).
Mike Vizdos over at Implementing Scrum has a cartoon this week called Work Naked on dysfunctional things he sees at the daily scrum and yes, the Scrum Witch made an appearance (although it would have been awesome if she made it into the cartoon, ahh someday...)
The message here is simple. The daily scrum is your commitment to the team, not a report to the PM or Scrum Master on what you did. Be kind and respectful and the pain will last only a few minutes.
Watch later this week for more scrum fun as I have a few posts on the go right now.
-
Introducing... the Scrum Witch!
My co-worker came by today and dropped off something at my desk. He calls it the Scrum Witch. Here she is:
She's a crazy one alright (and loud). We've had some challenges getting everyone to follow the daily Scrums as side discussions start happening, water cooler gossip, etc. and 10 minute standups turn into 30 minute meetings. We're also all about fun and trying to enjoy our jobs.
So anyone who starts to stray from the Scrum rules (a watered down version from various places like here that we've printed out and put up in the Scrum Room), we unleash the "Scrum Witch" on them. A small button on her back lets out a screaming wail to let the speaker know we're off on a tangent and a reminder to get back to business.
We'll see how it goes over the next few weeks (or until the entire team gangs up on the Scrum Master and beats him to death with, in which case this might be my last post).
-
The "need" for Scrum Tools
I got an email from Mike Vizdos about a blog post he was writing up. Mike is the author of a blog called Implementing Scrum. It's a great blog where he posts a cartoon to describe a Scrum concept in a very acceptable way (see below for an example). It's an excellent communication mechanism. I find myself printing out Mike cartoons all the time and putting them up around my office (aka the Scrum room) to hit home the Scrum concepts to people.
Mike recently blogged about Scrum tools and mentioned my own Scrum Tools Roundup post (thanks Mike!). His post talks about the value (or lack of) Scrum tools and I partially agree with him. There are times I've said exactly "Please make sure you update tool X so that we can report our burndown to [someone who is not even in the room]."
I personally just print out the burndowns (we use the Conchango Scrum Plugin for VSTS) and put them on the wall along with a splash screen for the project and the post-it notes that represent the tasks (our task board). We still use VSTS for tracking, but the wall is the conversation piece. Each morning (currently 2 Scrums soon to be 3) we get together and do our daily standup with everyone sort of huddled around the "wall" (a giant 14 foot wall I have in my office that holds all the post-its). People talk about what they did and what they're working on, move stickies around, and all is well.
I agree with Mike in that if you're burning 50% of your time in a project on maintaining a tool, a backlog in a tool (VSTS, spreadsheet, or otherwise) then you're spending about 49% too much time. However as the Scrum Master I keep the tool up to date, the PM uses it (constantly) to report progress to a heavenly body, and I personally try to get the team to not get hit too much with any administrivia tasks. The most any team member should do is to a) change the state of a task to In Progress or Done and b) knock down the work remaining on tasks as they're doing them say from 8 hours to 4 (or 0).
That shouldn't take more than a few minutes a day before the daily standup. Really.
If you're donig more than for sure you're spending too much time and you should read Implementing Scrum on a more frequent basis (and maybe change how you work).
-
A Plugin for a Plugin
Isn't life amazing? These days you can download a plugin (ReSharper) and write a plugin for it (VstsUnit). That's what my fellow plumber James Kovacs did. He was using VSTS for his unit testing but unfortunately the built-in Test Runner for ReSharper didn't support VSTS unit tests, only csUnit/NUnit. So armed with the ReSharper SDK and a few brain cells to kill, he went off to build a plugin for a plugin. Basically it allows you, with ReSharper installed, to run Visual Studio Team System based tests via the test runner. I personally use TestDriven.NET which supports anything you throw at but if you're a ReSharper guy and are stuck with VSTS rather than NUnit for your testing tools, take a look at this freebie. You can download it here.
-
Scrum tasks, tasks, and more tasks
I find that I'm often letting my teams know some norms around Scrum and the process of a task-oriented system so I thought I would throw these out to the world. We sometimes loose sight of these simple things and get wrapped up in bigger, more grandiose ideas so consider this a Wednesday morning reminder.
- Don't assign tasks to other people. You don't want people telling you what to do because frankly I don't function that way and I don't think people work well in this manner (in general). One of the key principles of Scrum is self-organized teams meaning teams that decide what they need to do to get the job done, not others telling them.
- Don't claim tasks as your own but don't do work on them. I often see people stake claim to tasks in Team System (our Scrum tool) and set them to In Progress but they remain that way the entire sprint. It deflates the value of the system and just makes it look like the team is busy (to outsiders) but we're not really doing anything (or you can't tell what you're doing).
- Don't create huge tasks that take days to implement. My rule is generally under 4 hours. If you have an 8 hour task what you're saying is that, uninteruppted, it will take me the entire day to work on this. In reality you'll be interuppted, they'll be meetings, phone calls, coffee breaks and 8 hours of effort will probably take 12 hours of duration which means you have one task that spans 1 1/2 days and maybe even 2. So as a team member, you're saying to the your team mates, leave me alone for 2 days while I do this in isolation. That's not condusive to a good team effort nor is it helping anyone. If you see a task that's more than 4 hours, ask yourself if it's really 1 big task or 2 small ones? The other advantage to smaller tasks is that you might break something up into two 4 hour tasks and each one can be done by two different people, meaning you actually deliver value faster and isn't that what we're trying to accomplish here?
- If you already have something "In Progress" don't pick up a new task. I've been told that I have ADD and while I might (I do have many projects on the go, both at work and home) I try to manage it. Picking something and saying "I'm working on this" then turning around the next day and saying the same thing on something else just looks like you're trying to look busy. It's okay to grab a couple tasks at a time or grab a new one if one task is just waiting on something or needs a small collaboration say with the customer, but knowing that a task has 2 hours of work left, yet grabbing a new one and starting it without finishing the first is just plain dumb. Why would you do that? Would you wash half your car, then go and cut the lawn knowing your car is covered with soap? Even with ADD I wouldn't.
How do you eat an elephant? Easy, one bite at a time.
-
Best Practices with FitNesse
Google doesn't seem to show me any best practices that anyone has put together with FitNesse, which is odd (or my Google skills suck) so I thought I would capture a bunch here that I've come up with to start.
- Keep your wiki test pages small
- Having a wiki test page with 20,000 tests doesn't do anyone any good. First off, it'll take days to load. Second, it's a sea of gobbly-gook looking at it in edit mode and next to impossible to find that one line that you need to edit. Do your team a favour and keep them small. Like development practices, I like to keep my FIT pages down to a screen or two at most.
- Organize your tests so they make sense
- FIT supports test suites and they're useful, especially for organzing things. Having one table with hundreds of scenarios might be good (more tests are always good) but if they're difficult to read or navigate they'll be cumbersome to maintain. Use a single responsiblity principle when it comes to organizing your tests and try to group them together into some kind of organizational category or unit that makes sense to the tests and users. For example if you have FIT tests that are testing accounts, consider writing a table for each type of account; a table for account fail conditions; a table for special conditions; etc.
- Use "Friendly Names"
- Rather than seeing complete namespaces and fixture names, use friendly names with spaces. So this:
"|MyCompany.MyApplication.MyFixture|"
can become:
"|My Fixture|"
Also you can use the !import table to remove the fully qualified namespaces. This makes it more appealing to look at when you're showing value to the customer of these tests. - Seed your test pages and engage the authors
- Getting started with FIT and actually having tests can be a big hurdle. To be setup for success, have the entire team not only go through creating the fixtures and tests but work with the authors about what scenarios they can test. For example not everyone thinks about the failure conditions that should be tested (using the fail[] markup) so make sure the authors of the tests know all the different things they can try. The best scenario you can ask is a perfect test author who knows all the things to test, but when adopting FIT you might need to do a FitNesse 101 with them and get them introduced to different ideas around testing, not just entering tables over and over again. Quality not quantity is what you're looking for in the end.
Feel free to add your own!
-
Development mottos to keep the team spirit alive
Today we were talking over some things as we start up the next sprint (sprint #4, 1 maybe 2 to go!). The conversation turned towards the fact that one guy on the team was away on holiday but he was the "report guy" and currently one report was causing problems. Unfortunately we've run astruck of the code ownership problem that I really wanted to avoid, namely being dependent on one resource for one slice of the application. Not a good place to be in and something you want to avoid. As we were chatting this set of syllables came streaming out of my mouth:
"If all you do is what you know, you'll never grow."
Plain, simple, and short. Now maybe I heard this somewhere before but after saying it, it made me think (and laugh) and we all had a good chuckle over it. However it really does ring true. Sure everyone has individual skills and some people are better at database programming vs. UI design vs. domain modeling, but in the end a well-oiled team needs to be able to respond to any problem. In any module. In any area of the code. While you might be great at writing the same thing over and over again, it isn't challenging let alone pushing any kind of thought-provoking edge so how do you expect to move with the times?
We wrote the quote on the whiteboard and it resonated. It's one of the mantras we're adopting to always remember not to paint ourselves into a corner and be dependent on any one resource and to tread into those uncharted areas of the your capacity. So get out a little bit, explore your code and if you've never written a view using MVP, now's as good as time as any to learn.
Later in the conversation we came up with another one (we thought we were on a roll). It started with the U.S. Army's "Be all that you can be" motto and became this:
"Test all that you can test."
Yeah, a little corny but then my co-worker Dale came up with this widget:
"If you don't write tests... you're dead."
It was getting later in the day and things started to go downhill but walk with me on this one. We laughed at it but then combined the two statements:
"Test all that you can test and if you don't write tests you're dead."
While it may sound a little chilling and morbid for a software development project, after we wrote it on the whiteboard it just clicked. The team was dead in the water if we don't write tests. We're currently facing new functionality and dealing with some bugs coming up and doing lots of fairly aggressive refactoring. You can't successfully refactor parts of your codebase if you don't know what it does or what the downstream impact is, so when you come upon muddy waters where there's no tests our mantra is to write one then move on. While we do have about 70 good tests (after 3 months of development) we could have more and we've been procrastinating to write more tests (especially for the presenters) for a long time. Pressures from the users, not enough time, blah, blah, blah, blah, blah. So with this little motto and some team re-enforcement of asking everyone at the Scrum when they mark something as "Done" we'll ask if they have tests for it. If not, we're not going to consider it done. Hopefully that'll get us back on track and be productive at the same time.
Finally, later today we had a technical overview and discussion of a new Smart Client project I'm leading up. It was the usual wallow through all the tools, techniques, technologies, process, and standards that we're going to do (with a load of the usual acronyms [CAB, SCSF, TDD, DDD, BDD, FIT, etc.] all thrown up on the whiteboard for discussion). About halfway through as we were talking about testing and specialization of code, I threw the two statements up on the whiteboard again.
"If all you do is what you know, you'll never grow."
"Test all that you can test and if you don't write tests you're dead."
A completely different team with varying levels of experience on the various tools and processes, yet everyone agreed with what we had written. Yup, that's what we have to do for this project to be successful (well that plus deliver a quality solution to the customer).
Anyways, just something to think about. Even if something sounds corny it's a morale builder and an item to talk about. Remember to keep these little team building exercises fun and light and hey, who knows, you might come up with a little motto for your team to keep things interesting!
-
Anonymous delegates for event handling
Let's start off the new year with a question. Traditionally here’s how you would code up an event handler for say a button on a Windows form (ignore the fact there are presenters and such and how they got initialized).
56 protected override void OnLoad(EventArgs e)
57 {
58 btnClose.Click += new EventHandler(btnClose_Click);
64 _presenter.OnViewReady();
65 }
67 void btnClose_Click(object sender, EventArgs e)
68 {
69 _presenter.OnCloseView();
70 }
That's all well and fine. The form loads, the event handlers are registered and the view is called. There's a method for each event setup (by default in the form of ControlName_EventName) so you might have dozens of additional methods in your view code depending on how complex the form is.With .NET 2.0 we can use anonymous delegates so the code above can become this:
56 protected override void OnLoad(EventArgs e)
57 {
61 btnClose.Click += delegate { _presenter.OnCloseView(); };
64 _presenter.OnViewReady();
65 }
Just setup the delegate in the load method for the form. Same rules apply as in the presenter method will get called when the button is clicked.I like the second method as in it's cleaner and I don't have to clutter up my view code with lots of methods that only pass thru to a presenter. Even with dozens of events on dozens of controls I would only have one line for each in my OnLoad method. It's not just reducing the number of lines of code but readiblity that's key here.
So any thoughts on these two approaches? Preferences? Ideas? Comments? Small unregistered marsupials?
-
MSBuild, NAnt, NUnit, MSTest, and frustration
Oh bother. Visual Studio 2003 and Cruise Control.NET. Simple and elegant. A basic NAnt script to build the solution and you're good to go. Run NUnit, output goes to a format CC can understand and Bob's yer uncle. Let me quantify this. Our cruise server has a subversion client (command line) and the .NET 1.1 SDK. Visual Studio isn't installed because, duh, it's a server and cruise just needs something to build the system with.
Enter Visual Studio 2005. I just recently setup CI for our 2005 projects but it's just plain ugly, in so many ways. First there was trying to get the system to build using MSBuild. That was fine because you can simply enter this:
msbuild /t:rebuild solutionname.sln
(or whatever target you want like Debug or Release)
Like I said, if that's all it was no problem but it gets real ugly real fast.
First there's VSTS unit test projects. The team is all equipped with Visual Studio Team Suite. An expensive proposition, but one made long ago by someone wiser than me. No problem though. We're not really using the Test Manager much, there are no automated web tests, so we just write unit tests (and run them with Jamie Cansdales excellent TestDriven.NET). However when MSBuild gets ahold of a solution that contains a VS unit test project it needs some additional set of assemblies (assemblies buried in the GAC_MSIL and other places). The snippet in the ccnet.config file to get MSBuild going was pretty straight forward:
<msbuild>
<executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable>
<workingDirectory>D:\ccnet\projects\ProjectName</workingDirectory>
<projectFile>SolutionName.sln</projectFile>
<buildArgs>/noconsolelogger /p:Configuration=AutomatedBuild /v:diag</buildArgs>
<targets>Build</targets>
<timeout>600</timeout>
<logger>C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger>
</msbuild>Through brute force (run MSBuild, figure out what assembly it needs, go find it, lather, rinse, repeat) I was able to get a 2005 solution (with unit test projects) to compile. However actually running the tests is another story. Again brute force reigned supreme here as I trodded through an hour or two of running MSTest.exe to try to coax a couple hundred unit tests to run. The cc.config entry for getting some unit tests looks something like this:
<exec>
<executable>C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\MSTest.exe</executable>
<baseDirectory>d:\ccnet\projects\ProjectName</baseDirectory>
<buildArgs>/testcontainer:Source\Tests\UnitTests\bin\AutomatedBuild\UnitTests.dll /runconfig:localtestrun.Testrunconfig /resultsfile:testResults.trx</buildArgs>
<buildTimeoutSeconds>600</buildTimeoutSeconds>
</exec>Remember that I said this sever did not have Visual Studio installed. For the VS2005 solutions, I just installed the .NET SDK 2.0 and that was good enough. Although MSTest.exe isn't included, I snagged the file (and it's crazy set of additional DLLs scattered all over the hard drive) from another system and stuck it where the EXE was so it would be happy.
No dice on running MSTest against a unit test project. It started down the path of running the test, but then hit a crazy COM error (CLSID not registered) and that was enough for me. No way I'm going to track down all the stupid COM registry settings for Visual Studio 2005. And what the hell was this? COM? I thought we got rid of that about 3 compilers ago?
So I was stuck to installing a full Team Suite on the server. Okay, I'll bite. I mean, I don't need everything so it'll be okay (I keep telling myself as I watch a million registry entries fill up). A few hours later and I'm staring at my command prompt again and type in my MSTest.exe command. And a dialog box pops up. Yup, a modal dialog box that tells me something is wrong (I don't remember the specifics but it wasn't very informative).
Visual Studio was installed fine and I could compile and run and build the solution I was trying to, but testing from the command line with MSTest.exe was a no-go. No matter how hard I tried, how much I cleaned up, or how many virgins I sacrificed it just won't go. And there's another problem. With 2003 and our NUnit tests, we go some nice stats. Timings, informative messages, all that good stuff. With MSTest we get nothing (other than x number of tests ran and maybe a failure, but I couldn't get that far to see if it would give the details of the failure). On top of that, the MSBuild logger bites and produces about 10,000 lines of gobbly-gook that isn't very useful. Yes, I could spend my time writing new xslt to make it pretty, trim out the "Everything was okay" lines that fill up the MSBuild task logger but I think that's not value-added at my rates.
Here's a sample email I got from the build which gives you an idea of how useless a CC.NET/MSBuild/MSTest combo is:
BUILD SUCCESSFUL Project: PROJECTNAME Date of build: 12/8/2006 8:08:30 AM Running time: 00:00:55 Integration Request: intervalTrigger triggered a build (ForceBuild) Errors (1) D:\ccnet\projects\PROJECTNAME\Source\Reports\ServerReports\ServerReports.rptproj (2,1): error MSB4041: The default XML namespace of the project must be the MSBuild XML namespace. If the project is authored in the MSBuild 2003 format, please add xmlns="http://schemas.microsoft.com/developer/msbuild/2003" to the <Project> element. If the project has been authored in the old 1.0 or 1.2 format, please convert it to MSBuild 2003 format.Warnings (1) Source\Reports\ServerReports\ServerReports.rptproj (,): warning MSB4122: Scanning project dependencies for project "Source\Reports\ServerReports\ServerReports.rptproj" failed. The default XML namespace of the project must be the MSBuild XML namespace. If the project is authored in the MSBuild 2003 format, please add xmlns="http://schemas.microsoft.com/developer/msbuild/2003" to the <Project> element. If the project has been authored in the old 1.0 or 1.2 format, please convert it to MSBuild 2003 format. D:\ccnet\projects\BRMS\Source\Reports\ServerReports\ServerReports.rptprojTests run: 0, Failures: 0, Not run: 0, Time: 0 seconds No Tests Run This project doesn't have any tests Modifications since last build (0) It's ugly. Really ugly. MSBuild produces a ton of crazy output. Writing a new MSBuild file is no walk in the park and even for someone like me that knows NAnt quite well, I'm still wrapping my head around how MSBuild does stuff. I had to create a special configuration inside of Visual Studio to omit our Report project because MSBuild can't build them (hence the target AutomatedBuild above which is not the same configuration that our developers use and something I don't like doing because that's one point of a CI server, consistent builds for everyone).
From the output above, Cruise said the build was okay but there's an error message that came out of the MSBuild logger (our report project). This is a 2005 project so the information makes no sense (I belive it's a bug that's logged but who knows when it might get fixed). And I really can't integrate the MSTest output into the email because, well, there is none. There's a hundred tests or so in this project but the logger doesn't produce anything.
Additionaly, there are some project types MSBuild can't handle and again, it takes a rocket scientist to create an MSBuild file (even using something cool like MSBuild Sidekick) that can call another MSBuild task and exclude certain projects. This certainly isn't as easy as it was in 2003 where you just created an exclusion list (we excluded our client app as there was no extra license for the grid control and a modal dialog came up when the trial version was even looked at by the compiler).
Okay, this is mostly a rant but there's some wisdom here. Continuous Integration does not need to be this hard. CruiseControl.NET is an excellent tool and very flexible with new tools and integrating output from those tools. However when those tools require a million registry settings and even more DLLs (put in very specific places, trust me, you can't just toss them in the GAC and call it a day) and dump gobs of XML that no mere mortal (well maybe DonXml could) would be able to translate, it's just wrong. And as for the built-in Team Build that you could us, that's equally as useless as a) you can't schedule builds to trigger off of code checkins and b) again it requires a full Team Suite client to be installed on the server. Worst case scenario when I first started setting up CC.NET servers it took 4 hours. Now I can get it done in an hour (which includes testing the build of the first project). I've already spent a good day on just trying to get something to compile. It's compiling now but the output is crap and no running of tests and thats just not good enough for me. You can get MSBuild and (maybe) MSTest running with CruiseControl.NET. It's not impossible. If you install the full client and your projects are "just right" it'll work but the output isn't that hot and you'll watch your server CPU slam when compiles happen.
My advice, avoid trying to combine MSBuild, MSTest, and CruiseControl and stick to NAnt, and NUnit (using MSBuild if you have to when building 2005 solutions).
Needless to say I'm looking at one option right now. Dumping the install of VS2005 on the server, changing all our unit tests back to NUnit and using NAnt to do everything (and just calling MSBuild as an exec task for VS2005 projects). I still need to run 2003 projects so our CI server is going to look like a Frankenstein monster by the time I'm done, building VS2003 and VS2005 projects, running NUnit, MSBuild, NAnt, Simian, FxCop and whatever else we have in our mix. Even given that, using NAnt the output will be simpler (and integrate well with CC.NET), test output will be useful and informative, and I don't need to install a $15,000 piece of software on a server that has the distinct possibility to pop-up a modal dialog someday when it can't find some registry key.
Grrr. Argh.