Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Extreme programming in agile methodology, Study Guides, Projects, Research of Computer Science

Agile methodology extreme programming

Typology: Study Guides, Projects, Research

2016/2017

Uploaded on 10/08/2017

rosarioantony
rosarioantony 🇮🇳

1 document

1 / 64

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Agile Methods
(Extreme Programming)
A Framework For Pulling It All
Together
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c
pf1d
pf1e
pf1f
pf20
pf21
pf22
pf23
pf24
pf25
pf26
pf27
pf28
pf29
pf2a
pf2b
pf2c
pf2d
pf2e
pf2f
pf30
pf31
pf32
pf33
pf34
pf35
pf36
pf37
pf38
pf39
pf3a
pf3b
pf3c
pf3d
pf3e
pf3f
pf40

Partial preview of the text

Download Extreme programming in agile methodology and more Study Guides, Projects, Research Computer Science in PDF only on Docsity!

Agile Methods

(Extreme Programming)

A Framework For Pulling It All

Together

Extreme Programming

  • (^) A deliberate and disciplined approach to software development
  • (^) Suited to risky projects with dynamic requirements - (^) Including late life cycle changes
  • (^) Emphasizes customer satisfaction
  • (^) Unproductive activities have been trimmed from the process - (^) Reduces cost - (^) Reduces frustration

Software project improvements

  • (^) Communication
    • (^) Between developers
    • (^) Between managers and developers
    • (^) Between customer and developers
  • (^) Simplicity
    • (^) Designs are keep simple
    • (^) Designs are keep “clean” (uncluttered with extraneous features)

Software project improvements

(cont.)

  • (^) Feedback
    • (^) Testing begins on day 1 thus encouraging feedback
    • (^) Customer feedback/requests are implemented immediately
  • (^) Courage
    • (^) Programmers respond to changing requirements
    • (^) Programmers respond to changing technology
    • (^) No fear of repercussion such as cost/time

Something New? (cont.)

  • (^) Testing is a crucial part of development
    • (^) Tests are created before, during, and after code is written
    • (^) Tests are well matched to the code they are testing
    • (^) Identification of bugs leads to new tests to ensure that the same bugs do not reoccur

Something New? (cont.)

  • (^) Change is embraced
    • (^) Customer feedback is encouraged throughout development
    • (^) Allows customers to take full advantage of unseen/unanticipated opportunities in the marketplace

When? (cont.)

  • (^) Extended development team
    • (^) Developers
    • (^) Managers
    • (^) Customers
    • (^) All must “buy in” to the process

Another Methodology?

  • (^) Software methodology
    • (^) The set of rules and practices used to create computer programs
  • (^) Heavyweight methodology
    • (^) Many rules, practices, and documents
    • (^) Requires discipline and time to follow correctly
  • (^) Lightweight methodology
    • (^) Few rules, practices, and documents
    • (^) Easy to follow

Another Methodology? (cont.)

  • (^) For the lightweight methodologies we pick and choose the rules to follow - (^) Learn from the past - (^) Keep rules that directly lead to the creation of quality software - (^) Omit the rules that hinder progress - (^) Simplify the rules that are too complex - (^) Make programmers feel free to be creative and productive while remaining organized and focused

What is Extreme Programming?

  • (^) A collection of rules and practices each

of which supports the development and

delivery of quality software

  • (^) The rules and practices support each

other (are used together)

  • (^) It’s an iterative process

User Stories

  • (^) Similar in purpose to use cases
  • (^) Create time estimates for release

planning (to be defined later)

  • (^) Replace large requirements documents
  • (^) Written by customers as things the

system must do for them (like scenarios)

  • (^) Helps to avoid technical jargon

User Stories (cont.)

  • (^) Drive the creation of acceptance tests
    • (^) Derive tests to verify the implementation of the story as the story is being written
  • (^) Provide only enough detail to make an

implementation time estimate

  • (^) Detailed descriptions will be solicited during implementation (i.e. questions for the domain expert or customer)

User Stories (cont.)

  • (^) Focus is on user needs
    • (^) As opposed to technical details that may be present in a “classical” requirements specification
    • (^) As opposed to GUI designs that may be present in a “classical” requirements specification

Release Plan/Planning

  • (^) Layout the overall project
  • (^) Layout individual iterations through the

project

  • (^) Release planning follows a set of rules
    • (^) Development team estimates user story times
    • (^) Customer determines user story priorities
    • (^) Management make resource decisions