The document discusses agile engineering practices for software development, including user stories/use cases, test-driven development, continuous integration, precise design, merciless refactoring, collective code ownership, coding conventions, pair programming, code reviews, and steps for adopting agile practices. It provides an overview of each practice and emphasizes adopting test-driven development first when transitioning to agile.

1. Agile Engineering Practices John A. Lewis Chief Software Architect Unicon, Inc. 20 February 2008 © Copyright Unicon, Inc., 2008. Some rights reserved. This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/us/

2. Agile Software Development

3. Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more . From the “Manifesto for Agile Software Development” See http://agilemanifesto.org/

4. Principles of Agile Development Our highest priority is to satisfy the customer through early and continuous delivery of 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. 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.

5. Principles of Agile Development (cont) Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention 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.

6. Nature of A Complete Method There are two critical aspects of a software development method: Process : How the project is conducted and coordinated. Provides for project management and control mechanisms. Not specific to software development. Practice : How the developers perform software development. A set of practices and conventions that all developers follow in order to collaborative effectively and produce high-quality results quickly.

7. Agile Engineering Practices

8. User Stories / Use Cases Plain-language descriptions of things the system does and how the user interacts to accomplish them. User Story: Very simple and written by the customer. Incomplete, possibly inaccurate, doesn't handle exceptional cases. Not a lot of effort is expended making sure it's correct. Serves as a reminder and a starting point for additional discussions with the customer about the full extent of his needs. Use Case: More complex and is written by the developer with the customer. Attempts to be complete, accurate, and handle all possible cases. A lot of effort is expended to make sure it's correct. Should be able to answer any developer questions about customer requirements so that developers do not need more discussion.

9. Test-Driven Development All development is done with a focus on testing. Test cases are developed prior to the code that it tests to ensure proper functionality. Unit tests are automated and can be run as a complete suite to test the entire system. Automated testing frameworks (e.g. JUnit) are used to manage and execute the tests.

10. Continuous Integration Instead of splitting up to work on modules separately, all developers always have each-others latest code. This ensures that the fully integrated system is always functional. Version control systems like CVS and Subversion promote continuous integration Only maintain one code line, so there are no big integrations (patches to released versions are a reasonable exception)

11. Precisely Enough Design The right design at any given time should: Pass all the tests Say things once – and only once Contains only the things you need now (not what you anticipate needing in the future) Eliminate everything else from your design “The simplest thing that could possibly work” “You Aren't Gonna Need It” (YAGNI)

12. Merciless Refactoring Whenever methods or objects are found to contain similar or identical functionality they are refactored into a single implementation. This is done repeatedly as the system evolves and keeps the design fresh and accurate. This makes things simpler, easier to understand, easier to extend, and more reliable.

13. Collective Code Ownership The code for the project is owned by the entire project team. No one developer “owns” any of the code. While building new functionality, developers may modify any code in the system. Developers are responsible for maintaining all unit tests and writing new ones for new functionality. All the normal integrity preservation duties apply to changes to any code.

14. Coding Conventions Use a complete set of well-defined coding standards so that all code is easily read and maintained by all developers. These include conventions for: Class / method / attribute naming Indentation White space Block delimiter placement Comments

15. Pair Programming Two programmers working together at one workstation when writing code Each complements what the other is doing: One writes unit tests, the other thinks about the class that will satisfy those tests One writes code logic, the other watches for bugs or makes suggestions for improvements Switch role in the pair frequently and switch pairs frequently (“promiscuous”) Admittedly controversial and hard to justify as being more than twice as productive

16. Code Reviews Upon completion of a feature/bug, the code changes are reviewed by some subset of the development team. Code is reviewed in real-time on a developer computer with a projector and screen. As problems are found, the developer makes changes right then and there. If the problems are too big to fix immediately, they are documented and a programmer is assigned to tackle it separately as a new bug or feature.

17. Steps For Adoption Agile Practices should be adopted gradually by projects running an Agile Process Tech Leads must encourage / enforce the practices with the development team Training and coaching from other experts is also valuable Test-Driven Development should be adopted first since it drives a lot of agile behavior and is painful to retrofit

18. Resources Website: http://www.agilealliance.org/ Website: http://www.extremeprogramming.org/ Book: "Extreme Programming Explained" by Kent Beck C2 Wiki: Extreme Programming Core Practices

19. Questions & Answers John A. Lewis Chief Software Architect Unicon, Inc. [email_address] www.unicon.net