8/9/2019 237384444 Agile Methodology

http://slidepdf.com/reader/full/237384444-agile-methodology 1/8

For Testing Related documents visit: www.gcreddy.net

Agile methodologywww.GCREDDY.NET

Agile software development

Refers to a group of software development methodologies based on iterativedevelopment , where requirements and solutions evolve through collaborationbetween self-organizing cross-functional teams . The term was coined in the year

!!" when the #gile $anifesto was formulated.

#gile methods generally promote a disciplined pro%ect management process thatencourages frequent inspection and adaptation, a leadership philosophy thatencourages teamwor&, self-organization and accountability, a set of engineering bestpractices intended to allow for rapid delivery of high-quality software, and a businessapproach that aligns development with customer needs and company goals.

'onceptual foundations of this framewor& are found in modern approaches tooperations management and analysis, such as lean manufacturing , soft systemsmethodology , speech act theory (networ& of conversations approach), and *i+*igma .

There are many specific agile development methods. $ost promote developmentiterations , teamwor&, collaboration, and process adaptability throughout the life-cycleof the pro%ect.

#gile methods brea& tas&s into small increments with minimal planning, and do notdirectly involve long-term planning. terations are short time frames ( timebo+es )that typically last from one to four wee&s. ach iteration involves a team wor&ingthrough a full software development cycle including planning, requirements analysis ,design , coding , unit testing , and acceptance testing when a wor&ing product isdemonstrated to sta&eholders. This helps minimize overall ris&, and lets the pro%ectadapt to changes quic&ly. *ta&eholders produce documentation as required. #niteration may not add enough functionality to warrant a mar&et release, but the goalis to have an available release (with minimal bugs ) at the end of each iteration. /"0

$ultiple iterations may be required to release a product or new features.

Team composition in an agile pro%ect is usually cross-functional and self-organizingwithout consideration for any e+isting corporate hierarchy or the corporate roles ofteam members. Team members normally ta&e responsibility for tas&s that deliver thefunctionality an iteration requires. They decide individually how to meet an iteration1srequirements.

For 2T3 Related documents visit: www.gcreddy.com 1

8/9/2019 237384444 Agile Methodology

http://slidepdf.com/reader/full/237384444-agile-methodology 2/8

For Testing Related documents visit: www.gcreddy.net

#gile methods emphasize face-to-face communication over written documents whenthe team is all in the same location. 4hen a team wor&s in different locations, theymaintain daily contact through videoconferencing, voice, e-mail, etc.

$ost agile teams wor& in a single open office (called bullpen), which facilitates suchcommunication. Team size is typically small (5-6 people) to help ma&e team

communication and team collaboration easier. 7arger development efforts may bedelivered by multiple teams wor&ing toward a common goal or different parts of aneffort. This may also require a coordination of priorities across teams.

8o matter what development disciplines are required, each agile team will contain acustomer representative . This person is appointed by sta&eholders to act on theirbehalf and ma&es a personal commitment to being available for developers toanswer mid-iteration problem-domain questions. #t the end of each iteration,sta&eholders and the customer representative review progress and re-evaluatepriorities with a view to optimizing the return on investment and ensuring alignmentwith customer needs and company goals.

$ost agile implementations use a routine and formal daily face-to-facecommunication among team members. This specifically includes the customerrepresentative and any interested sta&eholders as observers. n a brief session, teammembers report to each other what they did yesterday, what they intend to dotoday, and what their roadbloc&s are. This standing face-to-face communicationprevents problems being hidden.

#gile emphasizes wor&ing software as the primary measure of progress. This,combined with the preference for face-to-face communication, produces less writtendocumentation than other methods9though, in an agile pro%ect, documentation andother artifacts ran& equally with a wor&ing product. The agile method encouragessta&eholders to prioritize wants with other iteration outcomes based e+clusively onbusiness value perceived at the beginning of the iteration.

*pecific tools and techniques such as continuous integration , automated or + nittest , pair programming , test driven development , design patterns , domain-drivendesign , code refactoring and other techniques are often used to improve quality andenhance pro%ect agility.

History

The modern definition of agile software development evolved in the mid-"66!s aspart of a reaction against heavyweight methods, perceived to be typified by aheavily regulated, regimented, micro-managed use of the waterfall model ofdevelopment. The processes originating from this use of the waterfall model wereseen as bureaucratic, slow, demeaning, and inconsistent with the ways that softwaredevelopers actually perform effective wor&. # case can be made that agile anditerative development methods mar& a return to development practice from early inthe history of software development. / 0 nitially, agile methods were called

