Алистэр Коуберн - Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения Страница 3

Тут можно читать бесплатно Алистэр Коуберн - Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения. Жанр: Научные и научно-популярные книги / Деловая литература, год -. Так же Вы можете читать полную версию (весь текст) онлайн без регистрации и SMS на сайте «WorldBooks (МирКниг)» или прочесть краткое содержание, предисловие (аннотацию), описание и ознакомиться с отзывами (комментариями) о произведении.
Алистэр Коуберн - Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения

Алистэр Коуберн - Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения краткое содержание

Прочтите описание перед тем, как прочитать онлайн книгу «Алистэр Коуберн - Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения» бесплатно полную версию:
Мы, методологи, проектируем сложные системы, но не принимаем во внимание рабочие характеристики активного компонента этих систем, компонента, который известен своей нелинейностью и изменчивостью - человека. В этой статье вкратце перечислены те теории и проекты, которые мне пришлось изучить, чтобы осознать этот совершенно очевидный факт, а также определить, какие качества человеческой психики должны учитываться в создании методологии и более общих рекомендациях касающихся процесса разработки. Именно по этим качествам можно делать наиболее верные прогнозы относительно будущего течения проекта и применимости к нему какой-либо методологии.

Алистэр Коуберн - Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения читать онлайн бесплатно

Алистэр Коуберн - Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения - читать книгу онлайн бесплатно, автор Алистэр Коуберн

И тут я наконец-то понял, что прямо перед нами всегда находится нечто, чего мы не замечаем: люди. Именно человеческие качества обеспечивают успех тому или иному проекту, именно они являются фактором первостепенной важности, основываясь на котором надо строить прогнозы о проекте. Теперь я рассматриваю все в обратном порядке - сначала люди, а потом методология, как второстепенный показатель.

Весь мой опыт консультанта можно было бы описать, исходя всего лишь из нескольких свойств человеческой натуры. Теперь, применяя свои знания на практике, я могу гораздо лучше прогнозировать развитие проектов и давать гораздо более полезные рекомендации. Мне кажется, пришло время официально признать, что главным в исследованиях должен быть вопрос: "Какими качествами обладают люди, которые занимаются разработкой программного обеспечения, и какое влияние они оказывают на проектирование методологии?"

Четыре основных свойства

Люди - устройства активные, и у них есть режимы успешной работы и режимы сбоя. Вот несколько основных таких режимов, которые я определил, и которыми пользуюсь и по сей день:

Человек - существо, которому необходимо общение. Причем общаться он предпочитает в режиме непосредственного диалога, лично, по типу "вопрос-ответ".

Человеку трудно постоянно работать сверхурочно.

Человек - существо изменчивое, он меняется в зависимости и от времени, и от пространства.

Как правило, у человека есть чувство гражданского долга, он может хорошо ориентироваться в ситуации, брать инициативу в свои руки и делать "все, что необходимо" для того, чтобы проект завершился успешно.Есть и ряд других характеристик, которые я не буду описывать здесь подробно:

Человеку нужно время, как на размышление, так и на общение (см. [Co98], [Cs], [Dm]).

Человек хорошо работает, опираясь на примеры (этот тезис требует дальнейшего изучения, см. [J-L]).

Человек предпочитает скорее потерпеть неудачу из-за своего консерватизма, нежели рискнуть, но сделать что-то необычным образом [Pi]; ему больше нравиться изобретать, а не находить готовые решения, он может одновременно держать в голове совсем немного сведений, он делает ошибки и с трудом меняет привычки.

Отдельная личность может легко возобладать над проектом.

Способность человека выполнять те или иные задания в большей степени определяется его личными качествами.

Человек - существо общительное

Основным фактором в разработке программного обеспечения является возможность коммуникации. На рисунке 1 изображена некая кривая, с помощью которой я иллюстрирую свои методологические рассуждения. На этом рисунке видно, как падает эффективность коммуникации, если исчезает ее модальность и синхронизация. Этой теме посвящено несколько исследований (см. [Pl] и [Si]), кроме того, эту же зависимость подтверждает и Вайнберг, который описывал проекты около 30 лет назад [Wei].

Самым эффективным видом коммуникации является непосредственное, личное общение (например, когда вы обсуждаете что-либо и рисуете при этом на доске). Если мы будем убирать одно за другим все свойства общения, присущие двум людям, рисующим у доски, мы увидим, как падает эффективность коммуникации. Убирать мы будем следующие свойства:

Физическая досягаемость. Я не знаю, как это объяснить, но физическая досягаемость собеседников влияет на их общение. Что бы ни лежало в основе этого влияния - трехмерность, синхронизация, запах или малозаметные визуальные сигналы - при коммуникации это имеет большое значение.

Разнообразные модальности. Человек общается не только словами, но и при помощи жестов. Часто человек может высказать свое суждение жестикуляцией, например, поднимая бровь или указывая на что-то пальцем.

