6a.Agile Software Development.ppt

8/9/2019 6a.Agile Software Development.ppt

1/33

Agile Software

Development


2/33

I. Agile SoftwareDevelopment

Agile software development is a group of software developmentmethods based on iterative and incremental development, where requirementsand solutions evolve through collaboration between self-organizing, cross-functional teams. Methods Iterative incremental

It promotes adaptive planning, evolutionarydevelopment and delivery, a time-boediterative approach, and encourages rapid and fleible response tochange.

It is a conceptual framewor! that promotes foreseeninteractions throughout

the development cycle.

"heAgile Manifesto#introduced the term in $%%&. '(i!i, $& )ug &$*

+ets ta!e this definition apart.


3/33

a. Software DevelopmentMethod

A software developmentmethodology or systemdevelopment methodology insoftware engineering is a frameworkthat is used to structure, plan, andcontrol the process of developing an

information system.


4/33

b. Software Engineering / SoftwareDevelopment

Software Engineering !I"I# SE# is the applicationof a s$stematic, disciplined, %uanti&able approach tothe design, development, operation, andmaintenance of software, and the stud$ of theseapproaches' that is, the application of engineering to

software.

Software Development, a much used and moregeneric term, does not subsume the engineeringparadigm.

(he &eld)s future looks bright according to Mone$Maga*ine and Salar$.com, which rated +softwareengineer+ as the best ob in the -nited States in 0.

In 1, software engineering was again ranked as thebest ob in the -nited States, this time b$ 2areer2ast.com.


5/33

c. Information S$stem

An information system IS# 3 is an$ combinationof information technolog$ IT# and people)sactivitiesthat support operations, managementand decision making.

In a ver$ broad sense, the term information s$stemis fre%uentl$ used to refer to the interactionbetween people, processes, data and technolog$.

