1 / 34

Agile Methods

Agile Methods . What are Agile Methods? Extreme Programming is the best known example SCRUM is another popular example Agile Methods have the following in common Individuals over process Working software over documentation Collaboration over Contracts

jaden
Télécharger la présentation

Agile Methods

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Agile Methods • What are Agile Methods? • Extreme Programming is the best known example • SCRUM is another popular example • Agile Methods have the following in common • Individuals over process • Working software over documentation • Collaboration over Contracts • Responding to change over following a plan • Each of these helps to optimize the process Computer Engineering 203 R Smith Agile Development 1/2009

  2. Agile Methods • Why is there an interest in Agile Methods • Traditional methods have not greatly improved the state of: • On time, in budget delivery of Software • Customer satisfaction • Developer dissatisfaction with • Hours and schedules • Jobs are not fun • Speed of changes in the market Computer Engineering 203 R Smith Agile Development 1/2009

  3. Agile Methods • Comparison with traditional methods • Agile methods require customer involvement throughout development versus involvement only at specific phases. • Agile methods only develop detailed plans for the near term versus detailed planning over the entire project. • Agile methods use working code and prototypes versus documentation Computer Engineering 203 R Smith Agile Development 1/2009

  4. Agile Methods • Agile methods rely on early developer test case development versus separate test functions. • Example Test Driven Development • Agile methods design for one feature at a time versus complete design. • LEAN development • Agile methods produce many small release versus a limited number of larger releases. Computer Engineering 203 R Smith Agile Development 1/2009

  5. Agile still needs discipline • Even in Agile development models there are still processes and procedures that must be followed. • For example Scrum’s daily meeting is a requirement of the process. Computer Engineering 203 R Smith Agile Development 1/2009

  6. Agile Methods • Example Agile Methods • Extreme Programming • OpenUP • LEAN Development • Crystal • SCRUM • Test Driven Development Computer Engineering 203 R Smith Agile Development 1/2009

  7. Agile Methods • Agile Modeling • Flexible use of modeling to describe various aspects of the system. • Simplified approach of modeling without the formal syntax of UML • Method of communications that complements Agile development techniques. • Use of multiple models. Computer Engineering 203 R Smith Agile Development 1/2009

  8. Agile Principles • Customer satisfaction through early and continuous delivery of software. • Welcome changing requirements. • Delivery schedules in the scale of weeks. • Daily contact with the customer. • Motivated developers. • Face to Face interactions Computer Engineering 203 R Smith Agile Development 1/2009

  9. Agile Principles • Working software as a measure of progress. • Develop at a sustainable pace. • Promote technical excellence. • Simplicity. • Self-organizing teams. • Regular reflection. • Elimination of waste Computer Engineering 203 R Smith Agile Development 1/2009

  10. Agile Methods • Agile Modeling and UML • From Agile Modeling’s point of view • UML is not sufficient • Example user interface interaction flow • UML is too complex • UML working in practice Computer Engineering 203 R Smith Agile Development 1/2009

  11. Extreme Programming • Extreme Programming Practices • Programming • Program incrementally • Test first • Refactoring • Coding standards • Team Practices • Code ownership • Integration Computer Engineering 203 R Smith Agile Development 1/2009

  12. Extreme Programming • Overtime • Workspace • Release schedule • Metaphor • Pair programming • Process • On-site customer • Incremental planning Computer Engineering 203 R Smith Agile Development 1/2009

  13. Extreme Programming • Test first • Why? • You know the system works • Establish a stable code base • You know when something breaks • You have a test base when you make major changes • What to test? • Anything that could break • You know what already works Computer Engineering 203 R Smith Agile Development 1/2009

  14. Test First • When to test? • When implementing a new task • Before refactoring • After refactoring • Test frameworks • You will run tests often and you will need a frame work to run them Computer Engineering 203 R Smith Agile Development 1/2009

  15. Extreme Programming • Planning cycle • Estimates are given for near term implementations • Release planning • Cost of releases • Iterations • Setting priorities Computer Engineering 203 R Smith Agile Development 1/2009

  16. Extreme Programming • Onsite Customer • The onsite customer is a key factor in XP • Developing user stories • Developing test cases • Setting priorities Computer Engineering 203 R Smith Agile Development 1/2009

  17. Extreme Programming • Design and Refactoring • Design only enough to implement the current planning iteration • Write the simplest code • Design is an iterative process • Design spikes • Exploration effort in code • Often used in planning to provide better estimates Computer Engineering 203 R Smith Agile Development 1/2009

  18. Extreme Programming • Refactoring • What it is • A disciplined approach to improving the design of existing code. • What it not • Code hacking or implementing new features. • When to refactor? • Before you implement a new feature • Make the code easier to understand • Make the code easier to enhance Computer Engineering 203 R Smith Agile Development 1/2009

  19. Extreme Programming • When you finish a task to clean up the code • When you have trouble understanding the code or finding a bug. • Before you refactor make sure you have a complete test base. • Run the tests before and after you refactor. Computer Engineering 203 R Smith Agile Development 1/2009

  20. Extreme Programming • Pair Programming • Pair programming is two developers sitting at a single computer with one keyboard. • Tasks include design, code, test and debug • Focus is on constant review • Shared ownership • Higher quality code, fewer defects Computer Engineering 203 R Smith Agile Development 1/2009

  21. Extreme Programming • Issues, Reality Check • Can you really have an onsite customer • Authority to make decisions • Time and location involved • Pair programming • Finding the right partner, hours, location, style • Can you only plan a piece at a time? Computer Engineering 203 R Smith Agile Development 1/2009

  22. Software Craftsmanship • Craftsman versus Engineer • An engineer takes a planned structured approach. • The engineer relies on process to create structure and ensure results. • The craftsman takes one small step at a time. • The craftsman relies on the quality of the individual developer to ensure overall quality. Computer Engineering 203 R Smith Agile Development 1/2009

  23. Professional Responsibility • What is your role and responsibility as a Software engineer? • Workmanship and quality • Planning, estimates and schedule • What does the customer expect? • Cost • Schedule • quality Computer Engineering 203 R Smith Agile Development 1/2009

  24. A Management View of XP • Being a coach, monitor, enforce and change the process, mentor. • Running interference, XP requires a different way of thinking on senior management’s part. • Providing the environment • Knowing how to let the team run itself. Computer Engineering 203 R Smith Agile Development 1/2009

  25. A Management View of XP • Onsite User • Small releases • Limited planning horizon • Pair programming • Test first • Limited documentation Computer Engineering 203 R Smith Agile Development 1/2009

  26. Onsite User • The manager needs to decide if having an onsite customer is realistic. • Does the onsite customers reflect the views of the customer or are they only a body? • How stable are the requirements? • Is there only one customer? • Chrysler example Computer Engineering 203 R Smith Agile Development 1/2009

  27. Small Releases • Are small releases realistic? • What is the nature of your product? • What does it take to install? • How many customers are there? • How many releases will you need to support? • How accepting are your customers of new releases? Computer Engineering 203 R Smith Agile Development 1/2009

  28. Limited Planning Horizon • Does XP’s limited planning horizon work in your company environment? • Project/Product orientation • Budget cycle and control • Will the customer accept not knowing when the work will be done? Computer Engineering 203 R Smith Agile Development 1/2009

  29. Pair Programming • How do you create the pairs? • How do you estimate the production rate? • Productivity gains are in the quality of the code not in coding speed. • How to do you reward individual performance? • Programmer skill level Computer Engineering 203 R Smith Agile Development 1/2009

  30. Test First • Provides a stable environment • You know how far you have come • No separation between developers and testers • Aids in debugging by giving immediate feedback • When is the big picture tested? Computer Engineering 203 R Smith Agile Development 1/2009

  31. Limited Documentation • What is your view of your project team and work force? • How much job movement is there? • How are new developers added to the environment? • What is the effect of good times versus bad times? Computer Engineering 203 R Smith Agile Development 1/2009

  32. Does one model work best? • What is the scientific method to determine the best method? • Can we do experiments? • Are results repeatable? • How can comparisons be made? Computer Engineering 203 R Smith Agile Development 1/2009

  33. Balancing Agile Methods and Traditional Development • Management has valid requirements for traditional planned methods • Budgets • Customers • Still Agile methods can provide positive improvements to the development process Computer Engineering 203 R Smith Agile Development 1/2009

  34. Balancing Agile Methods and Traditional Development • Understand the environment you are developing within: • Your team • Your customer • Your Management • Select the techniques that are most effective in that environment. Computer Engineering 203 R Smith Agile Development 1/2009

More Related