3.2.4 Политика отслеживания и исправления ошибок

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

• Подробное описание шагов, необходимых для воспроизведения ошибки

• Ожидаемое поведение

• Наблюдаемое (неправильное) поведение

• Кому поручено исправить

• Исправлена ошибка или нет

Политика “Zero bugs” (ноль дефектов) которая была впервые внедрена Microsoft, теперь повсеместно используется во всех успешных компаниях создающих программное обеспечение, в том числе и для веб. Согласно этой политике, в любой момент времени наиболее важным является устранение ошибок до написания нового кода. И вот почему. В общем случае, чем больше компания тянет с исправлением ошибки, тем дороже (во временном и денежном измерении) ей это обойдётся. Например, если в коде приложения есть ошибка, которая обнаруживается при первом запуске, её можно тут же исправить, так как код ещё свеж в вашей памяти. Если ошибка обнаруживается в коде, который был написан несколько дней назад, потребуется какое-то время, чтобы отследить её, но если перечитать свой код, можно всё вспомнить и исправить ошибку в разумные сроки. Но если вы обнаружили ошибку в коде, который написан несколько месяцев назад, то вы скорее всего уже многое в нём забыли, и исправить её будет гораздо сложнее. Может случиться так, что вам придётся исправлять чужой код, автор которого отдыхает на Карибских островах. В этом случае поиск ошибки — целая наука: приходится долго, методично и тщательно искать, и неизвестно, сколько времени это займёт. А если ошибка обнаруживается в продукте, который уже продаётся, компания понесёт невероятные расходы, чтобы её исправить.

Вот это и есть главная причина, по которой лучше исправлять ошибки сразу: это занимает меньше времени.

3.2.5 Политика поддержки актуальности требований и документации

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

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

IV. Обзор подходов к планированию в рамках различных моделей и методологий разработки

Разработка приложений – это творческий процесс. Задача поиска повторяемого, предсказуемого процесса или методологии, которая бы улучшила продуктивность, качество и надежность разработки, стоит уже на протяжении десятилетий. Одни пытались систематизировать и формализовать разработку. Другие применяли к ней методы управления проектами и программной инженерии. Третьи считали, что без постоянного контроля со стороны заказчика разработка ПО выходит из-под контроля, съедая лишнее время и средства.

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

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