Practical Usage of Agile & Agile Case Studies
description
Transcript of Practical Usage of Agile & Agile Case Studies
Practical Usage of Agile & Agile Case Studies
Webinar Presentation
Dr. Youry KhmelevskyTrainingBC
(Follow-up for the Workshop: "Success in Software Engineering Projects")
OutlineMotivationAgile Extreme (XP) and Pair ProgrammingTDD and BDD DevelopmentScrumExamples of Agile in industry and research informationCase study in eXtreme ProgrammingSummary
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 ratesOnly 40% of projects met schedule, budget, and
quality goals. Best organizations are 10 times more successful than
worst organizationsBob 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 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 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 Agile1. Our highest priority is to satisfy the customer
through early and continuous deliveryof 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.
12 Principles of Agile (cont.)
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.
7. Working software is the primary measure of progress.
12 Principles of Agile (cont.)
8. Agile processes promote sustainable development - 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.
eXtreme Programming (XP)
Extreme Programming is one of several popular Agile Processes.
Extreme Programming was created by Kent BeckThe 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 XP1. Whole Team (the client is part of the team)2. Metaphor (a common analogy)
3. The Planning Game (incrementally)4. Simple Design5. Small Releases (about 2 weeks)6. Customer Test (develops acceptance test)7. Pair Programming8. Test Driven Development
The Rules of XP (cont.)9. Design Improvement (refactoring, incrementally
improving).10.Collective Code Ownership (anyone can modify any
code without asking anyone for permission).11.Continuous Integration (at all times the system
compiles, runs and passes all the tests).12.Sustainable Pace (no such thing as “a big final
push”)13.Coding Standards (developed code should look like
it was written by a single, consistent person)
Effects of XPXP provides redundancy for knowledge of all
codeXP forces the organization to be very clear about
requirements from the development teamXP allows “better on-boarding of new developers
due to the mentoring and training inherent in pair programming.”
2-week Agile/XP Iteration1. Talk to customer2. Lo-fi mockup3. User stories & scenarios4. Behavior-driven Design/ user stories5. Test-first dev. (unit/functions)6. Measure Velocity7. Deploy8. Go to -> 1.Tools for 4-7: Cucumber, RSpec, Pivotal Tracker, Heroku
Pair ProgrammingPair 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.)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)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] 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
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 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
’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 ScenariosA 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 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 1Scenario 1: Account has sufficient funds
Given the account balance is \$100 And the card is valid And the machine contains enough money When the Account Holder requests \$20 Then the ATM should dispense \$20And the account balance should be \$80 And the card should be returned
Agile Scenario Example 2In 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 CasesA 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 ExtensionExtension: "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 IBM Rational
Software Modeler
Use Case Example
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 ScrumScrum groups have special roles Roles occur from self-forming within the groupCertain roles should be assigned to senior personnelSome roles should be moved from one person to
another regularly
Scrum ManagementDaily 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 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 (8h time limit)
End of Cycle: "Sprint Review Meeting” – Demo (< 4 hours) "Sprint Retrospective” (< 3 hours)
Roles Within the ScrumProduct OwnerDevelopment TeamScrum MasterStakeholdersManagers
Scrum in Distr. Developm.Scrums held by each separate groupOne 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 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.)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) RSpec tests individual modules that contribute to
those behaviors (test driven development)
BDD+TDDBehavior-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 ProductivityCalculate 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 GroupPreviously 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, UKIT 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 & CoA leading provider of card-not-present
transaction payment processingIn 2001 a team of six developers decided to use
the Agile approach with XPBecause 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 ResultsIn 2003 Litle & Co’s revenue was $6 millionIn 2007 that had risen to $60.2 millionThe 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
Hesitant to implement pair programmingDirector 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
First week: PlanningNext four weeks: DevelopmentFinal two weeks: Production and acceptance
testing
Overlapping cycles allow for rapid prioritization of new requirements
Results: Litle & CoThe 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 StudyEmpirical study comparing Test-First projects
with Test-Last projectsDesigned to test for internal quality,
programmer productivity, and programmer perceptions of the sample projects.
Research conducted in both industrial and academic settings
Metrics in TDDThe study used a large number of metrics to
analyze the development, such as:Development time, effort per feature & per
LoCNumber of tests written, test coverage on
codeInternal 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 ResultsTest-First projects:
Had fewer statementsHad more exceptionsHad lower computational complexityHad lower nested block depthWere simpler (based on length and
level metrics)Took less effortHad fewer bugs
Notable StatisticsTest-First teams implemented twice as
many features as Test-Last teamsTest-First teams used 57% less effort per
feature than Test-Last teamsTest-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 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.
SummaryA 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 InfoWorld: BT: A case study in agile
programming (http://is.gd/HZwf9T) Best Practices in Scrum Project Management an
d XP Agile Software Development (http://is.gd/WXOK23)
Software Architecture Improvement through TestDriven Development (http://is.gd/OX6Mkm)
Engineering Software as a Service: An Agile Software Approach (http://is.gd/wrreqk)