This past weekend was Dallas TechFest 2011. It was a great conference filled with great speakers and great attendees. Despite speaking at 9am both mornings (which I consider to be far too early in the morning for...well, anything), I had amazing turn outs for both presentations. In short, I had a blast, I got to hang out with great people, and I even learned at thing or two. But I digress.
For the abridged version, just stick to the big italic text. ;)
The Setup
Having so many community leaders in one place at one time, on Friday night a Dot Net User Group leader meetup was held, and this meeting took the form of a fishbowl. Many questions were raised, most got answers, but of course others only wound up raising more questions. Something particularly fun that happened when Devlin Liles raised the question, and I'm paraphrasing: "Why are so many SIG (special interest group) websites so crappy?"
After we all kicked this around for a while, and all the arguments seemed to boil down to the fact that everyone uses different systems to organize their groups, and there does not exists a univerially accepted and easy process to integrate them. As the conversation wound down, I hopped up in the one of the chairs and offered to help spearhead a project to write some type of new website that could help solve these problems.
Then something really really cool happened: a show of hands was called, and almost everyone in the room expressed an interest in contributing to such an open source website!
We very quickly decided to hold an open requirements gathering session the next day at Dallas TechFest (coincidentally to be held in the CodeSmith Hack Room). This is just another example of why I love being a member of the .NET community. It shows just how fun, interactive, and giving the this particular geek can be.
The Problem
Our story continues Saturday morning in the CodeSmith Hack room. Almost three dozen devs showed up to participate, meaning that our numbers had already grown since the previous night! We started out by making two lists on the rooms white board, "this it absolutely must do" and "things it absolutely must not do". The lists were drawn up, votes were cast, and then the drill down debate began.
It took us an additional 45 minutes to realize that the mistake had already been made: We had all listed off similar requirements, but we all had different visions of what this website would actually do.
It took us a while, but we finally figured out that we were all using the same adjectives and verbs to describe different nouns. Finally we called a vote to discuss if we were talking about 1) a top down approach where the website collects and aggrigates data from other SIG sites, or 2) a bottom up approach where this is just an open source SIG website that anyone can host themselves.
So, why did it take us so long to identify the problem? Also, how could this miscommunication have been avoided?
The Solution
Countless statistics and case studies have pointed to the requirements phase as the key to determining whether not a project will succeed or fail. I view this as a modest reminder that no project is immune to this, especially not open source ones. I fear that developers, especially the rock stars who like to engage in open source projects, often forget this.
In my opinion, our particular situation could have been avoid if we had started by defining some basic use cases.
We started out by focusing on functional requirements, but depending on which permutation of these that we selected we would come out with very different products. If we had started out by defining some use cases, that might have helped us determine how our users would interact with this website and thus would have helped us better understand our functional requirements.
Examples
I am not saying that we should have broken out our UML Diagram tools. I am saying that by simply defining basic use cases we can help create a context in which to define functional requirements.
Here are some examples to help clarify this.
Objective: Create a website to help people find user groups.
Requirement 1: Must include user group information.
Requirement 2: Make events appear on a searchable calendar.
Requirement 3: Search for events by metroplex or geographical area.
Ambiguity: Is this a portal to other websites, or is it a hosting service for other websites?
Now, let's add two use cases (one for the end user, and one for the administrator) to clarify things.
Objective: Create a website to help people find user groups.
Requirement 1: Must include user group information.
Requirement 2: Make events appear on a searchable calendar.
Requirement 3: Search for events by metroplex or geographical area.
Use Case 1: Users may arrive at the website and see a list of upcoming events in their area.
Use Case 2: Administrators should be able to register their existing website with this portal.
Ambiguity: Not so much.
Anyway, I hope that helps!
~Tom
No comments:
Post a Comment