This blog is now officialy dead!
If you haven’t noticed by the date of the latest post, it is.I now blog on the Typemock blog. See you there.
If you haven’t noticed by the date of the latest post, it is.I now blog on the Typemock blog. See you there.
I firmly believe that in order for a team to succeed they should be committing themselves, and take accountability. I saw teams succeed when they do, and saw teams fail when they don’t. So in the upcoming changes we’re making, we want the team to be part of it. Thursday, we did a partial retrospection,
Ayende gives an example of how to set the bar high. The broken windows theory talks about what happens when you let your guard down. In software this means that if you start setting the bar low, for example allowing more bugs, or stop refactoring for a while (because now is not the right to
What makes a project succeed? Well, the list is long, so I won’t even try. I have seen failures and successes decided on team work. Why would a person contribute to the team success, or not? Apart from the “survivalist” who cares about his job, there are others that excel or remain average. Those who
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.
Ayende wrote about getting from a small utility to… a small utility. Let me see – I developed (or was part of a team that developed):1. Utility (Those were the days…)2. Project3. Application. (This was a bigger project, which got bigger)5. Framework (I should have made a U turn here).8. Platform. (Made and designed parts.
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.
This is such a short post, but full of good advice. Newbies should get feedback and be open to learning. Actually, experts also. Most of them became expert this way. Learning TDD, like everything, is a process. Pick up the good habits, one or few at a time, and do not try everything at once