Review

1
Review

• Software life cycle
• Software process
• Various software process models
• Have advantages and disadvantages
• A unified model
• Iterations
• Many ways of tailoring it for specific project

2
A Process Management Challenge

• Process complexity
• Many interacting processes
• Different processes may follow different process
  models
• The challenge
• To ensure the effectiveness and the efficiency of
  the processes involved in software projects
• To increase the predictability of the outcome for
  each process

3
Answer 1

• Keep it simple (KIS)
• Rapid feedback

4
Agile Software Processes

• Slides adapted from a tutorial presented by Pekka
  Abrahamsson from VTT Eletronics

5
Key Questions

• What is agility?
• Where is agility needed?
• What are agile software development methods?

6
What is agility

• Agile (Websters 1913)
• Having the faculty of quick motion in the limbs
• Apt or ready to move
• Agility for a software development organization
• The ability to adapt and react expeditiously and
  appropriately to changes in its environment and
  demands imposed by the environment
• The ability to both create and respond to change
  in order to profit in a turbulence business
  environment
• Agility at organization, project, and individual
  levels

7
Where agility is needed?

• Complex problems characterized by
• Change
• Turbulence
• Situations where accelerated development is
  required
• To meet tight delivery schedule
• To reduce the significant risk and uncertainty
• Changes imposed by rapidly evolving technology,
  business, and product needs

8
Agile Thinking Explained
The fundamental reason For a new paradigm
Need to respond To constant changes
9
Need to respond to constant change

• Software development can be affected by many
  changes
• Changes in development environment and technology
• Organizational changes
• Personnel changes
• Product requirement changes
• Software development should embrace change rather
  than avoid it

10
Manifesto for Agile Software Development

• We are uncovering better ways of developing
  software by doing it and helping others do it.
  Through this work we have come to value
• Individuals and interactions over processes and
  tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• 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.
  Source www.agilemanifesto.org

11
The 12 Principles

• Flexible and simple planning
• 1. Satisfy customers need through early and
  frequent delivery
• 2. Keep delivery short (e.g., every couple of
  weeks)
• 3. Working software is the primary measure of
  progress
• 4. Welcome changing requirements even late in the
  project

12
The 12 Principles (contd)

• Building and maintaining a good team
• 5. Business people and developers work together
  daily throughout the project
• 6. Build projects around motivated individuals
• 7. Place emphasis on face-to-face communication
• 8. The best results emerge from self-organizing
  teams

13
12 Principles (contd)

• Simple and good design
• 9. Continuous attention to technical excellence
  and good design
• 10. Promote sustainable development pace
• 11. Simplicity is essential
• 12. Team reflects regularly where and how to
  improve

14
Agile Philosophy

• The importance of self-organizing teams
• Communication and collaboration between team
  members
• Recognition that changes represent opportunities
• An emphasis on rapid delivery that satisfies the
  customer

15
How agility can change your organization

• Interaction and communication
• Much more interaction between developers,
  management, and customers
• Level of informal communication increases
• Visibility
• Related stakeholders know the exact status of the
  project
• Much shorter development cycle
• The pace of development can become very high
• Less effort spent up front

16
Agile Software Development Methods (Processes)

• Share the following characteristics
• Incremental
• Small releases, rapid cycles
• Cooperative
• Customers and developers working constantly
  together with close communication
• Straightforward
• The method is light, simple, well documented,
  easy to modify
• Adaptive
• The method is able to take into account last
  moment changes

17
Extreme Programming (XP)
18
Introduction

• Developed by Kent Beck in 1999
• Address the basic risks in software development
• Method is formed around common sense principles
  and simple to understand practices
• No process fits every project, rather, simple
  practices should be tailored to suit an
  individual project

19
(No Transcript)
20
Some XP Key Words

• Client as a team member
• User stories
• Short description of a desired functionality
• Fit on a 3x5 note card
• Stories can evolve
• The planning game
• Pair Programming
• Test-first software development
• Refactoring and continuous design improvement

21
(No Transcript)
22
XP Management Practices

• Small/short releases
• Planning game
• Release planning
• Iteration planning
• 40 hour weeks?

23
XP Implementation

• Coding standards
• Pair programming
• Metaphor
• Simple designs
• Refactoring
• Test-driven

