Skip to main content

Posts

Showing posts from 2011

Being Productive

The aim of this post is to organize my ideas and also share 3 aspect of my day that I believe helps me to became more productive. Pomodoro Technique Since I first listen about the pomodoro technique I got   really interested in it. I always had the feeling that I could produce more if I work less. Since I started using it I came studying the  physiological side of the technique and the more I use more I feel that I'm productive working less. Organize the goals But there's another point that I keep in mind, is that I have to produce a certain amount of work per day, and not necessary I have to work 8 hours per day to produce it. This is another rule that I try to follow, normally in the very begging of my day I ask myself: What do I have to do today? Normally I write the goals down in a piece of paper, then that becomes my goals for the day. I try to be fair to myself in the definition, I don't have to show it to any boss or manager, so if I put more work in the list

Most usefull git site so far

Two teams in my current company decide to give git a try. So in the last weeks I have expend sometime talking about DVCS. One item that I have seen that is difficult to understand about git is that it has many "areas". To explain the movement of changes between the areas normally I draw a picture in a paper with many arrows, showing the movement of changes for each git command... Gladly I found the site that taught me this: http://www.ndpsoftware.com/git-cheatsheet.html If you have to explain any git command to someone, definitely I recommend you to use this site. cheers...

Do it in small pieces

In a Agile project when we plan the work for the project, we split it in small pieces, a.k.a. User Stories. Then in the begging of the project we prioritize the small pieces in order to do first the most important pieces ("how" to prioritize is a subject to another post). But all of this doesn't matter if the team decide to work in all the story at once. The whole idea of breaking down the work and prioritize it, is to be able to keep delivering some business value along the development time. And more than that is a way to follow up the project progress. Suppose that we have a project that will have 1 week iterations. In the first day of the 1ยบ iteration the project board was with this status: Stories                          In Dev                         In Tests                 Done 1                                       X 2                                       X 3                                       X 4 5 6 7 In the second day the developer Fulanom

Managing Workflow is a lot easier than Managing Schedules

Last week I got involved in a project and while I was studying the scheduled dates for the project I remember the Lean concept that says: Managing Workflow is a lot easier than Managing Schedules . Managment people like the idea of managing dates for a project, and they have a false-positive impression that this is enough to set the base for a project, i.e., the project should be build on top of it. I agree that this is the starting point, but this is not enough. We need a workflow in place to be able to delivery a reliable project. This workfow should be repeated during the project and improved to suite the project reality. All the people involved in the project should be able to see the current status of each task in the workflow and see the results of each task in the end of the workflow. Some examples of workflow can be: Analysis -> Development -> Control Quality -> Integration or Ready to development -> Development-> Test or Whatever is suitable to your project. A v