Roger Almeida's Opinion

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

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

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

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

It's quite common to some business/manager people come to us and say: I'm trying to find ways to increase our production capacity... I would like to go faster. How quick can we  go? (...) The point is: Software development is not about how quick, but about how far. We always should think about how long our current solution will survive.

Lately I have been in some meetings to discuss if we should automate the tests scenarios or not. After some discuss with my colleagues we came up with this pattern: When reviewing a story instead of asking if we should automated the tests for the story ask: Why not to automate the tests scenarios for this story? If we don't have a really good reason to not automate, let's automate. If the reason is related to the size of the test scenarios, the difficult to write all the scenarios or quantity of scenarios then we should break/rewrite the story. If there's any technical reason, apply the 5 whys analysis to find the root cause, that in most of the cases will be a technical debt . What will left will be just real manual test, like visual validation.

This morning I got a great tip... I typed a command in my terminal but I wanted to run another command before executing the line that I just typed without loosing the information in the current line. For instance: I typed in my terminal the command: git commit -am "Unit test for scenarios A, B and C" But I was not sure if I was committing just the scenarios A, B and C that I have changed, I would like to run a git diff before committing but also without losing my committing message... Then my friend Duck told me to put a # in the begging of the line and...  voilà! # git commit -am "Unit test for scenarios A, B and C" It transform the line in a comment, so that I could hit enter without executing the commit and that line went to my history so that I could recovery it. Thanks Duck.