Over the last week I’ve been reading Practices of an Agile Developer. It’s a book with Pragmatic Programmer that discusses what Agile is, bad habits that developers tend to have in regards to production, development and their view on customers/users, and the best practices in trying to set aside these old habits in order to become a more productive developer for yourself and your team.
One of the major things they emphasize on in this book is feedback. Have a constant flow of feedback and get everything achieved in iterations (small periods of development to get things done) and making sure that you don’t end the day with things left to do. And sometimes that means splitting a list of tasks in order to get some things done and others done later.
After having read it, I have already started to break down my tasks. Let’s say for instance…You have a newsletter and you need to get it sent out. In this case I have a newsletter that gets sent out once a month and there’s quite a flow problem in getting it out there. I get a document with the information, I put it in an html file, I have it reviewed 7 times for 2 typos, and then I proceed to put it online and get it revised yet again. As you can tell it causes quite a bit of overhead.
So what am I doing this week? Making it a bit more Agile.
Step 1 : Receive document, put information in html and send for revision.
Step 2 : Edit
Step 3 : Once everything is done and given the go ahead, I put it on the CMS for the online version
Step 4 : Let them know it’s out of my hands now.
It doesn’t sound like it’s reduced THAT much in the process. But the organized structure allows me to work on my other tasks while I wait instead of having to put it in the CMS waiting for more of the changes. Waiting is a huge problem with development.
Anyways, if you’re interested, you can get Practices of an Agile Developer:
Hope you enjoy it!
0 Comments.