Google+ Followers

Friday, November 11, 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 become 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 than I can complete in one day I'm lying only to myself. When I started doing this, I had to do some extra-hours until get the felling of the right amount of work that I can achieve in one day.


Left the fun to the fun time.
I like to see videos during my day. I like to follow some updates in facebook. I also like to read my news feed. But I also have to work, so I normally do it in the pomodoro intervals or before/after work hours. It is just a matter of organizing your time. 


Work-life balance
I have to be feeling good to be productive. And it start way before the working hours. In my case it start with a good night of sleep. Unless I have an appointment in the early hours, I don't mind to run late in order to complete my sleep cycle.
Also the time with my friends/family has to be in order. Since I came back to São Paulo I manage to work from home 1 day per week, some weeks I can't do this, but this has showed very useful. Even more living in São Paulo, where you can easily expend 2 hours to drive from home to work. So normally I ask to do a home-office during the Fridays. And during the home-office time I keep following the others rules with Goals, Pomodoro. 


Passion for what I do
That, for sure, is the most important point, if you don't have, go! Seek your path.

Tuesday, November 1, 2011

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...

Wednesday, August 3, 2011

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 who was developing the Storie 2, decided to start coding a little piece of Storie 5 because the code was very similar to the Storie 2 code, just changing some parameters...

So in the second day the Project Board was:


Stories                          In Dev                         In Tests                 Done
1                                       X
2                                       X
3                                       X
4
5                                       X
6
7

All the others DEVs had the same ideia, what bring us to the following scenario:
Stories                          In Dev                         In Tests                 Done
1                                       X
2                                       X
3                                       X
4                                       X
5                                       X
6                                       X
7                                       X

This is bad, because now we have a Atomic Commit to the iteration, where or we delivery all the stories or we don't delivery any Story!
The idea behind the creating story, prioritizing,  is to not follow the Waterfall pattern of Atomic Projects.
Although sometimes from a coding perspective makes sense to code a new story instead of testing the coded story, this is not a great deal. As in the end you still have to test both stories. And as a test infected I'm sure that the surprises will arise during the tests. 

Monday, June 6, 2011

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 very important point is that  during the project this workflow should be repeated many times. Instead of doing all at once (waterfall way), do it in small chuncks, a.k.a. iterations. So instead of doing the analysis for the whole project before starting the development, do the analysis for a small chunck of stories and move it foward in the workflow.
In the end of each iteration the team should  get togheter and discuss what went well and what went not so well in the workflow, collecting action points to improve the workflow.
This way you can know in advance if the dates for the project are feasible or not. And yes, Managing Workflow is a lot easier than Managing Schedules.