3. Manifesto for Agile Software Development <ul><li>We are uncovering better ways of developing software by doing it and helping others do it.
4. Through this work we have come to value: </li><ul><li>Individuals and interactions over processes and tools
5. Working software over comprehensive documentation
6. Customer collaboration over contract negotiation
7. Responding to change over following a plan </li></ul><li>That is, while there is value in the items on the right, we value the items on the left more . </li></ul>From the “Manifesto for Agile Software Development” See http://agilemanifesto.org/
8. Principles of Agile Development <ul><li>Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
9. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
10. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
11. Business people and developers must work together daily throughout the project.
12. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
13. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. </li></ul>
14. Principles of Agile Development (cont) <ul><li>Working software is the primary measure of progress.
15. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
16. Continuous attention to technical excellence and good design enhances agility.
17. Simplicity—the art of maximizing the amount of work not done—is essential.
18. The best architectures, requirements, and designs emerge from self-organizing teams.
19. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. </li></ul>
20. Nature of A Complete Method <ul><li>There are two critical aspects of a software development method: </li><ul><li>Process : How the project is conducted and coordinated. Provides for project management and control mechanisms. Not specific to software development.
21. 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. </li></ul></ul>
22. Agile Development Practices
23. User Stories / Use Cases <ul><li>Plain-language descriptions of things the system does and how the user interacts to accomplish them.
24. User Story: </li><ul><li>Very simple and written by the customer.
26. Not a lot of effort is expended making sure it's correct.
27. Serves as a reminder and a starting point for additional discussions with the customer about the full extent of his needs. </li></ul><li>Use Case: </li><ul><li>More complex and is written by the developer with the customer.
28. Attempts to be complete, accurate, and handle all possible cases.
29. A lot of effort is expended to make sure it's correct.
30. Should be able to answer any developer questions about customer requirements so that developers do not need more discussion. </li></ul></ul>
31. Precisely Enough Design <ul><li>The right design at any given time should: </li><ul><li>Pass all the tests
32. Say things once – and only once
33. Contains only the things you need now (not what you anticipate needing in the future) </li></ul><li>Eliminate everything else from your design
34. “The simplest thing that could possibly work”
35. “You Aren't Gonna Need It” (YAGNI) </li></ul>
36. Test-Driven Development <ul><li>All development is done with a focus on testing.
37. Test cases are developed prior to the code that it tests to ensure proper functionality.
38. “ Red – Green - Refactor ”
39. Unit tests are automated and can be run as a complete suite to test the entire system.
40. Automated testing frameworks (e.g. JUnit) are used to manage and execute the tests. </li></ul>
41. Continuous Integration <ul><li>Instead of splitting up to work on modules separately, all developers always have each-others latest code.
42. This ensures that the fully integrated system is always functional.
43. Version control systems like Subversion promote continuous integration.
44. Only maintain one code line, so there are no big integrations (patches to released versions are a reasonable exception).
45. Automated nightly builds show any problems. </li></ul>
46. Collective Code Ownership <ul><li>The code for the project is owned by the entire project team. No one developer “owns” any of the code.
47. While building new functionality, developers may modify any code in the system.
48. Developers are responsible for maintaining all unit tests and writing new ones for new functionality.
49. All the normal integrity preservation duties apply to changes to any code. </li></ul>
50. Merciless Refactoring <ul><li>Whenever methods or objects are found to contain similar or identical functionality they are refactored into a single implementation.
51. This is done repeatedly as the system evolves and keeps the design fresh and accurate.
52. This makes things simpler, easier to understand, easier to extend, and more reliable. </li></ul>
53. Coding Conventions <ul><li>Use a complete set of well-defined coding standards so that all code is easily read and maintained by all developers.
54. These include conventions for: </li><ul><li>Class / method / attribute naming
56. White space
57. Block delimiter placement
58. Comments </li></ul></ul>
59. Pair Programming <ul><li>Two programmers working together at one workstation when writing code
60. Each complements what the other is doing: </li><ul><li>One writes unit tests, the other thinks about the class that will satisfy those tests
61. One writes code logic, the other watches for bugs or makes suggestions for improvements </li></ul><li>Switch role in the pair frequently and switch pairs frequently (“promiscuous”)
62. Admittedly controversial and hard to justify as being more than twice as productive </li></ul>
63. Code Reviews <ul><li>Upon completion of a feature/bug, the code changes are reviewed by some subset of the development team.
64. Code is reviewed in real-time on a developer computer with a projector and screen.
65. As problems are found, the developer makes changes right then and there.
66. 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. </li></ul>
67. Collaboration Tools <ul><li>Keep tools as simple as possible.
68. Use the right tools to help team collaborate: </li><ul><li>Wiki for simple docs, user stories, use cases, Sprint goals and overviews