Интонация и синхронизация речи. Чтобы подчеркнуть важность какого-либо высказывания или, к примеру, свое удивление, говорящий может ускорять или замедлять темп речи, делать паузы или изменять интонацию.

Ведение диалога в реальном времени (вопрос-ответ). С помощью вопросов слушающий выясняет для себя то, что ему было неясно в речи собеседника или же получает дополнительные сведения, которых ему не хватает для полного понимания предмета. Синхронизация вопросов и ответов является основополагающим определением типа коммуникации.

Рисунок 1. Виды коммуникацииИтак, что же произойдет, если мы начнем убирать одно за другим все эти свойства?

Убираем только физическую досягаемость. Поместим собеседников на противоположные концы видеосвязи. В принципе, при этом сохраняются все основные свойства физического присутствия, и тем не менее, эффект уже не тот. Когда мы испробовали этот способ в Норвегии, где одна часть команды разработчиков находилась в Осло, а другая - в Лиллехаммере, то оказалось, что команда находила верные проектные решения, только когда всем удавалось собраться вместе. Даже то время, которое люди тратили, чтобы вместе дойти до электрички, было более продуктивно для работы, нежели видеоконференция.

Убираем жестикуляцию и визуальную синхронизацию, оставляем интонацию и вокальную синхронизацию (другими словами, используем для общения телефон). Большинство людей во время беседы по телефону рисуют . Если человек рисует линию, которая соединяет два прямоугольника, это значит, что он собирается сказать нечто важное, то, что нужно отметить особо. Визуально-слуховая синхронизация информации закрепляет в сознании человека ее суть. Когда люди говорят по телефону, эта синхронизация исчезает, а вместе с ней из коммуникации исчезают жестикуляция, выражение лица собеседника, и т.д.

Теперь уберем голосовую синхронизацию и интонацию, оставим лишь возможность задавать вопросы (электронная почта). Без голосовой синхронизации мы не можем ни сделать эффектную паузу, ни подождать, не будет ли у собеседника возражений или вопросов, ни ускорить или замедлить темп речи, чтобы сделать высказывание. Лишив себя возможности использовать интонацию, человек не может выразить с ее помощью насколько удивительна, скучна или очевидна выраженная в письме идея.

Теперь уберем возможность задавать вопросы (но восстановим один из перечисленных выше факторов). Не имея возможности услышать вопросы собеседника, говорящий должен сам догадываться, что тот знает или не знает, какие вопросы мог бы задать и включить в свою речь ответы на эти несуществующие вопросы. И все это он должен сделать, не имея обратной связи со своим слушателем. Этот вид коммуникации допускает наличие визуальной (видеокассета) или слуховой (аудиокассета) информации.

И, наконец, убираем все свойства коммуникации - визуальные, слуховые, голосовые, синхронизацию общения, возможность задавать вопросы - что же мы получаем? Правильно, бумажную документацию. На приведенной выше модели вы видите, что документация является наименее эффективным способом коммуникации из всех возможных. Тот, кто пишет документацию, должен строить догадки относительно своей аудитории безо всякой обратной связи, у него нет возможности использовать ни синхронизацию и другие эмфатические сигналы, ни жестикуляцию и интонацию. Но если построенная нами модель справедлива, то с ее помощью можно понять, как улучшить условия работы. И это вполне реально. Более того, существует множество сложных проектов, которые весьма успешно применяют высказанные нами здесь идеи на практике.

"Посадите всех разработчиков в одной комнате". "Мне не нужно больше четырех человек, иначе мы не поместимся в одну комнату и не сможем общаться". Вот стандартные рекомендации, которые дают руководители успешных проектов. Такие руководители планируют работу, базируясь на самом эффективном виде коммуникации - непосредственном общении между людьми.

"Убедитесь, что во всем здании хватает досок для рисования и уголков, где можно попить кофе". Такие компании, как Hewlett-Packard и IBM давно поняли всю эффективность неформального общения, и сейчас в нашей индустрии стало обычным положение, что наиболее эффективное окружение для проектирования разработки ПО можно создать специально поощряя и разрешая собрания небольших групп разработчиков. Вайнберг зафиксировал особые случаи, когда неформальные беседы разработчиков оказывали значительный эффект на общую результативность работы всей группы [Wei]. Нередко удачные решения приходят, когда люди "просто беседуют".

Сейчас существует три сравнительно новых методологии, где одно из основных положений - размещение всех разработчиков в одной комнате или просто в непосредственной близости друг от друга. Это Adaptive Software Engineering [Hi], Extreme Programming [B99], [EP], и Crystal(Clear) [Co00]).

Модель коммуникации, которую мы рассмотрели выше, позволяет, кроме всего прочего, давать рекомендации по архивированию документации:

Перейти на страницу:
Вы автор?
Жалоба
Все книги на сайте размещаются его пользователями. Приносим свои глубочайшие извинения, если Ваша книга была опубликована без Вашего на то согласия.
Напишите нам, и мы в срочном порядке примем меры.
Комментарии / Отзывы
    Ничего не найдено.