Agile Methodologies
Upcoming SlideShare
Loading in...5
×
 

Agile Methodologies

on

  • 3,678 views

 

Statistics

Views

Total Views
3,678
Views on SlideShare
3,458
Embed Views
220

Actions

Likes
1
Downloads
131
Comments
0

9 Embeds 220

http://www.jroller.com 125
http://7feeds.com 45
http://jroller.com 17
http://www.linkedin.com 12
http://ww.jroller.com 11
http://www.slideshare.net 6
https://www.linkedin.com 2
http://209.85.135.104 1
http://www.searchfull.net 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution License

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 Methodologies Agile Methodologies Presentation Transcript

    • Dhaval Dalal software-artisan.com
    • dhaval.dalal@software-artisan.com Feedback Product Knowledge Software Requirement Specs Product Development Analysis Develop/UT QA
    • dhaval.dalal@software-artisan.com Rapid Feedback Small Product Knowledge Batch S/W Req. Specs as a “Big Product Development Batch” Analysis Develop/UT QA
    • dhaval.dalal@software-artisan.com Waterfall Model Iterative & Evolutionary Models Software dev is predictable Software dev is changeable Big up-front specs Evolutionary specs Upfront perfection Continuous Improvement Predictive planning Adaptive planning Batch Manufacturing Flow of Value
    • dhaval.dalal@software-artisan.com  Extreme Programming (XP)  Scrum  Crystal  DSDM (Dynamic System Development Method)  Lean  ...and many more
    • dhaval.dalal@software-artisan.com Individuals and interactions over processes and tools Working software over comprehensive Documentation Customer collaboration over contract negotiation Responding to change over following a plan While there is value in the items on the right, We value the items on the left more. Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas, Andrew Hunt
    • dhaval.dalal@software-artisan.com  Primary measure of progress is Working Software.  Deliver frequently.  Satisfy customer by adding business value.  Customer Collaboration and Visibility  On-site Customer.  Show Progress Charts publicly.  Constant Communication.  No substitute for a face-to-face conversation.
    • dhaval.dalal@software-artisan.com  Documents can be created, but don’t capture all project information in writing.  Documentation complements Code and Speech  Document shouldn’t try to do what the code already does well.  Vital detail about design is captured in the code.  It takes fastidiousness to write code that doesn’t just do the right thing, but also says the right thing. Source: Eric Evans, Domain Driven Design
    • dhaval.dalal@software-artisan.com  Eliminate Waste  Design  Defects  Hand-over  Embrace Change and Adaptive Planning We will plan by quickly making an overall plan, then refining it further and further on shorter and shorter time horizons – years, months, weeks, days. We will make the plan quickly and cheaply, so there will be little inertia when we must change it. Kent Beck
    • dhaval.dalal@software-artisan.com  Technical Excellence  Team-members commit to produce the highest quality code they can.  Continuous attention to good design enhances agility.  Sustainable Pace.  Self-Organizing Teams.
    • dhaval.dalal@software-artisan.com  Developers make estimates  Responsibilities are not handed to individual team members from the outside.  Responsibilities are communicated to the team as a whole, and the team determines the best way to fulfill them.  Best architectures, requirements, and designs emerge from self-organizing teams.  No “Blame Game”  Team members work together on all aspects of the project.  No single team member is responsible for the architecture, or the requirements, or the tests, etc.
    • dhaval.dalal@software-artisan.com
    • dhaval.dalal@software-artisan.com Master Story List
    • dhaval.dalal@software-artisan.com Release #1 Story List Master Release #2 Story Story List List Typically 3 Months Time boxed
    • dhaval.dalal@software-artisan.com Iteration #1 Release #1 Story List Story List Iteration #6 Story List Iteration #1 Master Release #2 Story List Story Story List List Typically 2 Weeks Time boxed Typically 3 Months Time boxed
    • dhaval.dalal@software-artisan.com Iteration #1 Story #1 Release #1 Story List A story is a Story #2 Story Story #3 smallest unit List Iteration #6 of work Story List Iteration #1 Typically 1-2 Master Release #2 Story List Days Story Story Time boxed List List Typically 2 Weeks Time boxed Typically 3 Months Time boxed
    • dhaval.dalal@software-artisan.com Iteration #1 Story #1 Release #1 Story List A story is a Story #2 Story Story #3 smallest unit List Iteration #6 of work Story List Typically 1-2 Generates Iteration #1 Unit Test Master Release #2 Story List Days Story Story Time boxed Cases. List List Sample Story Card Typically 2 Story <No.> Weeks As a <Role>, Time boxed I’d like to do <Task>, So that <Larger Goal>. Typically 3 Establishes Given That <> Months Acceptance When <> Time boxed Criteria. Then <> Acceptance Criteria.
    • dhaval.dalal@software-artisan.com  Schedule High priority and low- confidence stories first.  A Story with low-confidence can be “spiked”  Similar to a POC.
    • dhaval.dalal@software-artisan.com Analysis Develop/UT QA Story Card Story <No.> As a <Role>, I’d like to do <Task>, So that <Larger Goal>. Story Card Story <No.> As a <Role>, I’d like to do <Task>, So that <Larger Goal>. Story Card Story <No.> As a <Role>, I’d like to do <Task>, So that <Larger Goal>. Iteration N+1 Iteration N Iteration N-1
    • dhaval.dalal@software-artisan.com  Short, high energy, effective, to the point meeting.  To provide early and regular feedback on the team‘s progress  Achievements, Impediments, Problems Faced  When?  BOD  Upcoming work is described  Pairs Sign-up for stories  EOD  What were the problems faced and impediments raised.  What needs to be done and what was achieved.
    • dhaval.dalal@software-artisan.com  Test-first approach (TDD)  Evolve Code from Tests  Refactoring  Improves code, usually increasing the function while reducing code bulk.  Continuous Integration (CI)  Pair Programming and Pairing.
    • dhaval.dalal@software-artisan.com  Green field project  Unknown/Unstable Reqs., Unfamiliar territory.  High or Low Risk.  Time, Technology, complex biz. etc…  High or Low Team Expertise.  Short or Long project duration.
    • dhaval.dalal@software-artisan.com  http://www.agilemanifesto.org  http://www.agilealliance.com/articles  Agile Process  Robert C. Martin, Object Mentor Inc.  Extreme Programming Explained  Kent Beck, Three Rivers Institute.  http://www.martinfowler.com  ASCI Conference, April 2005, Bangalore.  Craig Larman’s Keynote, Valtech.  Agile Overview, Managing Iterations.  Naresh Jain, ThoughtWorks.  Distributed Agile Development  Bapiraju Nandury, Cúram Software.  Agile User Group Meeting, Chennai.  Sanjiv Augustine’s Keynote, CC Pace Inc.
    • dhaval.dalal@software-artisan.com