How to be an agile programmer?

Question

I am a trainee in development sector. My Boss says that i should be an agile programmer.

I went through through the net and found some interesting things about agile programming. Being a newbee how should I start with agile? What should be my first step in Agile programming?

At present I am in pair programming. But it's not exactly pair programming as I am just watching what my co-developer is doing. I also wish to be an agile developer. Can you suggest a way for me stepwise?

I wish to develop myself and also my programming skills.

Answer 1

Test Driven Development is a big part of being Agile. It doesn't take much, but makes one a much better programmer fast. It will teach you to write better-designed code, while making it more maintainable.

Also read Practices of an Agile Developer.

Answer 2

There's a difference between following agile practice and being an agile programmer. Be careful with this distinction.

Have a read of this: http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html

Learning good practice, to test, and above all to automate as much as you can will make you more productive.

Thinking and caring about what you're doing is half the battle.

Answer 3

Before you start being an agile programmer, you must aim to be a good programmer and software engineer. You cannot be the former without the later. Worry about code structure (including metrics such as LCOM and cyclomatic complexity), good practices, requirement analysis, software engineering, documentation, problem solving skills, etc.

That statement your boss made really and honestly amounts to nothing. He's just juggling with buzzwords. The fact that they have you just watching someone code without you being able to really do anything (pair programming or not) indicates me that their understanding of agility is superficial at best.

All in all, avoid gluing yourself to buzzwords. In a perfect world, every project would be lean and agile. But, unlike the actual physical engineering disciplines, we are not even there to develop an engineering discipline, and many self-called agilists are anything but.

Stick to the fundamentals and be good at them. Then focus about agility and pragmatism.

Answer 4

I agree with Rob Stevenson-Leggett that there is a distinction, and I think between being a programmer and an agile programmer is a mindset change.

I am an agile programmer working for a company that is still trying to move from no process or standards to having something better in place, but they don't know where they are going, so there are some struggles at times as I see development differently.

For example, with agile, you should release often, so that the users can see what you are doing, and help to correct if it isn't what they want. That is different than waiting until all the specs are implemented and tested. I would prefer to get something done, then as I get some features finished re-release.

But this also requires good bug tracking, so the users, or someone that interacts with users, can submit bugs and see what the state of them are, good version control, ideally with at least nightly builds and peer-reviewed unit testing.

Unit tests should be reviewed, at least initially, because bad unit tests are worse than no tests. If I know there are no tests I approach the software differently, but if the unit tests are very poor then I may trust that the code was tested and run into more problems later.

To start becoming an agile developer think in terms of use cases or stories. When you talk with users, don't be technical, ask them what it is they will want. Pictures are useful and just walk through what they are doing, what they expect to see, how they want to interact. Then, don't go create reams of diagrams/charts, break it down into small subtasks, and then organize that into priorities. Also, find out what must be done for it to be of any use, then, when those parts are done, do your first release, or next release.

For example, I recently had a chat with a couple end-users where I asked "What kind of questions will you be asked to justify the cost of this software". I am looking for what should be measured. I don't care for them to get into details about storing IP addresses or how to track users, they just need to tell me what type of questions need to be answered, as they create reports, or their superiors are curious, as I can't give them the info if I don't know what to collect.