We have encountered so many problems both technical and managerial this two-week iteration. Nate said that our velocity is 0.05 based on the figures in the Agile Planner, which means that our development speed is only 1/20 of what is expected. Though the timing of Agile Planner is untrustworthy, Nate said. It is so often that we forget to start and stop the session. Nate felt not quite good this morning when he saw that AP showed Li Pu had been continuously working on a task for more 16 hours!
We have paid so much time on configuring, nearly half of the work time. Configuring Linux, configuring Windows, configuring the company's machines, configuring our own machines. Nearly every time when we check out to start working, there are tests which should have passed in others' machine but fail in our machine. Finding what the problem is, trying to fix that problem by configuring the environment, often takes the whole four hours of work time, even the whole day.
If we can reduce the configuring time and put that time on productive work, we can significantly speed up, I proposed in the postmortem of the iteration today. As normal, we proposed so many problems that frustrated us so badly in the postmortem, and voted for the importance of each item. Because we have so many problems these few days, in the two-hour postmortem we did not have time to come up with solutions to these problems. Li Pu suggested to do it on the stand up meeting or the planning meeting next Monday. This reflected a common practice in the company, we call it time-boxing. When we try doing something, we set a time limit, called time-boxed. If we can not make any progress within the time limit, we stop it and find some way to get around it. If we fail in circumventing it, or if we find it very important to do it after reflection, then we rearrange a time to do it, and again, often time-boxed.
没有评论:
发表评论