Three simple steps to measure velocity in a software project:

• Estimate your requirements using a size metric.
• Agree on the concept of done.
• Define a timebox size.

Then we just need the formula:

Velocity = Points done / Timebox

Just to clarify:

• Integration test: modules of the system are tested together, as a group.
• Integration build: modifications made by developers are consolidated through a full build.

Although the integration build may include running integration tests, they’re are clearly two separate problems.

Sometimes in a project:

• People are treated as mere “resources”, being part of the project only to work on predefined activities and nothing else.
• The managers want to be sure that everyone is doing exactly what they think it’s the best, and forget that people can have good ideas.
• People prefer to work on tasks defined by someone else because they don’t want to be responsible for their work.

Having self managed teams is a good way to change this reality but to make people capable of managing their own work is a tricky task. With that in mind, the principles I consider most important to achieve it are:

1) Shared vision

The first step to build a self managed team is sharing the project goals. A good start is to define SMART (Specific, Measurable, Achiveable, Realistic, Timed) goals and to make sure that the goals make sense for the whole team.

2) Commitment

Once the vision is clear, the next step is to build the commitment. When the members of the team agree to work to achieve the defined goals, the perception of the their actions changes and they start thinking about the best solutions to get closer to the goals.

3) Trust

If people trust each other, a bond is created and there’s no reason to control other people’s work. On the contrary, people start helping each other.

4) Support

Every self managed team needs an “interface” with the rest of the organization. That’s why one or more people should be able to help when the solution to a problem depends on external factors. These people should be considered part of the team since they share the vision, are committed and trust the other members of the team.

Conclusion

Although these principles look very simple, they’re forgotten all the time. And they’re usually replaced by micromanagement, which on top of wasting people’s time frequently becomes the biggest cause of stress to the team.

If you haven’t tried Ruby on Rails because was too busy developing your J2EE applications, now you have no more excuses! It’s possible (and surprisingly simple) to deploy a RoR application in your favorite J2EE server just by following these few steps:

1) Install JRuby on Rails

Get JRuby and install the Ruby on Rails gem:

gem install rails --include-dependencies --no-rdoc --no-ri

2) Create a simple test application

Run the following commands to set up your new application:

rails test_app
cd test_app

You’ll have to edit the first line of the created scripts (’script‘ directory) to use JRuby:

#!/usr/bin/env jruby

And at this point you’re ready to test your application:

script/server

Open http://localhost:3000 and check if your application is running as it should.

Now let’s create some functionality. First, edit your config/database.yml file, defining your development and production database as it follows. Note that we don’t need the test database and we can use the same database for both development and production for the scope of this example:

adapter: mysql
database: test_app
user: root
password: xxx
host: localhost

Create a scaffold:

script/generate scaffold Dog name:string
rake db:drop:all
rake db:create:all
rake db:migrate

At this point you’re already able to point your browser to http://localhost:3000/dogs and start playing with with your database.

3) Install the JDBC adapter and change your application

In order to deploy as a Java web application, you’ll have to replace the database adapter by a JDBC one. To achieve this, first you need a new gem:

gem install activerecord-jdbc-adapter --no-rdoc --no-ri

You also need to copy your mysql driver (JAR file) to your JRUBY_HOME/lib directory and edit your database.yml once more:

adapter: jdbc
driver: com.mysql.jdbc.Driver
url: jdbc:mysql://localhost/test_app
username: root
password: xxx
host: localhost

Restart your server and, since we just changed its configuration, everything should be still working exactly as before.

4) Install Goldspike and create your WAR file

In your application directory, install the plugin:

script/plugin install http://jruby-extras.rubyforge.org/svn/trunk/rails-integration/plugins/goldspike

To include your database driver in the generated archive, you have a few options (Maven is one of them), but for now let’s just copy it to the ‘WEB-INF/lib’ directory of the application:

mkdir WEB-INF/lib
cp $JRUBY_HOME/lib/mysql-connector-java-5.0.5-bin.jar WEB-INF/lib

You also need to edit the app/controllers/application.rb file and include the line:

protect_from_forgery :secret => '6dc47d156f8f3724e4634c37bc0f9f94'

Finally, to create your WAR file, run:

rake war:standalone:create

Deploy the generated file in your favorite J2EE server like Tomcat or WebLogic.

Conclusion

The integration between Ruby on Rails and Java is easier than most people would expect, and it may become a new option to develop your next web application. That may be also a great motivation to learn JRuby and start taking advantage of its integration with existing Java code.

Reading about several things they don’t teach you in school, one that sounded me very important is how to deal with failure:

In school, kid’s learn that “failure” is a negative term.
However, it is nothing of the sort. There has never been a
single successful person who hasn’t failed numerous times on
their journey to success.

In fact, the most successful people in life are those who
have failed the most.

Edison ‘failed’ more than ten thousand times before he
succeeded in creating the light bulb. As said by Thomas
Edison: “I have not failed 10,000 times. I have
successfully found 10,000 ways that will not work.”

In software development, failure is mostly seem as a negative term too. Obviously we don’t want to deliver software with bugs to the end users, but I believe that most of the bugs could be avoided if the developers change their view about failure.

