Размер шрифта:     
Гарнитура:GeorgiaVerdanaArial
Цвет фона:      
Режим чтения: F11  |  Добавить закладку: Ctrl+D
Следующая страница: Ctrl+→  |  Предыдущая страница: Ctrl+←
Показать все книги автора/авторов: Cockburn Alistair
 

«Agile Software Development», Alistair Cockburn

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 relatively 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 phrase software 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 writing The 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.

Four Goals

In this book, I shall

· 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 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 Derive 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

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 experience with software-development projects, and if you are now looking for the boundaries for the rules you have learned, you will find the following topics most helpful:

· What sorts of methodologies fit what sorts of projects

· Indices for selecting the appropriate methodology category for a project

· The principles behind agile methodologies Being an intermediate practitioner, you will recognize that you must add your own judgement when applying these ideas.

If you are an advanced practitioner, you already know that all recommendations vary in applicability.

You may be looking for words to help you express that. You will find those words where the following topics are presented:

· Managing the incompleteness of communication

· Continuous methodology reinvention