practical usage of agile agile case studies n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Practical Usage of Agile & Agile Case Studies PowerPoint Presentation
Download Presentation
Practical Usage of Agile & Agile Case Studies

Loading in 2 Seconds...

play fullscreen
1 / 54

Practical Usage of Agile & Agile Case Studies - PowerPoint PPT Presentation


  • 229 Views
  • Uploaded on

Practical Usage of Agile & Agile Case Studies. (Follow-up for the Workshop: "Success in Software Engineering Projects"). Webinar Presentation Dr. Youry Khmelevsky TrainingBC. Outline. Motivation Agile Extreme (XP) and Pair Programming TDD and BDD Development Scrum

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Practical Usage of Agile & Agile Case Studies' - jun


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
practical usage of agile agile case studies

Practical Usage of Agile

& Agile Case Studies

(Follow-up for the Workshop:

"Success in Software Engineering Projects")

Webinar Presentation

Dr. Youry Khmelevsky

TrainingBC

outline
Outline
  • Motivation
  • Agile
  • Extreme (XP) and Pair Programming
  • TDD and BDD Development
  • Scrum
  • Examples of Agile in industry and research information
  • Case study in eXtremeProgramming
  • Summary
some horror stories
Some Horror Stories 
  • Why Projects Fail (http://is.gd/3TVZTN): IBM, Survey of 1,500 executives. Date: Oct 2008. IBM survey in the success / failure rates
    • Only 40% of projects met schedule, budget, and quality goals.
    • Best organizations are 10 times more successful than worst organizations
  • Bob Lawhorn presentation  on software failure March 2010: 66% project failure rate (source)
  • Portland Business Journal: 65 and 80% of IT projects fail to meet their objectives …
agile agile manifesto
Agile: Agile Manifesto
  • On February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski, relax, and try to find common ground and of course, to eat. Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened.
agile v alues
Agile Values:
  • Individuals and interaction over processes and tools
  • Functional software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
12 principles of agile
12 Principles of Agile
  • Our highest priority is to satisfy the customerthrough early and continuous deliveryof valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
12 principles of agile cont
12 Principles of Agile(cont.)
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
12 principles of agile cont1
12 Principles of Agile(cont.)
  • Agile processes promote sustainable development - maintain a constant pace indefinitely
  • Continuousattention to technical excellence and good design enhances agility.
  • Simplicity-the art of maximizing the amount of work not done-is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
extreme programming xp
eXtreme Programming (XP)
  • Extreme Programming is one of several popular Agile Processes.
  • Extreme Programming was created by Kent Beck
  • The first Extreme Programming project was started March 6, 1996 (in October 1999, Extreme Programming Explained was published).
  • XP created quite a buzz in the late 1990s and early 2000s, seeing adoption in a number of environments radically different from its origins.
the 13 rules of xp
The 13 Rules of XP
  • Whole Team (the client is part of the team)
  • Metaphor (a common analogy)
  • The Planning Game (incrementally)
  • Simple Design
  • Small Releases (about 2 weeks)
  • Customer Test (develops acceptance test)
  • Pair Programming
  • Test Driven Development
the rules of xp cont
The Rules of XP(cont.)
  • Design Improvement (refactoring, incrementally improving).
  • Collective Code Ownership (anyone can modify any code without asking anyone for permission).
  • Continuous Integration (at all times the system compiles, runs and passes all the tests).
  • Sustainable Pace (no such thing as “a big final push”)
  • Coding Standards (developed code should look like it was written by a single, consistent person)
effects of xp
Effects of XP
  • XP provides redundancy for knowledge of all code
  • XP forces the organization to be very clear about requirements from the development team
  • XP allows “better on-boarding of new developers due to the mentoring and training inherent in pair programming.”
2 week agile xp iteration
2-week Agile/XP Iteration
  • Talk to customer
  • Lo-fi mockup
  • User stories & scenarios
  • Behavior-driven Design/ user stories
  • Test-first dev. (unit/functions)
  • Measure Velocity
  • Deploy
  • Go to -> 1.

Tools for 4-7: Cucumber, RSpec, Pivotal Tracker, Heroku

pair programming
Pair Programming
  • Pair programming is an agile software development technique in which two programmers work together at one workstation.
  • One, the driver, writes code while the other, the observer or navigator (co-pilot), reviews each line of code as it is typed in.
  • The two programmers switch roles frequently.
pair programming cont
Pair Programming (cont.)
  • Programmers working in pairs usually produce shorter programs, with better designs and fewer bugs, than programmers working alone.
  • Studies have found reduction in defect rates of 15% to 50%, varying depending on programmer experience and task complexity
  • Remote pair programming, also known as virtual pair programming or distributed pair programming, is pair programming where the two programmers are in different locations.
test driven devel tdd
Test Driven Devel. (TDD)
  • Each new feature begins with writing a test.
    • If the test doesn’t fail - code exists or the test is defective.
  • The developer must clearly understand the feature's specification and requirements.
    • Tests and code are written in parallel for each work item as it is started through use cases and user stories.
  • The next steps:
    • 1. Run all tests and see if the new one fails;
    • 2. Write some code;
    • 3. Run the automated tests and see them succeed;
    • 4. Refactor code;
    • 5. Repeat
test example
Test Example

[Test] public void NumberToEnglishShouldReturnOne() { string actual = English.NumberToEnglish(1);

Assert.AreEqual("one", actual, "Expected the result to be \"one\""); }

  • The next thing to do is to ensure that the code satisfies the demands of the unit test. Agile methodologies, such as XP, say that only the simplest change should be made to satisfy the current requirements. In that case the method being tested will be changed to look like this:

[Code] public static string NumberToEnglish(int number) { return "one"; }

behaviour driven development
Behaviour Driven Development
  • Behavior-driven development (abbreviated BDD) is a software development process based on test-driven development (TDD)
    • Features are based on user stories
    • Outline of how user and system interact
    • Becomes a baseline for acceptance testing
    • Promotes customer / end user involvement
    • Each feature has one or more scenarios where the interaction is explained in steps
    • Each step can be represented by a method
user stories
User Stories
  • A user story is one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function.
  • Three components used to describe the story
    • As a _____: role played by the user
    • So that _____: goal to be achieved
    • I want to _____: task to be performed
  • These stories are used to develop scenarios where the feature is used
posts tagged user stories
Posts Tagged ‘user stories’

Having the story point estimate history from all previous stories makes it MUCH easier to create estimates for the current or new user stories.

agile usage scenarios
Agile Usage Scenarios
  • A usage scenario, or scenario for short, describes a real-world example of how one or more people or organizations interact with a system. 
  • They describe the steps, events, and/or actions which occur during the interaction. 
  • Usage scenarios can be very detailed, indicating exactly how someone works with the user interface, or reasonably high-level describing the critical business actions but not indicating how they’re performed. 
scenario step keywords
Scenario Step Keywords
  • Given:an initial state or prerequisite
  • When: an action taken or event triggered
  • Then: action taken in response to event
  • And/But: continuation or additional clauses
    • Each step can be categorized as above and tests can be written for each type to ensure they perform as expected
scenario example 1
Scenario Example 1
  • Scenario 1: Account has sufficient funds
    • Giventhe account balance is \$100
    • Andthe card is valid
    • Andthe machine contains enough money
    • Whenthe Account Holder requests \$20
    • Thenthe ATM should dispense \$20
    • Andthe account balance should be \$80
    • Andthe card should be returned
agile scenario example 2
Agile Scenario Example 2

In BDD, a developer or QA engineer might clarify the requirements by breaking this down into specific examples. The language of the examples below is called Gherkin and is used behave as well as many other tools.

use cases
Use Cases
  • A use case is a list of steps, typically defining interactions between a role (known in UML as an "actor") and a system, to achieve a goal. The actor can be a human or an external system.
  • ”A common style to use" as follows:
    • Title: "goal the use case is trying to satisfy”
    • Main Success Scenario: numbered list of steps
      • Step: "a simple statement of the interaction between the actor and a system”
    • Extensions: separately numbered lists, one per Extension
      • Extension: "a condition that results in different interactions from .. the main success scenario". An extension from main step 3 is numbered 3a, etc.
use case diagram example
Use Case Diagram Example

IBM Rational

Software Modeler

scrum sw development
Scrum (SW Development)
  • An iterative and incremental agile software development framework for managing software projects and product or application development.
  • Its focus is on "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal" as opposed to a "traditional, sequential approach".
forming the scrum
Forming the Scrum
  • Scrum groups have special roles
  • Roles occur from self-forming within the group
  • Certain roles should be assigned to senior personnel
  • Some roles should be moved from one person to another regularly
scrum management
Scrum Management
  • Daily Scrum meetings - 15 minutes:
    • What have you done since yesterday?
    • What are you planning to do today?
    • Any impediments/stumbling blocks?
  • Backlog grooming – 1 hour:
    • Meetings should not be longer than an hour.
    • Meeting does not include breaking stories into tasks.
    • The team can decide how many meetings are needed per week.
    • Though everything can be done in a single meeting
scrum management cont
Scrum Management (Cont.)
  • Scrum of Scrums (after the Daily Scrum):
    • Allow teams to discuss their work, focusing especially on areas of overlap and integration.
    • A designated person from each team attends.
  • Sprint planning meeting (every 7–30 days):
    • Select what work is to be done; Prepare the Sprint Backlog; How much of the work is likely to be done during the current sprint (8htime limit)
  • End of Cycle: "Sprint Review Meeting” – Demo (< 4 hours) "Sprint Retrospective” (< 3 hours)
roles within the scrum
Roles Within the Scrum
  • Product Owner
  • Development Team
  • Scrum Master
  • Stakeholders
  • Managers
scrum in distr developm
Scrum in Distr. Developm.
  • Scrums held by each separate group
  • One member of each group then participates in a Scrum of Scrums, where the key points from each Scrum meeting are shared with distant members of the project team
  • Short organized meetings allow for major improvements in communication, even in distributed development teams
tools for agile
Tools For Agile
  • The IBM Rational solution for Collaborative Lifecycle Management (CLM) (http://is.gd/jNfz5G)
  • The IBM Requisite Pro for Use Cases and Requirements Management (http://is.gd/Yi6U89)
  • Asana - team's communication (http://is.gd/tI2VEn)
  • Pivotal Tracker - Calculates velocity for team, manages user stories: Current, Backlog, Icebox
  • Cucumber - tests from customer-friendly user stories (http://cukes.info/)
    • Acceptance: ensure satisfied customer
    • Integration: ensure interfaces between modules consistent assumptions, communicate correctly
tools for agile cont
Tools For Agile (Cont.)
  • Rspec - a Domain-Specific Language for testing.
    • small programming language that simplifies one task at expense of generality
      • examples so far: migrations, regexes, SQL
  • Comparison between Cucumber and Rspec:
    • Cucumber describes behavior via features & scenarios (behavior driven design)
    • RSpectests individual modules that contribute to those behaviors (test driven development)
bdd tdd
BDD+TDD
  • Behavior-driven design (BDD)
    • via Cucumber, user stories become acceptance tests and integration tests
  • Test-driven development (TDD)
    • step definitions for new story, may require new code to be written
    • write unit & functional tests for that code first, before the code itself
    • write tests for the code you wish you had
measuring productivity
Measuring Productivity
  • Calculate average number of stories per week
  • Rate each user story in advance on a simple integer scale:
    • 1 for straightforward stories,
    • 2 for medium stories, and
    • 3 for very complex stories
  • Velocity: age number of points per week
agile example bt group
Agile Example: BT Group
  • Previously used third-party developers, which took 4 times as long including all requirements gathering, coding, and testing
  • Completed the task in 90 days of the Agile development cycle
  • Telecom company that adopted the Agile approach in 2005 to replace their UNIX phone traffic monitoring system with a new web-centric architecture
obstacles bt group uk
Obstacles: BT Group, UK
  • IT leaders worked closely with end users
    • Had to break through the perception that the Agile approach meant users could introduce frequent changes during the development cycle
  • IT infrastructure managers were against the change, as they were used to having formalized documentation for new software
agile case study litle co
Agile Case Study: Litle & Co
  • A leading provider of card-not-present transaction payment processing
  • In 2001 a team of six developers decided to use the Agile approach with XP
  • Because Agile allows for prioritizing features along the way they told the co-founder “you’ll have to accept that we won’t be able to tell you exactly what we will deliver in 9 months”
the case study results
The Case Study Results
  • In 2003 Litle & Co’s revenue was $6 million
  • In 2007 that had risen to $60.2 million
  • The company cites the use of Agile as an important factor in their success
  • They utilized eXtreme Programming and Test Driven Development in an iterative process
the case study implementation
The Case Study Implementation
  • Hesitant to implement pair programming
  • Director of software development later says: “I quickly came to enjoy it and depend on it.”
  • Started with 2 week iterations, later moved up to 1 month iterations
  • Each cycle was actually 7 weeks long, these were overlapped to produce a new iteration each month
breakdown of the 7 week cycle
Breakdownof the 7 Week Cycle
  • First week: Planning
  • Next four weeks: Development
  • Final two weeks: Production and acceptance testing
  • Overlapping cycles allow for rapid prioritization of new requirements
results litle co
Results: Litle & Co
  • The company reports the following positive results from using an Agile approach
    • Agile has had positive effects on hiring
    • Developers like that Agile provides the additional challenge of solving some business problems
    • Developers have higher job satisfaction
    • Developers enjoy work that is not based on specification documentation
  • Monthly releases provide a competitive advantage due to flexibility in prioritization
tdd empirical study
TDD Empirical Study
  • Empirical study comparing Test-First projects with Test-Last projects
  • Designed to test for internal quality, programmer productivity, and programmer perceptions of the sample projects.
  • Research conducted in both industrial and academic settings
metrics in tdd
Metrics in TDD
  • The study used a large number of metrics to analyze the development, such as:
    • Development time, effort per feature & per LoC
    • Number of tests written, test coverage on code
    • Internal quality (in tested & not tested areas)
    • Programmer perceptions of the method used
  • In total, over 50 structural and object-oriented metrics were used to gather information
industrial results
IndustrialResults
  • Test-First projects:
    • Had fewer statements
    • Had more exceptions
    • Had lower computational complexity
    • Had lower nested block depth
    • Were simpler (based on length and level metrics)
    • Took less effort
    • Had fewer bugs
notable statistics
NotableStatistics
  • Test-First teams implemented twice as many features as Test-Last teams
  • Test-First teams used 57% less effort per feature than Test-Last teams
  • Test-First teams wrote about twice as many assertions per LoC as Test-Last teams
  • Test-First teams covered 86% more branches of code than tests written by Test-Last teams
agile at home http is gd 9dbve8
Agile at Home http://is.gd/9dbVe8
  • Having weekly family meetings increased communication, improved productivity, lowered stress and made everyone much happier to be part of the family team.”
  • … we ask three questions, all adapted from agile: 1) What went well in our family this week? 2) What didn't go well? 3) What will we agree to work on this week? Everyone offers answers, then we vote on two problem areas to focus on.
summary
Summary

A strength of XP is the development of automated tests before a program feature is created.

The Scrum method is an agile method that provides a project management framework. It is centered round a set of sprints.

Scaling agile methods for large systems is difficult. Large systems need up-front design and some documentation.

extra sources
ExtraSources
  • InfoWorld: BT: A case study in agile programming(http://is.gd/HZwf9T)
  • Best Practices in Scrum Project Management and XP Agile Software Development(http://is.gd/WXOK23)
  • Software Architecture Improvement through TestDrivenDevelopment(http://is.gd/OX6Mkm)
  • Engineering Software as a Service: An Agile Software Approach (http://is.gd/wrreqk)