Up until yesterday we tracked lead-times on our Kanban-board by noting the dates that a feature entered each of the columns. This causes problems since some project members doesn’t yet have the discipline to write down the date when they pull a feature, and it also mean we have to account for weekends, holidays and so on when calculating the lead-time.
As of yesterday, our Kanban board has a colored marker at the top of each column. During the standup meeting each morning a team member or two makes a small mark on each feature using a pencil the same color as the color of the column it’s currently in. This makes it very easy to see how long a feature’s taken to move through the entire process, and by looking at the colors we can see how long it’s been in each stage which of course helps us optimize the process.
We use whiteboard markers to make the mark at the columns, and colored pencils to mark each feature-card, so you don’t have to run off and buy a bunch of magnets or anything. It’s real easy to implement, and I’m quite proud of having such a simple idea that can (and hopefully will) have such a large impact on planning and estimating :)
I get this question a lot by developers, both budding SharePoint developers and grizzled veterans. Well, the veterans mainly ask what the point of using Render is…
It’s quite simple, really; if you want interactivity then you need to override CreateChildControls() (and remember to call the base method as well), while if you’re only displaying data, go ahead and override Render().
Overriding Render() can save you quite a bit of memory and increase performance a lot, and since the majority of webparts tend to be about simply displaying data in different ways, by all means go ahead and use it.
I love Specflow. In fact, I rarely write a line of code unless a feature forces me to. It’s a wonderful tool and it’s Visual Studio integration is better than a lot people know. Here are a few things you may not know about.
Go to definition (F12) on a clause will take you straight to that step definition.
Are you running the tests in order to have missing steps generated so you can cut/paste them? This leads to a ton of Pending steps all mixed up and hard to maintain. Hit F12 on the clause you’re going to implement RIGHT NOW instead, and SpecFlow will place the definition, if missing, in your clipboard so you can stick it in the correct place.
Open a feature file and right-click on a single scenario. Choose Run SpecFlow Scenarios and only that specific scenario will be run.
If you’re using SpecFlow for SharePoint development you’ll know that SpecFlow will break your SharePoint features. Once you add a new SP feature, right-click it and clear the custom tool property in the property pane. The broken code-behind will be removed and things will work.
You can set breakpoints in your feature files, just be sure to select Debug SpecFlow Scenarios.
I keep finding new things about this tool, so I’m sure there will be more findings posted.