MTU Library Catalogue

Syndetics cover image
Image from Syndetics

Agile software development / Alistair Cockburn.

By: Cockburn, Alistair.
Material type: materialTypeLabelBookSeries: Agile software development series.Publisher: Boston : Addison-Wesley, 2002Description: xxv, 278 p. : ill. ; 24 cm.ISBN: 0201699699 (pbk.); 9780201699692.Subject(s): Computer software -- Development | Agile software development | Logiciels -- Développement | Software Engineering | Computers and ITDDC classification: 005.1 COC
Contents:
Introduction: Unknowable and Incommunicable -- Ch. 1. A Cooperative Game of Invention and Communication -- Ch. 2. Individuals -- Ch. 3. Communicating, Cooperating Teams -- Ch. 4. Methodologies -- Ch. 5. Agile and Self-Adapting -- Ch. 6. The Crystal Methodologies -- App. A. The Agile Software Development Manifesto -- App. B. Naur, Ehn, Musashi.
Summary: Alastair Cockburn offers advice on bringing difficult software development projects to a successful conclusion with a minimum of stress. The volume is based on over 10 years of interviewing software project teams.
Holdings
Item type Current library Call number Copy number Status Barcode
General lending MTU Kerry North Campus Library Ground Floor Main 005.1 COC (Browse shelf(Opens below)) 2 Available 38888000538201
General lending MTU Kerry North Campus Library Ground Floor Main 005.1 COC (Browse shelf(Opens below)) 1 Available 38888000479000
Total holds: 0

Enhanced descriptions from Syndetics:

This work presents a customizable light-weight methodology for improving software development. Alastair Cockburn offers advice on bringing difficult projects to a successful conclusion with a minimum of stress. The volume is based on over 10 years of interviewing software project teams and comparing what they have said with traditional software engineering disciplines.

Includes bibliographical references and index.

Introduction: Unknowable and Incommunicable -- Ch. 1. A Cooperative Game of Invention and Communication -- Ch. 2. Individuals -- Ch. 3. Communicating, Cooperating Teams -- Ch. 4. Methodologies -- Ch. 5. Agile and Self-Adapting -- Ch. 6. The Crystal Methodologies -- App. A. The Agile Software Development Manifesto -- App. B. Naur, Ehn, Musashi.

Alastair Cockburn offers advice on bringing difficult software development projects to a successful conclusion with a minimum of stress. The volume is based on over 10 years of interviewing software project teams.

Table of contents provided by Syndetics

  • List of Figures
  • List of Stories
  • Preface
  • Introduction: Unknowable and Incommunicable
  • The Problem with Parsing Experience. The Impossibility of Communication. Three Levels of Listening. So, What Do I Do Tomorrow?
  • Chapter 1 A Cooperative Game of Invention and Communication
  • Software and Poetry. Software and Games. A Second Look at the Cooperative Game. What Should This Mean to Me?
  • Chapter 2 Individuals
  • Them's Funky People. Overcoming Failure Modes. Working Better in Some Ways than Others. Drawing on Success Modes. What Should I Do Tomorrow?
  • Chapter 3 Communicating, Cooperating Teams
  • Convection Currents of Information. Jumping Communication Gaps. Teams as Communities. Teams as Ecosystems. What Should I Do Tomorrow?
  • Chapter 4 Methodologies
  • An Ecosystem That Ships Software. Methodology Concepts. Methodology Design Principles. XP under Glass. Why Methodology at All? What Should I Do Tomorrow?
  • Chapter 5 Agile and Self-Adapting
  • Light but Sufficient. Agile. Becoming Self-Adapting. What Should I Do Tomorrow?
  • Chapter 6 The Crystal Methodologies
  • Shaping the Crystal Family. Crystal Clear. Crystal Orange. Crystal Orange Web. What Should I Do Tomorrow?
  • Appendix A The Agile Software Development Manifesto
  • The Agile Alliance. The Manifesto. Supporting the Values
  • Appendix B Naur, Ehn, Musashi
  • Peter Naur, Programming as Theory Building. Pelle Ehn, Wittgenstein's Language Games. Musashi
  • Appendix C Books and References
  • Index

Excerpt provided by Syndetics

Is software development an art, a craft, science, engineering, or something else entirely? Does it even matter? Yes, it does matter, and it matters to you. Your actions and their results will differ depending on which of those is more correct. The main thing is this: You want your software out soon and defect free, but more than that, you need a way to examine how your team is doing along the way. Purpose It is time to reexamine the notions underlying software development. The trouble is that as we look at projects, what we notice is constrained by what we know to notice. We learn to distinguish distinct and separable things in the extremely rich stream of experience flowing over us, and we pull those things out of the stream for examination. To the extent that we lack various key distinctions, we overlook things that are right in front of us. We anchor the distinctions in our memories with words and use those words to reflect on our experiences. To the extent that we lack words to anchor the distinctions, we lack the ability to pull our memories into our conversations and the ability to construct meaningful strategies for dealing with the future. In other words, to reexamine the notions that underlie software development, we have to reconsider the distinctions that we use to slice up our experience and the words we use to anchor our memories. This is, of course, a tall order for any book. It means that some of the earlier parts of this book will be rather abstract. I see no way around it, though. The last time people constructed a vocabulary for software development was in the late 1960s, when they coined the phrasesoftware engineering,as both a wish and a direction for the future. It is significant that at the same time the programming-should-be-engineering pronouncement was made, Gerald Weinberg was writingThe Psychology of Computer Programming.In that book, software development doesn't look very much like an engineering discipline at all. It appears to be something very human-centric and communication-centric. Of the two, Weinberg's observations match what people have reported in the succeeding 30 years, and software engineering remains a wishful term. In this book, I will Build distinctions and vocabulary for talking about software development Use that vocabulary to examine and anchor critical aspects of software projects that have been pushed to the sidelines too often Work through the ideas and principles of methodologies as "rules of behavior" Merge our need for these rules of behavior with the idea that each project is unique, and derive effective and self-evolving rules I hope that after reading this book, you will be able to use the new vocabulary to look around at your project, notice things you didn't notice before, and express those observations. As you gain facility, you should be able to Discuss Extreme Programming, the Capability Maturity Model, the Personal Software Process, or your favorite process Determine when each process is more or less applicable Understand people who have differing opinions, abilities, and experience Audience Each person coming to this book does so with a different experience level, reading style, and role. Here's how you might read the book to use it to your greatest advantage: by experience, by reading style, or by role. By Experience This book is written for the more experienced audience. The book does not contain procedures to follow to develop software; in fact, core to the book is the concept that every technique has limitations. Therefore, it is impossible to name one best and correct way to develop software. Ideally, the book helps you reach that understanding and then leads you to constructive ideas about how to deal with this real-world situation. If you are an intermediate practitioner who has Excerpted from Agile Software Development by Alistair Cockburn All rights reserved by the original copyright owners. Excerpts are provided for display purposes only and may not be reproduced, reprinted or distributed without the written permission of the publisher.

Author notes provided by Syndetics

Alistair Cockburn is a recognized expert on use cases. He is consulting fellow at Humans and Technology, where he is responsible for helping clients succeed with object-oriented projects. He has more than twenty years of experience leading projects in hardware and software development in insurance, retail, and e-commerce companies and in large organizations such as the Central Bank of Norway and IBM.



0201699699AB07302002