Your SlideShare is downloading. ×
0
Agile Engineering
Agile Engineering
Agile Engineering
Agile Engineering
Agile Engineering
Agile Engineering
Agile Engineering
Agile Engineering
Agile Engineering
Agile Engineering
Agile Engineering
Agile Engineering
Agile Engineering
Agile Engineering
Agile Engineering
Agile Engineering
Agile Engineering
Agile Engineering
Agile Engineering
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Agile Engineering

598

Published on

Published in: Business, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
598
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
19
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Agile Development Practices John A. Lewis Chief Software Architect Unicon, Inc. 29 July 2010 © Copyright Unicon, Inc., 2010. 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 <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.
  • 25. Incomplete, possibly inaccurate, doesn't handle exceptional cases.
  • 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
  • 55. Indentation
  • 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
  • 69. Issue Tracking for Product Backlog, Sprint Backlog bugs, track workload, monitor velocity
  • 70. Version Control for collective code ownership and continuous integration
  • 71. Continuous Integration for nightly builds, automated testing, code analysis, metrics </li></ul></ul>
  • 72. Adopting Agile Practices <ul><li>Agile Practices should be adopted gradually by projects running an Agile Process.
  • 73. Tech Leads must encourage / enforce the practices with the development team.
  • 74. Training and coaching from other experts is also valuable.
  • 75. Test-Driven Development should be adopted first since it drives a lot of agile behavior and is painful to retrofit.
  • 76. Put key tools in place and reinforce simple and proper usage of the tools </li></ul>
  • 77. Resources <ul><li>Website: http://www.agilealliance.org/
  • 78. Website: http://www.extremeprogramming.org/
  • 79. Book: &quot;Extreme Programming Explained&quot; by Kent Beck
  • 80. C2 Wiki: Extreme Programming Core Practices </li></ul>
  • 81. Questions & Answers John A. Lewis Chief Software Architect Unicon, Inc. [email_address] www.unicon.net

×