Agile Development Brown Bag Lunches Slides

Agile Development Brown Bag Lunches Slides

• 1.
  What is thedeal with Agile? I mean really?   an overview of "Practices of an Agile Developer"
• 2.
  In  a nutshell....WaterfallVS. Agile Waterfall fixed price planning up front features documented with great detail Linear process - planning is first testing is at the end   Agile price TDB limited planning up front goals and problems documented over solutions Continuous, iterative process
• 3.
  The Agile ManifestoWe value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan    
• 4.
  The Spirit don'twork in isolation avoid quick hacks - they'll stay in the codebase forever understand the problem you are trying to solve fix the problem, not just the symptom blame doesn't fix anything criticize ideas, not people negativity kills innovation simplify - if it's too hard for one person to understand, it's probably not maintainable use timeboxing (by lunch, end of day, etc) to keep things moving forward (software projects are like sharks, if they don't keep moving, they'll die)
• 5.
  Feeding Agility Keepup with change keeping learning follow blogs for the latest "buzz" User groups and conferences READ! Share what you know with your team Know when to unlearn in this business, if you still doing something the same way you did it 3-4 years ago...it's probably time for a change Question until you understand (get past the symptoms, ask  "why?") think of all the stuff we could NOT build if we just asked "why?"
• 6.
  Delivering What UsersWant keep users involved in decision making don't show them when it's too late to change course present options early   early designs should be high level, not too exact - only as detailed as necessary to implement (think Lewis and Clark crossing the country) justify technology use - don't build it when you can download it always keep the application in a state that is ready to deploy, check in your work early and often (use CI) Frequent Demos Good software today is much better than Superior Software sometime next year - get something usable out ASAP      
• 7.
  Agile Feedback small,continuous adjustment requires constant feedback sprint reviews (every 1, 2 or more weeks) release notes build as early as possible (automate) improve constantly customers are the domain experts scope can change more easily (SOWs can be issued to accomodate in our case)
• 8.
  Coding Agile goodcode does not necessarily mean more classes and or fewer code re-use is key, code duplication should be in check Good programming can be simple to read, and well optimized - you can do both! refactor! everytime you re-use something, make improvments don't comment things out, remove them today's lazy hack is tomorrow's nightmare, don't give in to temptation...it will cost more in the long run, quick fixes are ticking time bombs
• 9.
  Bugs report andlog all exceptions - even if there is no plan to fix them right away provide useful messages to the client in the software for any event that occurs, whether it's an exception or a success for hard to find bugs in huge codebases, isolate the bug into a test or prototype that is more managable Blame does not fix bugs
• 10.
  Collaboration Client Facing:back log tasks keep a project glossary email status reporting (client facing, and SCRUMS) release notes with demos   Internal: improving team skills is just as important as getting projects out the door improve things with each go round, not just the quality of the deliverable, but better your skills (old code should dissapear over time) designers and architects must work on the deliverable tools (meetings, fogbugz, "the list")  
• 11.
  Wrapup better collaborationsystems auto genererated status reports auto generated release notes email tracking weekly or bi-weekly reviews with client gather client feedback     There no need to fix everything at once. Like agile itself, implementation should be incremental.   What we can take on now: Continuous Integration Source Control Change eventually integrate with collab system Results: fewer surprises, less overbuilding more SOWs better quality   better software more profit (fewer trainwrecks) happier clients