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

В плане проекта отображается прогресс завершения стадии проекта, а также плановые и фактические трудозатраты по стадии.

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

Исправлена проблема отправки уведомления наблюдателю документа, если изменение было выполнено в дочернем разделе документа.

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

Добавлена возможность создания шаблона заявки непосредственно из списка шаблонов.

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

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

Улучшена поддержка отчетов с результатами выполнения автоматических тестов в формате JUnit.

Добавлена возможность кастомизации форм просмотра заявки и списка заявок на портале тех. поддержки.

Исправлена проблема с округлением значений трудозатрат на карточках пожеланий и задач.

Исправлена проблема прокрутки дерева структуры базы знаний с большим количеством разделов.

Исправлена ошибка в цветомаркировке состояния тестового отчета.

Исправлены проблемы настройки интеграции с чатами Slack.

Исправлена проблема сохранения настроек пользовательского отчета.

Для фильтров с большим списком значений (Автор, например) добавлена возможность выбора пункта "<нет значения>"

Исправлена ошибка при ручном указании автора заявки, как внешнего пользователя (с использованием Email)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Исправлена ошибка отображения релиза или итерации на форме пожелания или истории, если релиз или итерация завершены.