Распространённые мифы о классическом процессе разработки(Прочитано 4055 раз)


Классический процесс разработки программного обеспечения делится на 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 заводит баг и помечает его, как критический. Этот баг тоже фиксится, поскольку он мешает проверить работоспособность фичи до конца.

Дальше: http://askofen.blogspot.ru/2013/08/blog-post_19.html
С уважением,
Кирилл Лебедев
http://askofen.blogspot.com



Здравствуйте, Кирилл.

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

Хотел поинтересоваться:
Цитировать
1. В серьёзных компаниях при старте проекта отдел QA составляет прогноз, в котором расписано: сколько багов будет найдено, сколько багов будет содержать каждая крупная фича, сколько багов будет признано некорректными, сколько багов будет зашиплено и т.д.
А каким образом и какими методами это делается?



Здравствуйте, Эдуард!

Хотел поинтересоваться: А каким образом и какими методами это делается?

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

Аналогичным образом поступают при составлении прогноза по подсистемам (фичам). Смотрятся исторические данные, анализируется сложность вносимых изменений. Если фича (или подсистема) - совсем новая, то анализируются исторические данные другой аналогичной по сложности подсистемы.

Таким же образом поступают, если разрабатывается совсем новый продукт - исследуются исторические данные аналогов.
С уважением,
Кирилл Лебедев
http://askofen.blogspot.com



А я вот не могу согласиться с каждым словом. Вернее по всем пунктам есть замечания.

Возьмем например:
Цитировать
Миф 5. Если исправление багов откладывать на финальную стадию проекта, то невозможно автоматизировать тестирование, так как тесты бесты будут постоянно разломаны.

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

Не согласен. Да, все прекрасно автоматизируется, но не потому, что "основной flow работал". Для автоматизации тестов нет необходимости что бы хоть что-то работало. Более того, для автоматизации тестирования нет необходимости в существовании тестируемого кода. И наиболее правильный (IMHO) вариант, когда код тестов появляется до тестируемого кода. То что по настоящему нужно для автоматизации тестирования - это соглашение об интерфейсах.

Цитировать
Миф 4. Чем больше времени проходит между внесением дефекта и его исправлением, тем дороже исправление
Так и есть. Это вовсе не миф. Хорошее время между внесением бага в код и донесением информации о нем до программиста - от секунд до четверти часа. Хорошее время между внесением бага в код и его исправлением - в пределах рабочего дня.

Ну и т.д.
Сергей Мартыненко
http://martyinenko-sergey1.moikrug.ru/



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

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

Так и есть. Это вовсе не миф. Хорошее время между внесением бага в код и донесением информации о нем до программиста - от секунд до четверти часа. Хорошее время между внесением бага в код и его исправлением - в пределах рабочего дня.

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

Кроме того, на большом проекте в разработке принимает участие множество людей. На одном из проектов, в котором мне довелось принять участие, команда состояла из 100 человек. Из них было 40 или 50 инженеров. При таком размере команды адресовать баг тому инженеру, который разрабатывал подсистему, в которой произошла ошибка, не так-то просто. Это, конечно, делается. Но получается не всегда.

Так что, с точки зрения отдельно взятого разработчика, Вы правы - проще баг исправлять сразу, пока детали реализации фичи ещё содержатся в памяти. Однако с точки зрения проекта и команды в целом, это не так.
С уважением,
Кирилл Лебедев
http://askofen.blogspot.com




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19