lightweight methods.

#n adaptive software development process was introduced in a paper by dmonds("6;<). /=0 8otable early #gile methods include *crum ("665), 'rystal 'lear , +treme

For 2T3 Related documents visit: www.gcreddy.com 2

8/9/2019 237384444 Agile Methodology

http://slidepdf.com/reader/full/237384444-agile-methodology 3/8

For Testing Related documents visit: www.gcreddy.net

3rogramming ("66>), #daptive *oftware ?evelopment , Feature ?riven ?evelopment ,and ?ynamic *ystems ?evelopment $ethod (?*?$) ("665). These are now typicallyreferred to as #gile $ethodologies, after the #gile $anifesto published in !!".

n !!", "; prominent figures /<0 in the field of agile development (then called light-weight methods ) came together at the *nowbird s&i resort in tah to discuss ways

of creating software in a lighter, faster, more people-centric way. They coined theterms #gile *oftware ?evelopment and agile methods , and they created the #gile$anifesto , widely regarded as the canonical definition of agile development andaccompanying agile principles. 7ater, some of these people formed The #gile #lliance,a non-profit organization that promotes agile development.

rinciples

#gile methods are a family of development processes, not a single approach tosoftware development. The #gile $anifesto states:

4e are uncovering better ways of developing software by doing it and helping othersdo it. Through this wor& we have come to value:

• !ndivid"als and interactions over processes and tools• #or$ing software over comprehensive documentation• C"stomer colla%oration 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 leftmore.

*ome of the principles behind the #gile $anifesto are:

• 'ustomer satisfaction by rapid, continuous delivery of useful software• 4or&ing software is delivered frequently (wee&s rather than months)• 4or&ing software is the principal measure of progress• ven late changes in requirements are welcomed• 'lose, daily cooperation between business people and developers• Face-to-face conversation is the best form of communication (co-location)• 3ro%ects are built around motivated individuals, who should be trusted• 'ontinuous attention to technical e+cellence and good design• *implicity• *elf-organizing teams• Regular adaptation to changing circumstances

The manifesto spawned a movement in the software industry &nown as agilesoftware development.

n !!5, #listair 'oc&burn and @im Aighsmith gathered another group of people9management e+perts, this time9and wrote an addendum, &nown as the 3$?eclaration of nterdependence .

For 2T3 Related documents visit: www.gcreddy.com 3

8/9/2019 237384444 Agile Methodology

http://slidepdf.com/reader/full/237384444-agile-methodology 4/8

For Testing Related documents visit: www.gcreddy.net

The functioning principles of #gile can be found in lean manufacturing and si+ sigma .These concepts include error proofing, eliminating waste, creating flow, addingcustomer value, and empowering wor&ers. The concepts were first formally espousedin the "< principles of the Toyota 4ay , the two pillars of the Toyota 3roduction*ystem ( @ust-in-time and smart automation ), the 5* methodology , and ?emingBs "<points . These have been summarized in the seven points of lean software

development .

Comparison with other methods

#gile methods are sometimes characterized as being at the opposite end of thespectrum from plan-driven or disciplined methods. This distinction is misleading,as it implies that agile methods are unplanned or undisciplined . # more accuratedistinction is that methods e+ist on a continuum from adaptive to predictive .#gile methods lie on the adaptive side of this continuum.

#daptive methods focus on adapting quic&ly to changing realities. 4hen the needs of a pro%ect change, an adaptive team changes as well. #n adaptive team will have

difficulty describing e+actly what will happen in the future. The further away a dateis, the more vague an adaptive method will be about what will happen on that date.#n adaptive team can report e+actly what tas&s are being done ne+t wee&, but onlywhich features are planned for ne+t month. 4hen as&ed about a release si+ monthsfrom now, an adaptive team may only be able to report the mission statement forthe release, or a statement of e+pected value vs. cost.

3redictive methods, in contrast, focus on planning the future in detail. # predictiveteam can report e+actly what features and tas&s are planned for the entire length ofthe development process. 3redictive teams have difficulty changing direction. Theplan is typically optimized for the original destination and changing direction cancause completed wor& to be thrown away and done over differently. 3redictive teamswill often institute a change control board to ensure that only the most valuablechanges are considered.

