Your SlideShare is downloading. ×
Agile Development
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

1,923

Published on

this presentations gives very useful introduction to Agile development process and its related processes like XP, Scrum, Lean...

this presentations gives very useful introduction to Agile development process and its related processes like XP, Scrum, Lean...

Published in: Education
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,923
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
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. Agile Software Development تقديم عامر يسير عبدالله الاسماعيل لؤي جيرودية محمد سليم فواز بإشراف د . محمد الحجي
  • 2. WATERFALL DEVELOPMENT PROCESS
  • 3. WATERFALL DEVELOPMENT PROCESS Agile Software Process
  • 4. AGILE DEVELOPEMENT Agile Software Process
  • 5. WATERFALL DEVELOPMENT PROCESS Agile Software Process
  • 6. WATERFALL VS. AGILE WATERFALL CHANGE AGILE CHANGE Agile Software Process
  • 7. DESIGN VS DEVELOPMENT
  • 8. AGILE MANIFESTO Agile Software Process 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.
  • 9. VALUES Agile Software Process
  • 10. AGILE THINKING EXPLAINED Agile Software Process
  • 11. THE 12 AGILE PRINCIPLES - Principle 1/12
    • Development Team
      • Will get feedback on the system under development which guide to the next step
    • Management
      • Customer feedback acts as a confirmation
    • Organization
      • Feed back indicate the project is on the right track
    • Development Cycle
      • Support all development cycles
      • (requirement ,analysis, design and implementation .. etc)
      • Satisfy customer through early and frequent delivery.
    Agile Software Process
  • 12. THE 12 AGILE PRINCIPLES - Principle 2/12
    • Synchronies and stabilize approach
      • Engineers make changes in design until late in the project
      • Keeping individuals more synchronized and the evolving project more or less stable
      • This approach is used in a very complex products
    • Pricing Strategies
      • Unstable requirement lead to adaptive pricing strategies
      • Welcome changing requirements even late in the project.
    Agile Software Process
  • 13. THE 12 AGILE PRINCIPLES - Principle 3/12
    • Requirement Management
      • Will becomes more efficient because the product is being tested and altered quickly
    • Short Development Cycles
      • Each iteration will lead requirement and the development process to be more suitable and precise
      • The feedback gained after each iteration will lead the entire development cycle more precisely
      • Keep delivery cycles short
      • (e.g., every couple of weeks).
    Agile Software Process
  • 14. THE 12 AGILE PRINCIPLES - Principle 4/12
    • Meet Business peoples expectations
      • Usually business peoples doesn’t work enough on development projects
      • The result is a product that doesn’t meet their expectation
    • Business Decision vs. Technical Decision
      • Business decision should be left to business peoples
      • Technical decision should be left to developers
      • Business people and developers work together daily throughout the project
    Agile Software Process
  • 15. THE 12 AGILE PRINCIPLES - Principle 5/12
    • Hire experienced motivated peoples
      • Experienced motivated peoples are the key factor to any project success
    • Experienced vs. Inexperienced
      • Build a team full of experienced peoples
      • If your team consists of experienced peoples & inexperienced peoples, the experienced people's time will be wasted in helping the non-experienced ones
      • Build projects around motivated individuals
    Agile Software Process
  • 16. THE 12 AGILE PRINCIPLES - Principle 6/12
    • Face-to-Face communication
      • Face-to-face communication will decrease the amount of documentation needed
      • Enables instant feedback
      • The best way to convey the tacit knowledge between a highly professionals
      • Assist in analysis & design as problems can be discussed and solved in a rich communication mode
      • Place emphasis on face-to-face Communication
    Agile Software Process
  • 17. THE 12 AGILE PRINCIPLES - Principle 7/12
    • Working software is the main measure of progress
      • Applying all agile principles guarantee us to satisfy all different quality measurements.
      • Quality metrics: addressed in 1 st & 2 nd Principles
      • Technical metrics: addressed in 9 th & 11 th principles
      • Size-Oriented-Metrics: addressed in 9 th principle.
      • Human-oriented-metrics: addressed in 11 th & 12 th principle
    Agile Software Process
      • Working software is the primary measure of progress.
  • 18. THE 12 AGILE PRINCIPLES - Principle 8/12
    • Project effectiveness
      • Nobody can work for more than forty house with the same level of intensive required creative work
      • Tired stuff is not agile, because the tired employees doesn’t make good result
    • Social responsibility
      • Projects should be organized in a way that everyone involved should work for a reasonable working hours
      • Everyone should stay alert not engaged
      • Promote sustainable development pace
    Agile Software Process
  • 19. THE 12 AGILE PRINCIPLES - Principle 9/12
    • Making good design
      • Developers should make a good design from the early stage of the project
      • The design should continuously refined
      • Better designs will facilitate other development cycles
      • Continuous attention to technical excellence and good design
    Agile Software Process
  • 20. THE 12 AGILE PRINCIPLES - Principle 10/12
    • Developer should only implements features that have been agreed with the customer
    • Start with simple requirement , which will become clearer as the project evolve
      • Simplicity – the art of maximizing the amount of work not done
    Agile Software Process
  • 21. THE 12 AGILE PRINCIPLES - Principle 11/12
    • Agile Team
      • Can be organized again and again.
      • Agile team consist of individuals with common focus
      • Mutual trust and respect and collaboratively
      • Ability to work with ambiguity
      • The best results emerge from self organizing teams
    Agile Software Process
  • 22. THE 12 AGILE PRINCIPLES - Principle 12/12
    • Development team meeting
      • Team will Discuss their working habits
    • Organization Agility
      • Team reflects regularly where and how to improve
    Agile Software Process
  • 23. DELIVER BUSINESS VALUE
    • Focus On Purpose, Not Process
    • Concentrate on building product rather than serving process
    • Deliver business value early and continuously
    • Welcome changing requirements
      • Consider them as competitive advantages
  • 24. STEADY FLOW
    • Arrange work in a prioritized queue that delivers a steady flow of running tested software (weekly/monthly/quarterly)
    • Product Owner should pull business value from the Team
  • 25. THINK BIG. START SMALL
    • Get something small and hard-hitting out there early
    • Collect feedback from real users
    • Build on it quickly with regular incremental releases
  • 26. WORK FROM THE OUTSIDE, IN
    • Let the users drive your efforts
    • See everything from the user’s point of view
    • Understand value from the user’s perspective
    • Ask the users what they want next
  • 27. FIX TIME AND BUDGET. VARY SCOPE
    • Vary scope only to deliver on time and on budget
    • Never compromise on quality
  • 28. MAKE SMALL DECISIONS
    • Made quickly
    • Keep you moving forward
    • Reversible
  • 29. WORKING CODE BEATS EVERYTHING
    • Running tested software (RTS) is the best measure of progress
    • Focuses attention
    • Provokes more meaningful feedback
    • Learn more about what you’re building
  • 30. MAKE IT RUN. MAKE IT RIGHT . MAKE IT FAST
    • Develop software iteratively
      • Get something working
      • Perfect it afterwards through successive refinement
    • Release incrementally
      • Deliver running tested software regularly
      • Build on what’s there
    • Build quality in from the start, don’t inspect for it afterwards
  • 31. LET THINGS EVOLVE
    • Let details emerge as things come into focus and you get feedback
    • Worry about details when they really matter
    • The best architectures, requirements and designs evolve over time
  • 32. REFLECT TO IMPROVE
    • At regular intervals, reflect on the past and how to become more effective
    • Seek improvement
    • Be Effective, Don’t get so busy that you lose your ability to be effective
  • 33. HOW AGILE CAN YOU BE? Agile Software Process
  • 34. COMPARISION
  • 35. COMPARISION
  • 36. AGILE UMBERLLA Agile Software Process
  • 37. XP Method
    • eXtreme
    • Programming
  • 38. XP Values
    • Communication
            • Within the team, and with customers
    • Simplicity
            • What is the simplest thing that could
            • possibly work?
    • Feedback
            • Test results are the best concrete
            • feedback.
    • Courage
            • If there is a flaw, fix it.
  • 39. The 12 Key Practices
    • The Planning Game
    • Small Releases
    • Metaphor
    • Simple Design
    • Test-Driven Development
    • Refactoring
    • Pair Programming
    • Collective Ownership
    • Continuous Integration
    • 40-Hour Workweek
    • On-site Customer
    • Coding Standards
  • 40. 1. Planning Game
    • Planning game is the point of interaction between customers and developers.
    • Release Planning is where the customer articulates the required features, the programmers estimate the difficulty
    • Iteration Planning is where a subset of the required features are broken down into tasks, estimated in more detail, and allocated to programmers
  • 41. 1. How it works for me?
    • Customer provides all the story cards that have been written
    • Developers write on each card an estimate of how long it will take to implement
    • Customer chooses stories by priority to fill the available time
    • Don’t plan too far ahead
    • Play the Planning Game after each increment
  • 42. 1. Planning Game
  • 43. 2. Small Releases
    • As small as possible, but still delivering business value
    • Get customer feedback early and often.
    • The team Incrementally improve the system, adding small features.
    • Do the planning game after each iteration
      • Do they want something different?
      • Have their priorities changed?
  • 44. 2. How it works for me?
    • Small releases are really valuable
    • Manage the risk of delivering something wrong
    • Helps the customer to define better the requirements
    • Release every few weeks
    • Large projects are not so flexible
      • Try to release something, even you know that it will be changed .
  • 45. 3. Simple Design
    • XP teams consider the simplest thing that could possibly work and try to implement it.
    • DTSTTCPW – “Do The Simplest Thing That Could Possibly Work
    • XP teams view design as something done continuously through the course of the development.
    • keep things simple by not implementing anything you don’t need right now, often known as YAGNI (“You Aren’t Gonna Need It”)
  • 46. 3. How it works for me?
    • Simple design does not mean "no design"
    • It is about establishing priorities
    • It's a set of tradeoffs you make
    • If something is important for this release and for the whole system, it should be designed well
  • 47. 4. Pair Programming
    • Pairs produce higher quality code
    • Pairs complete their tasks faster
    • Pairs enjoy their work more
    • Pairs feel more confident in their work products
  • 48. 4. . How it works for me?
    • “ Programming isn’t typing”
    • Pair programming is great for complex and critical logic
    • When developers need good concentration
    • Where quality is really important Especially during design
    • Trivial tasks can be done alone
    • most programmers enjoy it once they have tried it.
  • 49. 5. Test-Driven Development
    • Tests play the most important and central role in XP
    • Tests are written before the code is developed.
    • In this environment, change is
    • low cost and encouraged.
  • 50. 5. How it works for me?
    • This helps with two things:
      • It forces programmers to focus on the “what”, the interface itself, before the “how”, the implementation.
      • It means that there are tests for every facet of the system.
    • TDD is good for most projects, not for all.
  • 51. 6. Continuous Integration
    • XP teams force integration as often as they can.
    • XP teams don't have code freezes, or go through integration hell – they just integrate all the time.
  • 52. 6. How it works for me?
    • Integrating often is really valuable
    • Sometimes you cannot finish a task for one day and integrate it.
    • For small projects with small teams integration is not an issue.
    • For large and complex projects it's crucial
      • Think of automated build environment
  • 53. 7. Collective Code Ownership
    • Code to belongs to the project, not to an individual engineer!
    • Anyone can change any part of the part at any time.
    • Programmers are not required to work around deficiencies in code they do not own
    • Faster progress
    • No need to wait for someone else to fix something
    • This eliminates bottlenecks (“I can't work on that until Steve's free”)
  • 54. 8. Coding Standard
    • All the code produced by an XP team should look like it was produced by the same person.
    • An XP team needs this to support effective pairing and collective ownership.
    • Common code formatting .
  • 55. 9. On-Site Customer
    • Customer has to be present and available full-time for the team.
      • Clarify user stories
      • Make critical business decisions
    • Customer is considered part of the team
    • Developers don’t make assumptions
    • Developers don’t have to wait for decisions
    • Face to face communication minimizes the chances of misunderstanding
  • 56. 10. Metaphor
    • For effective communication, everyone in an XP team needs to be able to talk about the system using the same vocabulary and language
    • Often they communicate through a metaphor.
    • The default metaphor is the business domain, and it’s usually just fine
  • 57. 11. Forty-Hour Work Week
    • Kent Beck says, “ . . . fresh and eager every morning, and tired and satisfied every night”
    • Tired developers make more mistakes, which slows you down more in the long run
    • A maximum of 40-hour working a week.
  • 58. 12. Refactoring
    • Improve the design of existing code without changing its functionality
    • Relies on unit testing to ensure the code is not broken
    • Bad smells in code:
      • Long method / class
      • Duplicate code
      • Methods does several different things (cohesion)
      • Too much dependencies (coupling)
      • Complex / unreadable code
  • 59. 13. The 13 th Practice? The Stand Up Meeting
    • Start day with 15-minute meeting.
    • Everyone stands up (so the meeting stays short) in circle Going around the room everyone says specifically:
      • What they did the day before
      • What they plan to do today
      • Any obstacles they are experiencing
  • 60. 13. People Communicate Most Effectively Face-to- Face
  • 61. Main Roles in XP
    • Programmer
    • Customer
    • Tester
    • Tracker
    • Coach
    • Consultant
  • 62. Who benefits from XP?
    • get clear requirements & priorities
    • can do a good job
    • can make technical decisions
    • don’t work overtime
    • get accurate feedback
    • get most business value first
    • can make informed business decisions
    • can change their mind
    Programmers: Customers:
  • 63. When to Use XP
    • XP works when:
      • Requirements are changing rapidly
      • High risk, new challenge projects
      • Small groups of programmers (between 2-10)
      • Direct customer involvement is possible
  • 64. When does Extreme Programming fail?
    • Using the wrong people.
    • Having the wrong customer.
    • Poor communication.
  • 65. SCRUM
  • 66. SCRUM CHARACTERISTICS
    • Simple and scaleable
      • Easily combined with
      • other methods and
      • doesn’t prescribe engineering practices
    • Empirical process
      • Short-term detailed planning with constant feedback provides simple inspect and adapt cycle
    • Simple techniques
      • Requirements are captured as user stories in a list of product backlog
      • Progress is made in a series of 1 to 4-week Sprints
  • 67. SCRUM CHARACTERISTICS
    • Self-organizing Teams collaborating with the Product Owner
    • Optimizes working environment
    • Fosters openness
  • 68. EMPIRICAL PROCESS
    • Visibility
      • Keep everything visible at all times
      • There's no hiding problems , issues, or obstacles
      • See them , understand them, deal with them
      • Keep working software in plain sight and in the Product Owner’s mind
  • 69. EMPIRICAL PROCESS
    • Visibility
    • Inspection
      • Inspect frequently
      • Create as many opportunities to obtain feedback as possible
  • 70. EMPIRICAL PROCESS
    • Visibility
    • Inspection
    • Adaptation
      • Adapt frequently to optimize results
      • Be driven by results and not by effort
      • Measure progress by goals achieved and not by the effort it took to achieve them
  • 71. SCRUM CYCLE
  • 72. PRODUCT BACKLOG
    • Evolving queue of work expressed as user stories
    • Prioritized by business value
    • Aim to deliver highest business value user stories first
  • 73. SPRINT BACKLOG
    • User stories planned in Sprint
    • Sprint Goal
    • Owned by Team
    • Product Owner cannot change Sprint Goal nor Sprint Backlog once Sprint has started
    • Team can:
      • Request new user stories if others completed early
      • Update estimates
      • Ask Product Owner to de-scope user stories that can’t be completed
      • Terminate Sprint
  • 74. SPRINT
    • Fixed time-box of 1-4 weeks to build something valuable for the Product Owner
    • Delivers potentially shippable increment of product
    • Includes development, testing , etc
  • 75. PRODUCT OWNER
    • 1 per Team, collocated with Team
  • 76. PRODUCT OWNER
    • 1 per Team, collocated with Team
    • Visible, vocal and objective driving force making all business decisions for product
      • Responsible for business value delivered by Team
      • Reviews/accepts/rejects user stories delivered in Sprint
  • 77. PRODUCT OWNER
    • 1 per Team, collocated with Team
    • Visible, vocal and objective driving force making all business decisions for product
    • Keeper/owner of the Product Backlog
      • Defines goals
      • Writes/evolves user stories narrowing their focus as they approach release/iteration planning
      • Prioritizes Product Backlog by business value to set development schedule
  • 78. PRODUCT OWNER
    • 1 per Team, collocated with Team
    • Visible, vocal and objective driving force making all business decisions for product
    • Keeper/owner of the Product Backlog
    • Attend every Release/Sprint Planning Game and Sprint Review
    • Communicates user story details
    • to Team and provides timely
    • feedback throughout development
  • 79. SCRUM TEAM
    • Small team, 7±2 full-time people, collocated
    • Self-organizing , self-disciplined
      • Create and implement their own process and improvements
      • Organize themselves around the work
    • Empowered, accountable
      • Authority to do whatever is needed to
      • meet their commitments
      • Accountable for their commitments
  • 80. SCRUM MASTER
    • 1 per Team, collocated with the Team
    • Servant leader to Team
      • Facilitator without authority
      • Removes obstacles to help the Team maintain a sustainable pace
      • Mediates between management and the Team
    • Helps Product Owner:
      • Drive the development effort directly
    • Authority for Scrum process
      • Ensures the Team uses the values,
      • principles and the practices
  • 81. SPRINT PLANNING GAME
    • Planning up close
      • Plan only next Sprint in detail when it starts
      • Use Velocity as best guess of future progress (Yesterday’s Weather)
  • 82. PIGS AND CHICKENS
    • Scrum Team are known as pigs because they’re committed to delivering Sprint Goal
    • People who are involved but not dedicated to the project are known as chickens
      • Attend Daily Scrums as observers
  • 83. DAILY SCRUM
    • ≤ 15 mins, standing up at same time every day, at same place
    • Team members (pigs) talk , observers (chickens) listen
    • Heartbeat of Scrum
      • Pigs co-ordinate today's work and checks progress
      • Provides daily status snapshot to chickens
    • Commitments and accountability
      • Say what you’ll do and do what you say
    • Take discussions/problem-solving offline
  • 84. SPRINT REVIEW
    • ≤ 30 minutes at end of every Sprint
    • Product Owner, Team and other Stakeholders
    • Informal demonstration of functionality delivered in Sprint
    • Product Owner inspects completed business value
      • Establish whether Sprint Goal has been satisfied
      • Accepts/rejects functionality delivered by user stories
      • Provide feedback
  • 85. RETROSPECTIVE
    • Time to reflect
    • Amplify learning , seek improvement and adapt
    • Release retrospective
    • Heartbeat retrospective
      • 1 hour at end of every Sprint
      • Team
      • Reflect on process and how Team is
      • working and initiate improvements
  • 86. HOW SCRUM ARE WE?
  • 87. SCRUM
  • 88.  
  • 89. REFERENCES
    • An Introduction to Agile Methods
    • by Steve Hayes (Khatovar Technology)
    • INTRODUCTION TO AGILE AND SCRUM
    • by Simon Baker
    • Agile Software Development Methodologies and XP Svetlin Nakov National Academy for National Software DevelopmentSoftware Development
    • Kent Beck. “Extreme Programming Explained: Embrace The Change”
    • Ron Jeffries. “Extreme Programming Installed”
    • Kent Beck, Martin Fowler. “Planning Extreme Programming”
    • Kent Auer, Roy Miller. “Extreme Programming Applied: Playing to Win”
    • Martin Fowler. “Refactoring: Improving design of existing code”

×