Alistair Cockburn - Agile Software Development

Здесь есть возможность читать онлайн «Alistair Cockburn - Agile Software Development» весь текст электронной книги совершенно бесплатно (целиком полную версию без сокращений). В некоторых случаях можно слушать аудио, скачать через торрент в формате fb2 и присутствует краткое содержание. Жанр: Программирование, Деловая литература, на английском языке. Описание произведения, (предисловие) а так же отзывы посетителей доступны на портале библиотеки ЛибКат.

Agile Software Development: краткое содержание, описание и аннотация

Предлагаем к чтению аннотацию, описание, краткое содержание или предисловие (зависит от того, что написал сам автор книги «Agile Software Development»). Если вы не нашли необходимую информацию о книге — напишите в комментариях, мы постараемся отыскать её.

The agile model of software development has taken the world by storm. Now, in Agile Software Development, Second Edition, one of agile’s leading pioneers updates his Jolt Productivity award-winning book to reflect all that’s been learned about agile development since its original introduction.
Alistair Cockburn begins by updating his powerful model of software development as a “cooperative game of invention and communication.” Among the new ideas he introduces: harnessing competition without damaging collaboration; learning lessons from lean manufacturing; and balancing strategies for communication. Cockburn also explains how the cooperative game is played in business and on engineering projects, not just software development
Next, he systematically illuminates the agile model, shows how it has evolved, and answers the questions developers and project managers ask most often, including
· Where does agile development fit in our organization?
· How do we blend agile ideas with other ideas?
· How do we extend agile ideas more broadly?
Cockburn takes on crucial misconceptions that cause agile projects to fail. For example, you’ll learn why encoding project management strategies into fixed processes can lead to ineffective strategy decisions and costly mistakes. You’ll also find a thoughtful discussion of the controversial relationship between agile methods and user experience design.
Cockburn turns to the practical challenges of constructing agile methodologies for your own teams. You’ll learn how to tune and continuously reinvent your methodologies, and how to manage incomplete communication. This edition contains important new contributions on these and other topics:
· Agile and CMMI
· Introducing agile from the top down
· Revisiting “custom contracts”
· Creating change with “stickers”
In addition, Cockburn updates his discussion of the Crystal methodologies, which utilize his “cooperative game” as their central metaphor.
If you’re new to agile development, this book will help you succeed the first time out. If you’ve used agile methods before, Cockburn’s techniques will make you even more effective.

Agile Software Development — читать онлайн бесплатно полную книгу (весь текст) целиком

Ниже представлен текст книги, разбитый по страницам. Система сохранения места последней прочитанной страницы, позволяет с удобством читать онлайн бесплатно книгу «Agile Software Development», без необходимости каждый раз заново искать на чём Вы остановились. Поставьте закладку, и сможете в любой момент перейти на страницу, на которой закончили чтение.

Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

"Jumping the Communications Gap" examines people's efficiency in conveying ideas using warmer and cooler communication channels. It introduces the idea of adding "stickiness" to information, and looks at how those two topics relate to transferring information across time.

"Teams as Communities" discusses amicability and conflict, the role of small team victories in team building, and the sorts of subcultures that evolve on a project. We shall see that the differing cultural values are both useful to the organization and difficult for the team to deal with.

"Team Ecologies" considers a software development team as an ecosystem in which physical structures, roles, and individuals with personalities all exert forces on each other. Each project producing its own, unique ecosystem makes the job of methodology design even more difficult.

Convection Currents of Information

Saying that software development is a cooperative game of communication implies that a project's rate of progress is linked to how long it takes information to get from the head of one person to the head of another. If Kim knows something that Pat needs, the project's progress depends on

· How long it takes Pat to discover that Kim knows something useful

· How much energy it costs Pat and Kim together to get the knowledge transferred to Pat

Let's see how much this costs a project.

Suppose that people who program in pairs ask and get answers to 100 questions per day. Adding just one minute to the cost of each question adds 100 minutes of salary cost per person per week, plus a small delay to the project's delivery. For a 12-person project, that costs 20 hours of salary per week. On a 20-week project, it amounts to 10 work-weeks of salary cost, up to $50,000 in many companies.

The project gets delayed almost a full week and costs an extra $50,000 per minute of delay in getting questions answered, not assuming any other damage to the project for the questions taking longer to answer.

The delay is more on the order of 5 minutes if a person has to walk down the hall, but there is worse damage: Kim might not be there. That means that when Pat returns to his office, he has lost the train of thought he was working on, and has to spend more time and energy recovering it. That is still not the worst.

The worst is that the next time Pat has a question, he might decide against walking upstairs, since Kim might not be there. For not asking the question, he makes an assumption. Some percentage of his assumptions will be wrong, and each wrong assumption results in Pat introducing an error into the program. Finding and fixing that error costs the project anything from multiple minutes to multiple days.

