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.
migrated from stackoverflow.com Jan 19 '11 at 15:13
... 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
Here are some resources I use:
So I would say there are three main "awesome points" to using Agile as a freelancer:
A great way to begin your Agile journey is to set up your workflow using a KANBAN system.
We simply have 3 swimlanes:
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:
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.
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.