Agile Software Development

Rating: 1 - I can do better 2 - Jury's out 3 - Pretty darn good 4 - Splendiferous 5 - Awesometastic (by 1 person)   Your rating: 1 - I can do better 2 - Jury's out 3 - Pretty darn good 4 - Splendiferous 5 - Awesometastic

Agile Development

Software development is a complex endevour.  The larger the project, and the more people involved the more complex it becomes.  And the complexity compounds over time.  Humans are pretty smart people, but dealing with all this complexity isn't something we seem to do well.  So, finding ways to cope is what Agile Software Development is all about.

 

 

Agile Software Development 

Just like mother would have done, if she was a programmer

In the 1990's s number of software developers were not satisfied with the way software development projects were being done. Many projects were failures - either completely or to some degree - and it was definately an overall unsatisfactory situation.

Some of these folks involved in making software were exploring various alternative ways to go about developing software, and a number of them were posting to newsgroups and bulletin boards and discussing what they were up to with other interested programmers.

A number of similarities existed among the different approaches that were surfacing. Methodologies were starting to "gel" and it was clear that a lot of the thinking and practices were similar across methodologies. In 2001 a gathering of important players was called to discuss what was similar amoung these ideas. The result was the Agile Manifesto which defined a set of values and principles that clarified the collective thinking of these pioneers.

You can see the results at The Agile Manifesto, and I strongly suggest you take a look when you get a chance.

The Waterfall Has Failed 

The Waterfall has had its evil grip on software development for way too long.

Many of us have worked with a defined process such as "The Waterfall", and it seems like it should work - but there are numerous shortcomings that can be attributed to following this developemnt approach and that's what I explore in my lens on the Waterfall: The Waterfall Process

It is because of these issues (and others) that many of us feel compelled to look for a better path. And for many people the Agile approach is working well.

Life, Liberty, and the Pursuit of Agility 

It's my own blog

Please visit - I cover mostly Agile and programming topics

Loading Fetching RSS feed... please stand by

Scrum 

The Scrum approach is one of the best known and most widely followed among the Agile methodologies.

Scrum utilizes a well defined subset of the Extreme Programming practices, providing a strong foundation for the planning and management side of an Agile project, leaving the details of the developer practices (and some of the other practices) that will be used up to the teams on the project.

Here is an animated example of how a Sprint Task Board can be used to manage the work done during a Sprint: Animated Sprint Task Board

Extreme Programming 

When I discover something that works well, it is natural for me to contemplate what things might be like if I took it just a little bit further. For example, when I was a kid I liked to coast my bike down a hill. It was exhilerating to go faster than I was able to do under my own power. So, I couldn't help but wonder how much more fun it would be to find a bigger and steeper hill - and I went out looking for those bigger, steeper hills to give it a try. This is the same idea with Extreme Programming - if a programming practice works well, perhaps we can find a way to increase its value to us by taking it to the extreme.

The goal is to find a way of developing software that brings the most value to the customer as quickly as possible, allows the customer to steer the process so that the end result is the best it can be for the effort, and respects the people involved. Sounds like a worthwhile undertaking.

Extreme Programming identifes a set of values, principles, activites, and practices that work together to strive to achieve that goal.

Extreme Programming Practices (from Kent Beck):
  • The Planning Game
  • Small Releases
  • Metaphor
  • Simle Design
  • Testing
  • Refactoring
  • Pair Programming
  • Collective Ownership
  • Continuous Integration
  • 40-Hour Week (Sustatinable work pace)
  • On-site Customer
  • coding Standards

Lean Software Development 

Lean Software Development takes elements from Lean Manufacturing and Lean Product Development and applies them to the unique environment of making software.

Agile books I highly recommend 

Beg, borrow, or buy these books - new or used

Agile Principles, Patterns, and Practices in C# (Robert C. Martin Series)

The OOP principles that Robert Martin presents are an important base that all OOP developers should understand.

Amazon Price: $51.99 (as of 11/21/2008) Buy Now

Refactoring: Improving the Design of Existing Code (Addison-Wesley Object Technology Series)

This is the seminal work on the practice of refactoring. Things have changed a bit since this book was written, especially regarding automatic refactoring tools built in or added on to the ide's we use, but still, this is an important book in the how and why of refactoring.

Amazon Price: $47.99 (as of 11/21/2008) Buy Now

Working Effectively with Legacy Code (Robert C. Martin Series)

You are not a developer until you have maintained code you have written for 5 years. If you can do this, and remain sane, then you are a better man than I am. This is the book that kept me sane.

Amazon Price: $48.54 (as of 11/21/2008) Buy Now

Extreme Programming Explained: Embrace Change (2nd Edition) (XP Series)

There are two editions of this book, and I recommend getting both the original and the second editions.

Amazon Price: $32.24 (as of 11/21/2008) Buy Now

A Definition of Done 

Is it done, Done, DONE, DOOONNNNNEEEE??????

Every team needs a clear definition of done. No credit is given to the effort on a User Story if the code does not pass the definition of done. It is up to the team to decide what "done" means, but typically it should mean that the software has value to the customer, is working, and is passes all user acceptance tests.

Here is an example of a definition of done:
  • Contains business value for the customer
  • The code is written and compiles
  • Automated xUnit tests (micro tests) written and passing
  • Automated integration tests written and Running
  • Automated user acceptance/system tests written and passing
  • Any needed user documentation written
  • Database migration/update method in place and tested
  • Installation or deployment scripts or process in place

Please let me know what you like, and what needs to be improved. 

jeolaa wrote...

Very inspiring and informative lens. Values and principles of software development is clearly reviewed in this site. Like wise,step into a similar site Software Development and surf stuff about Software Testing Software and Software Testing Types.

ReplyPosted June 21, 2008

LyssaAdkins wrote...

Hey, Woody.

I see you joined the Agile Headquarters group. I tried to add your lens to the featured lens area, but was having some technical difficulties. I added you as a Featured Lensmaster instead. Check it out at:
http://www.squidoo.com/groups..agile/

And, glad to have you in the group

ReplyPosted December 03, 2007

Look who made this lens!

WoodyZ

WoodyZ

Hey.  I've been developing software for a long time.  And I love writing code.  However, I hate poorly managed development efforts.  I've be...

 more