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

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

В Devprom ALM вы найдете не только инструменты для управления процессом разработки ПО, но и готовые типовые схемы работы, которые можно применить как есть, а затем адаптировать под конкретные условия ваших проектов.

Наши типовые процессы делятся на две основные категории:

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

Типовые процессы предназначены для ознакомления с возможностями ALM, содержат предварительно настроенные данные и схемы работы. На основе типовых процессов вы сможете создавать ваши собственные, ориентированные на конкретные команды, проекты, схемы совместной работы.

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

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

В Devprom ALM требуемый результат описывается в первичных требованиях: пожеланиях, заявках и пользовательских историях, в зависимости от выбранного процесса разработки.

За технологию реализации первичных требований - этапы производства ПО - отвечают статусы требований и задачи.

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

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

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

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

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

Управление проектом на стадии поиска и создания продукта осуществляется на основе Scrum.

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

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

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

Пользовательские требования будущего релиза управляются процессом на основе Scrum. Здесь, как и в процессе "Поиск и создание продукта", осуществляется планирование спринтов, декомпозиция требований на задачи, демонстрация и приемка реализованной функциональности. Из-за того, что часть усилий команды будет оттягивать текущий релиз, требования к срокам (или составу) спринтов смягчаются.

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

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

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

С точки зрения управления проектом, в данном процессе используется подход Software Kanban. Это простой процесс из бережливого производства (Lean Management). Есть суть заключается в следующем:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процесс поддержки программного продукта обычно включает в себя следующие этапы:

• Сбор обращений пользователей через email, по телефону или через форму обратной связи.
• Попытка быстро решить проблему при помощи имеющихся типовых решенийили при помощи документации.
• Передача заявки разработчикам для исправления дефекта или реализации доработки.
• Общение с пользователем с целью выяснения деталей, сообщение о сроках решения заявки.

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

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

Для автоматизации процессов поддержки и разработки создайте два проекта: проект по поддержке создайте на основе шаблона "Поддержка", а проект по разработке - на основе шаблона "Баг-трекинг", например.

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

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

Если для решения заявки необходимо привлечь разработчиков, то выполните действие над заявкой "Реализовать в проекте" и укажите проект разработки. В списке "Мои заявки", в "Бэклоге" или на "Доске заявок" реализация этой заявки видна в столбце "Связанные заявки", где можно узнать статус заявки в проекте разработки.

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

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

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