Agile software development contains specific tools and techniques such as continuous integration, automated or xUnit test, pair programming, test driven development, design patterns, domain-driven design, code re-factoring and other techniques which are often used to improve quality and enhance project agility.
I'll cover some of the most important agile methodologies that I found very useful in executing projects.
1. Test-driven development (TDD):
It is a software development technique that relies on the repetition of a very short development cycle: First the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards.
Benefits
1. Using TDD meant writing more tests and, in turn, programmers that wrote more tests tended to be more productive.
2. Used in conjunction with a version control system, when tests fail unexpectedly, reverting the code to the last version that passed all tests may often be more productive than debugging
3. Test-driven development offers more than just simple validation of correctness, but can also drive the design of a program.
4. It allows a programmer to focus on the task at hand as the first goal is to make the test pass. Exceptional cases and error handling are not considered initially.
5. Eliminating defects early in the process usually avoids lengthy and tedious debugging later in the project.
6. TDD can lead to more modularized, flexible, and extensible code
7. TDD can lead to more modularized, flexible, and extensible code. See: Mock Object design pattern
8. Because no more code is written than necessary to pass a failing test case, automated tests tend to cover every code path.
Criticisms
1. The tests themselves become part of the maintenance overhead of a project.
2. The high number of passing unit tests may bring a false sense of security
3. Unexpected gaps in test coverage may exist or occur.
2. Mock Objects:
Mock objects allow you to set up predictable behavior to help you test your production code by emulating some functionality your code depends on. This might for example be a huge database which is too difficult and time consuming to maintain just for testing purposes.
Referances:
http://mockpp.sourceforge.net/ - a platform independent generic unit testing framework for C++
http://code.google.com/p/googlemock/
3. Pair programming:It is a software development technique in which two programmers work together at one work station. One types in code while the other reviews each line of code as it is typed in.
Benefits:
* Design quality: Shorter programs, better designs, fewer bugs.
* Reduced cost of development: With bugs being a particularly expensive part of software development, especially if they're caught late in the development process, the large reduction in defect rate due to pair programming can significantly reduce software development costs.
* Learning and training: Knowledge passes easily between pair programmers: they share knowledge of the specifics of the system, and they pick up programming techniques from each other as they work.New hires quickly pick up the practices of the team through pairing.
* Overcoming difficult problems: Pairs often find that seemingly "impossible" problems become easy or even quick, or at least possible, to solve when they work together.
* Improved morale: Programmers report greater joy in their work and greater confidence that their work is correct.
* Decreased management risk: Since knowledge of the system is shared among programmers, there is less risk to management if one programmer leaves the team.
* Increased discipline and better time management: Programmers are less likely to skip writing unit tests, spend time web-surfing or on personal email,[8] or other violations of discipline, when they are working with a pair partner. The pair partner "keeps them honest".
* Resilient flow. Pairing leads to a different kind of flow than programming alone, but it does lead to flow.[citation needed] Pairing flow happens more quickly: one programmer asks the other, "What were we working on?" Pairing flow is also more resilient to interruptions: one programmer deals with the interruption while the other keeps working.
* Fewer interruptions: People are more reluctant to interrupt a pair than they are to interrupt someone working alone.
* Decreased risk of RSI: The risk of repetitive stress injury is significantly reduced, since each programmer is using a keyboard and mouse approximately half the time they were before.
4. Extreme Programming (XP):
It is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent "releases" in short development cycles (timeboxing), which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted.
Other elements of Extreme Programming include:
1. programming in pairs or doing extensive code review,
2. unit testing of all code,
3. avoiding programming of features until they are actually needed,
4. a flat management structure,
5. simplicity and clarity in code,
6. expecting changes in the customer's requirements as time passes and the problem is better understood, and
7. frequent communication with the customer and among programmers.
XP attempts to reduce the cost of change by having multiple short development cycles, rather than one long one.
Criticism:
* A methodology is only as effective as the people involved, Agile does not solve this
* Often used as a means to bleed money from customers through lack of defining a deliverable
* Lack of structure and necessary documentation
* Only works with senior-level developers
* Incorporates insufficient software design
* Requires meetings at frequent intervals at enormous expense to customers
* Requires too much cultural change to adopt
* Can lead to more difficult contractual negotiations
* Can be very inefficient — if the requirements for one area of code change through various iterations, the same programming may need to be done several times over. Whereas if a plan were there to be followed, a single area of code is expected to be written once.
* Impossible to develop realistic estimates of work effort needed to provide a quote, because at the beginning of the project no one knows the entire scope/requirements
* Can increase the risk of scope creep due to the lack of detailed requirements documentation
* Agile is feature driven; non-functional quality attributes are hard to be placed as user stories
5. Scrum
Scrum is an iterative, incremental framework for project management and agile software development.
The main roles in Scrum are:
1. the “ScrumMaster”, who maintains the processes (typically in lieu of a project manager)
2. the “Product Owner”, who represents the stakeholders, represents the business
3. the “Team”, a cross-functional group of about 7 people who do the actual analysis, design, implementation, testing, etc.
During each “sprint”, typically a two to four week period (with the length being decided by the team), the team creates a potentially shippable product increment (for example, working and tested software). The set of features that go into a sprint come from the product “backlog,” which is a prioritized set of high level requirements of work to be done. Which backlog items go into the sprint is determined during the sprint planning meeting. During this meeting, the Product Owner informs the team of the items in the product backlog that he or she wants completed. The team then determines how much of this they can commit to complete during the next sprint.[1] During a sprint, no one is allowed to change the sprint backlog, which means that the requirements are frozen for that sprint. After a sprint is completed, the team demonstrates the use of the software.
Daily Scrum Meetings
Each day during the sprint, a project status meeting occurs. This is called a “daily scrum”, or “the daily standup”. This meeting has specific guidelines:
* The meeting starts precisely on time.
* All are welcome, but only “pigs” (i.e. the ones committed to the project in the Scrum process) may speak
* The meeting is timeboxed to 15 minutes
* The meeting should happen at the same location and same time every day
During the meeting, each team member answers three questions:
* What have you done since yesterday?
* What are you planning to do today?
* Do you have any problems preventing you from accomplishing your goal? (It is the role of the ScrumMaster to facilitate resolution of these impediments. Typically this should occur outside the context of the Daily Scrum so that it may stay under 15 minutes.)
