Лучше чем Microsoft TFS

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

Работа с требованиями

В Microsoft прекрасно понимают, что качество продукта в первую очередь определяется качеством требований. Однако, процесс разработки и управления требованиями в TFS практически не автоматизирован. Аналитикам и проектировщикам предлагается обычный трекер и минимум выразительных возможностей. В центре идеологии работы с требованиями - моделирование требований, то есть использование дополнительного толстого клиента (Visual Studio Enterprise), который позволяет рисовать и версионировать UML-модели.

Что же не так в TFS в части управления требованиями?

  • Нет представления требований в виде документов/спецификаций. Есть база данных требований, но получить целостное описание компонента, подсистемы или всей системы в виде одного документа/представления у вас не получится. Придется использовать дополнительные продукты, типа TeamSpec ($400 за лицензию).
  • Пользовательские требования или изменения в продукте приводят к появлению новых требований, а не к изменению существующих. Это классическая проблема ведения требований в трекерах. Проблема заключается в том, что после нескольких месяцев таких изменений, актуальные требования к приложению будут размазаны по множеству WorkItems. Их не выгрузить, не осознать, не прочитав все и не взаимоисключив конфликты в своей памяти.
  • Вы не сможете запланировать частичную реализацию требования, вам придется разбить исходное требование на части.
  • Все связи между проектными артефактами необходимо добавлять, обновлять и отслеживать вручную. Это приводит к дополнительному расходу времени и человеческим ошибкам. В Devprom все связи создаются естественным образом при создании артефактов, например, при создании доработки или тестового сценария на основе требования.
  • Нет никаких матриц трассируемости, только ручной и трудоемкий контроль целостности. Это почти то же самое, что документировать требования и их связи в Excel.
  • Вам обеспечена трудоемкая поддержка артефактов в актуальном состоянии после изменений в требованиях. Например, тестировщикам вручную нужно искать требования, затронутые изменениями и дорабатывать тесты. В отличие от этого Devprom сам следит за актуальностью связей и предоставляет механизм быстрого анализа и учета изменений.
  • Нет версионирования и бейзлайнов документов требований/спецификаций, нет анализа изменений в текстах и документах требований. Таким образом, вы не сможете узнать, что изменилось в требованиях между несколькими итерациями, релизами или версиями продукта.
  • Нет шаблонов требований и документов требований, то есть каждый аналитик будет писать требования как умеет, а то и каждый раз изобретать новую структуру для требования.
  • В отличие от Devprom, где UML-модель может добавить или исправить каждый член команды, даже добавить ее в комментарии, без установки какого-либо дополнительного ПО, для моделирования в TFS вам потребуется Visual Studio Enterprise.
  • Нельзя вставить макет UI (изображение), формулу или код-снипет непосредственно в текст требования. Все рекомендации на этот счет заканчиваются тем, чтобы вставить это в MSWord-документ, который затем прикрепить к WorkItem.

Тестирование

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

Чего не хватает?

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

Естественный вывод

Если вы не видите явных преимуществ в организации тестирования на платформе TFS, то без использования Visual Studio Enterprise, TFS представляет из себя довольно дорогой трекер ($45 за одну облачную лицензию в месяц). Воспользовавшись возможностью моделирования требований, вам придется заплатить $250 за одну облачную лицензию.

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


Подпишитесь на RSS