Wiki для управления требованиями

В качестве доступной альтернативы профессиональным инструментам управления требованиями некоторые команды рассматривают различные Wiki.

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

Слабые стороны технологии Wiki

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

• Работа с текстом, нет метаданных (атрибутов) и связей между страницами.
• Отсутствует концепция документа, что крайне важно для создания целостных, непротиворечивых и полных спецификаций или ТЗ.
• Нет концепции реестра требований, то есть нет работы с требованиями как с базой данных, что очень важно для продуктивной работы с большим объемом документации.
• Гик-подход к документированию вместо традиционного WYSIWYG, что не дружелюбно по отношению к аналитикам: нужно использовать спец. разметку, либо постоянно переключаться между режимом просмотра и редактирования страниц.
• Нет интеграции с остальными процессами, то есть требования сами по себе, разработка, тестирование и создание тех. документации живут как-то по-своему.

Чего нельзя сделать в Wiki

• Идентифицировать и атрибутировать требования, без чего крайне сложно управлять требованиями.
• Ранжировать требования (приоритет, оценка трудозатрат и т.п.)
• Организовать процесс разработки/согласования требований.
• Сохранить и сравнить версии документа, спецификации или ТЗ.
• Контролировать целостность требований/документации/продукта, а значит, при очередном изменении вы рискуете наделать очень много ошибок, которые обнаружите только перед релизом.
• Повторно использовать шаблон документа, а это часто нужно при создании типовых спецификаций и ТЗ.
• Создать ветку и мерджить изменения документа, что важно при параллельной разработки нескольких версий, либо кастомизации продукта под нескольких заказчиков.

Низкая эффективность использования Wiki

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

• Оценка прогресса подготовки/реализации требований.
• Получить текст спецификации на произвольную дату, версию продукта.
• Создать постановку на реализацию изменений в требованиях (изменение функциональности).
• Обеспечить качество продукта/документации при изменениях в требованиях.
• Увидеть изменения в формулах, UML-моделях, графических макетах UI.
• Оценить потенциальный объем изменений (анализ влияния).
• Узнать реальные трудозатраты по требованиям.

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

Несколько лет назад один банк попросил моего совета касательно проекта изменения системы обработки платежей. Работы было немного, и банк хотел использовать кое-какие преимущества Agile, чтобы ускорить разработку, но не хотел, чтобы Agile просочился куда-то ещё. К несчастью, это довольно частая просьба: «Увеличьте нашу скорость, только ничего не меняйте».

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

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