I'm not sure how far back this feature goes but I just discovered it yesterday, thanks to Michal Talaga.

When you follow the practice of defining your test before you write your method, you lose out on the beauty and addicting convenience of intellisense.  Since Visual Studio.Net v1.0, I have become dependent on intellisense to keep me productive and assist me in typing out long method names.  Having to type them once, and then again, sucks...

WOW, check out what is available when you write a method that doesn't exist!

Now I seem to recall running across this before but I was not yet privy to TDD.  As it turns out, this is even faster then waht intellisense gives you because the method signature is shaped according to the variables you pass in. 

Try it out and see if you don't also feel it was the missing piece of your TDD puzzle.

This is far from complete but it is working and that is where I wanted to get it before letting others have a look.

Please let me know if you try it and how it works for you.  I would LOVE some feedback from someone with a different subscription from mine just to ensure that it works generically.

Currently it only supports a user story workspace and you can only update certain fields on stories and tasks. 

I'll be updating this regularly.  Eventually, I plan to post this on sourceforge but for now you can download it from me bloggernaut.

RallyDev.VSAddIn

RallyDev.zip (download) note:
note: there is an error in the "RallyDev.VSAddIn.AddIn" file found in your "My Documents\Visual Studio 2005\Addins" directory.  Please open "RallyDev.VSAddIn.AddIn" in notepad and change the line <Assembly>RallyDev.VSAddIn.dll</Assembly>
to
<Assembly>RallyDev.VSAddIn\RallyDev.VSAddIn.dll</Assembly>

I'll fix it later but my wife is hovering over me wishing me to stop working on this for a moment!

I'm writing an Add-In that provides a Rally Agile Project Management Software interface inside Visual Studio.  I was feeling a little jealous of the people using Microsoft Team Foundation Server and realized that the consolidated development experience is critical if one wants to get the greatest benefit from the tools they invest in.  I sometimes won't check my email for two days because Lotus Notes takes too much memory and too long to load.  Its not a matter of not caring, its a matter of limited resources and screen realestate.  I also believe that convenience encourages compliance.  Make it easy and painless and people won't mind participating. 

Now that I have a start, I am excited for what new possibilities might present themselves.  For example, if an add-in were to show a test case, then perhaps a developer could drop a test case onto a unit test to associate that code with that test case.  Hmmm, one step at a time.

