Текст книги "Программист-прагматик. Путь от подмастерья к мастеру"

Автор книги: Эндрю Хант

Соавторы: Дэвид Томас
сообщить о нарушении

Текущая страница: 22 (всего у книги 28 страниц)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 8
Прагматические проекты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Общайтесь

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

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

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

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

Не повторяйте самого себя

"В разделе «Пороки дублирования» говорилось о трудностях, связанных с устранением дублирования работы, выполняемой разными членами команды. Это дублирование ведет к тому, что усилия тратятся впустую и все выливается в кошмарные ситуации при сопровождении. Ясно, что здесь нужно четкое взаимодействие, но в ряде случаев необходимо приложить и дополнительные усилия.

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

Если проект слишком велик для одного-единственного библиотекаря (или если никто не хочет брать на себя его функции), назначьте нескольких человек "фокусными точками" различных функциональных аспектов работы. Если кто-то хочет обговорить тему обработки даты, он знает, что по этому вопросу нужно обращаться к Мэри. Если же речь идет о базе данных, то следует обращаться к Фреду.

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

Ортогональность

Традиционная организация команды основана на устаревшем методе создания программного обеспечения, известного под названием «метода водопада». Отдельным членам команды назначаются роли, основанные на их должностных обязанностях. В команде имеются бизнес-аналитики, проектировщики, программисты, тестировщики, технические писатели и т. п. [45] В этом случае существует явная иерархия – чем ближе вы допущены к конечному пользователю, тем выше ваше положение.

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

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

Подсказка 60: Организуйте команду на основе функциональности, а не должностных обязанностей

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

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

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

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

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

Подобная организация команды напоминает старую концепцию "бригады главного программиста", впервые описанную в 1972 г. [Ваk72].

Автоматизация

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

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

Чувствуйте момент, когда нужно остановиться

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

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

• Энтропия в программах

• Суп из камней и сварившиеся лягушки

• Приемлемые программы

• Общайтесь!

• Пороки дублирования

• Ортогональность

• Проектирование по контракту

• Несвязанность и закон Деметера

• Вездесущая автоматизация

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

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

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

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

42
Вездесущая автоматизация

Прогресс цивилизации состоит в расширении сферы действий, которые мы выполняем не думая.

Альфред Норт Уайтхед

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

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

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