Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Basic Agile Development

Basic agile development, eliminating waterfall without adding much process.

John Sonmez

on 22 April 2010

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Basic Agile Development

What is Agile? Agile Manefesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to 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
That is, while there is value in the items on the right, we value the items on the left more.
Agile is just a system of values...
There are many ways to implement it in a process. Why not waterfall? Requirements Gathering Analysis / Design Development Testing Bug Fix Deploy Waterfall The Problem is Feedback! There isn't any! Think about driving a car Uh oh! Better hit the brakes! Too late By the time you see the rock in the road
It's too late! But, you can only see
the road once every
10 minutes The brakes take
1 minute to respond
to your push Waterfall Projects
DESIGN Let's look at an example: At the widget factory, we get
the requirements for building
and new kind of widget making
machine. Requirements are analyzed.
Design of the new widget making
machine is written in a spec. Engineering teams begin building
the widget making machine. Engineering teams "complete"
brand new widget making machine.
Test widgets are produced. Customer looks at test widgets and
realizes that is not what they want
at all. Machine has already been built
no time to redesign it, only option
is duct tape and "super engineer". 1 month 3 months 12 months 24 months
(Redesigning an already
built system can take as
long as initially building the
system) Questions:
Did documentation get updated?
What condition is the code after the change?
Is the solution good, or merely "acceptable"?
How much did the project run over time?
Over budget? Requirements Gathering Analysis / Design Development Testing Bug Fix Deploy Requirements Gathering Analysis / Design Development Testing Bug Fix Deploy Requirements Gathering Analysis / Design Development Testing Bug Fix Deploy Requirements Gathering Analysis / Design Development Testing Bug Fix Deploy Time Iteration 1 Iteration 2 Iteration 3 Iteration 4 What is happening here? We have made the feedback loop smaller.
We have accounted for change in our process, instead of trying to fight change... Change is inevitable.
We are going to go through the whole SDLC process every 2 weeks, or so.
We have increased the accuracy of our planning, because we can accurately estimate how much of the system is implemented. Taking it one step further If shortening the feedback cycle is good...
What if we shorten it more?
What if we make it continuous? Becomes Iteration 1 Iteration 2 Iteration 3 Iteration 4 What is happening here? We are blurring the lines between the "phases" of software development in order to make our feedback loop tighter.
Testing is happening as close to development as possible in order to catch problems as early as possible.
We are making the customer or customer represenative an active part of the development process in order to reduce miscommunication and better deliver what the customer wants. Jetsons meets Agile: Big picture of creating
a new kind of widget making
machine is approved. Users work with team to define
high level goals of the new
widget making machine. High level goals are broken
into stories which development
teams can build Development team iteratively develops
a user story, getting details from
working directly with customers.
Working prototypes of functionality are demonstrated to the customer as it
is built.
Feedback is used to improve product
each cycle. Repeat until customer is happy
Or product provides enough value
to release. Lets Talk Methodologies... Scrum Highly prescriptive - tells you what to do.
Disruptive. Organization must change from top down.
Planning and estimation for determining project progress.
Clearly defined roles - ScrumMaster, Product Owner, Team.
15 minute stand up meetings or "Scrum meetings."
Artificially time boxed into "sprints."
Talks more about process than standards. XP - Extreme Programming Highly prescriptive - very strict rules.
Disruptive. Developers must change. Paired programming is required. Test Driven Development is required. Very strict rules.
Principles and best practices are part of the process.
Excellent set of development practices.
Can be very difficult to implement.
Doesn't control work in progress. Kanban Not prescriptive - only requirement is a Kanban board.
Doesn't say anything about best practices.
Doesn't say anything about team structure.
Eliminates waste from development project.
Focused on reducing work in progress to increase effectiveness.
Lower impact to existing teams.
Some process Limiting WIP, Kanban board Development principles
Full transcript