Agile Software Development Values through Practices

1. Agile Software DevelopmentValues through Practices C Sc 335 Rick Mercer

2. Values: Communication • Communication • Client centric (Clients/PMs/SLs write stories) • Analysis & Design sessions (continuous) • Pair programming (will do this) • Iteration planning (first one this week) • What to do in the next iteration/sprint (there’ll be 3) • Retrospectives / Stand up meeting: Answer • What did I do? What do I plan to do? and what’s in my way? • Update progress in the ALM tool

3. Values: Simplicity • Simplicity • Choose the simplest thing that will work • Choose the simplest design, technology, algorithm, technique

4. 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 • Avoid or reduce branches (the source of conflicts) • Automated unit tests (JUnit, for example)

5. 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: half hours • Customers write these, we are not doing this in 335 • Customer feedback: daily (or several times/week) • Iteration feedback: when tasks are started, completed, or blocked • Project manager meetings weekly • The will mark the task as accepted A

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

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

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

9. Testing • Write tests at the same time as production code • Unit tests  developer • Feature/acceptance tests  customer (not 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

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

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

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

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

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

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

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

17. Continuous Integration • Find problems early • Can see if a change breaks the system more quickly -- while you remember the details • Add to the build in small increments

18. 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 6 or Java 7 • 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

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