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

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

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

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

---

• Для редко изменяемых, некритичных функций

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

• Когда все трещит по швам

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

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

Оборудование для тестирования

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

• 2-3 компьютера на каждого тестировщика

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

• 2 компьютера на одного разработчика

Помните: разработчики тоже занимаются тестированием. Один компьютер им нужен для разработки, другой — для тестирования. Разработчики могут переконфигурировать его при «охоте на жучков», и это не помешает их основной работе. Повторю: хорошо, если одна машина представляет компьютер конечного пользователя.

• Доступная библиотека программ

Все ПО, которое требуется для разработки или тестирования, должно быть постоянно доступно. Для быстрого и простого доступа сотрудников к инструментам, продуктам и ОС, необходимым для работы, удобен дисковод с автоматической сменой компакт-дисков. Конечно, придётся позаботиться о наличии лицензий, но избавление сотрудников от хождения по коридорам в поисках нужного диска того стоит.

• Тестовая лаборатория

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

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

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

На заре NuMega у нас не было постоянно доступной библиотеки программ, а охота за компакт-дисками здорово раздражала и отнимала драгоценное время. Часто наши планы требовали поддержки самой последней ОС или компилятора Microsoft. К счастью, мы участвовали в тестировании их бета-версий и регулярно получали обновления. Жаль, что только на одном компакт-диске. Когда кому-то требовалась последняя бета-версия Windows или Visual Studio, начиналась охота за диском. Если везло, мы находили человека с диском, который нам требовался, но чаще всего мы слышали: «Я отдал его тому-то», — и продолжали идти по следу. (Однажды я ходил так от одного к другому и только пятый человек в цепочке сказал мне, что этого диска в глаза не видел!) Если такой способ не работал, мы писали сообщение по электронной почте и с надеждой ждали ответа, а это время занимались чем-то другим.

После того, как в течение нескольких месяцев мы столкнулись с десятками таких сообщений, мы окончательно поняли, что проблему нужно решать, тем более что наша компания росла. Решением стала «вертушка» компакт-дисков. Это сработало, но только после того, как мы перевели все в режим онлайнового доступа. Наши попытки создать традиционную библиотеку не увенчались успехом, так как люди, бравшие компакт-диски, никогда не возвращали их на место, и мы вновь задавались вопросом: «У кого диск?»

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

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

Нехватка ресурсов

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

Если работы просто больше, чем ваши сотрудники могут выполнить, а вы хотите поставить качественный продукт, существует только два выхода:

• пересмотреть графики, чтобы они отвечали ограничениям, накладываемым разрабатываемыми функциями и возможностями персонала;

• пересмотреть функциональность программы, чтобы она отвечала ограничениям графика и возможностям персонала.

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

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

Недостаточная подготовка

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

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