复制成功
  • 图案背景
  • 纯色背景
网上书摊QQ..

上传于:2015-02-04

粉丝量:841

QQ 3555755295



Agile Risk Management (SpringerBriefs in Computer Science) (2014)

下载积分:800

内容提示: SPRINGER BRIEFS IN COMPUTER SCIENCEAlan MoranAgile Risk Management SpringerBriefs in Computer ScienceFor further volumes:http://www.springer.com/series/10028 Alan MoranAgile Risk Management123 Alan MoranZurichSwitzerlandISSN 2191-5768ISBN 978-3-319-05007-2DOI 10.1007/978-3-319-05008-9Springer Cham Heidelberg New York Dordrecht LondonISSN 2191-5776ISBN 978-3-319-05008-9(electronic)(eBook)Library of Congress Control Number: 2014931762? The Author(s) 2014This work is subject to copyright. All rights are re...

文档格式:PDF| 浏览次数:2| 上传日期:2015-02-04 23:11:24| 文档星级:
SPRINGER BRIEFS IN COMPUTER SCIENCEAlan MoranAgile Risk Management SpringerBriefs in Computer ScienceFor further volumes:http://www.springer.com/series/10028 Alan MoranAgile Risk Management123 Alan MoranZurichSwitzerlandISSN 2191-5768ISBN 978-3-319-05007-2DOI 10.1007/978-3-319-05008-9Springer Cham Heidelberg New York Dordrecht LondonISSN 2191-5776ISBN 978-3-319-05008-9(electronic)(eBook)Library of Congress Control Number: 2014931762? The Author(s) 2014This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part ofthe material is concerned, specifically the rights of translation, reprinting, reuse of illustrations,recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission orinformation storage and retrieval, electronic adaptation, computer software, or by similar or dissimilarmethodology now known or hereafter developed. Exempted from this legal reservation are briefexcerpts in connection with reviews or scholarly analysis or material supplied specifically for thepurpose of being entered and executed on a computer system, for exclusive use by the purchaser of thework. Duplication of this publication or parts thereof is permitted only under the provisions ofthe Copyright Law of the Publisher’s location, in its current version, and permission for use mustalways be obtained from Springer. Permissions for use may be obtained through RightsLink at theCopyright Clearance Center. Violations are liable to prosecution under the respective Copyright Law.The use of general descriptive names, registered names, trademarks, service marks, etc. in thispublication does not imply, even in the absence of a specific statement, that such names are exemptfrom the relevant protective laws and regulations and therefore free for general use.While the advice and information in this book are believed to be true and accurate at the date ofpublication, neither the authors nor the editors nor the publisher can accept any legal responsibility forany errors or omissions that may be made. The publisher makes no warranty, express or implied, withrespect to the material contained herein.Printed on acid-free paperSpringer is part of Springer Science+Business Media (www.springer.com) ForewordAgile is no longer a hype. It has matured—we even have an Agile Maturity Model!It is being used across the globe and continues to be innovated, overcoming manyold myths as well as some new ones. However, our work is not complete and itwill always demand of us that we keep up with new developments in technology,society and our working environment. One of these areas is agile risk management.The most used method of risk management I know is people just writing risksdown! With pride people will show you their most brilliant Excel sheets withfifteen to twenty columns that present information on what they perceived as risksin a given situation. Rarely do I meet people who actually manage risk, let alonemanage it in an agile way!This brings us to an important question, what is agile risk management? I havebeen discussing this with Alan and we agree on the fact that agile risk managementmeans managing risks in such a way that it facilitates the agile interaction conceptjust like any other agile practice or technique.Alan takes agile risk management a step further. He changes the perception ofwhat a risk is and what it can bring to a project or a team. We have been over thisground again and again and each time more value has been added. He busts a fewmyths and brings new techniques to the table. I hope that you will not only enjoythis book but that it will also help you in your work and give you new insights.I congratulate Alan on this work and hope to see more like it soon!Arie van Bennekumv PrefaceThis book is a critical analysis of the practice of risk management in agile softwaredevelopment projects. Risk, defined in terms of uncertainty relating to projectobjectives, is treated both as a threat and as an opportunity wherein the pitfalls andrewards that underpin project success lie. Although the agile community fre-quently cites risk management, research suggests that risk is often narrowlyframed and at best implicitly treated, which in turn leads to an inability to makeinformed decisions concerning risk and reward and a poor understanding aboutwhen to engage in risk-related activities. Moreover, the absence of reference toenterprise risk management means that project managers are unable to clearlyarticulate, scope or tailor their projects in line with the wider expectations of theorganisation.Yet the agile approach, with its rich toolset of techniques, is more thanequipped to effectively and efficiently deal with the risks that arise in projects. Inthis book we endeavour to address the above issues by proposing an agile riskmanagement process derived from classical risk management but adapted to thecircumstances of agile projects. We thus express the agile approach to risk man-agement and illustrate its application to selected methodologies (XP, Scrum andDSDM) chosen on account of their varying foci on the software developmentprocess and their attitudes towards risk. Though our interest lies in the softwaredevelopment process, much of what we say could be applied to other types of ITprojects.AudienceThis book is intended for those directly involved in agile software developmentwho share a concern for how risk should be managed. The primary interest groupsinclude project and risk managers, agile practitioners and general IT managers.Whilst we do not presume a thorough background in risk management, we doassume some basic level of familiarity with or exposure to agility. Where appro-priate we refer the reader to more detailed sources in the literature.vii OverviewWe begin in the chapter ‘‘Agile Software Development’’ with an initial survey ofagility focusing on those aspects that are of relevance later in the book and use thisopportunity to introduce our three main methodologies (i.e., XP, Scrum andDSDM). We characterize the cyclical nature of iterative development and incre-mental delivery in terms of agile charting (and related notions such as slicing,clock facing and escape velocity) and show how this tool can be used to facilitatecommunication and improve understanding within an agile team. We concludewith some remarks concerning the current state of agility and comment briefly onthe management perspective.In the ‘‘Project Risk Management’’ chapter we formally define project risk andconduct a comprehensive survey of project risk management as it is understood byrisk managers. We illustrate the consensus view by synthesizing best practices intoa generic model of project risk management before moving on to the notion ofenterprise risk management. In effect this sets the standard and defines the coreconcepts that agile risk management must embrace if we are to seriously apply riskmanagement in agile projects. The reader already familiar with the details ofproject risk management may choose to skim over this chapter.In the chapter ‘‘Agile Risk Management’’, we first explore how risk is perceivedand identify some of the shortcomings of agile methodologies before proposing anagile risk management process that is loosely based on traditional project riskmanagement, though we introduce a number of adaptations that make it moremeaningful in the context of agile projects. This process is concerned with how torisk scope a project and how to interpret this in the context of the wider riskenvironment by introducing the notion of a risk driver map. We then use agilecharting to explore how a methodology can be risk tailored at the project level. Inour treatment of risk management we explain a couple of techniques that can beused to identify risks during iteration planning and then go on to explain theoptions available to risk managers and the principles that underpin them. Weintroduce a number of tools such as a risk list and show how risks can be treatedwith a combination of risk tasking, risk techniqueing or contingency planning. Weshow how to make risks visible using a risk modified Kanban board and move onto describing a risk reporting technique using risk burndowns. We acknowledgethe systemic nature of risk, iteration residual risk, and how to measure theeffectiveness of risk management in terms of the iteration residual risk ratio.In ‘‘Applying Agile Risk Management’’ we illustrate the application of the agilerisk management process to our chosen methodologies. We critically review eachmethodology and describe its chief characteristics and level of maturity in relationto risk. From there we offer concrete advice and guidance on how to conduct riskmanagement and relate our suggestions to existing artefacts and practices foundwithin the respective methodologies.Our final chapter on ‘‘Enterprise Agility’’ notes the rise of frameworks(including DAD and SAFe) that attempt to scale agile practices to the enterpriseviiiPreface and we evaluate their contribution to agile risk management. We note an absenceof reference to enterprise risk management though there are indications of agrowing awareness and maturity.TerminologyThroughout we strive towards simplicity, clarity and neutrality in our use of ter-minology and for reasons of personal taste we often prefer the term ‘‘agility’’ over‘‘agile’’ (e.g., ‘‘enterprise agility’’ rather than ‘‘enterprise agile’’). We seek to useneutral language that is already widely accepted or understood within the agilecommunity. Thus we refer to ‘‘daily stand-ups’’ (rather than the more methodo-logically specific ‘‘Daily Scrum’’), ‘‘Kanban (board)’’ (rather than ‘‘Scrum-ban’’)and ‘‘backlog’’ (rather than the ‘‘product/Sprint backlog’’ of Scrum or the ‘‘pri-oritized requirements list’’ of DSDM). We trust that the context will render clearwhat is meant by our use of the terms and that no bias towards a specific meth-odology be inferred through our choice of nomenclature. Needless to say someterms are simply applied differently according to methodology so that although weuse ‘‘iteration’’ in the manner already defined earlier, we appreciate that this termis used in a broader sense in Scrum and a narrower sense in DSDM. Instead werespect our mutual differences and endeavour to make our language more precisewhere appropriate.AcknowledgmentsThough this book was born of efforts by the author to integrate risk managementpractices over a period of many years of setting up and working with agile pro-cesses, a truly deep understanding of how agility really works can only beachieved by working together with and learning from others. We would like toextend our thanks to all who directly or indirectly contributed to this book throughtheir discussions, feedback and comments and through the exchange of experi-ences based on mutual respect and tolerance. Special thanks is afforded to ourreviewers Scott Amber, Arie van Bennekum, Jutta Eckstein, Julia Godwin,Margaret Stewart and Patrick Verheij whose insightful remarks and commentshelped validate and clarify the ideas raised in this book. Finally, since nothingwould have been possible without the love and support of Helen, Markus andPatrick it is to them that I owe an unrepayable debt!Prefaceix ContentsAgile Software Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Agile Defined. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Iterations and Increments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Agility in Practice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Comparing Methodologies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Agile Charting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .State of Agility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Management Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Concluding Remarks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1135710131416Project Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Definition of Risk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Cultural Attitudes to Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Synthesis of Risk Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Initiation and Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Risk Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Risk Assessment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Risk Treatment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Risk Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Risk Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Enterprise Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1717182122242527293030Agile Risk Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Agility and Risk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Why Risk Management Matters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Agile Risk Management Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Project Context and Risk Environment . . . . . . . . . . . . . . . . . . . . . . .Risk Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Risk Tailoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Risk Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Concluding Remarks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3333363738393942444560xi Applying Agile Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . .General Advice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .eXtreme Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Methodology Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Agile Charting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Risk Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Risk Tailoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Risk Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Methodology Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Agile Charting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Risk Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Risk Tailoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Risk Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Dynamic Systems Development Method . . . . . . . . . . . . . . . . . . . . . . . .Methodology Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Agile Charting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Risk Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Risk Tailoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Risk Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Concluding Remarks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .616163636466666869707072737575767777798181838385Enterprise Agility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Scrum of Scrums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Dynamic Systems Development Method . . . . . . . . . . . . . . . . . . . . . . . .Disciplined Agile Delivery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Scaled Agile Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Concluding Remarks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87878990919394Appendix A: Agile Techniques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97xiiContents Agile Software DevelopmentAbstract Looking back at the origins of agile software development we provide anoverviewofitsuniqueblendofsupplepracticesandvividculturalfacetsthatcontrastso sharply with the plan-driven world of Waterfall methodologies. We discuss theiterative and incremental nature of agility and introduce a tool, agile charting, thatcan be used to facilitate communication within agile teams. Against this backdropwe introduce and compare the three methodologies (i.e., XP, Scrum and DSDM)used throughout this book to illustrate our application of agile risk management. Weconclude with a glimpse at the state of affairs of agility today and at the managementperspective on agile project management thereby setting the tone for the remainderof the book.Agile DefinedAgility, as a concept, came to prominence in the late 1990s through the endeavoursto address perceived difficulties with existing software development processes thatwere rooted in, and owed their rigidity to, plan-driven practices. Advocates of agilitypromotedthenotionthatprojectuncertaintiesshouldbeembracedandsoughttobal-ance planning and control with execution and feedback. Accordingly, agile projectsexhibit features of open communication amongst heterogeneous stakeholders, emer-gent behaviour within self-organizing teams and a culture of openness and learning(Cockburn 2007). Central to agile software development are the notions of iterativedevelopment and incremental delivery based on shared values enshrined in the agilemanifesto reproduced here for convenience.A. Moran, Agile Risk Management, SpringerBriefs in Computer Science,DOI: 10.1007/978-3-319-05008-9_1, © The Author(s) 20141 2Agile Software DevelopmentWe 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 toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more.(Beek et al. 2001a).This manifesto expresses the beliefs that interactions amongst project team mem-bers and their customers should underpin efforts to create working software in aflexible manner. Equally important are the twelve principles (Beck et al. 2001b) thatemphasize continuous delivery, an attitude of embracing change, frequent deliveryof functional components, daily interaction with business stakeholders, empower-ment through trust and support, direct communication, measurement of progressthrough functional software, sustainability, continuous excellence of design, sim-plicitythroughminimalism,self-organizationandteamreflection.Agilityisasmucha cultural stance on the process of software development, as it is a set of practicesand values. The discipline and focus needed to practice agility is frequently under-estimated (Boehm and Turner 2009) and has even been famously described as “hardand disruptive” (Schwaber 2006) by one of its leading proponents.Agility embodies a rich texture of humanist (e.g., cognitive, social and interper-sonal), organizational (e.g., managerial and cultural) and technological (e.g., practi-cal and technical aspects) traditions (Hazzan and Dublinsky 2008) and there alreadyexistsamaturebodyofliteratureconcerningbothitsculture(Cockburn2007)anditspractices (Coplien and Harrison 2005; Cohn 2010; Derby and Larsen 2009). Thereare numerous comparative surveys of agile methodologies (Larman 2003; Boehmand Turner 2009; Cockburn 2007) that highlight both the commonality rooted in themanifesto(anditsprinciples)togetherwiththeuniquenessoffocusandpurposewithwhich each approach is endowed. It is not our purpose to explore the fine detail of allthese methodologies, but rather we limit ourselves to a detailed discussion of threepopular approaches (XP, Scrum and DSDM1) and to the techniques they employ.For convenience, the techniques are described in Appendix A and we encouragethe reader to refer to this list when we mention a specific technique (e.g., Kanban2boards,burndowncharts).Throughoutthisbookweusethetermmethodologytorefera “system of methods and principles used in a particular discipline” (McKeown andHolmes 2009) consistent with the notion that it embodies not only practices but alsoprinciples, roles, artefacts and phases. We refer the interested reader to (Cockburn2007) for a detailed discussion of this topic.1Throughout this work when mentioning DSDM we will invariably be also referring to its projectmanagementcousin,AgilePM®,developedbytheDSDMConsortiumandaccreditedbytheAPMGInternational™.2Throughoutthisbookwhenwemention“Kanban”weusuallymeanjusttheboardbasedtechnique.Kanban in the wider sense is, however, a methodology in its own right. Agile Defined3Fig. 1 Agile Timeline. Adapted from (Agile Alliance 2013). Published with kind permission of© Alan Moran 2013. All Rights ReservedThe origins of agility are rooted in part in the Japanese manufacturing and indus-trial sectors to which many an agile concept owes its heritage. These include thevisual control concept found in the Toyota Production System that later anticipatedagile information radiators, the Kanban charts used in agile task assignment andtracking, and the continual influence of lean thinking on agility today (Poppendieckand Poppendieck 2003). The synthesis of Eastern and Western thinking so persua-sively laid out in (Takeuchi and Nonaka 2013), from the authors that introduced theterm “Scrum”, reflects the spirit in which the agile manifesto itself was conceived.The timeline depicted in Fig.1 marks out some of the key elements of relevance tothis book3and is adapted and extended from (Agile Alliance 2013).Iterations and IncrementsFrom its earliest inception, agility was understood as more of an evolution ratherthan a revolution. Its present day form is heavily influenced by the school of iterativedevelopmentandincrementaldeliverythatwasbythe1980salreadywellestablished.Indeed movements such as Rapid Application Development and the IBM RationalUnified Process gave birth to their modern day agile counterparts in the form ofDynamic Systems Development Method and Agile Unified Process respectively.Embedded in all of these is the notion of the Software Development Lifecycle4(SDLC) which refers to a generic model of software development comprising ofphasesbroadlydividedintothesolicitingandmanagementofrequirements,technicalanalysisanddesign,implementationofsoftwaresolutions,validationandverification3Our timeline omits many significant events to which we refer the interested reader to (AgileAlliance 2013).4The term Systems Development Lifecycle is also in widespread use. 4Agile Software DevelopmentFig.2 MetaphorfortheIterativeEvolutionofaSolution.Publishedwithkindpermissionof©AlanMoran 2013. All Rights Reservedof software artefacts and concludes with the deployment and maintenance of thesoftware solution. Implementations of the SDLC vary from the Waterfall model(Benington 1983; Royce 1970), that advocates transition through the model in termsofastrictlylinearprocesswitheachphasebeingcommencedonlywhenthepreviousphase is complete, to the agile approach that promotes rapid and repeated transitionsthrough all phases (some of which could even be said to be merged) resulting in theiterative derivation of a solution. It is interesting to note that the Waterfall method,which was adapted from the manufacturing industry, brought with it the assumptionthatchangeslateinthedevelopment processwereprohibitivelycostly.Thishasbeenrigorously challenged by agilists who argue that postponement of design decisionsuntil sufficient information is available is possible and endorse practices such asrefactoring5to cope with change. Between these the two viewpoints of Waterfalland agility, which were conceived approximately three decades apart, can be found aplethoraofvariantscomprisingofbothplan-drivenandhumanisticinfluences.Indeedagility finds itself today in a continual state of evolution with latter day influencesemerging once again from industry in the form of lean development practices asdescribed in (Poppendieck and Poppendieck 2003). The iterative and incrementalpractices,atopofwhichagilityisbuilt,laidthefoundationsforfeedbackmechanismsused to cope with change that have become the hallmark of agility.For the purposes of this book, iterative development refers to the traversal of theentire software development lifecycle with the aim of producing a self-contained,tested and partially functional product within a fixed timeframe. During successiveiterations the product is further refined thereby enabling lessons learned from earlieriterations to be fed back into the process. Incremental delivery refers to the pack-aging and deployment of a product artefact that can be meaningfully used by thecustomer. Typically an increment will require several iterations to complete and sev-eral increments are necessary before the final product is delivered. Borrowing froma metaphor appearing in (Patton 2008) Fig.2 describes the iterative manner in whichan artefact evolves. Though the general idea is clear from the outset, details emergegradually over time allowing participants to incorporate feedback back into the pro-duction process. At each stage there is a gaining of understanding and an adding ofdetail which can be clearly demonstrated and delivered to the customer.5We remind the reader to refer to Appendix A for a definition of this and other agile techniques. Iterations and Increments5Somemethodologies,notablyScrum,mergethesetwoconceptsintoonereferringto the process of “iterative and incremental development” (Schwaber 2004). Thusconsistentwithourviewofiterativedevelopment,JeffSutherland,aleadingadvocateof Scrum, describes iteration as the act of traversal of the whole during each pass ofwhichtheproductgraduallycomesintofocus.Forhimincrementsareconcernedwiththe notion that “incremental development is iterating on the whole thing” and thateach iteration should conclude with a “minimal useable feature set that is potentiallyshippable” indicating that this implies that code must satisfy the following definitionof done for the incrementthoroughlytested,well-structuredandwell-writtencodethathasbeenbuiltintoanexecutableand that the user operation of the functionality is documented, either in Help files or in userdocumentation (Schwaber 2004).though he later concedes that he “could have been clearer on what ‘potential ship-pable software’ means” (Sutherland 2010). There is thus a suggestion that incre-mental activity embodies the characteristics of a deployable artefact though Scrumleans towards the use of this term in the substantive rather than adjectival form e.g.,each iteration “delivers a fully functional increment” (Sutherland 2010). In essenceour use of the term, increment, reflects a conceptual designation that implies thepotential release of a deployment artefact. In reality there is little consensus in theagile community concerning the precise definition of an increment or indeed wherethe boundaries of agility lie. For example, owing to the structure of most organiza-tions, it ought not be assumed that a product development team has full control overthe means of deployment or of the dissemination of documentation (e.g., corporatedesign,accessibility).Moreover,itisordinarilythecasethatsomedeploymentactiv-ities (e.g., training of users and service desk staff) are assumed by people outsideof the project team. Whilst product focused methodologies (e.g., XP and Scrum)rarely consider what happens to the deliverable, other methodologies (e.g., DSDM,DAD,SAFe)consideritwithintheirremittomanagetheentiredeliveryprocessfrominception to transition. Accordingly, we allow ourselves to make this important con-ceptual distinction between these two related but different activities but accept thatthe terms iteration and increment will have their own connotations within specificmethodologies.Agility in PracticeAgileteamstendtobesmall6comprisingofheterogeneous“generalizingspecialists”(Ambler 2003) capable of engaging in several distinct types of work (e.g., analysis,development, testing). Customer representatives are expected to be highly engaged,attendplanninganddemonstration events andbeavailable onshortnoticeshouldthesolution team require their input. In this context the acronym CRACK,7first coined6Team sizes are consistently recommended to be in the range 7 ± 2 (Miller 1956).7Collaborative, Representative, Authorized, Committed and Knowledgeable. 6Agile Software Developmentin (Boehm and Turner 2009), sets the tone for what is expected of such representa-tives. This is in stark contrast to pre-agile approaches where business and develop-ment teams tended to be separated with relatively little contact beyond exchange ofrequirements and specifications. Agile methodologies employ a wide range of tech-niques and there is considerable overlap amongst the common methodologies bothin their interpretation and their application of them. Some of these practices workwell in concert (e.g., refactoring and continuous integration) whilst others mightbe considered complementary approaches to tackling a problem (e.g., modellingand prototyping). There does appear, however, to be a core set of practices that areused by most agile teams (which we see later comprises of daily stand-ups, iterationand release planning, unit testing, retrospectives, continuous integration, automatedbuilds and burndown charting) and enjoy a common interpretation, though the pre-cise wording may vary by methodology. Thus whilst it is true that all methodologiesbear their own interpretation of the agile manifesto, it is equally fair to say that theyborrow heavily from each other.Generallyspeakingateammustbalancetheneedforadaptation(e.g.,innovation)against the necessity of optimization. This suggests that lightweight methodologiesservice high adaptation and low optimization environments better, whereas heaviermethodologies are to be found in low adaptation and high optimization contexts(Cockburn 2007). It ought to be noted, however, that an enterprise typically requiresboth.Indeedithasbeenarguedthatthestabilityprovidedbyamatureprocessorientedorganization creates the necessary conditions for an innovative agile environment toflourish (Stephen et al. 2011)—a view that is perhaps at odds with the acceptedwisdom within agile communities.Agilepracticesarebestunderstoodatthedaily,iterativeandincrementallevelsforwhich we will later introduce the agile charting tool (the curious can take a glance atFig.4 for details). A typical agile day begins with a stand-up meeting of the projectteam members. During the day code may be integrated into a shared repositoryperhaps using continuous integration practices thereby ensuring a tight feedbackloop (e.g., unit testing may be performed as part of the integration thus providing anearly warning system for developers). At the end of each day a complete build anddeployment may be performed to assess the stability and readiness of the code aswell as demonstrating working software. Technical practices performed on a dailybasis tend to be highly automated (e.g., continuous integration).Each iteration begins with a...

关注我们

关注微信公众号