Your SlideShare is downloading. ×
0
Agile Development Brown Bag Lunches Slides
Agile Development Brown Bag Lunches Slides
Agile Development Brown Bag Lunches Slides
Agile Development Brown Bag Lunches Slides
Agile Development Brown Bag Lunches Slides
Agile Development Brown Bag Lunches Slides
Agile Development Brown Bag Lunches Slides
Agile Development Brown Bag Lunches Slides
Agile Development Brown Bag Lunches Slides
Agile Development Brown Bag Lunches Slides
Agile Development Brown Bag Lunches Slides
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Agile Development Brown Bag Lunches Slides

1,821

Published on

Published in: Technology
1 Comment
2 Likes
Statistics
Notes
No Downloads
Views
Total Views
1,821
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
13
Comments
1
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

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

×