I want to improve the way that I develop software. I want to develop faster and a great code! Today I use the waterfall method as freelancer, writing web stuffs (sites, systems, etc). Is there a way to use agile development (XP, SCRUM, etc) working in this way? I don't know nothing about agile development, where should I start? Thank you very much.
... Other than pair programming, sure. ;-)
Seriously, I'm a freelancer too and I use agile techniques as much as I can. It works for me very well. I make huge use of TDD,
Nobody anywhere uses 100% of XP or Scrum, but everybody uses parts of it, trying to adopt as much as works for them. In my opinion, the more of that you adopt, the better off you are.
The thing I miss out on the most is pair programming. The way you overcome that is
- Go to lots of user group meetings.
- Find a couple of folks whom you respect as developers.
- Ask them to meet you over coffee or something to write code. Give them part of your hourly wage occasionally if you feel that is necessary or just respond in kind to working on their code.
- Attend or create a Hack Club like this one: http://www.DallasHackClub.org.
Here are some resources I use:
- Extreme Programming -an online quick, but thorough guide through XP.
- A great Scrum overview.
- Fantastic and short book. Perfect for you!
So I would say there are three main "awesome points" to using Agile as a freelancer:
For larger clients, Work/bill in iterations. At the end of the iteration the customer can continue work on the project, or end the project (ie: it accomplished its goal). I know (from experience) I can't estimate well more than a few weeks out, and pay-per-iteration also keeps the cash-flow coming in. It's no fun to be at month 6 of a 3 month project, and waiting to finish the project so you can bil...
Agile means change happens. I've done a ton of fixed bid projects (which you think you can do with waterfall) that have lost me money, because of a customer request in the middle of the cycle. Change happens: the customer can deprioritize a ticket to get some other work done faster, or maybe you forcasted wrong and didn't get as much done as you had hoped.
Good customer collaboration tools. My standard estimate (for something smaller than an iteration's worth of work) is actually a series of Behavior Driven Development steps derived from the client's expectations. I send this to the client and say "Is this correct?". It makes sure everyone is on the same page.
Simplest thing that could possibly work. It's something to keep in mind as you're working: don't be afraid to go back to the client and say, "This would be a lot simpler (or more powerful, or whatever) if we did it this way..."
Scrum is important. I like sending my clients an email every day I work on their project. This is like my scrum to them: "what I worked on today", "what/when I'm going to work on their project next?", "Is there anything in my way?", and "Overall, how goes progress?"
Test driven development is really useful too, even as a single programmer. My "estimates with BDD stories in them" help me feed this process.
A great way to begin your Agile journey is to set up your workflow using a KANBAN system.
We simply have 3 swimlanes:
- Our TO-DO's or Backlog
- What we are working on or IN PROGRESS
- Things that we complete or DONE.
This simple Agile workflow is a great way to start.
In terms of coding, I would recommend using test-driven development (TDD). We included a lot of great links describing TDD in our article but will re-copy them here:
For more information check out the following resources:
- AgileData.org - A great resource for Test-driven development.
- JamesShore.com - Another great breakdown for TDD
- Net Tuts - A fun introduction to TDD I like!
- Artima - Interview with Martin Fowler
- Games From Within - A good case study of TDD
- DaniWeb - Introduction to TDD for developers
- Mark Levison - Article on TDD
Since your an individual, it's best you approach agile methodologies as something that's there to help you grok-out what works best for you. They're there to help you reach that "there is no spoon" plateau, but how exactly is that going to happen is entirely up to you and what you come up with in the end will greatly overlap with some methodologies on various levels, yet it'll be something completely yours.
Since your trying to find a your own way doing things to improve your overall effectiveness, here are some pointers that can help you at least not make the same mistakes I did:
Forgo all software solutions exclusively targeting agile methodologies, for as long as you can.
The fact that they are more suited for facilitating team collaboration is beside the point. Resist the temptation. You don't box yourself in a way of doing things and then hope adopting it will work out for the best. It doesn't, it just frustrates you. You first find your way of doing things and then seek out a suitable software solution. I've ended up with using whiteboards (started with one, but now I have two in my room) for tracking/developing stories and the Pomodoro Technique | To Do Today list to track my development tasks and it's friggin 2011. Stick to the basics until we get some interfaces such as those out of Iron Man 2 or flying cars begin to appear.
Reflection, reflection, reflection
This was what I came to understand to be the single most important part of any methodology for an individual. It's about developing this workflow that gives you a holistic view of your project so you can keep track of what needs to be done and when in a manner that is easily manageable and where bad decisions are rarely made and stand out so they can be quickly amended before they cause any damage... but you can't just pick it off the shelf. Start from somewhere, anywhere. You stick with it for as long as it works. Invest into tracking the good, the bad and the so-so. Improve your assumptions, then adjust the way you do things accordingly. That's the only way your going to improve.
Furget about deadlines, focus on how fast you get things done
I was probably like the next guy when I began, chasing dates. Burnout charts? I used to think of them as a way to visualize my development track against deadlines. It's a performance, not an estimate model. Time is there to measure your effectiveness by reflecting upon the work you've done within a certain time frame, not just some dumb value to represent the distance before impeding deadlines. The reality is that stuff gets done when it's done and your methodology should account for that.
In the end, who says you have to use user stories, or anything we know of for that matter? Don't think like that. If your more comfortable with thinking in features, then by all means defy the global development community and do it your way, because getting stuff done is all that matters at the end of the day. If you end up feeling like your doing something wrong, congratulations--you've just concluded that it's time to leap to something else. It's about the whats, not the hows.
I'd answer "how do you want to improve the way you develop software?". For your business model, what are the biggest issues you've encountered using the waterfall methodology?
Is your goal faster development, more robust code, greater reuse, meeting / adapting to changing requirements etc? Different methodologies exist to overcome different problems.
Of course adopting a design methodology other than Waterfall can be very useful in effectively managing a projects lifecycle depending on your business requirements. For agile development there are vast number of resources online. I would look into AUP (Agile Unified Process) which incorporates TDD (Test Driven Development). This can be extremely useful when building/managing large scalable systems.
There is no 'one size fits all' methodology and this is the main reason for the vast number of different approaches. I would start thinking about where you feel the bottlenecks are in your development process currently and then try to adopt a new methodology to overcome this.
For example do you often fail to meet deadlines? Do new features introduce a large number of bugs? Do new requirements cause major redevelopment? Does the business require regular working systems to be presented? Check out: Agile, Iterative and Agile Intro.