Waterfall Method Intensive planning and refactoring before coding is actually done Pros Great documentation and works well with other engineering fields Cons Increases man hour costs which are the most expensive part of software development ID: 701758
Download Presentation The PPT/PDF document "BEFORE AGILE METHODS Other Engineering f..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
BEFORE AGILE METHODS
Other Engineering fields development models were used, ie:
Waterfall Method: Intensive planning and refactoring before coding is actually done
Pros: Great documentation and works well with other engineering fields
Cons: Increases man hour costs which are the most expensive part of software developmentSlide2
BETTER METHODOLOGY NEEDED
1. Lots of dead time when creating specifications.
2. Not reuse oriented.
3. Software may be obsolete or have no market by the time its released.
4. 80% of software projects failedSlide3
LOOK TO TOYOTA
Toyota Production System 3 Principles:
1. Build only what is needed.
2. Eliminate anything that doesn't add value.
3. Stop if something goes wrong.Slide4
LEAN THINKING
5 principles derived from Toyota's model, book published 1996:
1. Specify value.
2. Identify the value stream.
3. Create the conditions for value to flow smoothly through the stream.
4. Have the customer pull value from the stream.
5. Pursue perfection.Slide5
SCRUM
1. First agile method where work is done iteratively in sprints.
2. Sprints are typically 2 to 4 weeks.
3. Customer can change requirements during project.Slide6
AGILE MANIFESTO 2001
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.
5. That is, while there is value in the items on the right, we value the items on the left more.Slide7
Fundamentals of Extreme Programming
1. Pair programming
2. Planning game
3. Small releases
4. Continuous testing
5. System metaphor
6. Simple design
7. Re-factoring
8. Collective code ownership
9. Continuous integration
10. Coding standards
11. 40-hour week
11. On-site customerSlide8
Extreme Programming
1. Requirements are described as scenarios that read like a story. Diagrams may be used to make it easier to understand.
2. Story boarding- Interactions are drawn using UML.
3. Class diagrams are made from the UML.
4. Behavior between classes needs described in pseudocode.
5. Code everything.
6. Testing.Slide9
RELEVANCE OF NEW PRINCIPLES
The web as a platform
UGCThe value of web software is dependent on user-generated content.
Self-sustainabilityAs a user network is built, more services are added to the software, creating a direct correlation between traffic and quality.Slide10
"Harnessing collective intelligence"
Let a playa playThe role of the host is to create an environment optimized for user input and exchange.
GPL Collective intelligence is a byproduct of a growing developer community.
Viral marketing Meeting the needs of users creates a self-perpuating growth rate.
Crowdsourcing Funding has gone viral.Slide11
The end of software cycles
Sorftware as a service:
The role of the host is to create an environment optimized for user input and exchange.Slide12
RELEVANCE OF NEW PRINCIPLES
Technical issues are not often the major contribution to the failure of the system development project. It is people issues that mainly cause the project failure.
1. People being inflexible and insisting on creating a detailed, up front to do architecture.
2. People not realize that you need to invest a bit of time up front to do architecture envisioning.
3. People not understanding the need to prove the architecture early in the project with working code.Slide13
PEOPLE’S PERSPECTIVES ON AGILE METHODOLOGIES
Lightweight programming models
Simplicity breeds adoptionSoftware development techniques that are more loose and less corporate are more likely to spread.
Innovation in assemblyReusable and highly accessible tools will challenge the proprietary standards.
Cross-functional teamsNo more compartmentalizing your developers. Teams and projects, like ideas, should flow freely.Slide14
Agile in the Industry
PROS & CONS
What are some of the disadvantages of Agile?
1. Active user involvement and close collaboration are required throughout the development cycle.
2. Requirements are revealed and evolve over time.
3. Agile requirements are intentionally minimal.
4. Testing is integrated throughout the lifecycle.
5. Feature sign off’s are required.
6. Agile development can be intense for developers.Slide15
IS AGILE FOR US?
Vital questions:
1. Do companies have to just choose either Waterfall or Agile or are there hybrid options?
2. What questions should be asked? How can a company decide whether to implement Agile methodologies?Slide16
Is the project suitable for Agile?
1. Does the project have a lot of ambiguity and uncertainty?
2. Does the product already exist or is this project starting from scratch?
3. How critical are the operations of the final product?Slide17
Is the team suitable for Agile?
1. Does the Product Owner have the right level of authority and influence?
2. Is there a dedicated, persistent, cross-functional team?
3. Is the team co-located?
4. Do you have an Uber Product Owner and Uber ScrumMaster?
5. Is there a controlled build environment?