Finally Tried Out ScrumWorks
I’ve been getting by with just Excel and a large cork board for tracking the one Scrum project I use. Still as a tool junkie and a hater of Excel in general I finally got around to trying out ScrumWorks.
So so far:
- Download and install cycle is pretty short and it just worked including the WebStart client. I’m running it on my work laptop, and since I don’t like to weigh a team down updating tasks, I’m maintaining the Sprint backlog and tasks.
- Entry of tasks and backlog items is fairly easy, though you have to right click a lot for add new. Much better than XPlanner’s multiple click interface.
- The ability to move backlog items in and out of a Sprint and to drag and drop the order of items is really nice.
- It calculates everything on real time which is a pain. Since I was entering data on a Sprint that was 8 days in, I have to wait until tomorrow to even get a data point since you can’t effectively go back in time. I guess they assume you’ll start the project with the tool, not try it out midway.
- If its going to replace Excel I probably need some better looking export reports, or I’m going to have to try screen captures.
I’ll give it to at least the end of the current Sprint as a test.
Simplicity over Complexity
Having read at least one and a half of Richard Monson-Haefel’s tomes I’m impressed that that he’s come around to the painful complexity that is J2EE:
Over the years however, EJB and its super set, J2EE, became increasingly complex until there was so much information it was difficult if not impossible to swallow. Today I’m a recovering J2EE developer; I’ve successfully regurgitated the massive J2EE bolus that slowed me down and made me mentally lethargic.
As an analyst for the Burton Group at least he can point out the potential faults of vendor driven highly complex standards like WS-*. Now if only we came across more skeptics at places like Gartner.
Rails with Rake test_performance Task
In a bid to have more fun, I’m hacking my way through the later parts of Agile Web Development with Rails (1st Edition). I added in the admittedly simplistic performance test of adding 100 orders to the database. Just to be a bit anal I wanted to add a Rake task for it as well.
I’m still pretty much in squid/newbie mode with Rake, but by adding the following 4 lines of code to in lib/tasks/performance.rake I was able to successfully create a test_performance task:
desc "Run performance tests" Rake::TestTask.new("test_performance") { |test| test.pattern = 'test/performance/*_test.rb' }
Then a simple
1
|
rake test_performance
|
runs the performance tests.
Design Patterns Study Group
Sometimes you really get a sense that things are going well from your staff. Today was one of those days.
I’ve been sending some of my more senior developers to conferences with the plan to expand their vision of software development. Sort of you don’t know what you don’t know until you’re exposed to it.
Coming back from one of those conferences one tech lead got very excited about design patterns. It took a while since he had quite a workload, but he just helped run a 3 hour session with another developer introducing design patterns and covering Strategy and Factory Method.
The initial session went off pretty well. They’ll probably refactor the format a bit, possibly going to more of a study group versus lecture/lab style, but it is immensely satisfying to watch people grow the team.
Making Things Fun Again
Every so often, work just seems like, well just work. At that point motivation goes down the tubes and you’re just slogging through. Drawn out architecture discussions on the benefits of paranoid security got me to a very un-fun state. Bad enough when you’re a solo developer, but even worse if you’re a software development manager and your mood is likely to rub off on the whole team.
Maybe it’s time to inject some fun courtesy of some Cruisecontrol powered lava lamps.