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», без необходимости каждый раз заново искать на чём Вы остановились. Поставьте закладку, и сможете в любой момент перейти на страницу, на которой закончили чтение.

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

Интервал:

Закладка:

Сделать

A senior executive of a video-communications firm returned to San Jose from London. It was her second trip in ten days, each being for a single meeting.

The astonishment for us around was that she obviously had access to state-of-the-art video conferencing facilities, and yet felt she could not conduct her business over the video link. Her meetings still required the lowest latency, richest, multi-modal communication possible: "in person."

We decided that it is easy to start negotiations over the phone or internet, but hard to bring them to conclusion that way.

Use of a shared, persistent information radiator. The whiteboard holds the drawn information in place, while words dissolve in the air. The people can all see the board, draw on the board, and can refer back to the board minutes later in the conversation.

The Impact of Removing Modalities

Now let's watch as we remove some of those mechanisms, and go to other communication settings.

Remove only physical proximity. With people at opposite ends of a video link, the visual and temporal characteristics should be very much the same as being in person. Somehow, though, they aren't, as witnessed by the video-communications executive who still flew to London for single meetings.

My teammates in Lillehammer, and I, in Oslo, often found that we only made design progress when we took the train trip together. Even walking to the train station together was a more effective design environment for us than talking over our video link.

Remove the visuals (use a telephone). Removing visuals also removes cross-modality timing. We lose the drawings, the gestures, the facial expressions, sight of the muscle tone, proximity cues, and the ability to link speech with action.

Remove voice (use email). With this, we lose vocal inflection, the ability to pause for effect, to check for interruptions, to speed up or slow down to make a point, to raise our tone or volume to indicate surprise, boredom, or the obviousness of the transmitted idea.

Remove the ability to ask questions (but possibly reinstate one of the above modalities). Without the questions, the sender must guess what the receiver knows, doesn't know, would like to ask, and what an appropriate answer to the guessed question might be -without feedback. Now, the sender really doesn't know what the receiver needs to hear, where the gaps are too big, where the shared experience lies. (This, of course, applies to me, communicating with you. How many words - which words - do I need to spend on this idea?)

Finally, remove almost everything. Remove visuals, sound, timing, kinaesthetics, cross-modality timing, question-and-answer, and we get ... paper.

How surprising it is in retrospect that most projects require documentation in the least effective communication format possible! The poor person trying to communicate a design idea must guess at what will work for the reader, does not get to use timing, vocal or gestural inflections, and gets no feedback along the way.

With this view in mind, it is less surprising to see the busiest and best project team leaders say: "Put all the people into one room." "Don't give me more than 4 people, that's all I can get into one room and talking together." "Give me printing whiteboards, and keep all the rest of your drawing tools."

"Make sure there are whiteboards and coffee corners all over the building."

The above are standard recommendations among successful project leaders, who count on using the highest communication mode, people, face-to-face. The discussion of communication modalities matches the findings of researchers, such as McCarthy and Monk (1994).

Making Use of Modalities

The graph in Figure 3-14 serves to capture the above discussion visually. In the graph, I separate two sets of situations, those in which question and answer are available, and those in which they are not.

Figure 3-14. Effectiveness of different modes of communication

The horizontal axis indicates the "temperature" of the communication channel. Warmer indicates that more emotional and informational richness gets conveyed. Email is cooler than audio or videotape, and two people face-to-face is the hottest channel.

What we see in the graph is communication effectiveness rising with the richness (temperature) of the communications channel. Two people at the whiteboard are using the richest.

The graph provides an idea on how one might improve the effectivenss of archival documentation: Videotaped Archival Documentation

Have the designer give a short, 5 - 15 minute description of the design to one or two colleagues who are not familiar with the work. These one or two will act as ombudsmen for the viewers of the videotape. While the designer leads the discussion, the colleagues interrupt and ask questions as they need. Videotape the discussion.

At the end, capture and print the examples and drawings used in the discussion, to act as mnemonic anchors of the discussion.

One might consider posting the talk online, accessing it using hyperlinked media.

I was pleased to hear from Lizette Velasquez of Lucent Technologies that not only had she already used that technique with success, but (she added) I had forgotten something important:

It is also important to mark and index places where "something interesting happened". While much of the discussion proceeds at a relatively slow pace, occasionally a question triggers a flurry of significant discussion, and the viewers will want to refer back to those sections.

I have been told by several people that they have videotaped talks on their project, but we are missing experiments telling us about this technique in actual use: how to set up the room, how long the discussion can be, what sort of person should be used for the ombudsman. Most of all, I am still waiting for someone to perform this experiement, and then, six months later, reflect on whether this was a good idea, and what would make it better.

If you are willing to try out this experiment, please let me know: what you did, what happened, and then, what you thought about it months later.

As a thought experiment about the utility of the graph and the experiment, consider the book Design Patterns (Gamma 1993). This book is excellent but difficult. I still have trouble understanding the patterns that I have not yet used. I suppose that others have similar difficulties. Imagine that instead of trying to extract the meaning of the patterns from the book, you could see one of the authors explaining the pattern in a video clip. They would, of course, rely on tonal inflections, gestures, and timing to get the idea across. I'm sure that I would understand those difficult patterns a lot easier, and suspect most people would.

The lesson is that we should try to move team communications up the curve as far as possible, for the situation at hand. We should rely on informal, face-to-face conversation, not merely tolerate it. Face-to-face communication should become a core part of your development process.

There is a second lesson to pay attention to. Sometimes a cooler communication channel works better, because it contains less emotional content. Cooler Communications Needed

A project leader told me that her team deals better with her when they speak over the phone, because she is too aggressive with her emotions in person.

A married couple told me that they communicated in a more "even" and less emotional level over the phone than in person, just because the face-to-face setting flooded them with visual and emotional cues. Hovenden (1999) describes a meeting in which a senior designer ruined a meeting's original plan by standing up and taking over the whiteboard for the rest of the meeting. In this case, the lack of anonymity created a social ranking that interfered with the intended meeting.

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

Интервал:

Закладка:

Сделать

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

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


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

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

x