Introduction to software engineering course Lecture 3 - Agile Development, Slides of Introduction to Software Engineering

Download Introduction to software engineering course Lecture 3 - Agile Development and more Slides Introduction to Software Engineering in PDF only on Docsity!

Lecture 03

Agile Development

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009).

Agile software development

Agile software development is a group of software development

methodologies based on iterative and incremental development,

where requirements and solutions evolve through collaboration

between self-organizing, cross-functional teams.

The Agile Manifesto (cont…)

• We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: 1. Individuals and 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
• That is, while there is value in the items on the right, we value the items on the left more.

1. Individuals and interactions

over

processes and tools

• Tools and processes are important, but it is more important to have competent people working together effectively.
• In agile development, self-organization and motivation are important, as are interactions like co-location and pair programming.
• A good team with no process (or worse) is better than a bad team with a good process.

3. Customer collaboration

over

Contract negotiation

• Requirements cannot be fully collected at the beginning of the software development cycle, therefore continuous customer or stakeholder involvement is very important.
• The primary purpose of collaboration is to work with the customer to make sure that they are involved in delivering the final product they need.

4. Responding to change

over

Following a plan

• A project plan is important, but it must not be too rigid to accommodate changes in technology or the environment, stakeholders' priorities, and people's understanding of the problem and its solution.
• Agile development is focused on quick responses to change and continuous development.
• Welcome changing requirements, even late in development.
• If you froze requirements one year ago and deliver tomorrow, your software is delivering on the business needs of one year ago.

Agility Principles - I

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face–to–face conversation.

Agility Principles - II

7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximizing the amount of work not done – is essential.
11. The best architectures, requirements, and designs emerge from self–organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

XP (Cont…)

• Beck's fundamental idea is to start simply, build something real that works in its limited way, and then fit it into a design structure that is built as a convenience for further code building rather than as an ultimate and exhaustive structure after thorough and time-consuming analysis.
• Because there is much face-to-face communication, the need for documentation is minimized.

XP Process

2. Design

• XP design strictly follows the KIS (keep it simple) principle.
• XP encourages the use of CRC cards (Chapter 7) as an effective mechanism for thinking about the software in an object-oriented context. CRC (class-responsibility collaborator) cards identify and organize the object-oriented classes that are relevant to the current software increment.
• XP Encourages “refactoring”—an iterative refinement of the internal program design. Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves the internal structure. It is a disciplined way to clean up code [and modify/simplify the internal design] that minimizes the chances of introducing bugs. In essence, when you refactor you are improving the design of the code after it has been written.

3. Coding

• After stories are developed and preliminary design work is done, the team does not move to code, but rather develops a series of unit tests that will exercise each of the stories that is to be included in the current release.
• XP Encourages “pair programming”.

In pair programming, two people work together at one computer workstation to create code for a story. In practice, each person takes on a slightly different role. For example, one person might think about the coding details of a particular portion of the design while the other ensures that coding standards (a required part of XP) are being followed or that the code for the story will satisfy the unit test that has been developed to validate the code against the story

Scrum

• An agile methodology
• Originally proposed by Schwaber and Beedle
• In recent years, further development on the Scrum methods has been performed by Schwaber and Beedle.
• Development work is partitioned into “packets”
• Testing and documentation are on-going as the product is constructed
• Work occurs in “sprints” and is derived from a “backlog” of existing requirements

Backlog

• A prioritized list of project requirements or features that provide business value for the customer.
• Items can be added to the backlog at any time (this is how changes are introduced).
• The product manager assesses the backlog and updates priorities as required.