Agile Development Brown Bag Lunches Slides
Upcoming SlideShare
Loading in...5
×
 

Agile Development Brown Bag Lunches Slides

on

  • 2,610 views

 

Statistics

Views

Total Views
2,610
Views on SlideShare
2,548
Embed Views
62

Actions

Likes
2
Downloads
12
Comments
1

4 Embeds 62

http://www.delphicsage.com 51
http://www.delphicdigital.com 9
http://m.delphicsage.com 1
http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Agile Development Brown Bag Lunches Slides Agile Development Brown Bag Lunches Slides Presentation Transcript

  • What is the deal with Agile? I mean really?   an overview of "Practices of an Agile Developer"
  • In  a nutshell....Waterfall VS. 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
  • The Agile Manifesto
    • We 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
    •  
    •  
  • The Spirit
      • don't work 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)
  • Feeding Agility
      • Keep up 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?"
  • Delivering What Users Want
      • 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
    •  
    •  
    •  
  • 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)
  • Coding Agile
      • good code 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
  • Bugs
      • report and log 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
  • 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")
    •  
  • Wrapup
      • better collaboration systems
        • 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