Какова отдача от методов?

В своей статье в журнале САСМ [Gla99b], написанной в 1999 г., Роберт Гласе сделал обзор исследований улучшений в производительности и качестве, достигнутых благодаря семи различным технологиям разработки программ (технология 4GL, структурные методики, CASE-средства, формальные методы, методология чистой комнаты, модели процессов и ООТ). Он сообщает, что первоначальное оживление, связанное со всеми этими методами, было преувеличено. Хотя существуют указания на то, что у некоторых методов есть преимущества, эти преимущества начинают проявляться только после существенного снижения производительности и качества, в период принятия технологии на вооружение и обучения пользователей.

Не стоит недооценивать стоимость принятия новых инструментальных средств и методов. Подготовьтесь к тому, что первые проекты с применением этих технологий будут предназначены для учебных целей.

Нужно ли использовать формальные методы?

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

Не подавайтесь ложному авторитету метода. Люди могут ходить на собрания, принося с собой гектары бумаги с изображением диаграмм классов и сто пятьдесят сценариев использования, но вся эта макулатура – лишь их ошибочная интерпретация требований и конструкции. Старайтесь не думать о том, сколько стоит тот или иной инструмент, глядя на результаты его работы.

Подсказка 59: Дорогие инструменты не всегда создают лучшие решения

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

Другие разделы, относящиеся к данной теме:

• Карьер для добычи требований

Вопросы для обсуждения

• Диаграммы сценариев использования являются частью процесса UML при сборе требований (см. Карьер для добычи требований). Являются ли они эффективным способом взаимодействия с вашими пользователями? Если нет, то почему вы их используете?

• Как вы можете объяснить пользу, которую приносит формальный метод вашей команде? Чем вы можете ее измерить? В чем состоит улучшение? Можете ли вы провести различие между пользой от инструментального средства и возросшим опытом сотрудников вашей команды?

• Где расположена точка безубыточности при внедрении новых методов в вашей команде? Как можно оценить компромисс между пользой, приносимой в будущем, и текущими потерями в производительности в период внедрения нового инструментального средства?

• Годятся ли инструментальные средства, применяемые в крупномасштабных проектах, для малых проектов? Верно ли обратное?

Глава 8

Прагматические проекты

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

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

Единственным и самый важным фактором, придающим последовательность и надежность процессам на уровне проекта, является автоматизация процедур. В разделе Вездесущая автоматизация мы объясним, почему это именно так, и приведем некоторые примеры из реальной жизни.

Выше говорилось о тестировании в ходе написания программ. В разделе Безжалостное тестирование мы переходим на следующую ступень философии и инструментов, применяемых в масштабе проекта, в особенности, если нет отдела контроля качества, находящегося у вас на побегушках.

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

Успех проекта находится перед глазами наблюдателя – спонсора проекта. Восприятие успеха – это самое главное, и в разделе Большие надежды мы покажем вам некоторые хитрости, которые порадуют сердце любого спонсора проекта.

Последней подсказкой в этой книге является прямое следствие всех остальных. В разделе Гордость и предубеждение мы поощряем вас подписывать свою работу и гордиться тем, что вы делаете.

Команды прагматиков

В группе L Стоффел руководит шестью первоклассными программистами – это руководящая работа, которую можно приравнять к управлению бродячими котами.

Журнал Washington Post от 9 июня 1985 г.

Пока в книге мы рассматривали прагматические методики, которые помогают отдельной личности стать лучшим программистом. Могут ли эти методы работать в приложении к командам?

Отвечаем на это громким да! В личностном прагматизме есть свои преимущества, но эти преимущества преумножаются, если личность работает в команде прагматиков,

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

Рассмотрим некоторые из предыдущих разделов с точки зрения команд.

Никаких разбитых окон

Качество является прерогативой команды. Для самого прилежного разработчика, попавшего в команду, которая безразлична к работе, окажется сложным сохранять энтузиазм, необходимый для устранения проблем, требующих кропотливости. Проблемы будут только усугубляться, если команда активно уговаривает разработчика не тратить время на устранение этих проблем.

Команда в целом не должна допускать наличия разбитых окон – этих маленьких недостатков, которые никем не устраняются. Команда обязана взять на себя ответственность за качество продукта, поддерживая разработчиков, исповедующих философию не живите с разбитыми окнами, описанную в разделе Энтропия в программах, и поощряя ее изучение теми, кто пока не открыл ее для себя.

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

Сварившиеся лягушки

Помните несчастную лягушку, сидевшую в кастрюле с водой, из разделе Суп из камней и сварившиеся лягушки? Она не заметила постепенного изменения в окружающей среде и в конце концов сварилась. То же самое может произойти с отдельными личностями, которые теряют бдительность. Трудно уследить за общим состоянием среды в разгаре работы над проектом.

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

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

Общайтесь

Очевидно, что разработчики в группе должны разговаривать друг с другом. В разделе Общайтесь! даны некоторые советы для облегчения подобного общения. Однако не забывайте, что сама по себе команда находится в рамках определенной организации. Команде как субъекту приходится четко взаимодействовать с остальным миром.

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

Лучшие проектные команды обладают ярко выраженной индивидуальностью. Люди ожидают встреч с ними, поскольку знают, что увидят хорошо подготовленную презентацию, от которой всем станет лучше. Производимая ими документация отличается четкостью, точностью и последовательностью. В такой команде нет разноголосицы [44]. У нее даже может быть чувство юмора.

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

Как отдавать свадебные фотографии? Мой метод отдачи материала


Похожие статьи.

Понравилась статья? Поделиться с друзьями: