|
|
|
Askofen |
|
|||
Новичок Профиль Группа: Участник Сообщений: 6 Регистрация: 12.4.2009 Репутация: нет Всего: нет |
Классический процесс разработки программного обеспечения делится на 3 этапа: pre-production, production и post-production. На этапе pre-production вырабатывается концепция продукта, разрабатывается его более-менее детальный дизайн, выполняется техническое проектирование и создаётся демонстрационная версия продукта, которая способна подтвердить правильность первоначальной задумки. Во время production разрабатывается сама программа, т.е. делаются фичи (features). На этом этапе основная масса багов не исправляется – исправляются только критические баги, которые связаны с неправильным функционированием фич или которые блокируют усилия тестеров по проверке фич. На этапе post-production — исправляются остальные баги. К сожалению, применению такого подхода во многих российских компаниях мешают две вещи. Первая вещь – это элементарная лень руководства. (Согласитесь, куда проще говорить, что команда должна сама eliminate wastes, чем наладить процесс производства.) А вторая вещь – устоявшиеся мифы. И если с ленью я ничего не могу поделать, то мифы – постараюсь развеять. Миф 1. Если исправление багов отложить на этап post-production, в скором времени количество багов вырастет, как снежный ком, и проект станет плохо прогнозируемым и плохо управляемым. Управляемость проектом не будет потеряна, потому что: 1. В серьёзных компаниях при старте проекта отдел QA составляет прогноз, в котором расписано: сколько багов будет найдено, сколько багов будет содержать каждая крупная фича, сколько багов будет признано некорректными, сколько багов будет зашиплено и т.д. Этот прогноз используется в работе отделом QA и менеджментом проекта. Более того, он регулярно корректируется с использованием актуальных данных. Так что ни о какой "плохой прогнозируемости" и "плохой управляемости" не может быть и речи. 2. Во время production отдел QA находит далеко не все баги, а только их часть. В проектах, в которых я принимал участие, их количество составляет от 30 до 40 процентов от общего числа багов. Причина этого проста — основные силы QA подключаются незадолго до того, как все фичи будут реализованы. Подключать их ранее не имеет смысла, потому что фичи ещё не сделаны, и нечего тестировать. Кроме того, ещё не готовы тест-кейсы, т.к. фичи находятся в работе, и представление продюсеров о них может меняться. Во время production отсутствуют необходимые условия для подключения большой команды тестеров. 3. Если фича работает не так, как нужно, то это не баг, а не сделанная фича. В таком виде она не принимается у программиста, и он должен сделать так, чтобы она работала, как и было запланировано. Если во время работы фичи происходит крэш или ассерт, то отдел QA заводит баг и помечает его, как критический. Этот баг тоже фиксится, поскольку он мешает проверить работоспособность фичи до конца. |
|||
|
||||
|
НА ЗЛОБУ ДНЯ: Дорогие посетители, прошу обратить внимание на то, что новые темы, касающиеся новых вопросов, создаются кнопкой "Новая тема", а не "Ответить"! Любые оффтопиковые вопросы, заданные в текущих темах, будут удалены. Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, arilou. |
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | УП: Методологии | Следующая тема » |
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |