Wiki для управления требованиями
В качестве доступной альтернативы профессиональным инструментам управления требованиями некоторые команды рассматривают различные Wiki.
По многим причинам это является недальновидным решением, с которым затем вам придется жить и испытывать ежедневные сложности. Многие наши клиенты уже прошли через этот не лучший выбор и поделились с нами причинами и следствиями, о которых вам обязательно нужно знать.
Слабые стороны технологии Wiki
Применение неподходящего инструментария часто хуже, чем использование ручного труда, поскольку приходится изобретать способы как обойти естественные ограничения технологии.
- Работа с текстом, нет метаданных (атрибутов) и связей между страницами.
- Отсутствует концепция документа, что крайне важно для создания целостных, непротиворечивых и полных спецификаций или ТЗ.
- Нет концепции реестра требований, то есть нет работы с требованиями как с базой данных, что очень важно для продуктивной работы с большим объемом документации.
- Гик-подход к документированию вместо традиционного WYSIWYG, что не дружелюбно по отношению к аналитикам: нужно использовать спец. разметку, либо постоянно переключаться между режимом просмотра и редактирования страниц.
- Нет интеграции с остальными процессами, то есть требования сами по себе, разработка, тестирование и создание тех. документации живут как-то по-своему.
Чего нельзя сделать в Wiki
- Идентифицировать и атрибутировать требования, без чего крайне сложно управлять требованиями.
- Ранжировать требования (приоритет, оценка трудозатрат и т.п.)
- Организовать процесс разработки/согласования требований.
- Сохранить и сравнить версии документа, спецификации или ТЗ.
- Контролировать целостность требований/документации/продукта, а значит, при очередном изменении вы рискуете наделать очень много ошибок, которые обнаружите только перед релизом.
- Повторно использовать шаблон документа, а это часто нужно при создании типовых спецификаций и ТЗ.
- Создать ветку и мерджить изменения документа, что важно при параллельной разработки нескольких версий, либо кастомизации продукта под нескольких заказчиков.
Низкая эффективность использования Wiki
Инструментальная поддержка призвана повысить продуктивность работы сотрудников. Если этого не происходит по большей части типовых активностей, то очевидным становится факт применения не того инструмента. Вот перечень типовых задач, которые сложно и неэффективно решаются при помощи Wiki:
- Оценка прогресса подготовки/реализации требований.
- Получить текст спецификации на произвольную дату, версию продукта.
- Создать постановку на реализацию изменений в требованиях (изменение функциональности).
- Обеспечить качество продукта/документации при изменениях в требованиях.
- Увидеть изменения в формулах, UML-моделях, графических макетах UI.
- Оценить потенциальный объем изменений (анализ влияния).
- Узнать реальные трудозатраты по требованиям.
|