24
Coding Standards

• Recommendations for the programmer with regards
  to
• how to lay out the code, e.g. tabbing, braces,
  comments
• where source code files should be located in the
  file system
• which settings should be used for the compiler
  and linker
• which naming conventions should be followed for
  files, classes, methods, attributes, parameters,
  and local variables.

25
Pair Programming

• TWO programmers working side-by-side,
  collaborating on the same design, algorithm, code
  or test. One programmer, the driver, has control
  of the keyboard/mouse and actively implements the
  program. The other programmer, the observer,
  continuously observes the work of the driver to
  identify tactical (syntactic, spelling, etc.)
  defects and also thinks strategically about the
  direction of the work. On demand, the two
  programmers can brainstorm any challenging
  problem. Because the two programmers periodically
  switch roles, they work together as equals to
  develop software.

26
Metaphor

• Explaining the project in terms understandable to
  the audience
• Different Metaphors for different audiences
• Patterns when explaining to other developers
• Plain English for the ccient companys CEO

27
Refactoring

• Early coding is kept simple to facilitate rapid
  early progress
• Subsequent iterations bring in complexity,
  including application of patterns

28
Other Practices

• XP SCM
• Collective code ownership
• Continuous integration
• XP VV
• Continuous testing
• On-Site customer test

29
How XP solve some SE problems
Problem Solution
Slipped schedule Short development cycles
Cancelled project Intensive customer presence
Cost of changes Extensive, ongoing testing, system always running
Defect rates Unit tests, customer tests
Misunderstand the business Customer part of the team
Business changes Changes are welcome
Staff turnover Intensive teamwork
30
Known Limitations

• Limitation
• XP is aimed at small to medium-sized teams
• Requires the development team to be located in
  one place
• Cannot solve the problems in projects that are
  not XP-able.

31
Scrum
32
Introduction

• Developed by Schwaber in 1995
• Based on experiences from adaptive,
  self-organizing product development in Japan
• Focuses on managing systems development in a
  changing environment
• Strictly management only
• The choice of the software development methods
  are up to the project

33
(No Transcript)
34
Key Concepts

• Backlog
• A dynamic set of product features
• Sprints
• A set of backlog items that can be done in a
  predefined timebox (30 days)
• Scrum daily meetings
• 15 minute status report
• What did you do since the last meeting?
• What obstacles are you encountering?
• What do you plan to accomplish by the next team
  meeting?

35
(No Transcript)
36
Key Concepts

• Effort estimation
• Product backlog
• Sprint
• Sprint planning meeting
• Sprint backlog
• Daily scrum meeting (15 minutes)
• Sprint review meeting (4 hours)

37
Sprint

• a short burst of work lasting approximately 30
  days during which an executable and other
  deliverables are built by an engineering team, as
  indicated by the assigned backlog.
• A sprint is undertaken by a cross functional team
  consisting of no more than 9 members.
• Every sprint has a specific goal, expressed as
  the backlog.
• the list of tasks that the Scrum team is
  committing that they will complete in the current
  sprint
• An executable demonstrating the goal will be
  completed by the team during the sprint.
• The sprint team has final say in estimating and
  determining what they can accomplish during the
  sprint.
• Once the sprint is underway, new backlog cannot
  be added to the sprint except that, if the scrum
  master determines that a new backlog item will
  enhance the viability of the product, is in
  alignment with the sprint, builds on the sprints
  executable, and can be completed within the
  sprints time frame, the backlog item can be
  added. Examples are building a demonstration of
  the executable for a specific purpose, such as a
  trade show or prospect.
• If external forces determine that the sprint is
  working on the wrong thing, a sprint can be
  halted and restarted with new backlog and purpose.

38
Mix-and-Match

• The practices in different agile methods can be
  extracted and combined
• Examples
• Pair programming and its variation
• Daily scrum meeting
• Test-driven development approach
• The key
• Understand the problems the practice is
  addressing
• Understand the essence of the practice

39
Agile method in one slide

• Is suitable for a volatile development
  environment
• Product requirements and business environment
  change often
• Tight schedule are required
• Places emphasis on individuals, interactions, and
  delivering working software
• Is both light and sufficient
• Are incremental, cooperative, straightforward,
  and adaptive in nature