Agile Software Development 1
Agile Software Development Agile is a framework that defines how software development needs to be carried on. Agile is not a single method, it represents the various collection of methods and practices that follow the value statements provided in the manifesto. Agile methods and practices do not promise to solve every problem present in the software industry (No Software model ever can). But they sure help to establish a culture and environment where solutions emerge. Principles:  Highest priority is to satisfy the customer through early and continuous delivery of valuable software.  It welcomes changing requirements, even late in development.  Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shortest timescale.  Build projects around motivated individuals. Give them the environment and the support they need, and trust them to get the job done.  Working software is the primary measure of progress.  Simplicity the art of maximizing the amount of work not done is essential.  The most efficient and effective method of conveying information to and within a development team is face-to-face conversation 2
Pro’s and Con’s Advantages:  Deployment of software is quicker and thus helps in increasing the trust of the customer.  Can better adapt to rapidly changing requirements and respond faster.  Helps in getting immediate feedback which can be used to improve the software in the next increment.  People – Not Process. People and interactions are given a higher priority rather than process and tools.  Continuous attention to technical excellence and good design. Disadvantages:  In case of large software projects, it is difficult to assess the effort required at the initial stages of the software development life cycle.  The Agile Development is more code focused and produces less documentation.  Agile development is heavily depended on the inputs of the customer. If the customer has ambiguity in his vision of the final outcome, it is highly likely for the project to get off track.  Face to Face communication is harder in large-scale organizations.  Only senior programmers are capable of taking the kind of decisions required during the development process. Hence it’s a difficult situation for new programmers to adapt to the environment. 3
Agile Development  In Agile development, Design and Implementation are considered to be the central activities in the software process.  Design and Implementation phase also incorporate other activities such as requirements elicitation and testing into it.  In an agile approach, iteration occurs across activities. Therefore, the requirements and the design are developed together, rather than separately.  The allocation of requirements and the design planning and development as executed in a series of increments. In contrast with the conventional model, where requirements gathering needs to be completed in order to proceed to the design and development phase, it gives Agile development an extra level of flexibility.  An agile process focuses more on code development rather than documentation. 4
Agile Life Cycle 5
Plan-driven and agile specification 6 separate development stages with the outputs to be produced at each of these stages planned in advance. Not necessarily waterfall model – plan- driven, incremental development is possible Iteration within stage Iteration of stage User's full agreement at end, not before code
7
Problems with agile methods  It can be difficult to keep the interest of customers / users who are involved in the process.  Team members may be unsuited to the intense involvement that characterizes agile methods.  Prioritizing changes can be difficult where there are multiple stakeholders.  Maintaining simplicity requires extra work.  Contracts may be a problem as with other approaches to iterative development.  Because of their focus on small, tightly-integrated teams, there are problems in scaling agile methods to large systems.  Less emphasis on documentation - harder to maintain when you get a new team for maintenance 8
Balance plan driven and agile  Not great for Agile:  What type of system is being developed? • Plan-driven approaches may be required for systems that require a lot of analysis before implementation (e.g. real-time system with complex timing requirements).  What is the expected system lifetime? • Long-lifetime systems may require more design documentation to communicate the original intentions of the system developers to the support team.  What technologies are available to support system development? • Agile methods rely on good tools to keep track of an evolving design  How is the development team organized? • Many teams; Outsourcing ---> need design documents to control borders  Culture or contract needs detailed specification  Is rapid feedback from users realistic?  Large scale, not co-located may require more formal communication methods  Need high level programming skills - refactoring, work with little spec  Outside regulation documentation requirements 9
Extreme programming  A popular form of Agile  Extreme Programming (XP) takes an ‘extreme’ approach to iterative development.  New versions may be built several times per day;  Increments are delivered to customers every 2 weeks;  All tests must be run for every build and the build is only accepted if tests run successfully.  Customer involvement means full-time customer engagement with the team. - Specifications through user stories broken into tasks  People not process : pair programming, collective ownership and a process that avoids long working hours.  Regular system releases. - release set of user stories  Maintaining simplicity through constant refactoring of code. 10
The extreme programming release cycle 11
Extreme programming practices (a) 12 Principle or practice Description Incremental planning Requirements are recorded on story cards and the stories to be included in a release are determined by the time available and their relative priority. The developers break these stories into development ‘Tasks’. See Figures 3.5 and 3.6. Small releases The minimal useful set of functionality that provides business value is developed first. Releases of the system are frequent and incrementally add functionality to the first release. Simple design Enough design is carried out to meet the current requirements and no more. Test-first development An automated unit test framework is used to write tests for a new piece of functionality before that functionality itself is implemented. Refactoring All developers are expected to refactor the code continuously as soon as possible code improvements are found. This keeps the code simple and maintainable.
Extreme programming practices (b) 13 Pair programming Developers work in pairs, checking each other’s work and providing the support to always do a good job. Collective ownership The pairs of developers work on all areas of the system, so that no islands of expertise develop and all the developers take responsibility for all of the code. Anyone can change anything. Continuous integration As soon as the work on a task is complete, it is integrated into the whole system. After any such integration, all the unit tests in the system must pass. Sustainable pace Large amounts of overtime are not considered acceptable as the net effect is often to reduce code quality and medium term productivity On-site customer A representative of the end-user of the system (the customer) should be available full time for the use of the XP team. In an extreme programming process, the customer is a member of the development team and is responsible for bringing system requirements to the team for implementation.
XP and agile principles  Incremental development is supported through small, frequent system releases  Customer involvement means full-time customer engagement with the team  People not process through pair programming, collective ownership and a process that avoids long working hours.  Change supported through regular system releases  Maintaining simplicity through constant refactoring of code 14
The Parts and the Whole Controller Inspect Set Target Adapt • Clean Design & Code & Refactor • User Stories - Late Elaboration • Shared Code Ownership • Test Driven Development….. • Iteration Plan • Daily Stand-Up • Pair Programming • Customer Reviews & Feedback • Retrospectives • AutoTest….. Sustainable pace Collective Ownership with users Minimal documentation for sprint 15
The Life of an Iteration 16
A ‘prescribing medication’ story 17
Examples of task cards for prescribing medication 18
Refactoring  Programming team look for possible software improvements and make these improvements even where there is no immediate need for them.  This improves the understandability of the software and so reduces the need for documentation.  Changes are easier to make because the code is well-structured and clear.  However, some changes requires architecture refactoring and this is much more expensive.  RISK:  Changes the user does not test  Changes to working software break it 19
Examples of refactoring  Re-organization of a class hierarchy to remove duplicate code.  Tidying up and renaming attributes and methods to make them easier to understand.  The replacement of inline code with calls to methods that have been included in a program library. 20
Test case description for dose checking 21
Test automation  Automate tests (junit)  Run upon checkin  Difficulties:  Time constraints  Programmer preferences to not test  Test coverage 22
Pair programming  In XP, programmers work in pairs, sitting together to develop code.  Common ownership  Knowledge spread  Informal review  Refactoring  Similar output to two people coding 23
Scrum  Project Manager's job: - Deliver needed system on time within budget  The Scrum approach - manage the iterations  There are three phases in Scrum.  outline planning phase - general picture and architecture  Sprint cycles releasing increments of the system.  The project closure phase - final delivery, documentation and review of lessons learned. 24
Scrum  The Scrum approach is a general agile method but its focus is on managing iterative development rather than specific agile practices  There are three phases in Scrum:  The initial phase is an outline planning phase where you establish the general objectives for the project and design the software architecture  This is followed by a series of sprint cycles, where each cycle develops an increment of the system  The project closure phase wraps up the project, completes required documentation such as system help frames and user manuals and assesses the lessons learned from the project 25
The Scrum process 26
The Sprint cycle  Every 2–4 weeks (a fixed length).  1) Project team with customer: Look at product backlog - select stories to implement  2) implement with all customer communication through scrum master (protecting pgmr at this point)  Scrum master has project manager role during sprint  Daily 15 min meetings Stand up often Team presents progress and impediments Scrum master tasked with removing impediments  3) Review system release with user 27
Scrum benefits  The product is broken down into a set of manageable and understandable chunks.  Unstable requirements do not hold up progress.  The whole team have visibility of everything and consequently team communication is improved.  Customers see on-time delivery of increments and gain feedback on how the product works.  Trust between customers and developers is established and a positive culture is created in which everyone expects the project to succeed. 28
Key points  Agile methods are incremental development methods that focus on rapid development, frequent releases of the software, reducing process overheads and producing high-quality code. They involve the customer directly in the development process.  The decision on whether to use an agile or a plan-driven approach to development should depend on the type of software being developed, the capabilities of the development team, and the culture of the company developing the system.  Extreme programming is a well-known agile method that integrates a range of good programming practices such as frequent releases of the software, continuous software improvement and customer participation in the development team. 29
Key points  A particular strength of extreme programming is the development of automated tests before a program feature is created. All tests must successfully execute when an increment is integrated into a system.  The Scrum method is an agile method that provides a project management framework. It is centred round a set of sprints, which are fixed time periods when a system increment is developed.  Scaling agile methods for large systems is difficult. Large systems need up-front design and a lot of documentation. 30

