Devprom ALM: Руководство пользователя

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

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

На этапе проектирования участвуют:

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

Участники проектировочного цикла работают с пользовательскими требованиями и производят системные требования, прототипы и макеты, проверяют технические гипотезы (PoC). На основе системных требований формируются задачи для разработки (доработки).

На этапе разработки участвуют:

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

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

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

Процесс используется при контрактной разработке.

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

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

При необходимости получить более детальную оценку, с учетом различных затрат на разного вида работы, для каждого раздела ТЗ создается набор задач, выполнение которых приводит к реализации данного требования. Это могут быть задачи связанные с проектированием интерфейсов, разработкой, тестированием и документированием. Модуль "Трудозатраты по ТЗ" позволяет увидеть подробную смету работ по данному ТЗ. Смету можно выгрузить в Excel для передачи заказчику. При использовании бюджетирования каждому исполнителю можно задать рейт (стоимость часа работы), тогда при помощи модуля "Расходы по требованиям" вы сможете получить детальную смету на проект в деньгах.

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

Управление сроками выполнения ТЗ осуществляется в модуле План. Выполнение ТЗ лучше организовать итерационно - создать итерации, распланировать работы по ним, с использованием модуля "Оперативный план". При помощи настройки группировки доску задач можно разделить по исполнителям или по требованиям.

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

В бэклоге собираются все изменения к ТЗ: новые пожелания, замечания от пользователей, ошибки обнаруженные в процессе тестирования и т.п. Эти изменения изучаются проектной командой и находят свое отражение в техническом задании - создаются новые разделы ТЗ или изменяются существующие.

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

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

При описании бизнес-процессов, правил и ограничений, на основе пожеланий создаются бизнес-требования. Это могут быть документы BRD, описание бизнес-кейсов или бизнес-процессов. На основе бизнес-требований создаются производные системные требования, например, в формате вариантов использования, спецификаций, UML-моделей и т.п. Если на проекте формализация бизнес-требований не нужна, то на основе пожеланий сразу создаются системные требования: спецификации или отдельные варианты использования, макеты, UML-модели.

Чтобы распределить работу над документами или разными требованиями, можно создать связанные задачи и назначить их на аналитиков, архитекторов и проектировщиков. Ход разработки документации отражает статусная модель требований. Для контроля целостности бизнес-требований, системных и первичных требований, используйте матрицу трассировки.

Согласование требований реализуется через дополнительные статусы требований. Таким образом вы можете организовать последовательный или параллельный процесс согласования документации. Для привлечения представителей заказчика к согласованию, отправьте им по почте ссылку на документ (операция "Поделиться"). Согласующие смогут оставить свои комментарии и оставить резолюцию.

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

План реализации требований можно представить в виде релизов или итераций.

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

Передача требований в разработку происходит путем создания доработок (укрупненных задач на разработку). Доработку можно создать на весь документ, на все требования в документе (кнопка Реализовать) или при помощи массовой операции "Реализовать" над произвольным подмножеством требований. После того как разработка распланирована, можно приступить к проработке документации на следующий релиз. Для этого создается бейзлайн с названием очередного этапа. Изменения, которые будут вноситься в документацию не повлияют на ранее запланированные доработки.

На доске разработки расположены все доработки и ошибки, которые необходимо реализовать в плановом релизе или итерации. У доработок свой жизненный цикл, отличающийся от жизненного цикла пожеланий. Каждая доработка обычно проходит несколько стадий технологического процесса: разработку (то есть создание программного кода), тестирование и документирование. Вы можете добавить собственные стадии производства, например, проектирование. На этой стадии можно создавать модели, программные интерфейсы или макеты UI на основе ранее утвержденных требований. Более того, вы можете заменить процесс Kanban на Scrum, если в данном проекте это добавит эффективности.

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

.

Этот процесс очень похож на "Разработку по требованиям" с той разницей, что названия этапов проекта приведены в соответствие с ГОСТ-ом. Такой процесс можно применять и адаптировать в ситуациях, когда требуется формальное планирование и управление проектом на основе ГОСТ.

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