A little Software Engineering: Agile Software Development, Practices through Values

1. A little Software Engineering:Agile Software Development,Practices through Values C Sc 335 Rick Mercer

2. Goal and Outline • Main Goal: • Suggest practices, values, and some process for completing a final project on time that is better than any one person could do it in in four times the time • Outline • Distinguish Waterfall (plan driven) from Agile • Practices and Values of quality software development

3. Waterfall Model • Waterfall was described by 1970 • Understood as • finish each phase • don’t proceed till done • W. W. Roycecriticized this • proposed an iterative approach

4. Became Popular • Management (usually software ignorant) like phases • to easily set deadlines • Customers provide all requirements • Analysts translate requirements into specification • Coders implement the specification • Reviews ensure the specification is met • Testing is performed by testers (not the devs) (QA) • Maintenance means modifying as little as possible • old code is good code • Change is hard (and costly)

5. To waterfall or not • Waterfall became popular, and for no good reasons • This process is still is used a lot • Craig Larman's book [1] provides proof that waterfall is a terrible way to develop software • In his study, 87% of all projects failed • The waterfall process was the "single largest contributing factor for failure, being cited in 81% of the projects as the number one problem." [1] Agile and Iterative Development: a Manager's Guide, Addison-Wesley Professional, 2003

6. A Spiral Approach • Dr. Barry Boehm proposed a spiral approach

7. Agile Software Development • set of practices to produce high-quality software • disciplined approach to software development • successful because it emphasizes customer involvement and promotes team work • not a solution looking for a problem • 59% of 2013 survey respondents use Agile • 83% planned to use agile in the upcoming year

8. Individuals and interactions Responding to change Working software Customer collaboration Following a plan Comprehensive documentation Contract negotiation Process and tools over over over over The Agile Manifesto:a statement of values Source: www.agilemanifesto.org

9. eXtreme Programming (XP)an Agile Process • Values • Communication, Simplicity, Feedback, Courage • Principles • Provide feedback, assume simplicity, make incremental changes, embrace change, quality work • Practices • Planning game, small releases, simple designs, automated testing, continuous integration, refactoring, pair programming, collective ownership, continuous integration, on-site customer, coding standard

10. Cost of change Waterfall Cost of change Agile time

11. Cost of the Project • Paraphrasing from two companies I've talked to (probably many more) • When we bid projects, we charge $X for doing it Waterfall and $X/2 for doing it Agile

12. Agile Practices: The Planning Game • The planning game involves user stories • Short descriptions of desired features • Provide value to customer • Testable (do we have that feature two weeks in?) • Clients write stories and prioritize them • In 335, SLs wrote the requirements, you prioritize • Developers estimate how long a story takes • If you are so inclined, estimate each requirement

13. Values: Communication • Simply talking about the project • Determining who will do what • Understand Requirements • Write user stories to represent what the system will do • Analysis & Design sessions • Happening whenever the team is together

14. Values: Communication • Pair programming • A good thing • Iteration planning • What to do in the next iteration • Retrospectives, for example what do we • Stop doing • Continue doing • Start doing

15. Values: Feedback • Feedback very important • Small Iterations • Pair programming • Constant code review (pair programming) • Continuous integration (add often to the build—sync your code with the system) • Check out, run all test including your new tests and code, if all pass, check in the updated system • Automated unit tests (JUnit)

16. Values: Feedback • Compiler feedback: seconds • Pair programming feedback: half minutes • Complete all tasks completed in a pair programming mode. • Unit test feedback: few minutes • Acceptance testing: Each Iteration • Your PM has accepted Iteration 1 or told you what’s missing

17. Practices: On-site customer • Many software projects fail because they do not deliver software that meets needs • A real client should be part of the team • Defines / decides the needs • Answers questions and resolves issues • Prioritizes features • Helps prevents devs from making decisions like: "They probably wanted us to ....” • Consider your PM playing this role

18. Practices: Simple design • The “right” design • Runs all tests • No code duplication, No code duplication, No code duplication • Composed methods

19. Practices: Testing • Software should be tested, but it is often spotty or overlooked • Automatic testing (JUnit, for example) helps us know that a feature works and it will work after refactoring, additional code, and other changes • Provides confidence in the program

20. Testing • Write tests at the same time as production code • Unit tests  developer • Feature/acceptance tests  grader in 335 • Don't need a test for every method (but why not?) • Testing can be used to drive development and design of code • But it helps to have an overall architecture first (see your UML class diagram, which is subject to change • Allows for regression testing • Did my change break previously working code? • If well-tested, you see the red bar when you break your code

21. Regression Testing • Regression Testing • re-testing of a previously tested program following modification to ensure that faults have not been introduced or uncovered as a result of changes. • Regression tests are designed for repeatability, and are often used when testing a second or later version of the system under test • Regression testing can be carried out on all applications, includinge-Commerce and web-based systems

22. Testing • Strong emphasis on regression testing • Unit tests need to execute all the time • Unit tests pass 100% • Other testing frameworks include • SUnit (Smalltalk), HttpUnit (WebApps), AceUnit (C), CPPUnit (C++), PyUnit (Python) • For a complete list, see http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks

23. Can't unit test always • Won’t have unit tests for • GUIs: There are testing frameworks to simulate and test user interaction, but not this course • Just added to WebCat • Network, use visual inspection while running • Views, animation, drawing: visually inspect • this is system verification too • Randomness: Some strategies might have some randomness, which can be hard to work with • Use “tournaments” to see which AI wins, print restults

24. Practices: Refactoring • Restructure code without changing the functionality • Goal: Keep design simple • Change bad design when you find it • Remove “dead” code • Examples at Martin Fowler's Web site: http://www.refactoring.com/see online catalog

25. Practices: Pair programming • Write production code with 2 people on one machine • Person 1: Implements the method (Driver) • Person 2: Thinks strategically about potential improvements, test cases, issues (Observer or Navigator) • Pairs change all the time. Has advantages such as • No single expert on any part of the system • Continuous code reviews, fewer defects • Cheaper in the long run, and more fun • Issues with Pair Programming: • Not all people like it, not everyone gets along • Pairs need to be able to work together (tough in college) • Requires tolerance, acceptance, showers, no bad breath

26. Practices: Collective ownership • All code can be changed by anybody on the team • Everybody is required to improve any portion of bad code s/he sees • Everyone has responsibility for the system • Individual code ownership tends to create "experts", the "experts" tend to create difficult team situations • Every year in 335... • What would you do? • A team member does not like curly brace line up the other 3 do. Should we go with 1, 3, or negotiate?

27. Practices: Continuous integration • Integration happens after a few hours of development • Checkout repo with your changes, • which may require handling conflicts of two people have modified the same class or method • Make sure all tests pass (green bar) • In case of errors: • Do not put changes into the repo, fix them first • Check in the system to the common repository • Repeat • Your team should be using Git from command line • Recommended: do not use the Egit plugin

28. Continuous Integration • Find problems early • Can see if a change breaks the system more quickly -- while you remember the details • Add to the build on BitBucket in small increments • Every few hours, or • after any new feature, or • When it feels right • Nice to have all 4 in the same room so everyone knows

29. Practices: Coding standards • Coding Standard • Naming conventions and style • Least amount of work possible: Code should exist once and only once • Everyone always use Java 7 always • Team has to adopt a coding standard • Makes it easier to understand other people’s code • Avoids code changes due to syntactic preferences • You get to fight over curly brace placement

30. Coding Standard with Eclipse You may use the Eclipse Standard