Womens Hair Re Growth Rogaine Side Effects To Vytorin Lotrel Metformin Accutane After Before Sucralfate Taken With Nexium Hgh Weightloss Shots Can Prilosec Cure Ulcers Diamond Brite Louis Mo Celebrex And Canada Tramadol Is Prescribed For Bactroban Lowest Price Effexor Diary Ring Purim Online Card Music Free Melatonin And Zoloft Interaction Cymbalta Suicide 2006 Avandia Purchase Singulair Phone Cymbalta And Abilify Lexapro Klonopin Alcohol And Paxil Cr Avandia New England Journal Irina Allegra Viagra Next Day Shipping Tricor Pacific Capital Calcaulating Motrin Dose Base On Weight My Dog Ate Allegra D Information On Vytorin Effectiveness Of Diflucan Ventolin Package Insert Craftsman Brite Driver Parts Canada Coreg 25mg Picture Of Generic Nexium Solar Brite Abana Marietta Prosthetic Heart Valves And Coumadin Levels Drug Interactions With Lexapro Ibuprofen Motrin Rainbow Brite Dance Song What Does Synthroid Look Like Lexapro Tardive Dyskinesia Can You Take Celexa While Pregnant Actos Manufacturer Prednisone Use Medication Self-management Coumadin Gneric Viagra Lasix And Heart Surgery Zestril Lichenplanus Cla Supplement Danger Hoodia Bipolar Hoodia Case Studies Flomax For Kidney Stones

After reviewing my previous post, I realised that the agile developer should be presented in an even simpler form. Seriously, that’s what an agile developer do: develop things as simple as possible, but no simpler. Ensuring that what is created match what is wanted by the customer, and the code written actually works.

The short version of an agile developer is a person who understand the details of the task and takes this understanding to his peers to find the simplest way to implement it. The agile developer creates the tests that will verify the details, before actually implementing the code that will handle these details. And he’s not satisfied with a running test before the code is refactored so simple and understandable that anyone can read it. But the agile developer will not rest before his implemented task works well together with the system as a whole and the customer returns with a satisfied feedback.

The details you find underneath:

    1. Get your task, specification, order, whatever. You now wonder: what is it really I should make? Keep in mind how many times you’ve experienced changes to the requirements document or some details weren’t covered in the document.
    2. Get hold of the decision maker, the customer with the answers. Ask if you can have a brief walk-through of the task. Make sure you catch the intention and ask whether the proposed solution really meets this intention. Oh, and if the customer gets carried away talking about his domain, make sure to keep him in that state. Promise to deliver something he can see or review no later than within a couple of weeks.
    3. Now, talk to a fellow developer or architect. Discuss the task with him and talk about how this fits into the big picture of the application, or more presice, what the architecture should look like.
    4. Spend some time to write up the functional features of the user stories from the meeting. Make the most important ones your priority. Create som tests against some “black box” functionality that gives you a return value you believe is relevant.
    5. Start implementing the core functionality in a way that the unit tests you created can be run. If you designed the tests wrong, change them accordingly.
    6. Make sure your tests run. When they do, simplify your code. When you realize you have overlapping og expanding functionality, keep refactoring and make sure the unit tests still work.
    7. When all is implented, tests run and the code is satisfactory simple, make sure to run an integration test with the rest of the system. Promote your functionality so the customer quickly can run through it.
    8. When the customer likes what he sees, the tests run and your task is complete, celebrate! Do so until the new iteration starts.
      I didn’t manage to keep it short, did I? Eight easy steps for success, that’s still so tricky to actually do.