When you start doing Test-Driven Development, one of the first lessons you learn is how failures are useful during the development process. Every test that fails is an allied to understand a little more about the problem you’re trying to solve. Why don’t they tell this in Software Engineering class? I really don’t know.

The first agile principle is about “individuals and interactions over processes and tools”. How can it be managed when people are not all in the same place?

Dave Churchville wrote about it and classified distributed team as:

1. Type A: All developers are together, all customers are remote
2. Type B: Multiple development teams in different locations (but each team is together)
3. Type C: “Virtual” team where nearly everyone works remotely (e.g. from home, in various offices, etc.)

I’ve been working in the last years mostly with Type A and Type C teams, and I believe the main goal in these cases should be improving the communication channels between people to be as effective as if everyone was in the same room. Long story short, this isn’t possible, but we can still make it work.

For remote costumers, the first challenge is having they available to talk with the development team. It can be painful at the beginning because “build software” normally is not their priority, but as long as they realize how their contribution is important to get the best results, they will probably change. And in this case, cellphone, skype, IM or even e-mail will become very important for their collaboration, and both costumer and team should not underrate these communication tools.

Here’s some tips to work with remote costumer:

• Try to build commitment since the first day.
• Ask for their oppinion during the development and show how their collaboration affect the results.
• Define open communication channels. Give preference for phone calls and instant message over e-mail.

The “virtual” team is an extension of the previous scenario, and beside there’s less people together, it can be surpassed easier if the team already realize how communication is important in an agile project. That’s because in this case the communication channels are already open. They can use Skype/IM/e-mail to talk to each other, and even VNC to share their desktops during coding sessions.

This means that if there’s lack of communication among team members, the challenges will be similar to the faced with the costumer. And probably the approaches to fix it will be similar.

After read the 10 Eclipse Navigation Shortcuts Every Java Programmer Should Know, I tried to figure out my favorites shortcuts. I think I would go for:

1. Alt + Shift + X, T: Run Test Unit
2. Ctrl + F11: Run Last Launched
3. Ctrl + Shift + F : Code Format
4. Ctrl + 1: Quick Fix
5. Alt + Shift + R: Rename (refactoring)
6. Ctrl + Shift + T: Open Type
7. Ctrl + Shift + R: Open Resource
8. Ctrl + /: Block comment
9. Ctrl + Alt + Down: Duplicate lines
10. Ctrl + Shift + O: Organize Imports

You can see more shortcuts (or even print them) in the eclipse-tools site.

Software contracts that define all software requirements up-front make your project half-way to failure. The software company will try to do exactly what is in it, and the client will try to believe that none of those requirements will change. And at certain part of the project both will realize they were wrong.

Let’s face it. Software requirements always change. But it doesn’t mean that people got they wrong, it means that after seeing a piece of working software people learn more about it and they will always have a lot of new ideas to improve it.

Let’s see how could we change this situation:

Don’t define requirements in the contract. Well, this sounds obvious, but the problem is that people most of the time confuse software scope with project scope. The project must define clear vision of the goals to achieve, but should let the software change during this period to get to these goals faster.
Define an initial cost and time. Once you have no requirements in your contract, people can argue that you can’t define the project cost and time. That’s wrong too. Even with requirements in your contract, project cost and time are just estimates. So, to create those estimates you can think about requirements (the MoSCoW or the Joelonsoftware technique should help), and you can even keep these written items as initial ideas, but they really should not be written in the contract.
Build the software in short cycles where working software has to be produced. And define that requirements can be changed and the development velocity can be evaluated between those cycles. This way it’s possible to guarantee that changes will not scare the development team and the client will be able to check the team productivity. By the way, that’s other myth about scope-flexible contracts, that people will work less if they don’t have the requirements defined up-front. But this way of thinking ignores the fact that the software company should have interest in get the software done as fast as possible. After all, it’s a way to impress the client and get more contracts.
(Bonus) Create a much smaller contract first. If the contractor could not be convinced that this type of contract is better, propose a smaller one (one month, for example). If after this contract he’s still not convinced, everybody will be able to evaluate the risks and try to come up with another idea.

See, all those items are not too complicated. And if you ever experienced the stress that a traditional software contract can cause, you should really think about adopting a more flexible one.

From the Guy Kawasaki’s blog:

I’m sure that none of you need to take this test, but you might know someone who does.

By the way, here is the test.

These are some good reasons to start a fresh new blog (or at least they are the reason I started this one):

1. Change the focus. In the last year I always came up with ideas for new posts and I didn’t write them because they were not related with my blog’s main topic (software development). Now I can write about other subjects. It’s a new blog after all.

2. Independent hosting. After using Blogger and Wordpress for a while I started to get upset about their limitation. I wanted to be able to edit my theme, use AdSense, try other plug-ins. And I wanted my own address. Free blog services are good for beginners, and they should really move to their own places when decide blogging seriously.

3. Start writing in another language. For those non-native speakers like me, writing in English represents two challenges: 1) Writing decently while improving the language skills; and 2) Interact with people from abroad. It’ll be harder, but I truly believe it will worth the effort.

This post starts a new phase in my blogging career. For the last year I wrote mostly about agile software development and programming techniques. If you’re curious about what I’ve been writing so far, take a look at my other blog (or should I call it “old blog”?) written in Portuguese. And if you want to start a new blog too, I’m using DreamHost and can give some feedback about it.