At work we’re about to begin a new project. Aside from the thrill of starting something new, we’re also going to try a new (for our team at least) development methodology: agile development. With the iterations and user stories and everything.
Admittedly, it’ll just be two of us including myself but it’s a start on the path to modernizing and I’m certainly down with getting more familiar with industry proven strategies. It’s good for my career and I agree with a lot of the principles. I can’t say the same for some of the others I work with, though; in fact, the further we get along with this and the more we fold others into using it, I can foresee a few being dragged kicking and screaming. Some just want to show up at 8am and leave at exactly 4pm.
We’re going to be using the latest and greatest Team Foundation, SharePoint, Visual Studio, and Expression Studio. We’re going to use .NET 4, WPF, and MVVM. In all likelihood we’ll probably also use MEF as a simple and easy dependency injection container. I’m certainly looking forward to it.
I haven’t seen it in practice yet (since we haven’t started just yet), but it seems to me that a nice bonus of using inversion of control, dependency injection, and the model view viewmodel patterns is that they almost fit in perfectly with agile. Breaking things up into tasks (based on user stories) and iterations fits great with an application built incrementally. Using interfaces and injecting dependencies means we can have a lot of “ghost” services that seem to exist but have no substance. We can then write a lot of the application parts discretely and as a team without too much stepping-on-of-toes, and just plug in the missing parts as we fulfill tasks.
Not surprisingly, one of the best ways to enforce something is to make it a necessity. By choosing these patterns it seems like it will help a lot as far as keeping us true to the agile method, mostly by reducing the friction between the development method and the design methods. It’ll be like choosing to park in the furthest spot from the office everyday to necessitate a bit of daily walking exercise.
Switching to a new development approach can be a big upset for teams, even if they’re enthusiastic about trying it (as I am). Even going into it positively, I’m still going to face a lot of “getting used to” things and learning as I go. That’s not hard in of itself but it’s an overhead cost when your real goal is to develop software since the learning curve will eat into your coding time and efficiency. Still, I think it’ll be worth it.
I’m endeavoring to write more on agile, design patterns, and the technologies as we use them.
No comments:
Post a Comment