In my time at a major insurance company in mid-state Illinois, we had a very interesting conversation on what it meant to be “done” with a user story. Done can mean a lot of things to a development team, anywhere from “hey, I just finished writing this code” to “we’ve turned on the feature in production.”
We created what we called a “spectrum of done” to illustrate various levels of “done-ness” (okay, enough with the “quotes”), and to help teams decide where they wanted to be when they said something was Done. Some of the highlights are:
- Code compiles on the developers machine
- Code compiles on a continuous integration build server
- Code passes regression test suite
- Functionality reviewed by the product owner/stakeholders
- Functionality deployed into test environment and tested with mock integrations to other servers
- Functionality deployed and tested with integrations to other real servers
- Functionality deployed into production
- Functionality used in production for some period of time
I submitted, only half-joking that we were really only Done with a feature when we turned the system off, because before that it was still subject to change or finding a problem.
There are a lot of reasons why you want your definition of Done to be as advanced as possible, but possibly the most important is that you want the best possible idea on whether you have anything left to do on a particular feature before it can be used in production. Measuring by what’s Done vs what’s not Done requires that you have a diminishing chance that when you say it’s Done, that there’s still something left to do.
The other side of this argument is that we want regular feedback on small chunks of functionality in order to give us regular data points to judge progress, and the amount of time you typically need to invest gets much bigger as you move up the Done scale. Deploying to production environments in the typical company requires change control procedures, and that means time and money.
The sweet spot for most folks seems to be in building on a shared development server, with some sort of robust suite of tests to assure that new functionality is at least working per the tests, and that nothing that used to work was broken (subject always to the suite of tests being reasonable). This most folks will recognize as Continuous Integration (although you should really read Continuous Integration isn’t a Tool!)
Keith returns to consulting on 9/1/11 after a year at RedSky Technologies. He’s currently looking for his next engagement.
The astute reader will have noticed by now that I haven’t posted anything in a while… back on September 1, I accepted a position as Vice President of Engineering for RedSky Technologies (http://www.redskye911.com), and it’s been keeping me pretty busy.
I’m going to keep Adept Technologies around, but don’t expect to be doing much with it for a while. I’ll continue to blog here off and on, but getting things working at RedSky is my current number one priority.
Thanks everyone for reading, and keep a look out for the occasional post here.
July 16, 2010 | Leave a Comment
I spend a lot of time talking to people about information security. I find that even when they’re interested in protecting their information from theft or misuse, they’re not always focused on the complete security picture. Today’s case in point is the report [via Gizmodo ] that thieves spent NINE HOURS stealing laptops from a government contractor, loading up two semi tractor trailers with computers before making their escape.
It does little good to pay attention to digital security if your physical security is weak. Security needs to be treated in a holistic fashion in order to be effective.
I’ve come to suspect that my blog is the victim of spambots that have decided they might be able to do something interesting if they sign up for an account. Maybe they think they get author privileges once they have an account, but I restrict that role to myself (at least for the moment). I’ve put up with it for a while, since I believe there’s no harm in them signing up, the only new superpower registered readers get is “subscribe,” I believe.
It’s been making me uncomfortable however, because I’ve not spent much time keeping up with any security concerns in WordPress (the underlying blogging platform), and since I get an email every time a new user registers, it’s never too far from my mind…
As a result, I decided today to turn off the “anybody can register” feature. I’m also debating going through my user rolls and deleting the obvious spambots (anybody in .RU for starters, since I can’t imagine I’m much interest to someone in Russia…)
In the event I do decide to start going all Stalin on the registered user rolls, I put up another post, so people can let me know if I delete them and they really were interested in having an account.
We now return you to your regularly scheduled web surfing, already in progress…
Over the few years, I’ve worked for or as a consultant for three different start-ups, and they’re a roller coaster. Two of those have gone out of business, and the third is my current client.
This morning, my client told me they are planning on managing their cash flow problem by making it at least partially mine: I’m back in the market looking for a new engagement, starting basically immediately. It’s the consultant’s life, I realize, but it really doesn’t make it that much more comfortable.
So, if you or someone you know is looking for a first-class Java architect (very hands-on), agile coach and/or application security specialist, please get in touch.
I spent the last two years working for a Very Large Insurance Company, and before that I’ve worked with a number of different sized companies, with various sized development organizations. It’s got me thinking: just how easy is it for a big development shop to be agile? Read more
I’ve gotten into several discussions in the last few months with various people who work at my current client, and a surprising number of them think that continuous integration is a tool. The conversation usually starts when someone says something like “We’d like to be doing continuous integration, but we can’t get the server set up correctly.” It’s a this point that I have to chime in and let them know they don’t understand continuous integration. Read more
Some time ago, I posted an article on how to enable dependency injection with a Spring and Struts application. In the meantime, I’ve come across an inefficiency in that article, and wanted to update my loyal readers (both of you
In the previous article, I mentioned that you create Spring beans for each of your actions in the Struts-Config.xml file. Two such beans could look like this:
<bean name=”/login” class=”com.adeptechllc.myapp.view.action.LoginAction”/>
<bean name=”/logout” class=”com.adeptechllc.myapp.view.action.LoginAction”/>
and beans such as this would work fine, except for a subtle point: because we’ve listed two different beans, but the same class, we’d actually get two instances of the LoginAction created. Since typically we want only a single instance of our actions, this could cause unexpected and difficult to diagnose problems later.
In order to only create a single instance of the LoginAction class, you can use an alias in Spring. I’ve started creating a single bean for each action, the aliasing the Struts actions to that single instance, like this:
<bean id=”LoginAction” class=”com.adeptechllc.myapp.view.action.LoginAction”/>
<alias alias=”/login” name=”LoginAction”/>
<alias alias=”/logout” name=”LoginAction”/>
You can also simply provide more than one name or ID directly in the first bean definition, but if you have a lot of URLs directed at a single action handler, I find this easier to manage.
One of my project teams was having a sprint planning meeting earlier this week. They were having a consulting expert working with them this sprint to develop a web service for their use.
“Have you worked with user stories before?” the project manager asked. “We’ll need you to give us a story point estimate for the work you’re going to do for us.”
I chimed in at this point. “Remember, story points are relative estimates of complexity. If our colleagues here are only doing one story for the project, then their story point estimate can’t really be relative to anything else they’re doing for us: they’re not doing anything else.”
This points out one of the things that I think is so tricky about agile projects. If you forget why you’re doing something, or worse yet if you don’t understand why you’re doing something, then you’re likely to do it at the wrong time. In this case, the project manager did know why we estimated story points for stories, but he’d forgotten the why, and was operating a bit on auto-pilot: the team needed to provide story point estimates for their work, and he’d momentarily lost track of why.
Agile’s lots of common sense things like this, but if you forget what your goal is, and fall back on patterns of behavior, you can do the wrong thing.
In a recent post I talked about ATM skimming devices. It seems from a recent article in Wired that theives have taken ATM fraud to a new high. In Europe machines have been found that have been compromised with modified software, which eliminates the need for card skimmers or cameras. It requires someone with insider access to install the software on the machine, but it definitely ups the ante quite a bit.
The malware captures account numbers and PINs from the machine’s transaction application and then delivers it to the thief on a receipt printed from the machine in an encrypted format or to a storage device inserted in the card reader. A thief can also instruct the machine to eject whatever cash is inside the machine. A fully loaded ATM can hold up to $600,000.
Where before you stood a chance of spotting a card skimming device on your neighborhood ATM, with this scheme you really have no idea whether the machine has been compromised, since it’s all in software.
The good news is it seems like more recent ATM machines have newer security measures that make the attack ineffective. On the other hand, how long has your bank had their current ATMs?
[ Original story at Wired ]keep looking »
- Ars Technica
- Dark Reading - IT Security
- Help Net Security
- SANS Internet Storm Center
- Schneier on Security - Dr. Bruce Schieier’s blog
- Security Info Watch
- What to Fix - Daniel Markham, fellow consultant
- Wired Gadget Lab
- Wordpress Documentation
- WordPress Planet
- Wordpress Support Forum