Data Exchange Framework. Essential basics and practical usage takeaways.
Practical Usage of Agile & Agile Case Studies
description
Transcript of Practical Usage of Agile & Agile Case Studies
![Page 1: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/1.jpg)
Practical Usage of Agile & Agile Case Studies
Webinar Presentation
Dr. Youry KhmelevskyTrainingBC
(Follow-up for the Workshop: "Success in Software Engineering Projects")
![Page 2: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/2.jpg)
OutlineMotivationAgile Extreme (XP) and Pair ProgrammingTDD and BDD DevelopmentScrumExamples of Agile in industry and research informationCase study in eXtreme ProgrammingSummary
![Page 3: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/3.jpg)
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 …
![Page 4: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/4.jpg)
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.
![Page 5: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/5.jpg)
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
![Page 6: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/6.jpg)
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.
![Page 7: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/7.jpg)
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.
![Page 8: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/8.jpg)
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.
![Page 9: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/9.jpg)
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.
![Page 10: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/10.jpg)
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
![Page 11: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/11.jpg)
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)
![Page 12: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/12.jpg)
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.”
![Page 13: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/13.jpg)
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
![Page 14: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/14.jpg)
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.
![Page 15: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/15.jpg)
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.
![Page 16: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/16.jpg)
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
![Page 17: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/17.jpg)
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"; }
![Page 18: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/18.jpg)
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
![Page 19: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/19.jpg)
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
![Page 23: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/23.jpg)
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.
![Page 24: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/24.jpg)
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.
![Page 25: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/25.jpg)
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
![Page 26: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/26.jpg)
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
![Page 27: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/27.jpg)
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.
![Page 28: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/28.jpg)
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.
![Page 29: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/29.jpg)
Use Case Diagram Example IBM Rational
Software Modeler
![Page 31: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/31.jpg)
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".
![Page 32: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/32.jpg)
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
![Page 33: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/33.jpg)
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
![Page 34: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/34.jpg)
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)
![Page 35: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/35.jpg)
Roles Within the ScrumProduct OwnerDevelopment TeamScrum MasterStakeholdersManagers
![Page 36: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/36.jpg)
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
![Page 37: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/37.jpg)
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
![Page 38: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/38.jpg)
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)
![Page 39: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/39.jpg)
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
![Page 40: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/40.jpg)
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
![Page 41: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/41.jpg)
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
![Page 42: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/42.jpg)
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
![Page 43: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/43.jpg)
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”
![Page 44: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/44.jpg)
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
![Page 45: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/45.jpg)
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
![Page 46: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/46.jpg)
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
![Page 47: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/47.jpg)
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
![Page 48: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/48.jpg)
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
![Page 49: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/49.jpg)
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
![Page 50: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/50.jpg)
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
![Page 51: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/51.jpg)
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
![Page 52: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/52.jpg)
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.
![Page 53: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/53.jpg)
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.
![Page 54: Practical Usage of Agile & Agile Case Studies](https://reader036.fdocuments.us/reader036/viewer/2022081507/5681687d550346895ddef2ad/html5/thumbnails/54.jpg)
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)