Bibliography - Springer978-3-319-05155-0/1.pdf · Bibliography All URLs checked January 2014....
Transcript of Bibliography - Springer978-3-319-05155-0/1.pdf · Bibliography All URLs checked January 2014....
Bi
[AgileAg
[AgileAg
[AmblSc
[AmblScco
[AmblScat
[AmblSced
[AmblScco
[AnanBa
[BasiliViDepa
[Beck Keed
[Beck Ke
[Beck KeAd
[BoehmBa
B. Meye© Sprin
bliography
All URLs checked January 2014.
2001]ile Manifesto, at agilemanifesto.org. 2011]ile Alliance: Velocity page at guide.agilealliance.org/guide/velocity.html, 2011.
er 2006]ott Ambler: Agile Adoption Rate Survey, at www.ambysoft.com/surveys/agileMarch2006.html. er 2001]ott W. Ambler: Agile Modeling and the Rational Unified Process (RUP), at www.agilemodeling. m/essays/agileModelingRUP.htm (part of Ambler’s “agile modeling” site), 2001.er 2010]ott W. Ambler: The Agile Maturity Model (AMM), in Dr. Dobbs Journal, April 2010, available www.drdobbs.com/architecture-and-design/the-agile-maturity-model-amm/224201005.er 2012]ott W. Ambler and Matthew Holitza: Agile for Dummies, Wiley, 2012. See also “IBM limited ition” available online at www-01.ibm.com/software/rational/agile/agilesoftware.er testing]ott W. Ambler: Agile Testing and Quality Strategies: Discipline Over Rhetoric, at www.ambysoft. m/essays/agileTesting.html#AgileTestingStrategies, undated.d site]chan Anand: Conscires site at agile.conscires.com. 1975]ctor R. Basili and Albert J. Turner: Iterative Enhancement: A Practical Technique for Software velopment, IEEE Transactions on Software Engineering, vol. SE-1, no. 4, December 1975, ges 390-396, available at www.cs.umd.edu/~basili/publications/journals/J04.pdf.2000]nt Beck: Extreme Programming Explained — Embrace Change, Addison-Wesley, 2000. (First ition; see also [Beck 2005].)2003]nt Beck: Test-Driven Development — By Example, Addison-Wesley, 2003.2005]nt Beck, with Cynthia Andres: Extreme Programming Explained — Embrace Change,, dison-Wesley, 2005. (Second edition; see also [Beck 2000].)
1981]rry W. Boehm: Software Engineering Economics, Prentice Hall, 1981.
r, Agile!, DOI 10.1007/978-3-319-05155-0, ger International Publishing Switzerland 2014
156
[BoehmBaAd
[BrookFr
[ChromCh
[CMMCMbeIn
[CockbAlCo
[CockbAl
[CockbAlali
[CockbAlAd
[CockbAlalibo
[CohnMco
[CohnM
[CohnM-d
[CohnM
[CohnMso
[CohnM
[CollaCo
[Cox 1Br
BIBLIOGRAPHY §
2004]rry W. Boehm & Richard Turner: Balancing Agility and Discipline – A Guide for the Perplexed, dison-Wesley, 2004.s 1975]
ed Brooks: The Mythical Man-Month, Addison-Wesley, 1975.atic 2003]
romatic: Extreme Programming Pocket Guide, O’Reilly, 2003.I 2010]MI Product Team: CMMI for Development, Version 1.3, Improving processes for developing
tter products and services, Technical Report CMU/SEI-2010-TR-033, Software Engineering stitute, November 2010, available at www.sei.cmu.edu/reports/10tr033.pdf.urn 2001]
istair Cockburn and Jim Highsmith: Agile Software Development: The People Factor, in mputer (IEEE), vol. 34, no. 11, November 2001, pages 131-133.urn 2001a]
istair Cockburn: Agile Software Development, Addison-Wesley, 2001.urn 2003]
istair Cockburn: The cone of silence and related project management strategies, online article at stair.cockburn.us/The+cone+of+silence+and+related+project+management+strategies, 2003.urn 2005]
istair Cockburn: Crystal Clear — A Human-Powered Methodology for Small Teams, dison-Wesley, 2005.urn 2010]
istair Cockburn: Vid of Alistair describing Shu Ha Ri, video lecture, 7 July 2010, available at stair.cockburn.us/Vid+of+Alistair+describing+Shu+Ha+Ri. See explanatory text (from 2001 ok) at alistair.cockburn.us/Vid+of+Alistair+describing+Shu+Ha+Ri. 2003] ike Cohn: The Need for Agile Project Management, online article at www.mountaingoatsoftware. m/articles/the-need-for-agile-project-management. 2006]ike Cohn: Agile Estimating and Planning, Addison-Wesley, 2006. 2009]ike Cohn: Intentional Yet Emergent, online article at www.mountaingoatsoftware.com/blog/agile esign-intentional-yet-emergent, 4 December 2009. 2010]ike Cohn: Succeeding With Agile, Addison-Wesley, 2010. 2010a]ike Cohn: The Role of Leaders on a Self-Organizing Team, online article at www.mountaingoat ftware.com/blog/the-role-of-leaders-on-a-self-organizing-team, 7 January 2010. site]ike Cohn: Succeeding With Agile site, www.mountaingoatsoftware.com.bnet site]llabnet Scrum Methodology site, at scrummethodology.com.
996]ad Cox: Superdistribution: Objects as Property on the Electronic Frontier, Addison Wesley. 1996.§
[CunnWat
[CusumMSoSc
[DeMaToDo
[DeMaToHo
[DemiW
[DennStma
[DerbyEsm/
[DhawKrEn
[DijksEdno
[EvansErAd
[EveleJ. SoBu[G
[GammErRe
[FowleM
[GhezzCaEd
[GlassRoCo
157
ingham 2004]ard Cunningham (interviewed by Bill Venners): The Simplest Thing that Could Possibly Work, www.artima.com/intv/simplest.html.
ano 1995]ichael A. Cusumano and Richard W. Selby, Microsoft Secrets: How the World’s Most Powerful ftware Company Creates Technology, Shapes Markets and Manages People, Simon and huster, 1995rco 1999]m DeMarco and Tim Lister: Peopleware: Productive Projects and Teams (Second Edition), rset House, 1999. (First edition was published in 1987.)rco 2001]m DeMarco: Slack: Getting Past Burnout, Busywork and the Myth of Total Efficiency, Dorset use, 2001.
ng 1966]. Edwards Deming: Some Theory of Sampling, 1966, reprinted by Dover Publications, 2010.ing 2012]eve Denning: The Case Against Agile: Ten Perennial Management Objections, in Forbesgazine, 17 April 2012, at onforb.es/HQ8i6J. 2011]ther Derby: Misconceptions about Self-Organizing Teams, online article at www.estherderby.co 2011/07/misconceptions-about-self-organizing-teams-2.html, 19 July 2011.an 2008]ishankumar Dhawan, Geste Kopfschuetteln Indien (Indian head-nodding), YouTube video (in glish), 30 June 2008, , at bit.ly/dmIoGj (short for www.youtube.com/watch?v=3hCV2oO2akw).
tra 1968]sger W. Dijkstra: Go To Statement Considered Harmful, Communications of the ACM, vol. 11, . 3, March 1968, pages 147-148. 2003]ic Evans: Domain-Driven Design: Tackling Complexity in the Heart of Software, dison-Wesley, 2003.
ens 2010]Laurens Eveleens and Chris Verhoef: The Rise and Fall of the Chaos Report Figures, in IEEE ftware, vol. 27, no. 1, Jan-Feb 2010, pages 30-36. See also S. Aidane, The “Chaos Report” Myth sters, 26 March 2010, www.guerrillaprojectmanagement.com/the-chaos-report-myth-busters, and lass 2006].a 1994]
ich Gamma, Richard Helm, Ralph Johnson and John Vlissides: Design Patterns: Elements of usable Object-Oriented Software, Addison-Wesley, 1994.r 1999]
artin Fowler: Refactoring: Improving the design of existing code, Addison Wesley, 1999.i 2002]rlo Ghezzi, Mehdi Jazayeri, Dino Mandrioli: Fundamentals of Software Engineering. 2nd
ition. Prentice Hall, 2002. 2006]
bert L. Glass: The Standish Report: Does it Really Describe a Software Crisis?, in mmunications of the ACM, vol. 49, no. 8, pages 15-16, August 2006.158
[GlazeHiNoww
[GualtMat
[HadamJaPr
[HalliwLuco
[HumpW20
[IBM IBww
[IEEEIE19
[JacobIvAd
[JacksMan
[JacksMAd
[JacobIvAd
[JeffrieRoAd
[JeffrieRo
[KnibeHe
[Kraft PhUn
[LarmCran
BIBLIOGRAPHY §
r 2008]llel Glazer, Jeff Dalton, David Anderson, Mike Konrad and Sandy Shrum: CMMI or Agile: Why t Embrace Both!, Technical Note CMU/SEI-2008-TN-003, November 2008, available at w.sei.cmu.edu/library/abstracts/reports/08tn003.cfm.
ieri 2011]ike Gualtieri: Agile Software Is A Cop-Out; Here’s What’s Next, blog article, 12 October 2011, blogs.forrester.com/mike_gualtieri/11-10-12-agile_software_is_a_cop_out_heres_whats_next.
ard 1945]cques Hadamard: Psychology of Invention in the Mathematical Field, Princeton University ess, 1945
ell 2008]ke Halliwell: The Agile Disease, blog article, 16 November 2008, at lukehalliwell.wordpress. m/2008/11/16/the-agile-disease.hrey 2005]
atts S. Humphrey: PSP: A Self-Improvement Process for Software Engineers, Addison-Wesley, 05.2012]M-sponsored study by Project At Work: Agile Maturity Report, 2012, available online at w-01.ibm.com/software/rational/agile/agilesoftware.
1998]EE: Standard 830-1998, Recommended Practice for Software Requirements Specifications, 98, available (for a fee) at standards.ieee.org/findstds/standard/830-1998.html.son 1992]ar Jacobson: Object Oriented Software Engineering: A Use Case Driven Approach, dison-Wesley, 1992.
on 1995]ichael Jackson: Software Requirements and Specifications: A Lexicon of Practice, Principles d Prejudices, Addison Wesley / ACM Press, 1995.on 2000]ichael Jackson: Problem Frames: : Analysing & Structuring Software Development Problems, dison-Wesley, 2000.
son 1992]ar Jacobson: Object-Oriented Software Engineering: A Use Case DrivenApproach, dison-Wesley, 1992.s 2001]n Jeffries, Ann Anderson and Chet Hendrickson: Extreme Programming Installed, dison-Wesley, 2001.s site]n Jeffries: Xprogramming site at xprogramming.com. rg 2010]nrik Kniberg and Mattias Skarin: Kanban and Scrum — Making the Most of Both, InfoQ, 2010.1977]ilip Kraft: Programmers and Managers: The Routinization of Computer Programming in the ited States, Springer Verlag, 1977.
an 2010]
aig Larman and Bas Vodde: Practices for Scaling Lean & Agile Development: Large, Multisite, d Offshore Product Development with Large-Scale Scrum, Addison-Wesley, 2010.§
[LeffinDePr
[Lutz 1RoISww
[MadeLeSp
[MarkDaww
[MartiAnVi
[McBrPe
[McCoSte
[McCrDaSI
[MeyeBe
[MeyeBeCo
[MeyeBe
[MeyeBeAC
[MeyeBeSp
[MeyeBethase
[MeyeBeat
[MeyeBebe
159
gwell 2011]an Leffingwell: Agile Software Requirements — Lean Requirements Practices for Teams, ograms, and the Enterprise, Addison-Wesley, 2011.993]byn Lutz: Analyzing Software Requirements Errors in Safety-Critical, Embedded Systems, in
RE 93 (Proc. Int. Symposium on Requirements Engineering), IEEE, 1993, also available at w.cs.iastate.edu/%7Erlutz/publications/isre93.ps.
yski 2010]ch Madeyski: Test-Driven Development – An Empirical Development of Agile Practice, ringer Verlag, 2010.ham 2010]niel Markham: Agile Ruined My Life, blog article, 7 September 2010, available at w.whattofix.com/blog/archives/2010/09/agile-ruined-my.php.
n 2009]gela Michele Martin: The Role of Customers in Extreme Programming Projects, PhD thesis,
ctoria University of Wellington, New Zealand, 2009.een 2002]te McBreen: Questioning Extreme Programming, Pearson Education, 2002.nnell 2006]ve McConnell: Software Estimation: Demystifying the Black Art, Microsoft Press, 2006.
acken 1982]niel D. McCracken and Michael A. Jackson: Life cycle concept considered harmful, in ACM
GSOFT Software Engineering Notes, vol. 7, no. 2, April 1982, pages 29-32.r 1988] rtrand Meyer: Object-Oriented Software Construction (first edition), Prentice Hall, 1988.r 1995]rtrand Meyer: Object Success: A Manager’s Guide to Object Orientation, Its Impact on the rporation and its Use for Reengineering the Software Process, Prentice Hall, 1995.r 1997] rtrand Meyer: Object-Oriented Software Construction, second edition, Prentice Hall, 1997.r 2008]rtrand Meyer: Design and Code Reviews in the Age of the Internet, in Communications of the M, vol. 51, no. 9, September 2008, pages 66-71.
r 2009]rtrand Meyer: Touch of Class: Learning to Program Well, Using Objects and Contracts, ringer-Verlag, 2009.r 2009a]rtrand Meyer, Ilinca Ciupa, Andreas Leitner, Arno Fiva, Yi Wei and Emmanuel Stapf: Programs t Test Themselves, IEEE Computer, vol. 42, no. 9, September 2009, pages 46-55, available at
.ethz.ch/~meyer/publications/computer/test_themselves.pdf.r 2012]rtrand Meyer: A Fundamental Duality of Software Engineering, 14 October 2012, blog article bertrandmeyer.com/2012/10/14/a-fundamental-duality-of-software-engineering/.r 2013]
rtrand Meyer: Apocalypse no! (part 1, includes a link to part 2), 12 March 2013, blog article at rtrandmeyer.com/2013/03/12/apocalypse-no-part-1/.160
[MeyeBebe
[Mills HaDi
[MittaNizin
[Mob M
[MozilM
[MülleMpe
[NASAMat CN
[NATOPetheho
[NawrJeEu
[NonaIkCo
[ParnaDaIEav
[PfleegShEd
[PichleRo
[PoppeMww
[PoppeM
[PoppeM
BIBLIOGRAPHY §
r 2013a]rtrand Meyer: What is wrong with CMMI, 12 May 2013, blog article at rtrandmeyer.com/2013/05/12/what-is-wrong-with-cmmi/.1971]rlan D. Mills: Chief programmer teams, principles, and procedures, IBM Federal Systems vision Report FSC71-5108, Gaithersburg, 1971.l 2013]tin Mittal: Self-Organizing Teams: What and How, at scrumalliance.org/articles/466-selforgani g-teams-what-and-how, 7 January 2013.
site]ob Programming site, at mobprogramming.org.la modules]ozilla Modules and Module Owners, at www.mozilla.org/hacking/module-ownership.html.r 2005]atthias Müller: Two controlled experiments concerning the comparison of pair programming to er review, in Journal of Systems and Software 78, 2005, pages 166-179. 1999]
ars Climate Orbiter Mishap Investigation Board Phase I Report, 10 November 1999, available bit.ly/Ot7mJ8 (short for ftp.hq.nasa.gov/pub/pao/reports/1999/MCO_report.pdf). See also the N article at bit.ly/d51nla. 1968]
ter Naur and Brian Randell (eds): Software Engineering, Report on a Conference Sponsored by NATO Science Committee, Garmisch, Germany, 7-11 October 1968, republished in 2001 at mepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF.ocki 2001]rzy Nawrocki and Adam Wojciechowski: Experimental evaluation of pair programming, in ropean Software Control and Metrics (Escom), April 2001, pages 269-276.
ka 1995]ujiro Nonaka and Hirotaka Takeuchi: The Knowledge-Creating Company: How Japanese mpanies Create the Dynamics of Innovation, Oxford University Press, 1995.s 1986]vid L. Parnas and Paul C. Clements: A Rational Design Process: How and Why to Fake it, in EE Transactions on Software Engineering, vol. 12, no. 2, February 1986, pages 251-257, ailable at y.web.umkc.edu/yzheng/classes/doc/IEEE86_Parnas_Clement.pdf.er 2009]ari Lawrence Pfleeger and Joanne M. Atlee: Software Engineering: Theory and Practice. 4th
ition, Prentice Hall, 2009.r site]man Pichler Consulting: Scrum site at www.romanpichler.com.ndieck 2001]
ay Poppendieck: Lean Programming, in Dr Dobb’s, two-part article, 1 May and 1 June 2001, at w.drdobbs.com/lean-programming/184414734 and www.drdobbs.com/lean-programming/184414744.ndieck 2003]
ary and Tom Poppendieck: Lean Software Development — An Agile Toolkit, Addison-Wesley, 2003.
ndieck 2010]ary and Tom Poppendieck: Leading Lean Software Development, Addison-Wesley, 2010.
§
[PoppeM
[PoppeM
[ReeveJaco
[RoyceWW
[SchwKe
[SchwKe
[SchwKe
[SchwKeDe
[SchwThManvo
[ScrimJa
[ScrumSc
[ShoreJa
[ShoreJaco
[ShoreW
[SilverM20
[SobelDaPr
[StellmAn
[StephMAp
161
ndieck essays]ary Poppendieck, Lean Essays site, www.leanessays.com.ndieck lean]
ary and Tom Poppendieck: Lean Software Development site, www.poppendieck.com.s 1992-2005]
ck W. Reeves: What is Software Design?, in C++ Journal, Fall 1992, available with two mplementary essays (2005) at www.developerdotstar.com/mag/articles/reeves_design.html. 1970]
inston D. Royce: Managing the Development of Large Software Systems, in Proc. IEEE ESCON, 1970, pages 1-9, at www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf.aber 2002]n Schwaber and Mide Beedle: Agile Software Development with Scrum, Prentice Hall, 2002.
aber 2004]n Schwaber: Agile Project Management with Scrum, Microsoft Press, 2004.
aber 2004a]n Schwaber: Managing Agile Projects, Addison-Wesley, 2004.
aber 2012]n Schwaber and Jeff Sutherland: Software in 30 Days: How Agile Managers Beat the Odds, light Their Customers, And Leave Competitors In the Dust, Wiley, 2012.
eigert 2012]omas Schweigert, Risto Nevalainen, Detlef Vohwinkel, Morten Korsaa and Miklos Biro: Agile
aturity Model: Oxymoron or the Next Level of Understanding, in Software Process Improvement d Capability Determination (SPICE), Communications in Computer and Information Science l. 290, 2012, pages 289-294, at link.springer.com/chapter/10.1007%2F978-3-642-30439-2_34.shire site]mes Scrimshire: Hurricane Four site, hurricanefour.com. Alliance]
rum Alliance site at scrumalliance.org. 2008]mes Shore and Shane Warden: The Art of Agile Development, O'Reilly. 2008. 2008a]mes Shore: The Decline and Fall of Agile, blog article, 14 November 2008, at www.jamesshore. m/Blog/The-Decline-and-Fall-of-Agile.html. site]eb site for [Shore 2008] at jamesshore.com/Agile-Book. 2007]elanie Silver: Am I, or Am I Not, Using Scrum? That is the Question, Scrum Alliance site, 18 March 07, www.scrumalliance.org/articles/41-am-i-or-am-i-not-using-scrum-that-is-the-question. 2007]va Sobel: Longitude: The True Story of a Lone Genius Who Solved the Greatest Scientific oblem of His Time, Walker, 2007.an site]drew Stellman and Jennifer Greene: Building Better Software site, www.stellman-greene.com/.
ens 2003]
att Stephens & Doug Rosenberg: Extreme Programming Refactored: The Case Against XP, ress, 2003.162
[SurowJaCo
[SurowJaww
[SutheJeww
[SutheJeM20
[SutheJe
[SutheJeav
[WakeBi
[WallaDoAd
[WaterKe
[WeiseCoww
[WellsDo
[WenzJo
[WirthNi64
[YeggeStblo
[YourdEd
[Zave PaTOpa
[Zave Paa p
BIBLIOGRAPHY §
iecki 2004]mes Surowiecki: The Wisdom of Crowds: Why the Many Are Smarter Than the Few and How llective Wisdom Shapes Business, Economies, Societies and Nations, Knopf Doubleday, 2004.iecki 2013]
mes Surowiecki: Requiem For a Dreamliner, in the New Yorker, 4 February 2013, available at w.newyorker.com/talk/financial/2013/02/04/130204ta_talk_surowiecki.
rland 2009]ff Sutherland: Self-Organization: The Secret Sauce for Improving your Scrum Team, video at
w.youtube.com/watch?v=M1q6b9JI2Wc.rland 2010]ff Sutherland, Carsten Ruseng Jakobson and Kent Johnson: Scrum and CMMI Level 5: The agic Potion for Code Warriors, in Proc. 41st Hawaii Int. Conf. on System Sciences, 7-10 Jan. 08, at ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4439172&tag=1 (and bit.ly/17LZE2R).rland 2012]ff Sutherland, Rini van Solingen and Eelco Rustenberg: The Power of Scrum, CreateSpace, 2012.rland 2013]ff Sutherland: Scrum: The Art of Doing Twice the Work in Half the Time, tutorial notes, 2013, ailable at jeffsutherland.com/CSMjsv16.pdf. site]ll Wake: Exploring Extreme Programming site at xp123.com.ce 2002]ug Wallace, Isobel Raggett & Joel Aufgang: Extreme Programming for Web Projects, dison-Wesley, 2002.s site]lly Waters: All About Agile site, www.allaboutagile.com.rt 2010]nrad Weisert, Are Agile Methods and Reusable Components Incompatible?, online article at w.idinews.com/agileReUse.html.
site]n Wells: Extreme Programming site, www.extremeprogramming.org.
el site]el Wenzel, In Point Form site, joel.inpointform.net. 1995]klaus Wirth: A Plea for Lean Software, in IEEE Computer, Vol. 28, no. 2, February 1995, pages -68. 2006]
eve Yegge: Good Agile, Bad Agile, blog article, 27 September 2006, available at steve-yegge. gspot.com/2006/09/good-agile-bad-agile_27.html.on 2003] Yourdon: Death March, 2nd edition, Prentice Hall, 2003. (First edition published in 1997.)1997]mela Zave and Michael Jackson: Four dark corners of requirements engineering, in ACM SEM (Transactions on Software Engineering and Methodology), vol. 6, no. 1, January 1997,
ges 1-30.FAQ]
mela Zave, Feature Interaction FAQ, at www2.research.att.com/~pamela/faq.html, with links to age listing many publications on feature interaction.InIn the e
a priorisee a
abstractadditiveAffordaagile
and Cand dand r
cw
artifaasses
teassumbookclaimLuddManimethpract
amte
precaprinc
ooshte
rolesosese
transvalue
all-or-nAmbleranecdot
see aanti-patApacheAPI 10approva
dexlectronic version, clicking a page number will take you to the corresponding occurrence.
A, a posteriori 113lso dual developmentness 49, see under complexityble Care Act (Obamacare) 61
MMI 46-47esign 39-41equirements 32-37hange criticism 35aste criticism 33-34cts 10-12, 117-131sment xi-xii, 12-15, 145, 149-154chniques xi-xiiptions 2-4
s 133, 136-139s 28-30ite tendencies 131festo 1-2, 5, 7, 50, 66, 68, 91, 97, 135, 140ods 2, 133-143ices 8-10, 89-115lso called “ceremonies” in Scrum 89anagerial 89-102chnical 103-115utions in reading agile texts 17-30iples 4-7, 49-78fficial 5, 50-51rganizational 5, 51-69ould be prescriptive 49chnical 6-7, 70-78 7, 79-87nly three in Scrum 80e manager, product owner, scrum master, teamparation 86-87
ition 145-147s 2-4othing ix, 22, 27, Scott W. 43, 47, 118, 145e viii, xi-xii, 17-22, 54, 57, 61, 119, 135-136lso under prooftern 110 101
separate from arousal 106-107architecture 3-4, 9, 14, 19, 21, 31, 33, 35-41, 43,
46, 50, 54, 56, 59-62, 66-67, 69-70, 74-75, 82, 86, 97, 100, 109-114, 120-121, 125, 129-130, 135-138, 149, 152-154associated with “design” 37
Aristotle xiArmstrong, Lance 22, 135-136arousal
separate from approval 106-107artifact, see under agileassertion 118assessment
in CMMI 44-45of the agile approach, see assessment under agile
Atlee, Joanne M. 32
Bbachelor’s degree 47backlog 80-81, 89, 98, 117, 126-129balance point 27-28Basili, Victor R. 70Baudoin, Claude xiiiBeck, Kent xiii, 26, 32-33, 35, 52-53, 58, 60, 77, 94,
101, 104-107, 109-111, 113-114, 117, 123, 125, 137-138, 146-147
Beedle, Mike xiiiBerkeley Unix 108-109Big Bang approach to integration 72, 103, 105, 154Big Idea 133-134, 136-137, 139, 141Big Upfront, see upfront tasksBishop, Judith xiiibloat 58, 61, 135, 152blog xiiiboard (story board, task board) 10-12, 117, 127-128Boehm, Barry W. ix, xiii, 25, 31, 52, 62, 124, 145Boeing Dreamliner (787) 61booking.com 68Brecht, Bertolt 25bug, see defectbullpen 125
0l
burndown, burnup, see under chartBusiness Week 66
164
Calvin catastroceremocertificachange
see aas cricontrincidmust
cChaos rchart
burndburnudepeearneGant
chickenchief prChina SClausewClear, sClemenclosed-cloud-bcluster CMM, CMMI
75, and Ilevel
coach 7see a
Cockbu 81,
code 3 65- 122see aassoccentrdifferdifferinspeobjecowne
aa
reviesmelstand
Cohn, M 84,
INDEX
C 24phism 22, 26-27ny, Scrum name for practice 89tion (CMMI, Scrum) 45, 47, 84, 140
lso extendibilityticism of requirements 33, 35ol 101ental and essential 112 be accepted 4, 6, 35, 68-69, 90, 139-140, 154ontradiction with minimalism 69, 151eport 26-27
own 10-11, 117, 128-129p 128-129, 131
ndency 61, 129-131, 150d-value 131t, see dependency under chart 82, 139, 153ogrammer 86-87hop rule 104itz, Carl von 39
ee under Crystalts, Paul C. 39window rule 90-91, 139-140, 154ased tools 131 70see CMMI(Capability Maturity Model Integration) 43-47, 99, 141ndia 45s 44-45, 47, 29, 55, 84-87, 99, 151
lso Master under Scrumrn, Alistair xiii, 21, 26, 47, 56-57, 60, 73-74, 96-97, 101, 108, 125, 130, 141-4, 6, 9-10, 13, 15, 35-39, 46, 57-58, 60-61, 66, 69-70, 77, 100-107, 109-115, 117-118, , 125, 129-130, 135, 137-138, 151-153lso implementationiated with tests 118al role 4, 15, 39, 60, 117, 129ence with documentation 37-39ence with “implementation” 37ction xii, 13, 107, 138, 152t-oriented 69rship 8-9, 100-102, 138, 153
nd cross-functionality 102ssessment 100-102, 153w, see inspection under codel, see this termards 10, 109
collective code ownership, see ownership under codecologne, strong 106Columbus, Christopher 24
Columbus syndrome 24commit then review (CTR) 101communication
see documentation, verbal communicationcore, see core communicationosmotic, see osmotic communication
Communications of the ACM xiiicomplexity 120, 123
see also simplicityadditive and multiplicative 58, 63-65, 71, 100, 112,
150cone of uncertainty 124configuration management 35, 44-45, 76, 101, 104consumables 60, 65continuous integration viii, 8-9, 103-105, 118, 138,
154control
subtle, surreptitious, by love, see subtle controlcore communication 141core participant, see members and observers under teamcover-your-behind 22, 27-28creep, see under featurecross-functionality 81, 98, 102, 130, 153
and code ownership 102Crystal vii, ix-x, 2, 57, 97, 101, 125, 128, 131, 133,
141-143, 153assessment 142Clear 141principles 141
cubby 125cubicle 3, 57, 96
see also space under workingCunningham, Ward 59, 137customer xii, 2-7, 11, 13, 21, 33-36, 41, 50-53, 60-
62, 68, 70, 73, 75, 79-83, 90, 94-96, 99, 102, 119-120, 127, 129, 134-135, 137-138, 151-152, 154see also product ownerat the center 51-53embedded 53, 83, 86, 96, 151interaction 83onsite 83, 96, 151
Cusumano, Michael A. 14, 104CVS 104
Ddaily build 14, 72, 103-105
at Microsoft 104daily meeting 8, 15, 81-82, 84, 89, 91-93, 98, 140,
153
ike xiii, 17, 19-21, 32-33, 40, 54-55, 65, 78,91, 95, 122-124, 126, 130, 139also known as daily scrum 91also known as standup meeting 91
INDEX
threedaily ScDavid (death mdebt, sedefect
118class
defineddefinitiDelphi DeMarcDemingDenninDepartmdepend
chartDerby, design
see adifferpatteseparsmelupfro
Design develop
distrido nodual,iterattest-d
DhawanDijkstraDijkstraDilbert Disneyldistribudocume
differversu
domainmodevs m
done, seDonizeDreyfusdual deDuboisDuluth dynami
Easiest egoless
165
questions 8, 91, 153rum, see daily meetingMichelangelo statue) 67arch 56e technical debtxiii, 6, 18, 44, 46, 64, 72, 75-76, 105, 110, , 126, 135ification 76 (CMMI level) 45on of done 71, 117, 123, 125, 140 95o, Tom 56, 58, W. Edwards 57
g, Steve 23-25ent of Defense 43, 45
ency 71, 99-100, 102, 104, 112, 129-131, see dependency under chartEsther 54, 56
lso architectureence with “architecture” 37
rns, see this termate from implementation? 37-39l, see this termnt, see upfront tasksby Contract x, 118mentbuted, see distributed under teamt start until all tests pass 76
see dual developmentive, see iterative developmentriven, test-first, see these terms, Krishankumar 20, Edsger W. xi, 38, 40, 67, 75. Edsger W. 77 3, 109and 23ted, see under teamntation 21, 27, 34-35, 38-39, 60, 123, 129ence with code 37-39s verbal communication 19-21
l 120-121, 150achine (in requirements) 36-37, 120, 150e definition of done
tti, Gaetano 107 model 47
velopment 28, 74, 113, 121, Paul xiii, 18 101c binding 69
E
Eiffel 118, 126Eiffel Software xiiiEinstein, Albert 24-25either-what-or-when x, 71, 146-147Emacs 108embedded, see under customerempirical software engineering viii-ix, xi-xiii, 25, 27,
29, 52, 58, 62, 105, 107-108ESEC (European Software Engineering Conference) 25essential change 112-113estimation 8, 58, 93-95, 98-99, 121-124, 130, 153Estler, Hans-Christian xiiiETH Zurich xiiieuro, scheduling of introduction 146Eveleens, J. Laurens 26Everest 73experience xiextendibility 5, 10, 13-14, 40, 59, 68-69, 75, 112,
151see also change
Extreme Programming vii, x, 1-3, 6-10, 13, 32, 53, 57-58, 60, 68, 73, 77, 83-84, 93-94, 96, 100-106, 108-110, 112-114, 117-118, 123-125, 133, 135, 137-139abbreviated as XP 2assessment 139books 137-138notion of simplicity 110, 135, 137
extremism, see all-or-nothing
FFacebook 69, 86falsification, falsifiability xi, 49, 77feature
creep 61, 77, 90, 100dependency, see this terminteraction 63-65
featurismcreeping, see creep under feature
Federal Aviation Administration 62fellow traveler, see members and observers under teamFibonacci sequence 94, 123flexible working schedules 92Forbes 23Ford, Henry 79formal methods 19-20, 39, 75, 154fox 133Freud, Sigmund 42function point 122
GGalileo Galilei xigame, see under planningGamma, Erich 38, 109, 112, 117
Thing First, Hardest Second 73 programming 109
Gantt chart, see dependency under chartgeneralization 109
166
genericGerstneGhezzi,GIGO (Git 104Glass, RGoogle
DocsGötterdgravity Gries, Dgummi Günthaguru 2gut feel
HadamhandovhardestHarrisoHawthohead nohedgehHighestHighsmHoare, Holitzahotel boHowardHumphHyatt 1hygiene
I MusicIBM 2ICSE
Engiimpedimimplem
97-9see adiffer“prodseparsepar
incidenIndia 1
and Cindividuinformainspectiintegratinteract
of fea
INDEX
ity 69r, Ralf xiii Carlo 32Garbage In, Garbage Out) 111
obert L. 26 14, 58, 86, 101 32ämmerung 30 145-146avid 67
bears 123rt, Claudia xiii3, 79ing xi
Hard, Jacques 39er 36 thing the team can succeed with 73n, John 24rne effect 29dding 20og 133 Business Value First 73-74ith, Jim 81C.A.R. 67, Matthew 145oking 17, 19, Mark xiiirey, Watts 467, personal 106
Ii 55-569, 42, 145-146( In te rna t iona l Confe rence on Sof tware neering) 25ent 8, 15, 68, 84, 91-92, 117, 129, 140, 153
entation 3, 9, 34, 36-37, 40-43, 82, 86, 89, 8, 120, 128, 149, 152
lso codeence with “code” 37uction” is a synonym 37ate from design? 37-39ate from requirements? 36tal change 112-1139-20, 45, 85, 87, 94MMI 45al code ownership, see ownership under codetion hiding 69on, see under codeion, see big bang, continuous integration
with customers 83International Standards Organization 43intimidation viii-ix, 22-26ISO standards 43Italy xi, 94iteration, see iterative development
backlog, see this termiterative development 2-3, 5-7, 9, 11, 13-15, 34, 40-
43, 51, 56, 65, 70-72, 74, 89-90, 94, 98-99, 103, 105, 111, 121, 123-124, 126-127, 135, 138-140, 149assessment 72-75freeze requirements during iterations 71-72
see also closed-window ruleiteration planning 98-99kinds 70-71length of iterations 71, 138, 154order of tasks 73-74working iterations 5-6, 14, 50-51, 60, 65, 70-75,
117, 135, 154
JJackson, Michael A. xiii, 36, 41-42Jacobson, Ivar xiii, 10, 119Jazayeri, Mehdi 32Jeffries, Ron 58-59, 83, 137Jobs, Steve 25, 66, 79Joy, Bill 108-109JUnit 76, 117
KKanban 4, 128, 133-134, 136, 146
board 136card 136
Kanban board 136Knuth, Donald Erwin 108-109Kolb, Peter xiiiKraft, Philip 57
LLa Fille du Régiment 107Larman, Craig xiii, 26, 32, 40, 84, 99, 108, 126, 139lasagne 63Lean Software vii, x, 2-3, 13-14, 27-28, 33, 46, 57,
67, 91, 119-120, 129, 133-136, 146assessment 135-136books 136
Leffingwell, Dean 31length of iterations, see under iterative developmentlifecycle 7, 31, 39, 41-43, 46, 68, 82
model 41-42, 82V-model 82
linguine 63, 71Linux 108-109
iontures, see interaction under feature
Lister, Tim 56LOC (line of code), see SLOC
INDEX
logical Louis Xlove, seLudditeLutz, R
machinmake (cmanagemanage
61-6 92, incomtechn
MandriManifemaster’mathemmaturit
for agMcBreeMcConMcCracmeetingmembe
see mmentor
differpro
methodsee mdefin
metho“me
Meyer,Meyer,Meyer,MichelaMickeyMicroso
ProjeMills, Hminiatuminima
artifaassescontrfunctnot thprodusoftw
minimaMitin, RMittal,
167
reasoning xiIV 42e subtle control 131obin 52
Me vs domain (in requirements) 36-37, 120onfiguration management tool) 38, 104d (CMMI level) 45r vii, x, 2-3, 5, 7, 13, 25, 28-29, 36, 53-56, 3, 68, 71-72, 74, 76, 79-81, 84-87, 89-90,
97, 104, 107-108, 123, 131, 135-136, 150petent 25, 29, 36, 68, 74, 97, 107
ical 87oli, Dino 32sto, Agile, see Manifesto under agiles degree 47atics, see formal methods
y model 43-47ile methods 47n, Pete ix, xiiinell, Steve 124, 145ken, Daniel D. 41-42, see daily meeting, retrospective review meeting
r (in meetings)embers and observers under team 7, 55, 107ence between mentoring and pair gramming 107
ethods under agileition of the term 133dology , compar i son of th i s t e rm wi th
thod” 133 Annie xiii Raphaël xiii Viktoria (no relation) xiiingelo (di Ludovico Buonarroti Simoni) 67 Mouse 23ft iv, 9, 14, 72, 86, 100, 104
ct 130-131arlan D. 86
re, see under processlcts 4, 51, 60sment of minimalism 61-67adiction with acceptance of change 69, 151ionality 4-5, 51, 58, 152e same as simple 66-67ct 4-5, 51, 58-60are 4-5, 10, 13, 51, 58-67lism, see minimal
mob programming 107model
domain, see model under domainlifecycle, see model under lifecyclematurity, see maturity model
Moltke, Marshall Helmuth von 35Morgan, Carroll xiiiMozilla 100MS-DOS 60Müller, Matthias 107multiplicative, see under complexity
Nnanny 79napkin, as a substitute for documentation 21Napoléon Bonaparte 97NASA 21, 52NATO 1968 conference 37Naur, Peter 37Nawrocki, Jerzy 107no estimates 107Nonaka, Ikujiro 54
OObamacare 61object-oriented programming 9-10, 37, 39, 69, 121-
122, 154agile criticism 69
Observer pattern 38-39observer (in meetings)
see members and observers under teamonsite customer 96OOPSLA conference 25open
room, see space under workingspace, see space under working
Oprah 62optimizing (CMMI level) 45, 141oracle 118order of tasks, see under iterative developmentosmotic communication 125, 141, 153ownership
code, see ownership under code
Ppace
sustainable, see sustainable pacepair programming xii, 8, 10, 13, 89, 96, 101, 105-
109, 138, 152assessment 13, 107-109, 152definition 106-107difference with mentoring 107
paper napkin, as a substitute for documentation 21Parnas, David L. 39, 67
oman xiiiNitin 55
partisanship viiipatterns, design viii, 37, 112, 154
168
see aObseVisit
PeopleWpersonaPersonaPfleegePhD dePiccionPichler,pig 82,plannin
gameiterat
mepoke
platitudpoker, spolymoPoppen
37, PowerPpracticepredicti
not thprescripprincipl
agiledefindiffer
processminiamode
productproduct
96, product
termsProgramprogramprogram
anarcchief
programsee aegoleextremob,objecpair, struc
proofby anby ci
PSP, se
INDEX
lso anti-patternrver 38or 37, 112
are 56-57, 126l safety 56-57l Software Process (PSP) 46-47, 107r, Shari Lawrence 32gree 47i, Marco xiii Roman 80 139, 153g viii, 8, 93-94, 121, 123, 153ion, see iteration planning under iterative develop-ntr 8, 93-95, 98, 121, 123, 153e 5, 49, 138ee under planningrphism 69dieck, Mary and Tom xiii, 22, 27-28, 33, 36-46, 58, 60, 65, 69, 81, 105, 119-120, 134-136oint 60s, see under agileve 31-32e same as waterfall 31tive principle 49e, see principles under agileition 49ence with a platitude 49
ture 97-98l, see CMMI backlog, see backlog owner 7, 53-54, 68, 80, 83, 86-87, 90, 95-98-99, 151, 154ion, see implementation used as synonyms 37 Design Language 39, see code, implementation, programmingmer
hy 107, see chief programmerming
lso design, architecture, code, implementationss 109me, see Extreme Programming see mob programmingt-oriented, see object-oriented programmingsee pair programmingtured, see structured programming
ecdote xi, 17-22
Qquantitatively managed (CMMI level) 45questions, see three questions under daily meeting
RRational Unified Process 42-43RCS 104Red Army 85Reeves, Jack W. 38refactoring 3, 8-9, 40, 60, 62, 72, 109-114, 130,
137-138, 149, 151, 153assessment 110-113covered in part by “generalization” 109definition 109-110must improve quality 110pattern 110
regression test suite 4, 35, 68, 75-77, 101, 103-105, 114, 117-118, 139
Reinertsen, Don 126requirements xii, 3-7, 9, 12-15, 17, 19-20, 27, 31-37,
43, 45, 49-53, 56, 60-62, 65-66, 68, 70-72, 77-78, 82-83, 91, 97, 109, 119-121, 123, 126-127, 135, 139, 149-152, 154see also specification, user storysee also user storyagile criticism 32-36as design or implementation 36-37as software 35as source of errors 52as waste 33domain
vs machine ??-39, 120domain vs machine 36-37elicitation 32techniques 32upfront, see upfront tasksworkshops 53
retrospective 9, 99, 141Return On Investment 3-5, 57, 77reusability, reuse 5, 10, 13, 40, 59, 112, 151review
see inspection under codemeeting 99review then commit (RTC) 101
rhetorical devices 17-30Rite of Spring 73ROI, see Return On Investmentroles, see under agileroom, see space under workingRosenberg, Doug ixRoyce, Winston D. 31RUP, see Rational Unified Process
tation 67e Personal Software Process
SSaint-Exupéry, Antoine de 66-67
INDEX
scenarioschedulSchwab
96, Schweiscope
creepScrimshScrum
45, 91-9 139AlliaassesbookdailyMast
99cin
of scscrumm
der SseamlessecuritySelby, Rself-orgseminarShu Haside-bySilicon simplic
see aas desimpsimp
61Skype slack 5slanderSLOC (Smacchsmell 1Sobel, Dsoftwar
compcrisisestimminim
Softwarsource,spaghetspeakinspecific
78,
169
, see use case, user storye, see iterative development, schedules under worker, Ken xiii, 22, 26, 30-31, 54, 57, 80-81, 84, 99-100, 139gert, Thomas 47
, see creep under featureire, James 85-86
vii, x, xiii, 2-3, 6-8, 15, 22, 26, 28, 31, 42, 47, 53-54, 57, 63, 68, 71-72, 74, 79-87, 89, 4, 98-100, 103, 124-127, 129, 133, 136-137,
-140, 146, 151nce 29, 139-140sment 139-140s 139, see daily meetinger xiii, 7, 47, 53, 57, 79-81, 84, 86-87, 92, , 129, 139, 151
ertified xiii, 84 vacation 57
rums 99-100aster, Scrummaster, ScrumMaster, see Master un-crums development 39 40, 42ichard W. 14, 104
anizing team, see self-organizing under teamist 17-21 Ri (or Shuhari) 47-side programming 108Valley 126ity 50, 58, 66-67, 91, 110lso complexityfined by Beck 110, 135, 137le is not the same as minimal 66-67lest solution that can possibly work 3, 8, 10, 59-, 64, 66, 73-74, 111198 by association 23, 31source line of code) 106, 111, 122ia, Patrick xiii01, 109-110, 113, 130ava 24
eonent, see reusability 26ation, see this termal, see this term
e Engineering Institute 43 see code, implementation, SLOCti, see linguineg, see verbal communication
see also requirements, testingspeed of light 37sprint 3, 7, 33, 42, 57, 68, 71-72, 74-75, 80-81, 84,
89-91, 98-99, 124, 126, 140assessment 91backlog, see this termretrospective 99review, see review meeting
stakeholder 19, 21, 32, 45, 52-53, 61-62, 83, 90, 98-99, 123
Stallman, Richard 108standards, see under codeStandish Group 26-27stand-up meeting, see daily meetingStephens, Matt ixStockholm Syndrome 86story
see user storyboard, see this termcard, see story card under user storypoint, see story point under user story
Stravinsky, Igor 73structured programming viii, 57, 154subtle control 54, 57Subversion 104Surowiecki, James 62, 95sustainable pace 4-5, 50-51, 56-58, 92, 152Sutherland, Jeff xiii, 2, 26, 28, 30-31, 47, 54, 125,
139
TTaboo 42Takeuchi, Hirotaka 54task
board, see this termcard 127order of tasks, see under iterative development
TDD, see test-driven developmentteam vii-viii, 2-5, 7-12, 14-15, 19-21, 25, 28-29, 34,
40-41, 46-47, 50-60, 62, 68, 71-75, 79-81, 83-87, 89, 91-93, 95-96, 98-102, 104-106, 108-109, 111, 115, 118-119, 121, 124-125, 127-130, 134-135, 137-139, 150-154cross-functional, see cross-functionalitydistributed xiii, 20, 92-93, 126, 128, 152-153empowerment 14members and observers 82, 98, 153multiple 99self-organizing viii, 4-5, 7, 25, 50-51, 53-56, 80-
81, 96, 101, 137, 150, 152Team Software Process (TSP) 46technical debt 117, 125, 129-131telephony 64-65
ation 6, 13, 18-20, 23, 36-37, 45, 49, 75, 77-115, 118, 120, 151
test, see testing, test-driven development, test-first devel-opment
170
test-driv 118assescycle
test-drivtest-firs
assestesting
49, 101 127do nointegregretests unit t
TeX 10TFD, sethrashinthree qutime-botime zoTintin TorvaldTotem Tour deToyota traps, rhTschanT-shirt TSP (TTurner,
UML 3uncertaunit tesunverifupfront
57, 149
use caseuser sto
81, 138assesboardstorystorystory
velocityasses
verbal cVerhoe
INDEX
en development 6, 8-9, 15, 77, 89, 113-115, , 138, 151sment 115, 151 113en development. 138
t development 77, 113-115, 138, 151sment 115, 151 2, 4-6, 8-9, 12-13, 15, 23, 32, 35, 44, 46, 51-52, 58, 60-61, 66, 68, 75-78, 82, 89, 98, , 103-105, 111, 115, 117-118, 120, 123, 125, -129, 136-139, 151, 154t start new development until all tests pass 6, 76rating tests into the code 118ssion, see regression test suiteas a key resource 6, 15, 75-76est 82, 117-1188-109e test-first developmentg 107estions, see under daily meetingxed 3, 15, 71, 146-147, 154ne 9213s, Linus 108-109
42 France 135 4, 57, 134, 136etorical 22-30
nen, Julian xiiisizing 95eam Software Process) 46 Richard ix, xiii, 25, 31
U9, 43, 60-61
inty, cone of, see cone of uncertaintyt, see under testingiable claims 28-30 tasks 2-4, 9, 13, 31-32, 35, 40-41, 43-47, 52, 61-62, 65, 69, 73, 77, 83, 93, 109-113, 135, -150, 152-154 6, 10-13, 78, 119-120ry viii, 6, 10-13, 43, 60-61, 64, 74, 78, 80-84, 89, 94, 98, 115, 117, 119, 123-128, 130, , 140, 150-151sment 119-121, 150, see this term
board, see board card 10-11, 127 point 93-94, 117, 120-125, 127-128
V viii, 11, 117, 122-124, 127-129, 140, 154sment 124, 154
video tape manufacturing 136Visitor pattern 37, 112V-model, see under lifecycleV&V (Verification and Validation) 41
Wwaste 3-5, 13, 18, 27, 33-34, 36, 46, 52, 57-59, 67,
91, 117, 120, 122-123, 125, 127, 129-131, 134-136, 151, 153as criticism of requirements 33-34
waterfall 31, 39, 41-42not the same as predictive 31
Western Electric 29Wikipedia 101Wirth, Niklaus 67, 134Wojciechowski, Adam 107work in progress 4, 136working
code, see working iterations under iterative develop-ment
days 128schedules 92, 153space 10, 12, 57, 96-97, 125-126, 138, 152
work-in-progress 136workshop, see under requirementsWorld Bank 23Worst Thing First 73writing, see documentation
XXML 112XP, see Extreme ProgrammingX-rated 106xUnit 109, 114, 117
YY2K 60YAGNI 58-59, 69, 77Yourdon, Ed 56YouTube 20
ZZave, Pamela 36, 64zoology 82Zuill, Woody 107
ommunication, versus documents 17-21f, Chris 26