Agile Difference « Be Different…

Agile Difference

Agile Manifesto rewritten

That is, while there is value in the items on

the right, we value the items on the left more.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

People completely mis interpret what the manifesto says about the items on the right.

All the items above make up quality software. The art is finding the
right balance of tools, contract negotiation, documentation and plan to
produce working software built by self managed agile teams.

Agile Developer Bookshelf - In no particular order

Pragmattic Programmer - If you are a good programmer, you have to read this book. ( Does it mean if you dont read you are not programmer
Pragmatic Unit Testing
Test Driven Development - The original bible of TDD
Agile Estimation - From user story –> Story points –> Tasks –> Sustained Velocity => Less Risk and more chance of success
Refactoring: Improving the Design of Existing Code- Don’t jump to coding without this. Simple tools => clean code => better design
Design Patterns: if
you really dont know what to do with your time and are a bit drunk,
this book will make a perfect companion It take a few shots of
Tequila to understand the complex world of Patterns
All I Really Need to Know I Learned in Kindergarten
Daily stand up - Do it right

This is a excellent intro to convince you to pair programming

Test Driven Devel0pment

There are some common misconception developers and managers have about TDD.

TDD for many means no design. Infact the core of Test Driven
Development is Design. Yes there is a overall architectire roadmap. If
writing software was as simple as going from requirements to production
code, I am sure by now many of us would have to find different
professions.

TDD is a tool that helps us drive the design by have some general guidelines

a) have a overall architecure road map of the system.

b) Use paper napkins and white board to your benefit. Its best to
keep the design formality low tech. Use your time more to think about
the problem than figuring out which template to use in your super
complex UML modelling system

c) Do relentless refactoring. That is the only way to achieve better
design. You cannot change anything if you are not sure you can verify
what you changed did not break something. Thats where good functional,
unit and integration tests come to play.

d) Use tools/ frameworks , patterns to help you write better
software. Dont make them your impediment. Follow your style of coding.
Learn from those that can show you a different way.

http://codebetter.com/blogs/jeremy.miller/archive/2005/12/19/135757.aspx

Watch these videos from someone who claims to have done TDD quite a bit

Tips for a healthy TDD living:

1) When you start in the morning the first thing, even before you
brush is to get clean code from source control, make sure all tests
run and then start thinking of changing any code.

2) Work in small increments of one to two hour shifts. Siftware
developers are better at one task at a time. Think of your eight hours
as four shifts. Each shift start again with step 1 above.