#gile methods have much in common with the Rapid #pplication ?evelopmenttechniques from the "6C!D6!s as espoused by @ames $artin and others.

Contrasted with other iterative development methods

$ost agile methods share other iterative and incremental development methods1emphasis on building releasable software in short time periods. #gile developmentdiffers from other development models: in this model time periods are measured inwee&s rather than months and wor& is performed in a highly collaborative manner.

$ost agile methods also differ by treating their time period as a timebo+ .

Contrasted with the waterfall model

#gile development has little in common with the waterfall model . #s of !!6, thewaterfall model is still in common use. The waterfall model is the most structured ofthe methods, stepping through requirements-capture, analysis, design, coding, andtesting in a strict, pre-planned sequence. 3rogress is generally measured in terms of

For 2T3 Related documents visit: www.gcreddy.com 4

8/9/2019 237384444 Agile Methodology

http://slidepdf.com/reader/full/237384444-agile-methodology 5/8

For Testing Related documents visit: www.gcreddy.net

deliverable artifacts: requirement specifications, design documents, test plans, codereviews and the li&e.

# common criticism of the waterfall model is its infle+ible division of a pro%ect intoseparate stages, where commitments are made early on, ma&ing it difficult to reactto changes in requirements as the pro%ect e+ecutes. terations are e+pensive. This

means that the waterfall model is li&ely to be unsuitable if requirements are not wellunderstood or are li&ely to change in the course of the pro%ect.

#gile methods, in contrast, produce completely developed and tested features (but avery small subset of the whole) every few wee&s. The emphasis is on obtaining thesmallest wor&able piece of functionality to deliver business value early, andcontinually improving it and adding further functionality throughout the life of thepro%ect. f a pro%ect being delivered under the waterfall method is cancelled at anypoint up to the end, there is nothing to show for it beyond a huge resources bill. 4iththe agile method, being cancelled at any point will still leave the customer with someworthwhile code that has li&ely already been put into live operation.

#daptations of *crum show how agile methods are augmented to produce andcontinuously improve a strategic plan.

*ome agile teams use the waterfall model on a small scale, repeating the entirewaterfall cycle in every iteration. Ether teams, most notably +treme 3rogramming teams, wor& on activities simultaneously.

Contrasted with &cow%oy coding&

'owboy coding is the absence of a defined method i.e., team members do whateverthey feel is right. The #gile approach is often confused with cowboy coding, due to#gile1s frequent re-evaluation of plans, emphasis on face-to-face communication, and

relatively sparse use of documentation. Aowever, #gile teams follow defined9andoften very disciplined and rigorous9processes.

#s with all development methods, the s&ill and e+perience of users determine thedegree of success andDor abuse of such activity. Rigid controls, which aresystematically embedded within an #gile process, offer stronger levels ofaccountability. The degradation of well-intended procedures can lead to activities thatare often categorized as cowboy coding.

'"ita%ility of agile methods

There is little if any consensus on what types of software pro%ects are best suited for

the agile approach. $any large organizations have difficulty bridging the gapbetween the traditional waterfall method and an agile one.

7arge scale agile software development remains an active research area.

#gile development has been widely documented as wor&ing well for small (G"!developers) co-located teams.

*ome things that can negatively impact the success of an agile pro%ect are:

For 2T3 Related documents visit: www.gcreddy.com 5

8/9/2019 237384444 Agile Methodology

http://slidepdf.com/reader/full/237384444-agile-methodology 6/8

For Testing Related documents visit: www.gcreddy.net

• 7arge scale development efforts (H ! developers), though scaling strategiesand evidence to the contrary /";0 have been described.

• ?istributed development efforts (non-co-located teams). *trategies have beendescribed in Bridging the Distance and Using an Agile Software Process withOffshore Development /"60

• 'ommand-and-control company cultures• Forcing an agile process on a development team• $ission critical systems where failure is not an option at any cost (*oftware

for surgical procedures).

*everal successful large scale agile pro%ects have been documented. IT has hadseveral hundred developers situated in the J, reland and ndia wor&ingcollaboratively on pro%ects and using #gile methods. 4hile questions undoubtedlystill arise about the suitability of some #gile methods to certain pro%ect types, itwould appear that scale or geography, by themselves, are not necessarily barriers tosuccess.