Agile Software Development in Bachelor of Computer Applications.ppt

  • 1.
  • 2.
    Agile Software Development Agileis a framework that defines how software development needs to be carried on. Agile is not a single method, it represents the various collection of methods and practices that follow the value statements provided in the manifesto. Agile methods and practices do not promise to solve every problem present in the software industry (No Software model ever can). But they sure help to establish a culture and environment where solutions emerge. Principles:  Highest priority is to satisfy the customer through early and continuous delivery of valuable software.  It welcomes changing requirements, even late in development.  Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shortest timescale.  Build projects around motivated individuals. Give them the environment and the support they need, and trust them to get the job done.  Working software is the primary measure of progress.  Simplicity the art of maximizing the amount of work not done is essential.  The most efficient and effective method of conveying information to and within a development team is face-to-face conversation 2
  • 3.
    Pro’s and Con’s Advantages: Deployment of software is quicker and thus helps in increasing the trust of the customer.  Can better adapt to rapidly changing requirements and respond faster.  Helps in getting immediate feedback which can be used to improve the software in the next increment.  People – Not Process. People and interactions are given a higher priority rather than process and tools.  Continuous attention to technical excellence and good design. Disadvantages:  In case of large software projects, it is difficult to assess the effort required at the initial stages of the software development life cycle.  The Agile Development is more code focused and produces less documentation.  Agile development is heavily depended on the inputs of the customer. If the customer has ambiguity in his vision of the final outcome, it is highly likely for the project to get off track.  Face to Face communication is harder in large-scale organizations.  Only senior programmers are capable of taking the kind of decisions required during the development process. Hence it’s a difficult situation for new programmers to adapt to the environment. 3
  • 4.
    Agile Development  InAgile development, Design and Implementation are considered to be the central activities in the software process.  Design and Implementation phase also incorporate other activities such as requirements elicitation and testing into it.  In an agile approach, iteration occurs across activities. Therefore, the requirements and the design are developed together, rather than separately.  The allocation of requirements and the design planning and development as executed in a series of increments. In contrast with the conventional model, where requirements gathering needs to be completed in order to proceed to the design and development phase, it gives Agile development an extra level of flexibility.  An agile process focuses more on code development rather than documentation. 4
  • 5.
  • 6.
    Plan-driven and agilespecification 6 separate development stages with the outputs to be produced at each of these stages planned in advance. Not necessarily waterfall model – plan- driven, incremental development is possible Iteration within stage Iteration of stage User's full agreement at end, not before code
  • 7.
  • 8.
    Problems with agilemethods  It can be difficult to keep the interest of customers / users who are involved in the process.  Team members may be unsuited to the intense involvement that characterizes agile methods.  Prioritizing changes can be difficult where there are multiple stakeholders.  Maintaining simplicity requires extra work.  Contracts may be a problem as with other approaches to iterative development.  Because of their focus on small, tightly-integrated teams, there are problems in scaling agile methods to large systems.  Less emphasis on documentation - harder to maintain when you get a new team for maintenance 8
  • 9.
    Balance plan drivenand agile  Not great for Agile:  What type of system is being developed? • Plan-driven approaches may be required for systems that require a lot of analysis before implementation (e.g. real-time system with complex timing requirements).  What is the expected system lifetime? • Long-lifetime systems may require more design documentation to communicate the original intentions of the system developers to the support team.  What technologies are available to support system development? • Agile methods rely on good tools to keep track of an evolving design  How is the development team organized? • Many teams; Outsourcing ---> need design documents to control borders  Culture or contract needs detailed specification  Is rapid feedback from users realistic?  Large scale, not co-located may require more formal communication methods  Need high level programming skills - refactoring, work with little spec  Outside regulation documentation requirements 9
  • 10.
    Extreme programming  Apopular form of Agile  Extreme Programming (XP) takes an ‘extreme’ approach to iterative development.  New versions may be built several times per day;  Increments are delivered to customers every 2 weeks;  All tests must be run for every build and the build is only accepted if tests run successfully.  Customer involvement means full-time customer engagement with the team. - Specifications through user stories broken into tasks  People not process : pair programming, collective ownership and a process that avoids long working hours.  Regular system releases. - release set of user stories  Maintaining simplicity through constant refactoring of code. 10
  • 11.
    The extreme programmingrelease cycle 11
  • 12.
    Extreme programming practices(a) 12 Principle or practice Description Incremental planning Requirements are recorded on story cards and the stories to be included in a release are determined by the time available and their relative priority. The developers break these stories into development ‘Tasks’. See Figures 3.5 and 3.6. Small releases The minimal useful set of functionality that provides business value is developed first. Releases of the system are frequent and incrementally add functionality to the first release. Simple design Enough design is carried out to meet the current requirements and no more. Test-first development An automated unit test framework is used to write tests for a new piece of functionality before that functionality itself is implemented. Refactoring All developers are expected to refactor the code continuously as soon as possible code improvements are found. This keeps the code simple and maintainable.
  • 13.
    Extreme programming practices(b) 13 Pair programming Developers work in pairs, checking each other’s work and providing the support to always do a good job. Collective ownership The pairs of developers work on all areas of the system, so that no islands of expertise develop and all the developers take responsibility for all of the code. Anyone can change anything. Continuous integration As soon as the work on a task is complete, it is integrated into the whole system. After any such integration, all the unit tests in the system must pass. Sustainable pace Large amounts of overtime are not considered acceptable as the net effect is often to reduce code quality and medium term productivity On-site customer A representative of the end-user of the system (the customer) should be available full time for the use of the XP team. In an extreme programming process, the customer is a member of the development team and is responsible for bringing system requirements to the team for implementation.
  • 14.
    XP and agileprinciples  Incremental development is supported through small, frequent system releases  Customer involvement means full-time customer engagement with the team  People not process through pair programming, collective ownership and a process that avoids long working hours.  Change supported through regular system releases  Maintaining simplicity through constant refactoring of code 14
  • 15.
    The Parts andthe Whole Controller Inspect Set Target Adapt • Clean Design & Code & Refactor • User Stories - Late Elaboration • Shared Code Ownership • Test Driven Development….. • Iteration Plan • Daily Stand-Up • Pair Programming • Customer Reviews & Feedback • Retrospectives • AutoTest….. Sustainable pace Collective Ownership with users Minimal documentation for sprint 15
  • 16.
    The Life ofan Iteration 16
  • 17.
  • 18.
    Examples of taskcards for prescribing medication 18
  • 19.
    Refactoring  Programming teamlook for possible software improvements and make these improvements even where there is no immediate need for them.  This improves the understandability of the software and so reduces the need for documentation.  Changes are easier to make because the code is well-structured and clear.  However, some changes requires architecture refactoring and this is much more expensive.  RISK:  Changes the user does not test  Changes to working software break it 19
  • 20.
    Examples of refactoring Re-organization of a class hierarchy to remove duplicate code.  Tidying up and renaming attributes and methods to make them easier to understand.  The replacement of inline code with calls to methods that have been included in a program library. 20
  • 21.
    Test case descriptionfor dose checking 21
  • 22.
    Test automation  Automatetests (junit)  Run upon checkin  Difficulties:  Time constraints  Programmer preferences to not test  Test coverage 22
  • 23.
    Pair programming  InXP, programmers work in pairs, sitting together to develop code.  Common ownership  Knowledge spread  Informal review  Refactoring  Similar output to two people coding 23
  • 24.
    Scrum  Project Manager'sjob: - Deliver needed system on time within budget  The Scrum approach - manage the iterations  There are three phases in Scrum.  outline planning phase - general picture and architecture  Sprint cycles releasing increments of the system.  The project closure phase - final delivery, documentation and review of lessons learned. 24
  • 25.
    Scrum  The Scrumapproach is a general agile method but its focus is on managing iterative development rather than specific agile practices  There are three phases in Scrum:  The initial phase is an outline planning phase where you establish the general objectives for the project and design the software architecture  This is followed by a series of sprint cycles, where each cycle develops an increment of the system  The project closure phase wraps up the project, completes required documentation such as system help frames and user manuals and assesses the lessons learned from the project 25
  • 26.
  • 27.
    The Sprint cycle Every 2–4 weeks (a fixed length).  1) Project team with customer: Look at product backlog - select stories to implement  2) implement with all customer communication through scrum master (protecting pgmr at this point)  Scrum master has project manager role during sprint  Daily 15 min meetings Stand up often Team presents progress and impediments Scrum master tasked with removing impediments  3) Review system release with user 27
  • 28.
    Scrum benefits  Theproduct is broken down into a set of manageable and understandable chunks.  Unstable requirements do not hold up progress.  The whole team have visibility of everything and consequently team communication is improved.  Customers see on-time delivery of increments and gain feedback on how the product works.  Trust between customers and developers is established and a positive culture is created in which everyone expects the project to succeed. 28
  • 29.
    Key points  Agilemethods are incremental development methods that focus on rapid development, frequent releases of the software, reducing process overheads and producing high-quality code. They involve the customer directly in the development process.  The decision on whether to use an agile or a plan-driven approach to development should depend on the type of software being developed, the capabilities of the development team, and the culture of the company developing the system.  Extreme programming is a well-known agile method that integrates a range of good programming practices such as frequent releases of the software, continuous software improvement and customer participation in the development team. 29
  • 30.
    Key points  Aparticular strength of extreme programming is the development of automated tests before a program feature is created. All tests must successfully execute when an increment is integrated into a system.  The Scrum method is an agile method that provides a project management framework. It is centred round a set of sprints, which are fixed time periods when a system increment is developed.  Scaling agile methods for large systems is difficult. Large systems need up-front design and a lot of documentation. 30