Часть 3
Часть 3. Управление проектами и группами
Обьединяющая
Работа руководителя проекта заключается в том, чтобы обеспечить выпуск высококачественного продукта в заданные сроки и при этом уложиться в рамки отпущенного бюджета. Однако эта задача не всегда оказывается выполнимой. В сфере разработки программного обеспечения превышение сроков и бюджета самое обычное дело.
Модель разработки программного обеспечения — это тот принцип, по которому руководитель проекта составляет план выполнения задач.
Метод водопада представляет собой классичестй подход к управлению проектом. Особенно часто он применяется для крупных разработок. В соответствии с этим методом проект разбивается на ряд последовательных этапов — анализ требований, разработка проектной документации, кодирование, тестирование и выпуск.
При эволюционном подходе к разработке программного продукта функции добавляются к нему последовательно, одна за другой.
Процесс добавления функций и отлади программы продолжается до тех пор, пока не получится достаточно приемлемый продукт.
Тестирование — это наиболее ответственный этап разработки. К моменту начала тестирования программа уже практически полностью написана. После прекращения поиска ошибок она сразу же выходит в свет. Если проект достаточно велик для подключения нескольких тестировщиков, подумайте о том, чтобы назначить одного-двух человек для постоянного выполнения неформального тестирования. Цель работы такого сотрудника — каждую неделю находить пару настолько серьезных ошибок или недостатков, что выпустить с ними продукт просто невозможно. Во время исправления этих ошибок остальная часть группы будет последовательно ”прочесывать” программу в соответствии с планом. Эта тактика особенно хорошо зарекомендовала себя на больших и серьезных проектах, где она позволяет сэкономить очень много времени.
Затраты на качество продукта это затраты на предотвращение ошибок, их поиск и исправление. С точки зрения бизнеса деньги вкладываются в тестирование потому, что выпуск продукта с ошибками в конечном счете обходится дороже. Если удастся доказать, что определенный вид тестирования сэкономит компании деньги, его финансирование вам обеспечено.
Проектирование продукта
Это самый первый этап разработки, на котором определяется, что же будет представлять собой задуманный программный продукт. При проектировании первым делом формулируются требования к продукту, а затем разрабатывается его внутренняя и внешняя структура.
Тестирование на этапе проектирования продукта
Если повезет, вам предложат проанализировать проектные документы, как только они будут написаны. Это прекрасная возможность познакомиться с продуктом и начать планирование собственной работы.
Реализация базовых функций
На этом этапе программа может работать только в одном видеорежиме. Она может печатать только на одном принтере. В ней может отсутствовать большая часть задуманных возможностей. Она наверняка полна ошибок. А при эволюционном: методе разработки на данном этапе вообще готово только ее ядро.
На данном этапе тестирование может быть еще достаточно неформальным. Можно просто путешествовать по программе, экспериментировать с ней без какого бы то ни было плана.
Однако если разработка ведется эволюционным методом, именно на данном этапе начинается самое что ни на есть серьезное тестирование, цель которого — добиться полной стабильности ядра программного продукта.
Почти альфа
На этом этапе большая часть программы уже готова, а значит, определился ее стиль и характер.
Тестирование накануне завершения альфа-версии
Прежде всего позаботьтесь о необходимом для работы оборудовании. Закажите то, что планируется купить, и поищите возможности взять напрокат остальное.
Интенсивное плановое тестирование
Выберите одну из областей программы и полностью на ней сконцентрируйтесь. После короткого неформального тестирования можно перейти к плановой и скрупулезной работе.
Регрессионное тестирование
Один раз тщательно протестировать каждую область программы еще не достаточно — ее тестирование необходимо регулярно повторять. Программа постоянно меняется, возникают новые проблемы, повторно появляются старые ошибки. Регрессионное тестирование должно охватывать программу так же полно, как и первоначальное, однако не требовать так же много времени.
Пре-бета
Во многих компаниях готовность бета-версии считается одним из важнейших рубежей разработки. По его достижении принимаются важные решения, завершаются одни виды работ и начинаются другие.
Как и перед объявлением альфа-версии, будьте готовы к огромному количеству последних изменений и исправлений. Планируйте свое время так, чтобы проверять их быстро и немедленно сообщать о результатах.
Бета-версия — это версия, которую можно передать бета-тестировщикам, т.е. людям не работающим в компании, но готовым поэксплуатировать какое-то время ваш не вполне еще отлаженный продукт и сообщить о своих впечатлениях и найденных ошибках.
Тестирование после завершения бета-версии
Незадолго до завершения бета-версии попросите руководителя проекта подписать план тестирования. Хотя как минимум однажды он уже знакомился с планом работ вашей группы, в ходе предыдущего этапа этот план довольно сильно изменился. Поэтому необходимо еще раз согласовать все ключевые вопросы, касающиеся масштаба и сроков работ, а главное, полноты предполагаемого тестирования. Убедитесь, что вы полностью понимаете друг друга и между вами не осталось никаких противоречий.
Замораживание пользовательского интерфейса
Раньше или позже в разработке наступает момент, когда все дальнейшие изменения пользовательского интерфейса, т.е. практически любые видимые изменения программы запрещаются. Любому видимому исправлению, даже если оно явно лучше, с этого момента предпочитают невидимое. Разумеется, могут быть и исключения из этого правила, но только в самых крайних случаях, когда найдена катастрофическая ошибка и ее никак нельзя исправить, не затронув интерфейса программы.
Тестирование на этапе подготовки финальной версии
Для тестировщиков этап подготовки к выпуску финальной версии является особенно важным. Если в программе остались настолько серьезные ошибки, что ее нельзя выпускать в производство, это ваш последний шанс их найти.
После окончания последнего этапа тестирования продукта он либо отправляется в производство и затем в продажу, либо передается в руки тех, кому предстоит выполнить его приемочное тестирование.
У качества продукта множество составляющих, включая интерфейс, функциональные возможности, полезность и надежность.
Высокая надежность продукта означает, что пользователи едва ли найдут в нем ошибки. Если же такая вероятность достаточно велика и особенно если в процессе эксплуатации могут проявиться достаточно серьезные ошибки, надежность продукта считается низкой.
Окончательное решение
Последнее слово всегда остается за руководством. Оценивать степень риска и вероятность успеха — это его работа. В одних случаях принимается решение немедленно выпустить несколько несовершенный продукт, в других же — решение выпустить его в следующем году, но зато уж абсолютно безупречным. Факторов, влияющих на принятие того или иного решения, может быть очень много, и прежде всего для этого необходимо глубокое знание рынка и четкое видение собственной позиции и целей компании, которое имеется только у ее руководства.
Работа руководителя группы тестирования заключается в другом гарантировать правильное понимание руководством степени риска. Во что обойдется этот риск компании, руководство знает и так, как и то, что поставлено на карту. Руководству известно, во что обходится каждая неделя задержки. Ему известна стоимость проводимых работ. От вас ему важно узнать о степени вероятности серьезных сбоев программы, которые могут повлиять на ее популярность или иметь другие неприятные для компании последствия.
После выпуска
Во многих компаниях по окончании работ проводится их заключительный анализ. Вас могут попросить подготовить отчет обо всем, что происходило в ходе работы над проектом: что прошло удачно, что нуждается в доработке или усовершенствовании, каковы были самые серьезные проблемы и какие важные работы так и не были выполнены. Этот отчет может быть подан в письменном виде или прочитан на ближайшем совещании.
Для вас как для руководителя группы тестирования заключительный отчет о проведенной работе является важным политическим документом.
Управление группой тестирования
Главной работой сотрудников группы тестирования является поиск и документирование ошибок. Практически любой компании выгодно иметь собственную группу профессиональных тестировщиков.
Руководство группой тестирования — это очень большая ответственность. Это бесконечные проблемы с неопытным персоналом. И очень мало славы. Психологическая нагрузка на руководителей тестовых групп так велика, что они чаще всех других сотрудников меняют место работы. Их политическая роль в компании крайне невыгодна — ведь они изобличают недостатки продукта, которые всегда являются чьими-то недоработками, а значит, сплошь и рядом наживают себе врагов.
Однако не все так мрачно. Можно создать прекрасную команду, которуко будут ценить за огромный вклад в повышение качества разрабатываемых продуктов, и при этом сохранить мирные и конструктивные отношения с другими подразделениями компании.
Честность, профессионализм и уважение к людям являются главным залогом успеха руководителя группы тестирования.
Настоящей группой контроля качества в любой компании является ее руководство.
За качество продукта отвечает руководитель проекта. Служба тестирования только снабжает его технической информацией, сопровождая данные собственной интерпретацией.
Все это вовсе не означает, что служба тестирования вообще ни за что не отвечает. Она отвечает за качественное тестирование, интерпретацию его результатов и их своевременное предоставление руководству, документирование своей работы.
Если в подразделении разработки программного обеспечения нет группы тестирования, программисты знают, что правильная работа программы лежит полностью на их ответственности. Однако как только такая группа появляется, программисты расслабляются и некоторые ошибки остаются ими незамеченными. (Собственно говоря, ведь за это тестировщикам и платят, не так ли?)
Программисты обязаны тщательно тестировать свои программы, они должны заботиться об их правильности и стабильности. Зная программный код как свои пять пальцев, они находят ошибки гораздо быстрее тестировщиков, причем могут обнаружить такие проблемы, которые тестировщикам самостоятельно не найти. В свою очередь, тестировщики анализируют программу с иной точки зрения и видят те ее недостатки, которых не замечают программисты. Поэтому для полноценного тестирования программы необходимы объединенные усилия обеих сторон.
Одной из главных обязанностей руководителя группы тестирования является защита своих подчиненных.
Если вы работаете в компании, где статистические данные о производительности труда могут быть использованы против отдельных тестировщиков, не собирайте эту информацию.
Не допускайте, чтобы сотрудник, высказавший неверную на чейлибо взгляд оценку, почувствовал себя глупым или виноватым.
Напротив, всячески поошряйте свободное выражение сотрудниками собственного мнения. Оно вполне может оказаться верным. Если же нет, они сами поймут это з ходе дискуссии или некоторое время спустя.
Классификация проекта
Нередко стоимость работ по тестированию приходится оценивать задолго до того, как у вас появится достаточно информации. Поэтому вам нужна определенная схема классификации проектов с приблизительными оценками их стоимости.
Общее количество времени, необходимого для тестирования программы, складывается:
из суммы длительностей всех фиксированных заданий, из среднего количества времени, уходящего на выполнение всех повторяющихся задач в течение одного цикла, умноженного на количество циклов.
Примерно к середине проекта вы уже будете проводить все эти вычисления и прикидки быстро и практически безошибочно. Основываясь на уже имеющемся опыте, вы сможете точно оценить количество времени, необходимого для полного завершения тестирования продукта.
Советы
Вот несколько моментов, которые часто упускают из виду.
Если один человек тестирует несколько продуктов, учтите дополнительное время, которое ему потребуется для переключения между ними. Каждый раз, переходя от одного проекта к другому, такому специалисту необходимо будет вспомнить, на чем он остановился и что делать дальше.
Накладные расходы лучше всего выделить в отдельный список. Кроме основной работы, приличное количество времени уходит на совещания, составление отчетов и прочие подобные дела. Постарайтесь поточнее выяснить, сколько именно, учитывая особенности работы и традиции конкретной компании. Соберите своих людей где-нибудь в кафе в спокойной располагающей обстановке и побеседуйте с ними на эту тему. Подготовьте список затрат времени, неизбежность которых можно убедительно объяснить руководству.
Если ваши подчиненные тратят на тестирование по шесть часов в день, значит, работа прекрасно организована.
Подводя итог, можно сказать, что идеальный тестировщик образован, сообразителен, умеет четко выражать свои мысли, умеет и вникать в детали, и видеть картину в целом, настойчив, но воспитан и обладает здравым смыслом. Он — творческая личность с организаторскими и техническими способностями. Как видите, этот набор качеств несколько отличается от того, который необходим хорошему программисту.