Iarry Ioehm and Richard Turner suggest that ris& analysis be used to choose

between adaptive ( agile ) and predictive ( plan-driven ) methods. /"50 The authorssuggest that each side of the continuum has its own home ground as follows:

#gile home ground:

• 7ow criticality• *enior developers• Requirements change often• *mall number of developers• 'ulture that thrives on chaos

3lan-driven home ground: /"50

• Aigh criticality• @unior developers• Requirements do not change often• 7arge number of developers• 'ulture that demands order

Agile methods and method tailoring

n the literature, different terms refer to the notion of method adaptation, including Kmethod tailoringB, Kmethod fragment adaptationB and Ksituational method

engineeringB. $ethod tailoring is defined as:

# process or capability in which human agents through responsive changes in, anddynamic interplays between conte+ts, intentions, and method fragments determine asystem development approach for a specific pro%ect situation.

3otentially, almost all agile methods are suitable for method tailoring. ven the?*?$ method is being used for this purpose and has been successfully tailored in a'$$ conte+t. *ituation-appropriateness can be considered as a distinguishing

For 2T3 Related documents visit: www.gcreddy.com 6

8/9/2019 237384444 Agile Methodology

http://slidepdf.com/reader/full/237384444-agile-methodology 7/8

For Testing Related documents visit: www.gcreddy.net

characteristic between agile methods and traditional software development methods,with the latter being relatively much more rigid and prescriptive. The practicalimplication is that agile methods allow pro%ect teams to adapt wor&ing practices according to the needs of individual pro%ects. 3ractices are concrete activities andproducts that are part of a method framewor&. #t a more e+treme level, thephilosophy behind the method, consisting of a number of principles , could be

adapted (#ydin, !!<).

+treme 3rogramming (L3) ma&es the need for method adaptation e+plicit. Ene ofthe fundamental ideas of L3 is that no one process fits every pro%ect, but rather thatpractices should be tailored to the needs of individual pro%ects. 3artial adoption of L3practices, as suggested by Iec& , has been reported on several occasions. / 0 #tailoring practice is proposed by $ehdi $ira&horli which provides sufficient roadmapand guideline for adapting all the practices. RD ractice is designed forcustomizing L3. This practice first time proposed as a long research paper in #3*Ewor&shop at '* !!C conference and yet it is the only proposed and applicablemethod for customizing L3. #lthough it is specifically a solution for L3, this practicehas the capability of e+tending to other methodologies. #t first glance, this practiceseems to be in the category of static method adaptation but e+periences with R?33ractice says that it can be treated li&e dynamic method adaptation . Thedistinction between static method adaptation and dynamic method adaptation issubtle. / =0 The &ey assumption behind static method adaptation is that the pro%ectconte+t is given at the start of a pro%ect and remains fi+ed during pro%ect e+ecution.The result is a static definition of the pro%ect conte+t. Miven such a definition, ro"temaps can be used in order to determine which structured method fragments shouldbe used for that particular pro%ect, based on predefined sets of criteria. ?ynamicmethod adaptation, in contrast, assumes that pro%ects are situated in an emergentconte+t. #n emergent conte+t implies that a pro%ect has to deal with emergentfactors that affect relevant conditions but are not predictable. This also means that apro%ect conte+t is not fi+ed, but changing during pro%ect e+ecution. n such a caseprescriptive route maps are not appropriate. The practical implication of dynamic

method adaptation is that pro%ect managers often have to modify structuredfragments or even innovate new fragments, during the e+ecution of a pro%ect (#ydinet al., !!5).

Agile methods and pro(ect management

#gile methods differ to a large degree in the way they cover pro%ect management.*ome methods are supplemented with guidelines on pro%ect management, but thereis generally no comprehensive support.

Ioth 3$3 and 3R 8' have been suggested as suitable, complementary pro%ectmanagement systems.

)or *T !nformation+

www.gcreddy.com)or ,an"al Testing+

For 2T3 Related documents visit: www.gcreddy.com 7

8/9/2019 237384444 Agile Methodology

http://slidepdf.com/reader/full/237384444-agile-methodology 8/8

For Testing Related documents visit: www.gcreddy.net

www.gcreddy.net

For 2T3 Related documents visit: www.gcreddy.com 8