Reading the Spec
A few months back I held a Sprint Retrospective meeting after a fairly successful project release. We were going through the list of what went right and what went wrong when the issue of the Spec came up.
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
Arul: (slightly guiltly look) Well, we really should have written a better specification. We just copied the it from Phase I, and it got signed just before we delivered to QA.
Ed: Did anyone read the spec? John: I checked the HTML prototype a lot, but I didn't even look at the business rules document until after I had coded everything. Michelle: It's always easier to work from the mockups. Ed: So no one really used the spec document for anything, and maybe if we had put together a one page document on how we wanted to organize or project directory structure and naming conventions we would have gotten more out of the document. Arul: But we have to write a spec. Ed: Really the spec is just a design document for us to come to a common understanding. It sounds like we should just move the business rules elements into the HTML prototype since it's the only artifact anyone actually looks at. Michelle: But the PM won't stand for that they'll crucify us. |
Eventually I brought the team around to the idea that a traditional spec document wasn’t required for the project. As always old habits die hard, but we haven’t done any non-HTML spec documents for Phase III and it’s gone fine so far. If the HTML prototype is the one thing the developers find valuable, then the rest of the artifacts are just extra work. Some of the PMs are coming around to the idea as well one of them actually ran around a design document for signatures with one sentence in it, pretty agile.
$500 Barrier to IntelliJ Entry
Listening to JavaCast, a new podcast, I got to hear a bit of a rant by one of the hosts on he hated 30 day licenses like IntelliJ’s and that $500 was way too much of a barrier to entry. Based on my experiences I’d say there’s a bit of truth in the statement even if I think it’s way off base.
I’ve used at least 4 Java IDEs in addition to some text editors during my java programming career. I played around with JBuilder quite a few years ago, but never did much with it because the commercial versions were pretty expensive. After that I worked for a professional services shop that was an Oracle partner, so I used JDeveloper since we were trying to sell customers on the Oracle stack. As Eclipse began to build momentum, I picked it up along with a book since I found the interface pretty horrible to understand without it. When I started my current job the developers mentioned they used IntelliJ IDEA.
I’d of course heard of IntelliJ through it’s many raving fans at JavaRanch, the ServerSide and other sites. They all claimed that it was completely worth the cost, but I had never even tried it out because I didn’t need a new IDE and I couldn’t afford to pay for it.
Given the chance to actually use it, I downloaded it and ordered a license. The first thing I noticed was I was productive right away. I didn’t need to figure out perspectives or the plugin architecture. There was no weird forced directory setup for new projects and the CVS integration worked by turning on a single project setting, no need to even type in a password. The keyboard shortcuts were easy and straightforward. The refactoring features were very nice.
Now I’m not willing to give it up even though we’re in the process of adopting IBM’s toolset. Very much like the Mac OS itself it just works, and better yet it functions intuitively. I admit freely that Eclipse has pretty much the same feature set and certainly more options with all of the plugins available. Still, I won’t go back to it as my full time IDE after being exposed to the productiveness of IntelliJ.
The grain of truth is that a $500 price point did stop me from initially even evaluating it years ago. The difference was as a manager the 30 day trial and $500 price point made no difference, given how productive it was. All of my developers use IntelliJ now, and it has helped many of them as they worked through their first java projects. Many developers on another team use Eclipse and they find it fairly hard to use, since adjusting to things like perspectives can be painful.
So in closing I think IntelliJ is still solid Java IDE choice despite the price.
Pain with XPlanner
While XPlanner looked like a good solution for my problem, reality intruded when I got a 2 hour window to play around with it. It requires MySQL and a servlet container (Tomcat). In about 90 minutes on Friday I got it up and running.
Today I tried to setup a sample project or two with iterations, user stories and tasks. All of that seems to work fine. The problem would be that I can’t actually add team members and assign them to a project, a fairly significant problem. I went with blaming it on myself, until I came across a very similar bug. Apparently the fix is that after adding users you sometimes need to restart Tomcat. Unfortunately that didn’t work for me and the bug isn’t listed as resolved.
Next step was to drop back a version and try it. Unfortunately, the same problem, I can’t assign a person to a team. Next try is pulling the snapshot down from the Subversion repository. Or maybe I just fall back to the old excel spreadsheet.
Experimenting with XPlanner
Now that we’re starting to run multiple Scrum projects, I’m finding an excel spreadsheet not quite enough for organizing purposes. I looked at XPlanner and ScrumWiki today. Gave up on ScrumWiki pretty early since it’s Perl CGI based and doesn’t look like its had any active development for over a year. So that left XPlanner.
XPlanner is setup to work with MySQL, though you can use other databases since it implements its persistence layer with Hibernate. Installing MySQL on my work Windows laptop didn’t turn out to be too much of a chore, mostly wizard type install these days. No major hitches with XPlanner which is deployed as a WAR file. A minor item was that the current version of XPlanner isn’t compatible with Java 1.5 since it has the enum keyword in some of its packages. A quick addition of
1
|
source="1.4"
|
to the
1
|
javac
|
tags and the problem was solved.
Tomorrow hopefully I’ll get some time to play around with it and figure out if its worth the effort.
Successful Collocation Experiment
One of the common practices in most Agile methodologies is the idea of collocation. Tomorrow, 5 of my developers will move back to their home cubes from another building on our campus complete with machines and chairs.
The scenario was we had a nasty large project that had been in defect resolution for well over a year. There were lots of communication issues resolving defects and both sides had a tendency to throw things over the fence and let issues sit for days. Every time I talked about setting up a war room or bringing the QA testers over to sit with the developers I was essentially told it wasn’t going to happen. So this March I decided I probably had the power to move the developers out to the QA area in another building. While I think they were a little surprised I didn’t get that much flack for it. So 6 developers and myself in the afternoons moved over to sit next to the QA staff.
After a lot of missed deadlines on the project, we finally delivered at the end of July for the first time on schedule. While collocation wasn’t the only factor it was a definite contributor. QA and development finally got on the same page. At least one other project team has been collocated now, so hopefully this will be a continuing trend.