Showing posts with label work. Show all posts
Showing posts with label work. Show all posts

Thursday, May 21, 2009

User story maps and use cases

I am three days old in my new position at my new employer, Osiris Data, and one of many exciting things that happens here are the always ongoing discussions on how we do things around here.

This time, I asked Terje on what they expect from design and inception, and we quickly went into a friendly debate on Use Cases in general and how to write them.

Two tings I came to remember during the conversation seemed to struck a chord:

  1. The new user story backlog is a map.
  2. Why I still use use cases.

Jeff Patton explains why we need a user story map:

Arranging user stories in the order you'll build them doesn't help me explain to others what the system does. Try handing your user story backlog to your stakeholders or users when they ask you the question "what does the system you're building do?"

And Alistair Cockburn writes about why he still use use cases:

I’ve been testing this out for the last 3 years – I walk in and ask, “On your agile project(s), do you by any chance suffer from any of these three things?” ... and then list the three … Much stronger than even I expect, there hasn’t been a single organization I asked these of that hasn’t said, “Oh, Yes, and How!”

And those three things he refers to are:

  1. User stories and backlog items don’t give the designers a context to work from – when is the user doing this, and what is the context of their operation, what is their larger goal at this moment?
  2. User stories and backlog items don’t give the project team any sense of “completeness” – what I keep finding is that the development team bids/estimates the projects at (e.g.) 270 story points, and then as soon as they start working, that number keeps increasing, seemingly without bound. The developers are depressed and the sponsors are equally depressed by this. How big is this project, really?
  3. Related to completeness, user stories and backlog items don’t provide a good-enough mechanism for looking ahead at the difficulty of upcoming work (In principle they could, just in practice they don’t) – I keep hearing this complaint, “We asked our customer (product owner) a question and she/he took 2 weeks to get us an answer. We must have the wrong person in this role.” No, they don’t have the wrong person, they have a broken process – certain types of questions take a long time to research, as the various departments and user groups work out what is the correct, balanced answer for the whole lot of them. Staring at the set of extension conditions in a use case lets the analysts suss out which ones will be easy and which will be difficult, and to stage their research accordingly. User stories and backlog items are not set out in that granularity early enough on for that assessment – the extension conditions are usually detected mid-sprint, when it is too late.

Friday, May 15, 2009

Will IT show it’s foolishness next?

In Too much experience could be hurting your IT job search, it’s argued that experienced IT professionals will get a harder time getting a new job. A CEO is quoted:

As a result many companies are focused on hiring front-line workers who can make the most impact on their business with the least amount of financial risk.

One commenter nailed it:

Inexperienced staff are always the riskiest to hire. I'm sure this can't be only obvious to me.

No it’s not. This is common sense, but as Voltaire once said:

Common sense isn’t very common.

We are, unfortunately, managed by too many people living in a cost-oriented world, where they equate cost to be equal to risk.  Eli Goldratt published The Goal in 1984. 35 years has past since then, and we have learned nothing.

Monday, September 03, 2007

Note Taking: A Beginner's Guide to Mind Mapping Meetings - Lifehacker

Note Taking: A Beginner's Guide to Mind Mapping Meetings - Lifehacker

The value of enjoyable work

This one got me thinking: Chinese Factory Worker Can't Believe The Shit He Makes For Americans.

I know the sinking feeling I get when I fail to see the value in my work. I usually get that feeling after working long hours over a longer period, without any meaningful progress. Or when I am idle. But I can't imagine how this poor fellow really feels. How awful it must be to do worthless things, day after day.

Now, some of the items seems worthless due to cultural differences. I mean, to me it is just as unusual not to have a car, as it is for a Chinese to have one. So a soda-can holder is valuable if its usable and your car doesn't have one built-in.

But all that other crap, which clearly is not built to last. Why do we buy them?

Sunday, August 27, 2006

Developing as a non-admin

I just got my new, shiny Lenovo T60p lap top. Since I had to reinstall my development environment, anyway, I decided to try to run as a non-admin.

The sad, short story is that it didn't work out too well.

The slightly longer story contains the pieces that didn't work:
  • Windows Update: Maybe it did work, after all. I am now an admin and can't see any new critical changes. But then it could be my Dorry-like memory (you know, the heroess from Finding Nemo): I think I added myself to the Admin group, re-logged on and ran Windows Update. Anyway, as a non-admin I could runas Internet Explorer as admin and run Windows Update, but not without strange error messages. And another thing: I prefer to download the changes and decide when to install. How do I do that as a non-admin? Seems like I can download, but after that there's no way to actually do the install.
  • Copying files from my old laptop: Not so much the actual copying, but I got trouble with file access and ownership. Windows let me take ownership, or so it seems, but the process aborts after half a second and without any messages. So did it work? In some places, yes, but there were folders and files I could read, but not move.
  • I like Unlocker. When I try to do something with a locked file, it pops up with the locking process and provides unlocking options. It failed with a messsage saying something about not being able to debug.
  • Installing msi's is cumbersome. I didn't find a workaround on that one, so I had to runas the command prompt as admin, cd to the msi folder and then run it.
There were a few more issues, but my I struggled with problems on how to run things as an admin, and strange failures when I did. It seems like Windows is not designed for this kind of usage.

I haven't experienced any problems in the past, running as an admin. No viruses, no hijacked homepages, and my web apps run as ASPNET, so I know immediately when access rights is a problem.

But I like the concept. My hope is Windows will support this better in the future.