Эд Салливан - Время — деньги. Создание команды разработчиков программного обеспечения

• Название: Время — деньги. Создание команды разработчиков программного обеспечения
• Автор: Эд Салливан
• Издательство: Русская Редакция
• Жанр: Деловая литература
• Год: 2002
• ISBN: 5-7502-0189-9, 0-7356-1184-X

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

Книга состоит из 15 глав и предметного указателя.

---

• Прежде, чем внедрять новые приёмы, нужно извлечь максимум из имеющихся

Один из самых обескураживающих аспектов разработки ПО — внедрение новых приёмов, в то время как команда не полностью использует все возможности имеющихся. В вашей команде так быть не должно. За правильное использование имеющихся приёмов отвечают менеджеры и ведущие специалисты. Можно потерять доверие участников команды, санкционируя добавление новых технологических приёмов и игнорируя те, что уже есть. Если обнаружится, что ни один из имеющихся документированных приёмов не используется полностью, созовите собрание группы и решите, представляют ли они ценность. Да — оставьте их и используйте «на все сто». Нет — избавьтесь от лишних технологических приёмов. Что толку держать приёмы, развесив их по стенам, как картины? Они только портят интерьер.

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

• Взвешивайте потребности отдельного специалиста и всей команды

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

Из собственного опыта

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

Представляет ли новый приём ценность для компании? Иногда — да, когда дополнительная точная информация позволит легче устранять ошибки, но число таких ошибок не превышает 5-10 в месяц. Однако затраты на ввод этой информации, который должны были выполнять 15 человек на протяжении всего внутреннего цикла разработки (особенно когда приходилось регистрировать до 10 ошибок в день), не стоили потенциальной пользы. Кроме того, большинство ошибок воспроизводилось на любой машине, в противном случае было нетрудно связаться с офисом, откуда поступило сообщение об ошибке, и выяснить необходимую информацию о конфигурации.

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

Типичные проблемы и их решение

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

Проблемы с ранжированием

• Не держите ранжирование в секрете

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

• Не затрудняйте переход из одного круга в другой

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

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

• Не заводите фаворитов

Не допускайте использования рангов для определения фаворитов и не путайте его со средством вознаграждения любимчиков. Ранг должен быть основан исключительно на личном вкладе работника. Если ваш друг из группы не вносит вклад наравне с остальными, он не должен участвовать в получении благ наравне с остальными, и точка. Если вы не в состоянии пойти на такое решение, следует вовсе отказаться от ранжирования.

• Играйте честно

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

Проблемы с культурой

• Культуру можно изменить

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

• Если организация растёт

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

— кто мы?

— чем мы занимаемся?

— почему мы делаем своё дело лучше, чем кто-либо другой?

— чем мы отличаемся от других?

— что мы ценим?

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

Глава 5 Инструментальные программы

В компании NuMega мы использовали лишь те инструментальные программные средства, которые были жизненно необходимы для нашей работы и вписывались в наш стиль работы. Из всех доступных инструментов мы больше всего применяли и полагались на систему управления исходным кодом и систему устранения проблем и неисправностей (поиска «жучков»). Возможность приспосабливать эти продукты к нашим нуждам позволила ускорить работу — вся команда использовала их почти каждый день.

Средства управления исходным кодом

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