Agile Model for Beginner’s
Download as PPTX, PDF0 likes548 views
The document provides an overview of the Agile model for software development. It defines Agile as a time-boxed, iterative approach that focuses on incremental delivery of working software from the beginning of a project. The key aspects of Agile covered include user stories, prioritization, continuous integration, adaptive planning, and valuing working software over documentation. Agile values collaboration, rapid feedback, and responding to change over rigid adherence to plans.
Agile Model for Beginner’s
- 1. Agile Model for Beginner’s Mohammad Nasir Uddin Developer Page 1 12/15/2016
- 2. What is Agile? Page 2 12/15/2016
- 3. About Agile Agile is a Software Development Methodology It means ‘ability to move quickly and easily’ and responding swiftly to change It’s a time boxed, iterative approach Develop and deliver software incrementally from the start of the project, instead of trying to deliver it all at once near the end. Page 3 12/15/2016
- 4. About Agile (Cont.) Iterations are typically 1 to 4 weeks so that the development is aligned with the changing business needs It works by breaking projects down into little bits of user functionality called user stories, prioritizing them, and then continuously delivering them in short two week cycles called iterations. Page 4 12/15/2016
- 5. Agile Development Cycle Page 5 12/15/2016
- 6. Agile Life Cycle Page 6 12/15/2016
- 7. How does it work? Page 7 12/15/2016
- 8. Make a list Sitting down with the customers make a list of features they would like to see in their software. We call these things user stories and they become the To Do list for project. Page 8 12/15/2016
- 9. User Stories Page 9 12/15/2016
- 10. Size things up Size user stories using Agile estimation techniques Coming up with a guess as to how long each user story will take. Page 10 12/15/2016
- 11. Time Estimations Don’t estimate things absolutely, as we are not good at that. Try to estimate things relatively as we are good at that Page 11 12/15/2016
- 12. Time Estimations (Cont.) Relatively sizing means – don’t worry about exactly how big a story is. Worry more how this story’s size compares to others. Page 12 12/15/2016
- 13. Set some priorities Like any other lists, there always seems to be more to do than time allows. Ask the customer to prioritize their list Get the most important stuff done first, and save the least important for last. Page 13 12/15/2016
- 14. Start executing Start delivering some value. Start at the top. Work your way to the bottom. Building, iterating, and getting feedback from your customer as you go. Page 14 12/15/2016
- 15. Update the plan as you go Then, as you and your customer starting delivering, one of two things is going to happen. You'll discover: You're going fast enough. All is good. Or, You have too much to do and not enough time. At this point you have two choices. You can either a) do less and cut scope (recommended). Or you can b) push out the date and ask for more money. Page 15 12/15/2016
- 16. How is Agile different? Page 16 12/15/2016
- 17. Continuous Activities Analysis, design, coding, and testing are continuous activities You are never done analysis, design, coding and testing on an Agile project. So long as there are features to build, and the means to deliver them, these activities continue for the duration of the project. Page 17 12/15/2016
- 18. Development is iterative Iterative development means starting with something really simple, and adding to it incrementally over time. It means evolving the architecture, accepting that your requirements are going to change, and continuously refining and tweaking your product as you go. Page 18 12/15/2016
- 19. Planning is adaptive When reality disagrees with their plans, Agilists find it easier to change their plans than reality. It is called adaptive planning. And while there are many ways to changes plans, the preferred way is to flex on scope. Page 19 12/15/2016
- 20. Scope can vary Agile deals with the age old problem of having too much to do and not enough time by doing less. By fixing time, budget, and quality, and being flexing around scope, Agile team's maintain the integrity of their plans, work within their means, and avoid the burn out, drama, and dysfunction traditionally associated with our industry. Page 20 12/15/2016
- 21. Requirements can change Traditionally change has been avoided on software projects because of it's high perceived cost late in the game. Agile challenges this notion and believes the cost of change can be relatively flat. Through a combination of modern software engineering practices, and open and honest planning, Agilists accept and embrace change even late in delivery process. Page 21 12/15/2016
- 22. Measure of success Working software is the primary measure of success In Agile productivity is measured in rate at which teams can turn their client’s wishes into working software. Project plans, test plans, and analysis artifacts are all well and good but Agilists understand they in themselves are of no value to the end customer. Page 22 12/15/2016
- 23. Agile Manifesto The Agile Manifesto, also called the Manifesto for Agile Software Development It is a formal announcement of four key values and 12 principles to guide an iterative and people-centric approach to software development. Page 23 12/15/2016
- 24. Agile Core Values The agile software development emphasizes on four core values. 1) Individual and team 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 Page 24 12/15/2016
- 25. Twelve Principles 1. Customer satisfaction through early and continuous software delivery – Customers are happier when they receive working software at regular intervals, rather than waiting extended periods of time between releases. 2. Accommodate changing requirements throughout the development process – The ability to avoid delays when a requirement or feature request changes. 3. Frequent delivery of working software – Scrum accommodates this principle since the team operates in software sprints or iterations that ensure regular delivery of working software. Page 25 12/15/2016
- 26. Twelve Principles (Cont.) 4. Collaboration between the business stakeholders and developers throughout the project – Better decisions are made when the business and technical team are aligned. 5. Support, trust, and motivate the people involved – Motivated teams are more likely to deliver their best work than unhappy teams. 6. Enable face-to-face interactions – Communication is more successful when development teams are co-located. Page 26 12/15/2016
- 27. Twelve Principles (Cont.) 7. Working software is the primary measure of progress – Delivering functional software to the customer is the ultimate factor that measures progress. 8. Agile processes to support a consistent development pace – Teams establish a repeatable and maintainable speed at which they can deliver working software, and they repeat it with each release. 9. Attention to technical detail and design enhances agility – The right skills and good design ensures the team can maintain the pace, constantly improve the product, and sustain change. 10. Simplicity – Develop just enough to get the job done for right now. Page 27 12/15/2016
- 28. Twelve Principles (Cont.) 11. Self-organizing teams encourage great architectures, requirements, and designs – Skilled and motivated team members who have decision-making power, take ownership, communicate regularly with other team members, and share ideas that deliver quality products. 12. Regular reflections on how to become more effective – Self-improvement, process improvement, advancing skills, and techniques help team members work more efficiently. Page 28 12/15/2016
- 29. Agile vs Waterfall Page 29 12/15/2016
- 30. Fundamental Assumptions Traditional: Systems are fully specifiable, predictable, and can be built through thorough and extensive planning. Agile: High-quality, adaptive software can be developed by small teams using the principles of continuous design improvement and testing based on rapid feedback and change. Control Traditional: Process-centric Agile: People-centric Management Style Traditional: Command-and-control Agile: Leadership-and-collaboration Role Assignment Traditional: Individual—favors specialization Agile: Self-organizing teams—encourages role interchangeability Agile vs. Waterfall Page 30 12/15/2016
- 31. Agile vs. Waterfall (Cont.) Communication Traditional: Formal Agile: Informal Customer’s Role Traditional: Important Agile: Critical Project Cycle Traditional: Guided by tasks or activities Agile: Guided by product features Development Model Traditional: Life cycle model (Waterfall, Spiral, or some variation) Agile: The evolutionary-delivery model Technology Traditional: No restriction Agile: Favors object-oriented technology Page 31 12/15/2016
- 32. Agile Methods Page 32 12/15/2016