You are on page 1of 12

Agile Software Development Topics covered Agile methods Plan-driven and agile development Extreme programming Scrum Agile

Agile project management Scaling agile methods Rapid software development Rapid development and delivery is now often the most important re uirement for software systems !usinesses operate in a fast "changing environment and it is practically impossi#le to produce a set of sta#le software re uirements Software has to evolve uic$ly to reflect changing #usiness needs

Rapid software development Specification% design and implementation are inter-leaved System is developed as a series of versions with sta$eholders involved in version evaluation &ser interfaces are often developed using an 'DE and graphical toolset(

Agile methods Dissatisfaction with the overheads involved in software design methods of the )*+,s and )**,s led to the creation of agile methods( These methods .ocus on the code rather than the design Are #ased on an iterative approach to software development Are intended to deliver wor$ing software uic$ly and evolve this uic$ly to meet changing re uirements(

The aim of agile methods is to reduce overheads in the software process /e(g( #y limiting documentation0 and to #e a#le to respond uic$ly to changing re uirements without excessive rewor$( Agile manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools; Working software over comprehensive documentation; Customer collaboration 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 left more. The principles of agile methods Agile method applica#ility Product development where a software company is developing a small or medium-si1ed product for sale( 2ustom system development within an organi1ation% where there is a clear commitment from the customer to #ecome involved in the development process and where there are not a lot of external rules and regulations that affect the software( !ecause of their focus on small% tightly-integrated teams% there are pro#lems in scaling agile methods to large systems( Pro#lems with agile methods 't can #e difficult to $eep the interest of customers who are involved in the process( Team mem#ers may #e unsuited to the intense involvement that characterises agile methods( Prioritising changes can #e difficult where there are multiple sta$eholders( 3aintaining simplicity re uires extra wor$( 2ontracts may #e a pro#lem as with other approaches to iterative development( Agile methods and software maintenance 3ost organi1ations spend more on maintaining existing software than they do on new software development( So% if agile methods are to #e successful% they have to support maintenance as well as original development(

Two $ey issues Are systems that are developed using an agile approach maintaina#le% given the emphasis in the development process of minimi1ing formal documentation4 2an agile methods #e used effectively for evolving a system in response to customer change re uests4

Pro#lems may arise if original development team cannot #e maintained( Plan-driven and agile development

Plan-driven development A plan-driven approach to software engineering is #ased around separate development stages with the outputs to #e produced at each of these stages planned in advance( 5ot necessarily waterfall model " plan-driven% incremental development is also possi#le( 'teration occurs within activities(

Agile development Specification% design% implementation and testing are inter-leaved and the outputs from the development process are decided through a process of negotiation during the software development process(

Plan-driven and agile specification Technical% human% organi1ational issues 3ost projects include elements of plan-driven and agile processes( Deciding on the #alance depends on 's it important to have a very detailed specification and design #efore moving to implementation4 'f so% you pro#a#ly need to use a plan-driven approach( 's an incremental delivery strategy% where you deliver the software to customers and get rapid feed#ac$ from them% realistic4 'f so% consider using agile methods( 6ow large is the system that is #eing developed4 Agile methods are most effective when the system can #e developed with a small co-located team who can communicate informally( This may not #e possi#le for large systems that re uire larger development teams so a plan-driven approach may have to #e used(

Technical% human% organi1ational issues 7hat type of system is #eing developed4 Plan-driven approaches may #e re uired for systems that re uire a lot of analysis #efore implementation /e(g( real-time system with complex timing re uirements0(

7hat is the expected system lifetime4 8ong-lifetime systems may re uire more design documentation to communicate the original intentions of the system developers to the support team(

7hat technologies are availa#le to support system development4 Agile methods rely on good tools to $eep trac$ of an evolving design

6ow is the development team organi1ed4 'f the development team is distri#uted or if part of the development is #eing outsourced% then you may need to develop design documents to communicate across the development teams(

Technical% human% organi1ational issues Are there cultural or organi1ational issues that may affect the system development4 Traditional engineering organi1ations have a culture of plan-#ased development% as this is the norm in engineering(

6ow good are the designers and programmers in the development team4 't is sometimes argued that agile methods re uire higher s$ill levels than plan-#ased approaches in which programmers simply translate a detailed design into code

's the system su#ject to external regulation4 'f a system has to #e approved #y an external regulator /e(g( the .AA approve software that is critical to the operation of an aircraft0 then you will pro#a#ly #e re uired to produce detailed documentation as part of the system safety case(

Extreme programming

Perhaps the #est-$nown and most widely used agile method( Extreme Programming /9P0 ta$es an :extreme; approach to iterative development( 5ew versions may #e #uilt several times per day< 'ncrements are delivered to customers every = wee$s< All tests must #e run for every #uild and the #uild is only accepted if tests run successfully( 9P and agile principles 'ncremental development is supported through small% fre uent system releases( 2ustomer involvement means full-time customer engagement with the team( People not process through pair programming% collective ownership and a process that avoids long wor$ing hours( 2hange supported through regular system releases( 3aintaining simplicity through constant refactoring of code( The extreme programming release cycle Extreme programming practices /a0 Extreme programming practices /#0 Re uirements scenarios 'n 9P% a customer or user is part of the 9P team and is responsi#le for ma$ing decisions on re uirements( &ser re uirements are expressed as scenarios or user stories( These are written on cards and the development team #rea$ them down into implementation tas$s( These tas$s are the #asis of schedule and cost estimates( The customer chooses the stories for inclusion in the next release #ased on their priorities and the schedule estimates( A :prescri#ing medication; story Examples of tas$ cards for prescri#ing medication 9P and change

2onventional wisdom in software engineering is to design for change( 't is worth spending time and effort anticipating changes as this reduces costs later in the life cycle( 9P% however% maintains that this is not worthwhile as changes cannot #e relia#ly anticipated( Rather% it proposes constant code improvement /refactoring0 to ma$e changes easier when they have to #e implemented( Refactoring Programming team loo$ for possi#le software improvements and ma$e these improvements even where there is no immediate need for them( This improves the understanda#ility of the software and so reduces the need for documentation( 2hanges are easier to ma$e #ecause the code is well-structured and clear( 6owever% some changes re uires architecture refactoring and this is much more expensive( Examples of refactoring Re-organi1ation of a class hierarchy to remove duplicate code( Tidying up and renaming attri#utes and methods to ma$e them easier to understand( The replacement of inline code with calls to methods that have #een included in a program li#rary( Testing in 9P Testing is central to 9P and 9P has developed an approach where the program is tested after every change has #een made( 9P testing features Test-first development( 'ncremental test development from scenarios( &ser involvement in test development and validation( Automated test harnesses are used to run all component tests each time that a new release is #uilt( Test-first development

7riting tests #efore code clarifies the re uirements to #e implemented( Tests are written as programs rather than data so that they can #e executed automatically( The test includes a chec$ that it has executed correctly( &sually relies on a testing framewor$ such as >unit( All previous and new tests are run automatically when new functionality is added% thus chec$ing that the new functionality has not introduced errors( 2ustomer involvement The role of the customer in the testing process is to help develop acceptance tests for the stories that are to #e implemented in the next release of the system( The customer who is part of the team writes tests as development proceeds( All new code is therefore validated to ensure that it is what the customer needs( 6owever% people adopting the customer role have limited time availa#le and so cannot wor$ full-time with the development team( They may feel that providing the re uirements was enough of a contri#ution and so may #e reluctant to get involved in the testing process( Test case description for dose chec$ing Test automation Test automation means that tests are written as executa#le components #efore the tas$ is implemented These testing components should #e stand-alone% should simulate the su#mission of input to #e tested and should chec$ that the result meets the output specification( An automated test framewor$ /e(g( >unit0 is a system that ma$es it easy to write executa#le tests and su#mit a set of tests for execution( As testing is automated% there is always a set of tests that can #e uic$ly and easily executed 7henever any functionality is added to the system% the tests can #e run and pro#lems that the new code has introduced can #e caught immediately( 9P testing difficulties Programmers prefer programming to testing and sometimes they ta$e short cuts when writing tests( .or example% they may write incomplete tests that do not chec$ for all possi#le exceptions that may occur(

Some tests can #e very difficult to write incrementally( .or example% in a complex user interface% it is often difficult to write unit tests for the code that implements the :display logic; and wor$flow #etween screens( 't difficult to judge the completeness of a set of tests( Although you may have a lot of system tests% your test set may not provide complete coverage( Pair programming 'n 9P% programmers wor$ in pairs% sitting together to develop code( This helps develop common ownership of code and spreads $nowledge across the team( 't serves as an informal review process as each line of code is loo$ed at #y more than ) person( 't encourages refactoring as the whole team can #enefit from this( 3easurements suggest that development productivity with pair programming is similar to that of two people wor$ing independently( Advantages of pair programming 't supports the idea of collective ownership and responsi#ility for the system( 'ndividuals are not held responsi#le for pro#lems with the code( 'nstead% the team has collective responsi#ility for resolving these pro#lems( 't acts as an informal review process #ecause each line of code is loo$ed at #y at least two people( 't helps support refactoring% which is a process of software improvement( 7here pair programming and collective ownership are used% others #enefit immediately from the refactoring so they are li$ely to support the process( Agile project management The principal responsi#ility of software project managers is to manage the project so that the software is delivered on time and within the planned #udget for the project( The standard approach to project management is plan-driven( 3anagers draw up a plan for the project showing what should #e delivered% when it should #e delivered and who will wor$ on the development of the project delivera#les( Agile project management re uires a different approach% which is adapted to incremental development and the particular strengths of agile methods(

Scrum The Scrum approach is a general agile method #ut its focus is on managing iterative development rather than specific agile practices( There are three phases in Scrum( The initial phase is an outline planning phase where you esta#lish the general o#jectives for the project and design the software architecture( This is followed #y a series of sprint cycles% where each cycle develops an increment of the system( The project closure phase wraps up the project% completes re uired documentation such as system help frames and user manuals and assesses the lessons learned from the project( The Scrum process The Sprint cycle Sprints are fixed length% normally ="? wee$s( They correspond to the development of a release of the system in 9P( The starting point for planning is the product #ac$log% which is the list of wor$ to #e done on the project( The selection phase involves all of the project team who wor$ with the customer to select the features and functionality to #e developed during the sprint( The Sprint cycle @nce these are agreed% the team organi1e themselves to develop the software( During this stage the team is isolated from the customer and the organi1ation% with all communications channelled through the so-called :Scrum master;( The role of the Scrum master is to protect the development team from external distractions( At the end of the sprint% the wor$ done is reviewed and presented to sta$eholders( The next sprint cycle then #egins(

Teamwor$ in Scrum

The :Scrum master; is a facilitator who arranges daily meetings% trac$s the #ac$log of wor$ to #e done% records decisions% measures progress against the #ac$log and communicates with customers and management outside of the team( The whole team attends short daily meetings where all team mem#ers share information% descri#e their progress since the last meeting% pro#lems that have arisen and what is planned for the following day( This means that everyone on the team $nows what is going on and% if pro#lems arise% can re-plan short-term wor$ to cope with them( Scrum #enefits The product is #ro$en down into a set of managea#le and understanda#le chun$s( &nsta#le re uirements do not hold up progress( The whole team have visi#ility of everything and conse uently team communication is improved( 2ustomers see on-time delivery of increments and gain feed#ac$ on how the product wor$s( Trust #etween customers and developers is esta#lished and a positive culture is created in which everyone expects the project to succeed( Scaling agile methods Agile methods have proved to #e successful for small and medium si1ed projects that can #e developed #y a small co-located team( 't is sometimes argued that the success of these methods comes #ecause of improved communications which is possi#le when everyone is wor$ing together( Scaling up agile methods involves changing these to cope with larger% longer projects where there are multiple development teams% perhaps wor$ing in different locations( 8arge systems development 8arge systems are usually collections of separate% communicating systems% where separate teams develop each system( .re uently% these teams are wor$ing in different places% sometimes in different time 1ones( 8arge systems are :#rownfield systems;% that is they include and interact with a num#er of existing systems( 3any of the system re uirements are concerned with this interaction and so don;t really lend themselves to flexi#ility and incremental development(

7here several systems are integrated to create a system% a significant fraction of the development is concerned with system configuration rather than original code development( 8arge system development 8arge systems and their development processes are often constrained #y external rules and regulations limiting the way that they can #e developed( 8arge systems have a long procurement and development time( 't is difficult to maintain coherent teams who $now a#out the system over that period as% inevita#ly% people move on to other jo#s and projects( 8arge systems usually have a diverse set of sta$eholders( 't is practically impossi#le to involve all of these different sta$eholders in the development process( Scaling out and scaling up :Scaling up; is concerned with using agile methods for developing large software systems that cannot #e developed #y a small team( :Scaling out; is concerned with how agile methods can #e introduced across a large organi1ation with many years of software development experience( 7hen scaling agile methods it is essential to maintain agile fundamentals .lexi#le planning% fre uent system releases% continuous integration% test-driven development and good team communications( Scaling up to large systems .or large systems development% it is not possi#le to focus only on the code of the system( Aou need to do more up-front design and system documentation( 2ross-team communication mechanisms have to #e designed and used( This should involve regular phone and video conferences #etween team mem#ers and fre uent% short electronic meetings where teams update each other on progress( 2ontinuous integration% where the whole system is #uilt every time any developer chec$s in a change% is practically impossi#le( 6owever% it is essential to maintain fre uent system #uilds and regular releases of the system( Scaling out to large companies Project managers who do not have experience of agile methods may #e reluctant to accept the ris$ of a new approach(

8arge organi1ations often have uality procedures and standards that all projects are expected to follow and% #ecause of their #ureaucratic nature% these are li$ely to #e incompati#le with agile methods( Agile methods seem to wor$ #est when team mem#ers have a relatively high s$ill level( 6owever% within large organi1ations% there are li$ely to #e a wide range of s$ills and a#ilities( There may #e cultural resistance to agile methods% especially in those organi1ations that have a long history of using conventional systems engineering processes( Bey points Agile methods are incremental development methods that focus on rapid development% fre uent releases of the software% reducing process overheads and producing highuality code( They involve the customer directly in the development process( The decision on whether to use an agile or a plan-driven approach to development should depend on the type of software #eing developed% the capa#ilities of the development team% and the culture of the company developing the system( Extreme programming is a well-$nown agile method that integrates a range of good programming practices such as fre uent releases of the software% continuous software improvement and customer participation in the development team( Bey points A particular strength of extreme programming is the development of automated tests #efore a program feature is created( All tests must successfully execute when an increment is integrated into a system( The Scrum method is an agile method that provides a project management framewor$( 't is centred round a set of sprints% which are fixed time periods when a system increment is developed( Scaling agile methods for large systems is difficult( 8arge systems need up-front design and some documentation(