Software Development The Agile Way
Download as PPT, PDF3 likes906 views
Agile software development is a set of methodologies based on iterative progress through collaborative processes within cross-functional teams, emerging as a response to rigid waterfall models in the mid-1990s. Key principles include prioritizing individuals and interactions, working software, customer collaboration, and adaptability to change. Notable methods within Agile include Scrum, Extreme Programming, and Adaptive Software Development, characterized by practices that encourage frequent delivery of working software and active stakeholder involvement.
Software Development The Agile Way
- 1. Software Development- The Agile Way It is all about Common sense. Audience: Development Team
- 2. What is Agile Group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams.
- 3. History Evolved in the mid-1990s as part of a reaction against "heavyweight" methods. Heavily regulated, regimented, micro-managed use of the waterfall model of development. Initially, agile methods were called "lightweight methods." Common Methods: Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development, and Dynamic Systems Development Method (DSDM) (1995)
- 4. History In 2001, 17 prominent figures, at the Snowbird ski resort in Utah, coined the terms "Agile Software Development" and "agile methods", and they created the Agile Manifesto. Later, The Agile Alliance , a non-profit organization that promotes agile development. In 2005, Alistair Cockburn and Jim Highsmith gathered another group of people—management experts, this time—and wrote an addendum, known as the PM Declaration of Interdependence .
- 5. The Values behind the Agile Manifesto Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
- 6. The principles behind the Agile Manifesto Customer satisfaction by rapid, continuous delivery of useful software Working software is delivered frequently (weeks rather than months) Working software is the principal measure of progress Even late changes in requirements are welcomed Close, daily cooperation between business people and developers Face-to-face conversation is the best form of communication (co-location) Projects are built around motivated individuals, who should be trusted Continuous attention to technical excellence and good design Simplicity Self-organizing teams Regular adaptation to changing circumstances
- 7. Problems with Suitability of agile methods Large scale development efforts (>20 developers), though scaling strategies and evidence to the contrary have been described. Distributed development efforts (non-co-located teams). Strategies have been described in Bridging the Distance and Using an Agile Software Process with Offshore Development Command-and-control company cultures. Forcing an agile process on a development team
- 8. Agile methods / practices Agile methods Agile Modeling Agile Unified Process (AUP) Agile Data Method DSDM Essential Unified Process (EssUP) Extreme programming (XP) Feature Driven Development (FDD) Getting Real Open Unified Process (OpenUP) Scrum Lean software development Agile practices Test Driven Development (TDD) Behavior Driven Development (BDD) Continuous Integration Pair Programming Planning poker RITE Method
- 9. Agile Modeling (AM) Core Practices: Active Stakeholder Participation including direct users, their management, senior management, operations staff, and support (help desk) staff. Model With Others . Apply The Right Artifact(s) . UML diagram/ER diagram Iterate To Another Artifact . Prove It With Code . Use The Simplest Tools . Model In Small Increments . Single Source Information .
- 10. Agile Modeling (AM) Collective Ownership . Create Several Models in Parallel . Create Simple Content . Depict Models Simply . Display Models Publicly . Supplementary Practices: Apply Modeling Standards . Apply Patterns Gently . Discard Temporary Models . Formalize Contract Models . Update Only When It Hurts . References: http://www.agilemodeling.com/practices.htm
- 11. Scrum Iterative incremental framework for managing complex work (such as new product development) commonly used with agile software development
- 12. Key Terms Product owner Project’s key stakeholder and represents users, customers and others in the process. Scrum Master Responsible for making sure the team is as productive as possible. Product backlog Prioritized features list containing every desired feature or change to the product Sprint: Time-boxed period of software development focused on a given list of goals (but with variable scope).
- 14. Meetings Daily Scrum /“the daily standup” During the meeting, each team member answers three questions: What have you done since yesterday? What are you planning to do today? Do you have any problems preventing you from accomplishing your goal? Scrum of scrums Each day normally after the daily scrum. These meetings allow clusters of teams to discuss their work, focusing especially on areas of overlap and integration. A designated person from each team attends. The agenda will be the same as the Daily Scrum, plus the following four questions: What has your team done since we last met? What will your team do before we meet again? Is anything slowing your team down or getting in their way? Are you about to put something in another team’s way?
- 15. Sprint Review Meeting Review the work that was completed and not completed Present the completed work to the stakeholders (a.k.a. “the demo”) Incomplete work cannot be demonstrated Four hour time limit Sprint Retrospective All team members reflect on the past sprint Make continuous process improvements Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint? Three hour time limit
- 16. Burn down Graphical representation of work left to do versus time. The outstanding work (or backlog) is often on the vertical axis, with time along the horizontal.
- 17. Burn down Types sprint burndown chart Release Burndown Chart Alternative Release Burndown Chart
- 18. General practices of Scrum The following are some general practices of Scrum: Customers become a part of the development team (i.e., the customer must be genuinely interested in the output). Scrum has frequent intermediate deliveries with working functionality, like all other forms of agile software processes. This enables the customer to get working software earlier and enables the project to change its requirements according to changing needs. Frequent risk and mitigation plans are developed by the development team itself—risk mitigation, monitoring and management (risk analysis) occurs at every stage and with commitment. Transparency in planning and module development—let everyone know who is accountable for what and by when. Frequent stakeholder meetings to monitor progress—balanced dashboard updates (delivery, customer, employee, process, stakeholders) There should be an advance warning mechanism, i.e., visibility to potential slippage or deviation ahead of time. No problems are swept under the carpet. No one is penalized for recognizing or describing any unforeseen problem. Workplaces and working hours must be energized—“Working more hours” does not necessarily mean “producing more output.”
- 20. An other view( SCRUM Methodology )
- 21. SCRUM Phases SCRUM has the following groups of phases: 1.Pregame 2.Game 3.Postgame Pregame Planning : Definition of a new release based on currently known backlog, along with an estimate of its schedule and cost. If a new system is being developed, this phase consists of both conceptualization and analysis. If an existing system is being enhanced, this phase consists of limited analysis. Architecture : Design how the backlog items will be implemented. This phase includes system architecture modification and high level design.
- 22. SCRUM Phases Game Development Sprints : Development of new release functionality, with constant respect to the variables of time, requirements, quality, cost, and competition. Interaction with these variables defines the end of this phase. There are multiple, iterative development sprints, or cycles, that are used to evolve the system. Postgame Closure : Preparation for release, including final documentation, pre-release staged testing, and release.
- 23. Planning Development of a comprehensive backlog list. Definition of the delivery date and functionality of one or more releases. Selection of the release most appropriate for immediate development. Mapping of product packets (objects) for backlog items in the selected release. Definition of project team(s) for the building of the new release. Assessment of risk and appropriate risk controls. Review and possible adjustment of backlog items and packets. Validation or reselection of development tools and infrastructure. Estimation of release cost, including development, collateral material, marketing, training, and rollout. Verification of management approval and funding.
- 24. Architecture/High Level Design Review assigned backlog items. Identify changes necessary to implement backlog items. Perform domain analysis to the extent required to build, enhance, or update the domain models to reflect the new system context and requirements. Refine the system architecture to support the new context and requirements. Identify any problems or issues in developing or implementing the changes Design review meeting, each team presenting approach and changes to implement each backlog item. Reassign changes as required.
- 25. Development (Sprint) The Development phase is an iterative cycle of development work. The management determines that time, competition, quality, or functionality are met, iterations are completed and the closure phase occurs. This approach is also known as Concurrent Engineering. Development consists of the following macro processes : Meeting with teams to review release plans. Distribution, review and adjustment of the standards with which the product will conform. Iterative Sprints, until the product is deemed ready for distribution.
- 26. Development (Sprint) Each Sprint consists of one or more teams performing the following: Develop: Defining changes needed for the implementation of backlog requirements into packets, opening the packets, performing domain analysis, designing, developing, implementing, testing, and documenting the changes. Development consists of the micro process of discovery, invention, and implementation. Wrap: Closing the packets, creating a executable version of changes and how they implement backlog requirements. Review: All teams meeting to present work and review progress, raising and resolving issues and problems, adding new backlog items. Risk is reviewed and appropriate responses defined. Adjust: Consolidating the information gathered from the review meeting into affected packets, including different look and feel and new properties.
- 27. Development (Sprint) Each Sprint is followed by a review, whose characteristics are: The whole team and product management are present and participate. The review can include customers, sales, marketing and others. Review covers functional, executable systems that encompass the objects assigned to that team and include the changes made to implement the backlog items. The way backlog items are implemented by changes may be changed based on the review. New backlog items may be introduced and assigned to teams as part of the review, changing the content and direction of deliverables. The time of the next review is determined based on progress and complexity. The Sprints usually have a duration of 1 to 4 weeks.
- 28. Closure When the management team feels that the variables of time, competition, requirements, cost, and quality concur for a new release to occur, they declare the release “closed” and enter this phase. This phase prepares the developed product for general release.Integration, system test, user documentation, training material preparation, and marketing material preparation are among closure tasks.
- 30. Key Terms Velocity: The amount of work that you can do in each iteration How much product backlog effort a team can handle in one sprint. Impediment Anything that prevents a team member from performing work as efficiently as possible.
- 31. Estimation Using Scrum Involve everybody you think would be part of the project. The first step is to break your requirements into user stories. User stories is a piece of functionality which has a functional flow and can be delivered. User stories are simple, clear, brief descriptions of functionality that will be valuable to either a user or purchaser of a product User stories: help deferring details till later They talk problems not solutions They fit nicely as your Product Backlog items
- 32. Scrum Planning The two levels of planning Strategic level / Story level / product backlog Tactical level / Task level / spring backlog
- 36. Example
- 37. Support in MS visual studio 2008 http://channel9.msdn.com/pdc2008/TL09/
- 38. Support in MS visual studio 2010 A special template is provided to follow Scrum
- 39. Drawback of Agile No process is guaranteed to work straight out of box.
- 40. References http://www.agilemanifesto.org http://agilesoftwaredevelopment.com http://www.agilesecrets.com/ http://www.agile-software-development.com http://www.agilemodeling.com/ http://www.agilemodeling.com/ http://scrumforteamsystem.com http://www.agilejournal.com http://www.youtube.com/view_play_list?p=E5EAAE9043D08AB4
- 41. Further Discussion A soft copy will be available at: http://softarchitect.wordpress.com For Future discussion, join http://tech.groups.yahoo.com/group/SoftArchitect/