Thus, Pat's not asking his question and getting it answered represents a large lost opportunity cost. Over the course of the project, the lost opportunity cost is far greater than the cost of walking upstairs.

I hope you palpably feel the project's development costs rising in the following six situations:

1. Kim and Pat pair-program on the same workstation (Figure 3-1). Pat wonders a question out loud, and Kim answers. Or, Kim mentions the answer in passing as part of their ongoing conversation, and Pat recognizes it as useful information. This takes little work by each person, and the least time.

Figure 3-1. Two people pair programming. (Photo courtesy of Evant, Inc.)

2. Kim and Pat at separate workstations, but right next to each other (side-by-side programming). Using peripheral vision or the usual chit-chat that develops when sitting lose together, Kim notices that Pat is looking for something on the web, and asks what the question is. Or, Pat simply asks. Kim answers, possibly without looking away from the screen. Not much work, not much time is involved.

3. Kim and Pat work on opposite sides of a room, facing away from each other (Figure 3-2). Kim is not likely to notice that Pat is looking for something, but Pat can easily see whether Kim is available to answer a question. At that point, Pat asks and Kim answers.

Figure 3-2. Two people sitting at opposites sides of the room. (Photo courtesy of Thoughtworks, Inc.)

4. Kim and Pat sit in adjacent offices, separated by a wall. Kim can't notice when Pat is looking for something, and Pat can't see if Kim is available. Pat must get up, peek around the doorframe to see if Kim is in, and then ask Kim the question.

5. Kim and Pat sit on different floors or in adjacent buildings. Pat walks upstairs, only to find that Kim is out! Now, Pat has lost time, energy, the train of thought he was holding while he was working downstairs, and the motivation to walk upstairs the next time he has a question. The lost opportunity cost starts to mount.

6. Kim and Pat sit in different cities, possibly with several time zones between them. In this setting, not only will they not ask each other questions so often, they also will have to use less efficient, less rich communication channels to discuss the question and its answer. They expend more energy, over a longer period of time, to achieve the same communication result.

The main question is, if you were funding this project, which working configuration would you like Kim and Pat to use?

What we see is that even minor differences have an impact on the rate of information flow.

Figure 3-3. Pair programming and working across a partition. Between which pair of people will information discovery happen fastest? (photo courtesy of Thoughtworks, Inc.)

Notice, in Figure 3-3, the two different situations in play at the same time. The two people on the left are pair programming. It may be nice for them to have a small separation from the person on the right. However, if it happened to be the two people across the partition who needed to work together, the partition would soon become a problem. Indeed, I visited two people working across a partition, and it wasn't long before they removed the partition. As one of them explained, "I couldn't see his eyes"!

Erg-seconds

Comparing the flow of information with that of heat and gas is not as far-fetched as it may at first seem. With every speech act, Kim radiates both information and energy into the environment around her. That information or energy gets picked up by people within sight or hearing. Pat also radiates, with every speech act.

In his case he radiates his need for information. Sooner or later, either Kim detects Pat's information need, or Pat detects that Kim has the information. Whichever way the discovery goes, they then engage in conversation (or Pat reads Kim's document, if Kim's information is in written form,).

In gas dispersion problems, one analyzes the distance molecules travel in a certain amount of time. The unit of measure for molecules is moles, that for distance is meters, so gas dispersion is measured in mole-meters / second (how many moles of the gas travel how far, in how much time).

We can analyze the movement of ideas (memes, to borrow an appropriate term from The Selfish Gene (Dawkins 1990)) using similar terms. We are interested in how many useful memes flow through the project team each minute.

Meters is not the correct unit, though, since ideas travel through phone lines, email and documents, rather than through space.

What we care about is the amount of energy it takes to move a meme from one head to another. The appropriate units are erg-seconds. Ergs is a unit of work (such as walking up the stairs), and seconds is a unit of time (such as time spent on the telephone), so erg-seconds captures the cost in both labor and time to get a question answered.

(Bo Leuf comments that its inverse is also useful: argh-seconds, a measure of the pain of expending energy and not managing to convey the idea).

Using this metaphor, let's look at office layouts to see the energy cost associated with detecting that someone else has some needed information.

Читать дальше
Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

Похожие книги на «Agile Software Development»

Представляем Вашему вниманию похожие книги на «Agile Software Development» списком для выбора. Мы отобрали схожую по названию и смыслу литературу в надежде предоставить читателям больше вариантов отыскать новые, интересные, ещё непрочитанные произведения.


Отзывы о книге «Agile Software Development»

Обсуждение, отзывы о книге «Agile Software Development» и просто собственные мнения читателей. Оставьте ваши комментарии, напишите, что Вы думаете о произведении, его смысле или главных героях. Укажите что конкретно понравилось, а что нет, и почему Вы так считаете.

x