Week 2 - Agile Software Development PDF

SOFTWARE ENGINEERING AGILE SOFTWARE DEVELOPMENT Businesses now operate in a global, rapidly changing environment. They have to respond to new opportunities and markets, changing economic conditions, and the emergence of competing products and services. Software is an important part of alm...

SOFTWARE ENGINEERING AGILE SOFTWARE DEVELOPMENT Businesses now operate in a global, rapidly changing environment. They have to respond to new opportunities and markets, changing economic conditions, and the emergence of competing products and services. Software is an important part of almost all business operations, so new software has to be developed to take advantage of new opportunities and respond to competitive pressure. Because these businesses operate in a changing environment, it is practically impossible to derive a complete set of stable software requirements. Requirements change because customers find it impossible to predict how a system will affect working practices, how it will interact with other systems, and what user operations should be automated. 1|Page It may be after a system has been delivered and users interacted with it that the real requirements become clear. Even then, external factors drive requirements change. Plan- driven software development processes completely specify the requirements then design, build, and test a system where requirements are not dynamic. As the requirements change the system design or implementation has to be reworked and retested. Plan-based development models may not work well in a dynamic business environment. By the time the software is available for use, the original reason for its development may have changed so radically that the software may not serve its purpose Therefore, for business systems, in particular, development processes focus on rapid software development since they can handle changing requirements. These agile methods are designed to produce useful software quickly. 2|Page Common Characteristics of Agile Methods 1. The processes of specification, design, and implementation are interleaved. 2. The system is developed in a series of increments. End- users and other system stakeholders are involved in specifying and evaluating each increment. 3. Extensive tool support is used to support the development process. Tools that may be used include automated testing tools, tools to support configuration management, and 3|Page system integration and tools to automate user interface development. Origin of the Agile Methodologies In the 1980s and early 1990s, there was a widespread view that the best way to achieve better software was through careful project planning, formalized quality assurance, the use of analysis and design methods supported by software tools, and controlled and rigorous software development processes. This view came from the software engineering community responsible for developing large, long-lived software systems such as government systems. These Plan-driven approaches involve a significant overhead in planning, designing, and documenting the system. This overhead is justified when the work of multiple development teams has to be coordinated when the the system is critical, and when many different people will be involved in maintaining the software over its lifetime. 4|Page However, the overhead is large when this plan-driven development approach is applied to small and medium-sized business systems. More time is spent on how the system should be developed than on program development and testing. As the system requirements change, rework is essential, and, the specification and design have to change with the program. The dissatisfaction with these plan-based approaches led to the development of agile methods in the late 1990s. These methods allowed changing requirements to deliver working software quickly to customers. The Principles of Agile Methods 5|Page Areas of development where Agile methods have been successful 1. Product development where a software company is developing a small or medium-sized product. Virtually all software products and apps are now developed using an agile approach. 2. Custom system development within an organization, where there is a clear commitment from the customer to become involved in the development process. AGILE DEVELOPMENT TECHNIQUES Extreme Programming (XP) This is perhaps the most significant approach to changing software development. The name was coined by Kent Beck (1998) because the strategy was developed by pushing recognized good practices, such as iterative development, to “extreme” levels. 6|Page For example, in XP, several new system versions may be developed by different programmers, integrated, and tested in a day. The XP test software release cycle In XP, requirements are expressed as scenarios (called user stories). Programmers work in pairs and develop tests for each task before writing the code. All tests must be successfully executed when new code is integrated into the system. There is a short time gap between releases of the system. 7|Page Principles of The Agile Manifesto Agile project management Like every other professional software development process, agile development has to be managed to make good use of the time and resources available to the team. 8|Page To address this issue, the Scrum agile method was developed to provide a framework for organizing agile projects and, to provide external visibility of what is going on. In any software business, managers need to know what is going on and whether or not a project is likely to meet its objectives and deliver the software on time with the 9|Page proposed budget. Plan-driven approaches to software development evolved to meet this need. Scrum is an agile method as it follows the principles from the Agile Manifesto as discussed earlier. However, it does not mandate the use of specific development practices. The Scrum software sprint cycle Each process iteration produces a product increment that could be delivered to customers. The starting point for the Scrum sprint cycle is the product backlog the list of items such as product features, 10 | P a g e requirements, and improvements that have to be worked on by the Scrum team. The initial version of the product backlog may be derived from a requirements document, a list of user stories, or other descriptions of the software to be developed. While most entries in the product backlog are concerned with implementing system features, other activities may also be included such as clarification which needs to be done. The team may carry out some prototyping or trial development to understand the problem and come up with a solution. There may also be backlog items to design the system architecture or to develop system documentation. The Product Owner ensures a detailed description of the pending tasks is done. For example, a backlog item could be a complete user story or it could simply be an instruction such as “Refactor user 11 | P a g e interface code” that leaves it up to the team to decide on the refactoring to be done. Each sprint cycle lasts a fixed length of time, which is usually between 2 and 4 weeks. In each cycle, the Product Owner prioritizes the items on the product backlog to define the most important tasks to be done. Sprints are never extended to take account of unfinished work. Items are returned to the product backlog if these cannot be completed within the allocated time for the sprint. The whole team then selects which of the highest priority items they believe can be completed. They then estimate the time required to complete these items in the next sprints (sprint backlog). The team self-organizes to decide who will work on what, and the sprint begins. During the sprint, the team holds short daily meetings (Scrums) to review progress and, where necessary, to re-prioritize work. Thus, everyone on the team knows what is going on and, if problems arise, can re-plan short-term work to cope with 12 | P a g e them. Everyone participates in this short-term planning; there is no top-down direction from the ScrumMaster. The daily interactions among Scrum teams may be coordinated using a Scrum board. This is an office whiteboard that includes information and post notes about the Sprint backlog, work done, unavailability of staff, and so on. Since this is a shared resource the team members can, at a glance, see what others are doing and what work remains to be done. At the end of each sprint, there is a review meeting involving the whole team. To review their work and reflect on how things could have been done better. Second, it provides input on the product and the product state for the product backlog review that precedes the next sprint. 13 | P a g e The ScrumMaster reports on progress to senior management and is involved in longer-term planning and project budgeting. Example of User Stories A user story is a scenario of use that a system user might experience as shown in the example below. 14 | P a g e The system customer works closely with the development team and discusses these scenarios with other team members to develop a “story card”. A Story card briefly describes a story summarising the customer's needs. Using the story cards the development team breaks the requirements down into tasks and estimates the effort and resources required for implementation. 15 | P a g e This process usually involves discussions with customers to refine requirements and prioritize the stories for implementation in the next sprint when the next release of the system is made available to the customer. As requirements change, the backlog stories change or may be discarded. If changes are required for a system that has already been delivered, new story cards are developed, and the cycle continues. Advantages of User Stories − Users relate to these stories much easier than to a conventional requirements document or use cases − They help in getting users involved in suggesting requirements during an initial requirements elicitation activity − The customer decides whether certain changes should have priority over new functionality 16 | P a g e Disadvantages of User Stories − It is difficult to judge if enough user stories have been developed to cover all of the essential requirements − It is also difficult to judge if a single story gives a true picture of an activity. − Experienced users are often so familiar with their work that they leave out some details in their descriptions. During development one of the important differences between incremental development and plan-driven development is in the way that the system is tested. Extreme Programming developed a new approach where testing is automated and central to the development process, and development cannot proceed until all tests have been successfully executed. The key features of testing in XP are: - - test-first development, - incremental test development from scenarios, - user involvement in the test development and validation - use of automated testing frameworks. 17 | P a g e Test-driven development Test-driven development is one of the most important innovations in software engineering. Instead of writing code and then writing tests for that code, you write the tests before you write the code as shown below: - Why use a Test-Driven Approach - Writing tests implicitly define both the interface and specify the functionality being developed. - Problems of misunderstanding requirements are reduced. - Test-first development requires a clear relationship between system requirements and the code implementing the corresponding requirements. This is clear in XP 18 | P a g e  because the story cards representing the requirements are broken down into tasks and the tasks are the principal units of implementation. - The task implementers have to thoroughly understand the specifications to write tests for the system. - ambiguities and omissions in the specification have to be clarified before implementation begins. - It avoids the problem of “test lag” (when the developer of the system works at a faster pace than the tester). This can lead to skipping tests to meet the deadlines. - In the user stories each task generates one or more unit tests that check the implementation described in each task - Customer involvement in the testing process helps in developing acceptance tests for the stories. Advantages of Using Scrum 1. The product is broken down into a set of manageable and understandable chunks that stakeholders can relate to. 2. Unstable requirements do not hold up progress. 3. The whole team has visibility of everything, and consequently, team communication and morale are improved. 19 | P a g e 4. Customers see on-time delivery of increments and gain feedback on how the product works. They are not faced with last-minute surprises when a team announces that software will not be delivered as expected. 5. Trust between customers and developers is established, and a positive culture is created in which everyone expects the project to succeed. 20 | P a g e