In this sense, the term is used to refer not only to the information and communicationtechnolog$ I2(# that an organi*ation uses,

but also to the wa$ in which peopleinteractwith thistechnolog$ in support of business processes. !iki#

d I i d I l


6/33

d. Iterative and IncrementalDevelopment

Iterative and Incremental development is at the

heart of a c$clic software development processdeveloped in response to the weaknesses of thewaterfall model.

It starts with an initial planning and ends with

deplo$ment with the c$clic interactions in between.

Iterative and incremental development areessential parts of the Rational Uniedrocess, E!treme rogramming andgenerally the various agile softwaredevelopment framewor"s.

It follows a similar process to the 4plan3do3check3act5 c$cle of business rocess im rovement.


7/33

e. (ime36o7ed Approach

In time management, a time box allots a

fixedperiod of timefor an activity.

Timeboxingplans activity by allocatingtime

boes.
http://en.wikipedia.org/wiki/Timehttp://en.wikipedia.org/wiki/Time


8/33

. Introductor$ (houghts

8ears regarding software development ledto a number of pioneers / industr$ e7pertsto develop the #gile$anifestobased

up some &rm values and principles.

9ractitioners had become afraid thatrepeated software failures could not be

stopped without some kind of guidingprocess to guide development activities.


9/33

2ommon 8ears

9ractitioners were afraid that

(he proect will produce the wrongproduct

(he proect will produce a product ofinferior %ualit$

(he proect will be late

!e:ll have to work ; hour weeks !e:ll have to break commitments

!e won:t be having fun.


10/33

Agile Alliance Several individuals, The #gile #lliance,

motivated to constrain activities

such that certain outputs and artifacts arepredictablyproduced.

Around , these notables got together toaddress common development problems.


11/33

(hese activities arose in large part to runawayprocesses. 8ailure to achieve certain goals was met with >more

process.: Schedules slipped' budgets bloated, and

processes became even larger.

(he Alliance 1?# created a statement ofvalues= termed the manifestoof the Agile

Alliance.

(he$ then developed the '(rinciples of#gility&


12/33

Manifesto for Agile SoftwareDevelopment

4!e are uncovering better wa$s of developingsoftware b$ doing it and helping others do it. (hroughthis work we have come to the value=

1. Individuals and interactions over processes and tools.!orking software over comprehensive [email protected] collaboration over contract negotiation.Besponding to change over following a plan

(hat is, while there is value in the items on the right,

we value the items on the leftmore.5

Cet:s look at these values to discern e7actl$ what ismeant.


13/33

Interactions over 9rocesses

and (ools Strong players= a must, but can fail if don:t work

together. Strong player) not necessaril$ an >ace': work well

with others 2ommunication and interacting is more importantthan raw

talent. >Right* toolsare vital to smooth functioning of a team. Start small. 8ind a free tool and use until $ou can

demo $ou:ve outgrown it. Don:t assume bigger isbetter. Start with white board' Fat &les before going toa huge database.

+uilding a teammore important than buildingenvironment& Some managers build the environment and e7pect the team to

fall together. Doesn:t work.

Cet the team build the environment on the basis of need.


14/33

over 2omprehensive

Documentation odeG not ideal medium for communicating rationaleand s$stem structure.

(eam needs to produce human readable documentsdescribing s$stem and design decision rationale.

Too much documentation is worse than too little.(ake time' more to keep in s$nc with code' Hot kept

in s$nc it is a lie and misleading.

Short rationale and structure document.

"eep this in s$nc' Jnl$ highest level structure in thes$stem kept.


15/33

over 2omprehensive

Documentation -ow to train newbeesif short K sweet !ork closel$ with them.

(ransfer knowledge b$ sitting with them' make part ofteam via close training and interaction

Two essentialsfor transferring info to new team

members=

odeis the onl$ unambiguous source of information.

Teamholds ever$3changing roadmap of s$stems intheir heads' cannot put on paper.

+est wayto transfer info3 interact with them.

.atal /aw= 9ursue documentation instead of software=

Rule= 9roduce no document unless need is immediateand signi&cant.


16/33

2ollaboration over 2ontract

Hegotiation 1 of #

Hot possible to describe softwarere%uirements up front and leave someoneelse to develop it within cost and on time.

2ustomers cannot ust cite needs and goawa$

Successful proects re%uire customerfeedbac" on a regular and fre%uent basisG and not dependent upon a contract or SJ!.

l @ 2 t


17/33

alue @= 2ustomer2ollaboration over 2ontract

Hegotiation of # +est contracts are 01Tthose specif$ingre%uirements, schedule and cost. 6ecome meaningless shortl$.

.arbetter are contractsthatgovern theway the development team andcustomer will wor" together.

"e$ is intense collaboration with customerand a contract that governed collaboration

rather than details of scope and schedule Details ideall$ notspeci&ed in contract. Bather contracts could pa$ when a block passed

customer:s acceptance tests. !ith fre%uent deliverables and feedback,

acceptance tests never an issue.


18/33

alue = Besponding to2hange over 8ollowing a 9lan

1ur plans and the ability to respond to changes iscritical2

ourse of a pro3ect cannot be predicted far into thefuture& Too many variables4 not many good ways at estimating cost&

Temptingto create a 9EB( or


19/33

alue = Besponding to2hange over 8ollowing a 9lan

+etter planning strategyG ma"e detailedplans for the ne!t few wee"s, very roughplans for the ne!t few months, ande!tremely crude plans beyond that&

Heed to know what we will be working on the ne7tfew weeks' roughl$ for the ne7t few months' avague idea what s$stem will do after a $ear.

1nly invest in a detailed plan for immediatetas"s' once plan is made, diLcult to change dueto momentum and commitment. 6ut rest of plan remains Fe7ible. (he lower resolution

parts of the plan can be changed with relative ease.


20/33

Agile 9rinciples 1#

(he following principles are thosethat dierentiate agile processesfrom others.


21/33

Satisfy the ustomerthrough Earlyand

ontinuousDeliveryof aluable

Software Humber of practices have signi&cant impact upon %ualit$ of &nals$stem=

1. Strong correlationbetween %ualityand early delivery ofa partially functioning system& (he less functional the initial deliver$, the higher the %ualit$ of the

&nal deliver$. . Another strong correlatione7ists between nal %ualityandfre%uently deliveries of increasing functionality. (he more fre%uent the deliveries, the higher the &nal %ualit$.

#gile processes deliver early and often. Budimentar$ s$stem rstfollowed b$ s$stems of increasing

functionality ever$ few weeks. 2ustomers m$ use these s$stems in production, or Ma$ choose to review e7isting functionalit$ and report on changes

to be made. Begardless, the$ must provide meaningful feedbac".


22/33

rinciple () 6elcome hangingRe%uirements, even late in Development.Agile 9rocesses harness change for the2ustomer:s 2ompetitive Advantage. (his is a statement of attitude.

9articipants in an agile process are notafraidofchange.

Be%uirement changes are good'

Mean team has learned more about what it will take tosatisf$ the market.

Agile teams work to keep the softwarestructure/e!ible, so re%uirement change impact is minimal.

Moreso, the principles of ob3ect oriented design

help us to maintain this kind of Fe7ibilit$.


23/33

Principle 3: Deliver Working Software Frequently

(From a couple of weeks to a couple of months with a

preference to the shorter time scale.

!e deliver working software. Deliver early and often.

+e not contentwith delivering bundlesof documents, or plans.

Don:t count those as true deliverables.

(he goalof delivering software thatsatis&es the customer:s needs.

rinciple 7) 6usiness 9eople and


24/33

rinciple 7) 6usiness 9eople andDevelopers Must 6or" Together Daily

throughout the 9roect.

8or agile proects, there must besignicantand fre%uentinteractionbetween the

customers, developers, and

stakeholders.

An agile proect must be continuouslyguided.

rinciple 8) +uild ro3ects around


25/33

rinciple 8) +uild ro3ects around$otivated Individuals.


26/33

rinciple := (he Most ELcient andEective Method of 2onve$ing Informationto and within a Development (eam is face;

to;face ommunications. In agile proects, developers talkto each other.(he primary mode of communication is

conversation.

Documents ma$ be created, but there is no attempt

to capture all proect information in writing. An agile proect team does not demand

writtenspecs, written plans, or written designs.(he$ ma$ create them if the$ perceive an

immediate and signicant need, but the$ are not

the default.(he default is conversation.


27/33

rinciple


28/33

rinciple @) #gile rocesses promotesustainable developmt (he sponsors,developers, and users should be able tomaintain a constant pace inde&nitel$.

An agile proect is not run like a O $ard dash' it is runlike a marathon. (he team does not take o at full speed and tr$ to

maintain that speed for the duration.

Bather the$ run at a fast, but sustainable, pace.

Bunning too fast leads to burnout, shortcuts, anddebacle.

Agile teams pace themselves. (he$ don:t allow themselves to get too tired. (he$ don:t borrow tomorrow:s energ$ to get a bit more

done toda$. (he$ work at a ratethat allows them to maintain the

highest %ualit$ standards for the duration of the proect.

i i l A 2 i A i


29/33

rinciple A) 2ontinuous Attention to(echnical E7cellence and


30/33

9rinciple 1= SimplicityG the art ofma!imiBing the amount of wor"

not done C is essential&

Agile teams take the simplest path thatis consistent with their goals.

(he$ don:t anticipate tomorrow:s problemsand tr$ to defend against them toda$.

Rather they do the simplest andhighest %uality wor" today, condentthat it will be easy to change if andwhen tomorrows problems arise&


31/33

rinciple '') The 6est Architectures,Be%uirements, and Designs emerge from Self;

1rganiBing Teams

An agile team is a self organi*ing team. Besponsibilities are not handed to individual

team membersfrom the outside. Besponsibilities are communicatedto the team

as a whole, and the team determinesthe best

wa$ to ful&ll them.

Agile team members work together on allproect aspects. Each is allowed input into the whole.

Ho single team member is responsible for thearchitecture, or the re%uirements, or the tests, etc.(he team shares those responsibilities and each

team member has inFuence over them.

rinciple '() At regular Intervals the Team


32/33

rinciple '() At regular Intervals, the Teamre/ectson how to become moreeective,

then tunes and ad3usts its behavioraccordingl$.

An agile team continuall$ adusts itsorgani*ation, rules, conventions,

relationships, etc.

An agile team knows that its environment

is continuousl$ changing, and knows thatthe$ must change with that environmentto remain agile.


33/33

2onclusions The professional goal of every software engineer, and every

development team, is to deliver the highest possible value to ouremployers and customers. And yet, our projects fail, or fail to deliver value, at a dismaying rate.

Though well intentioned, the upward spiral of process inflationisculpable for at least some of this failure.

The principles and values of agile software development were

formed as a way to help teams break the cycle of process inflation, and to focus on simple techniques for reaching their goals.

At the time of this writing there were many agile processes tochoose from. These include

!"#$, !rystal, Feature %riven %evelopment (F%%&, Adaptive oftware %evelopment (A%'&, and most significantly, )treme 'rogramming (*'&. +thers