I still have to work in paging, provide the ability to search tasks first (currently, I'm querying for stories then showing child tasks), provide more detail about each item, allow a user to add tasks, allow them to reassign tasks or stories to other users and link back to the appropriate url in Rallyin an intelligent way (doubleclick?).

Here are some screens to wet your appetite.

 

Today the Rentals.com team joined up with out RentClicks counterparts to estimate a joint project that was less the trivial in scope.  We started with a simple model of where we were and what needed to be changed, in what way, and then broke that down into digestable chunks.  We estimated each one as a team and I was surprised by how easy it was to have agreement with vague requirements.  We had a feel for what we needed to do and a hunch as to how long it would take.  Its fantastic to see the team operating as one with such efficiency.

After we logged points for each story, I counted up the points and came up with what represented, according to our time to point conversion factor, 10 developer weeks.  A quandry came over me as I realized we'd landed two months late on our current release and began to wonder how to factor that into our planning.  It is not reasonable, after all, to assume the same thing would not happen again.  A suggestion was made to bloat the estimates with a fudge factor.  This is the traditional way to account for unforeseen circumstance when plannig a project.  I think this would take 3 weeks so I'll add 30% to account for things that I haven't thought of.  I used to do this myself with amazing accuracy.  I'd tack on 30% to all my estimates and I would almost always be right on the money.  Something didn't feel right, however, with that approach.  First, this was essentially just lying strategically.  We think it will take two days so we'll say three?  Considering the whole purpose for using points in place of time is that you can adjust point translation according to circumstance...  ah hah!  The amount of work you can accomplish per iteration is called velocity.  Don't adjust the estimate, adjust the velocity!

During our last project, we lost one developer and I was split between two independent products.  I was also distracted with unrelated initiatives that sucked most of my time and energy and effectively lost me to the team.  This contributed to our missed Dec 20 target date.  Missing that date introduced the holidays which pretty much eats a week.  Then a separate, unplanned release was inserted right in the middle that caused a slide in both schedule and scope.  None of these things were accounted for in our project plan.  When something impacts the project, its important to reflect that in some visible way against one of the vectors of the project projection.  Its either going to complete on some other date or scope myust be adjusted to accomodate the changes.  The preferred approach is to adjust scope.  I did not and therefore had no idea when things would wrap up until the project started to show a steate of completion.

The appropriate thing to do would have been to subtract the scope of the developer who left and calculate the new velocity.  Then we should have reduced the scope of that iteration to meet the date planned for delivery or, if necessary, change the date. 

Looking back, this is what makes the most sense going forward.  Rather then fudge the estimates in some arbitrary way, I've tried to calculate the impact of the lost developer and the holidays and factor in the intermediate release.  From there I think a 30% factor is appropriate for adjusting or plan.  Rather then bloat the estimates, I will reduce velocity for iteration planning by 30%.  This will visibly show that we are experiencing some inefficiencies that have reduced our productivity.  If this is concering to decision makers, its a great topic for conversation.  Why have you reduced your velocity to 66 points per 2 week iteration?  ...well, our last release was off track and we're adjusting to reflect that something is slowing us down.  Our goal is to bring that back up to 80 points per week and we're activley seeking ways to accomplish that.  The reduced velocity will keep everyone aware of our present condition.  That's not a bad way to talk about it.  Its a good measure to keep an eye on and set a goal against.  In fact, the two new developers on the team will only provide a fraction of their optimal velocity until they are through the HR hurdles, familiar with the product and work flow and have their environment configured.  Now its really making sense.  We have a logical way say, "this is a two week task but it will take us a little longer."

Frankly, this was a good day

I've realized something valuable after reading http://martinfowler.com/articles/itsNotJustStandingUp.html.  A pattern emerged on my present team where people show up to work around 10am, usually.  Sometimes they call in to the scrum and lately, often really, we end up with more then one caller.  Frankly, more times then not, the caller is me.

I have been curious as to why I have shifted my schedule unintentionally and why the whole team now works a later day.  We all have families so its unlikely that anyone is out partying late into the night.  The article pointed out that the daily stand-up either starts the day or it doesn't.  If your stand-up is in the morning, make it appropriately early so that it kicks of the core work hours.  If its not on by, say 9:30, move it to the afternoon.  Psychologically, the team will associate that meeting with the beginning of their day and they won't be motivated to begin any work until that commitment is behind them.  This is perfectly normal and makes sense in hindsight but it hadn't occurred to me until I read it.  I'm not advocating strict working hours or even suggesting that a later start is inherently bad, merely that one should be aware of scheduling impact.

I believe there is tremendous value to starting the day with the daily stand up or "scrum".  Don't wait until its is convenient for everyone to be present.  Rather, schedule it at a reasonable time that everyone can agree to be ready.  9:30 for example.  The team should plan to be at work around 9, log in, check their email, reboot Windows 6 times, and fill their coffee.  Then, at 9:30, come together and hit it like gangbusters. 

Granted, if the team is composed of a bunch of young punks who like to stay out late and prefer to start work at 10 am and work into the evening hours, there is nothing at all wrong with a 10:30 scrum.  Adjust accordingly but understand the impact of your kick off time.

I've read and been told that a transition to Agile is not an easy undertaking.  I under-estimated the resistance I'd receive to documented techniques and practices when the organizational leaders announced that it was their intention and desire to: "abandon our heavy waterfall process and go Agile."  I'd convinced myself that this was something that would be easy to sell once it came from the top.  I've come to realize, appropriately, that change takes time, even good change.  If its worth doing, its worth doing right and if it were simple, it'd be done already.

We recently had a meeting to discuss what documents wereto be authored, by who, who owned them and who the approvers or reviewers were.  A business counterpart of mine continues to ask about when "hand-offs" should occur.  Many insist that story cards are not adequate to convey requirements.  Business owners prefer a proxy from whom they channel all their communication with the team doing the work. 

I work with a left handed individual. When I sit at his computer, I cross my right arm over my left and operate the mouse with my arms tangled over one another.  Two other techniques that work much better are either to move the mouse over to the right side of the computer (revert to previous process) or to use my left hand on the mouse (adopt a new, unfamiliar technique).  I've found I am perfectly capable with my left hand operating the mouse.  However, Its slightly uncomfortable.  So I find myself crossed and bound up thinking that something must be wrong with this left-handed programmer.  I know, however, that my natural habit is the real cause for challenge and with practice it would feel more natural.  I'll have to remember to be patient and considerate of these long-established habits.

The ironic thing is that it was actually easier when everyone else stated that they were in favor of waterfall and I quietly and confidentially began researching how to manage a project with less ceremony and demonstrated the results of it in small, project by project, increments.  The first three projects lacked significant aspects of an Agile project but began to show the merits of the movement.  The most recent, http://preview.rentals.com,  lacked only frequent delivery to production.  We'd go as far as qa, then stop.  However, we were by no means fully implementing an Agile process.  We had facets of it: continuous integration, small iterations, automated unit testing, frequent communication, reflective review, collaboration, story card based development, just in time elaboration, pair programming, and others.  We still tested at the end of each iteration (not ideal) and some project contributors were outside the development process with little accountability.  We'd do sub-optimal things like extend dates to finish testing or fit a few extra features in.  Our review meetings would be postponed a week after the iteration was complete so that feedback from that review may affect work already completed.  I'm definitely learning as I go, we all are.  I am truly a fanatic about the change in approach.  However, there's a backslide happening lately...

In a book by Robert Pirsig - Lila, the author describes evolutionary change as having a ratcheting effect.  Things change, begin to fall back a bit, then they stabalize.  Then they change a little more, fall back a bit again, then stabalize again.  Stable patterns persist until mutation, or dynamic patterns, cause some change in the overall model.  If the new pattern has staying power, if it is superior, it will stick, and eventually become a static pattern.  If, however, it is unstable, it will fall back to the previous static pattern from which it evolved.  The static patterns are represented by the majority and the dynamic patterns are represented by the innovators and the rebels. Obviously, not all things persist.  Some good changes will be overtaken by a powerful competitive majority.  Sometimes several ratchets are needed to complete a massive redirection of behavior and sometimes people will have to fail before they will succeed.  Edison said that every failure is just one step closer to eventual success, or something like that.

My last note is that eternal question of: if there is no one in a forest who cares if trees stand or fall, should you bother to cut them down?  ...and if you do, should you do it your way or someone elses way?  ...and what the hell was I thinking getting into luberjacking in the first place?   I thought I was a guitar player

I know this probably seems quite intuitive, and now that i've discovered the solution it is, but I still thought it worthy of blogging.

When configuring CruisControl.net <webURL> node in ccnet.config, html encode the string value.  After all, its in an xml config document.  I was trying to url encode it, which didn't work, or include it raw, which violates xml rules.

The correct config setting looks something like this:

<webURL>ttp://buildbox.corp.mycompany.com/ccnet/default.aspx?_action_ViewProjectReport=true&amp;server=BuildBox&amp;project=MyCompany.Project1</webURL>

The exceptiont that is raised in the cctray is bizarre.  At the moment, I can't even get it to blow up for me and I'm over messing with ccnet.config today.

happy building

"Download CCTray" link fails?  The default installation of CruiseControl.Net dashboard worked almost perfectly out of the box.  However, the link to download the CCTray fails.  Following some investigation of the configuration file and iis settings, I found the simple solution.

<cctrayDownloadPlugin />

When I installed the CruiseControl.Net application under a virtual directory in IIS, the default setting for directory permissions was "scripts and executables". 

This caused a 404 to result from clicking the link provided for CCTray installation (provided by the cctrayDownloadPlugin).    The more appropriate, and correct, setting is "scripts only". 

Right click the virtual directory in IIS Admin mmc, On the virtual directory tab, under application settings, set execute permissions to "Scripts only".

By the way, this is an iis default setting, not a cruise control installation.  Furthermore, CruiseControl.net is probably the third most incredible open source product I've ever had the pleasure to use. Third after nAnt and nUnit (although nAnt deleted my c: drive last week...  lost a little love that day).  I am presently addicted to the green tray icon and the dashboard itself. I love seeing "another successful build" pop in the corner of my screen.  Thanks CCNet dudes, you rock!

Posting this because my newsgroup post got no response :>(

I have the folder cctray below the webdashboardlink  root and it contains the

setup file for cctray

Yet, when I click on the link provided by the plugin:

./ccnet/default.aspx?_action_CCTrayDownload=true

i get a 404

any suggestions? ( solution described above )

I managed to get each project set up independently.  I hightly recommend starting with the latest CCNet bits.  I upgraded after I had 0.6 working and regretted it.  Open source folk tend to get a little inconsiderate with breaking expected features, config and interface.  Its free, its their perogative. 

One thing I found with version 0.8 is that you really should stick to absolute file paths for any config path you specify.  There is a new "WorkingDirectory" at the project level.  It seams inconsistently handled when using relative paths in other sections of the config file. 

Eventually, I got 0.8 working.  I have a cruise.build file whose purpose is to clean the project directories, get vss latest source, and call the actual build file that is retrieved from the source project.  In addition, it copies the result of each project build to any necessary consumer projects before they can be built. 

The default target "run" performs the whole solution build.  Each project has a target for: run-, clean-, get-, copyDependencies-, build-.  The build target calls the project specific nant build file in the source directory after the get- retrieves it.  The called build compiles to a directory "build" parallel to the source directory.  The cruise.build file expects this and copies artifacts from the "build" directory of the compiled project to the "source" directory of any project that uses that assembly.  This means a "solution build" must occur before any single project build will work.  That's fine.  I create a Solution project in ccnet.config.  I have a faked out sourcecontrol config block (vss path points to a deep image directory within one of the projects) and specified a forceBuild once per day.  That's my nightly build.  It also calls the target deploy-webProject.  This backs up web.config, deploys the project to two dev servers, then replaces web.config.  The first thing to do is force a build of the solution.  Then, once each project is set up initially, the source control monitor can take over.  I forced each individual project just to get each project into a successful state.

All my projects copy their log to the same web dashboard.  This works out great.  Thre project name is listed with each report. 

The ccnet tray is so sweet.  I love watching the build happening and then the "woohoo" when it all works.  I read a post on attaching lava lamps to X10 autmoation controls to indicate the build state via retro coolness. I'll link to that tomorrow

I've been building using nAnt for about two years now.  each project in our enterprise has a nant build file.  This file expects all dependencies to be available either in the root or the bin directory, whichever is appropriate.

I built a custom build utility application that manages inter-project dependencies and the build process.  It has served us well.  At least I think it has.

I want to move in the direction of more iterative development and integration.  Today, I took a first step.  I set up Cruise Control to operate on our enterprise projects in VSS. 

First I had to create a build file that would set up the entire suite from visual source safe.  This isn't that hard to do when dealing with the latest files.  So I created one target for each project, specifying where to get the source files from. 

Then I worked from the most stable project (with the least dependencies and the most consumers) to the project with the most dependencies, setting up the call to the build file in each source directory and then the copy of the next project's dependencies into its source directory (or bin, where appropriate).

It was enlightening to go through this exercise!  I found that each project, almost without exception, built on top of its child projects dependencies.  Example: (in this case, project refers to source and assembly refers to compiled result)  Project B depends on Project A.  Project C depends on project B and A.  However, project B contains the result of Project A, as it is required for project B's assembly to operate.  Some people may not want to keep a copy of Assembly A with Project B's build result but I think it makes sense.  That way, you can use Assembly (or project) B without worrying much about Project A as long as you get Assembly A when you get the artifacts of Project B.   Therefore, you do not need to explicitly manage Project C's dependency to Project A if you get the related assemblies for Project B.  When its time to set up the dependencies for Project C, just get the compilation result of Project B.

There were a few 3rd party dependencies that needed to be explicitly retrieved from VSS but the final build file was manageable and logical.

Once the build file was set up, I moved on to Cruise Control integration.  I had set it up previously with a small test project.  This helped a lot.  It took the complexity described above out of the equation.  I had only defined one project, previously.  I replaced the test VSS path with the real one and was in business, almost.  First, the change monitor in the sourcecontrol plugin gets the files to a local directory.  I am curious as to whether I can use the same directory for the monitor and the build.  I think its likely that the above mentioned dependency management may corrupt the modification monitor process.  I'll experiment with that and report back.  Second, I have all these inter dependent projects as part of an enterprise solution.  I don't want to monitor and build them independently, I want to integrate them!  Continuously.  That's the point, right?!  The latest version may handle this better, the version I used is out of date. 

So that is the experience so far.  I plan to put together a step by step for those who dare to venture down this road.

Bottom line?  if changes are integrated sooner, problems are caught earlier and resolved immediately.  Developers have, fresh in their mind, the changes that need to be assessed.  If tests can be introduced a little at a time, the application can slowly become more stable and dependable.  If development can be reviewed in a stable development deployment without developer interruption, sponsors and managers can have provide better feedback and more contribution to the overall development effort.  Its a communication tool.  It communicates how things are going.  I like that, it makes me feel comfy.