Practical Usage of Agile & Agile Case Studies

1. Practical Usage of Agile & Agile Case Studies (Follow-up for the Workshop: "Success in Software Engineering Projects") Webinar Presentation Dr. Youry Khmelevsky TrainingBC

2. 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

3. 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 …

4. 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.

5. 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

6. 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.

7. 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.

8. 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.

9. 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.

10. 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

11. 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)

12. 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.”

13. 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

14. 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.

15. 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.

16. 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

17. 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"; }

18. 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

19. 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

20. A User Story’s Card Ex.

21. A User Story’s Test Case

22. User Stories Example

23. 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.

24. 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. 

25. 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

26. 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

27. 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.

28. 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.

29. Use Case Diagram Example IBM Rational Software Modeler

30. Use Case Example

31. 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".

32. 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

33. 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

34. 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)

35. Roles Within the Scrum • Product Owner • Development Team • Scrum Master • Stakeholders • Managers

36. 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

37. 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

38. 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)

39. 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

40. 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

41. 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

42. 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

43. 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”

44. 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

45. 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

46. 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

47. 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

48. 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

49. 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

50. 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