Not really, but there are improvements. One of the PMs has scheduled builds every Thursday. The team is working cohesively to meet these deadlines and share the responsibilities. Status is communicated every two days, and solutions to problems are found. It takes a lot of re-planning, as things change from week to week. Features are
We’re going agile! Note that it’s not with a capital A. And when we do it is with small steps. However, I think it is a step in the right direction. How did this miracle happen? I can take some of the credit, but it’s mostly letting people absorb the theory until it looks real.
This came up in a very interesting time, since we just “discovered” this happens here. I don’t think Johanna’s talking about us, though (I don’t know that our company was part of the course. Maybe we should have). There’s the main integration branch where people are checking in fixes. But some fixes are planned for
First, this is in Hebrew. Danko compares real life estimation (where normal people take into account abnormal occurances) to project estimation (where normal project managers don’t). This is so true in so many levels. Been there, and unfortunately done it. I’m waiting for the follow up post. This Fibonacci series estimation looks mighty interesting.
Oren Ellenbogen writes about TDD, testability and Scrum implementation in his team. Very interesting. The way I react today to untestable code makes me realize how far I’ve become as a developer. So far off than the “just-make-it-work” manager I used to be.
One of my greatest decisions ever (in my view, anyway) was on a project I managed a few years back. Under pressure, and no time to waste – sounds familiar, I know – all we could do is produce more bugs. I asked the test team lead to assign testers to developers, to sit with
Paul Stovell created a tool for traceability between code and requirements. All you have to do is add attributes to the classes/methods, and through reflection, it correlates the tested code to requirements. Therefore, it can actually create code coverage report against requirements. Cool stuff. [via Brian Harry]
I listened during my commute to the latest HanselMinutes. This time it was a bit different. Scott talked Tim Ferriss, the author of the best seller “The 4-Hour Work Week“. One of the things Tim talked about why working on email on a plane is more productive than doing that in the office. The two
Scott is very smart, and may be sometimes very expressive (read: extreme) in his views. His blog is on CodeBetter, where other great bloggers are abound. He has a posts on dependency patterns. A primer. Very readable, and accessible to a newbie. It’s a good read. Read it here.
I almost cried when I read this. It’s via Scott Hanselman’s blog. Patrick Cauldwell wrote down a list of commandments for the developer. While it is a bit .Net centric, it can be modified to suit everyone. As long their into TDD, continuous integration, refactoring and patterns.