Статьи

Почему решили внедрять?

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

Скачал trial (90-дневную по-моему) версию и…

 

Как было до внедрения?

Расскажу вкратце, что было в компании до момента внедрения TFS:

·  Баг трекинг – MQC

·  Требования, запросы на изменение – SPS, Outlook (!)

·  Технические задания – SPS, SVN

·  Source Control – SVN

·  Автоматическая сборка – самописная утилита - командный файл

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

С чего началось внедрение. Описание процесса разработки.

Возможно, процесс разработки в нашей компании несовершенный, но успешно «живет» уже несколько лет и показал свою эффективность. Проектов в компании масса, у каждого есть свои особенности, но в целом процесс выглядит примерно так:

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

Собственно говоря, весь этот процесс и был переложен в TFS: заведены WI ChangeRequest (запросы на изменения), Defect (дефекты, не нравится мне слово баг), RequirementSpecfication (технические задания).

Для всех WI ввели понятие PlannedIn, чтобы можно было определить, в состав какого релиза входит WI.

Для ChangeRequest опредили новые поля EstimatedEffect и Cost, добавили новых статусов и т.д., таким образом ревью Change Request’ов превратился в изменение статуса WI на Accepted и указания, в каком релизе планируется разработка. Для EstimatedEffect мы реализовали возможность задавать значения: 3- High, 2 –Medium, 1 – Low, для Cost соответственно: 1 – High, 2 – Medium, 3 – Low. Таким образом, сортируя список WI по возрастанию поля EstimatedEffect (наверное, в релиз должны входить сначала полезные фичи, а не легкие по реализации), а потом по убыванию по полю Cost, мы получали список, в начале которого находились WI с большой эффективностью для бизнеса и низкой трудоемкостью для разработки. Они в первую очередь и включаются в состав релиза.

Всех деталей описывать не буду, желающим могу выслать xml файлы каждого WI.

Фишки:

Среди одной из многих фишек, реализованных в процессе внедрения TFS, отмечу следующую: как задать права на создание/изменение отдельного WI.

Почитав массу форумов нашел, что сделать это не просто, и чуть ли не единственный способ -  задать права на редактирование отдельных узлов AreaPath или IterationPath. Вводить в AreaPath разделы типа «Дефекты», «Запросы на изменения» и управлять таким образом правами для тестеров, разработчиков и пользователей не хотелось.

В итоге пришло в голову следующее простое решение:

Права на создание WI типа Defect только тестировщиками:

Defect.xml:

<FIELD type=”String” name=”Title” refname=”System.Title”>

<REQUIRED />

<READONLY not=”[Project]\Testers” />

</FIELD>

Права на создание WI типа ChangeRequest только определенной группой пользователей:

<FIELD type=”String” name=”Title” refname=”System.Title”>

<REQUIRED />

<READONLY not=”[Project]\Contributors” />

</FIELD>

Точно также управляется возможность отнести WI к тому или иному релизу только для ProjectManager’ов.

<FIELD reportable=”dimension” type=”String” name=”Planned In” refname=”Custom.PlannedIn”>

<READONLY not=”[Project]\Project Managers” />

</FIELD>

Что получили после внедрения?

Единая среда для работы с кодом, SourceControl, баг-трекингом для разработчиков и тестировщиков.

Веб-интерфейс для пользователей.

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

Теперь отдельно по пунктам:

Баг трекинг – TFS

В дополнение к баг-трекингу MQC получили возможность отслеживания изменения в коде, которые были связаны с исправлением ошибки, осуществить привязку дефекта к конкретному ТЗ.

Требования, запросы на изменение – TFS

Аналитики, пользователи системы через понятный web-интерфейс заводят требование. Прозрачные статус и история требования.

Технические задания – TFS

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

Source Control – TFS, SVN

Появилась возможность обязать указывать комментарии при каждой операции check-in. Source Control предоставляет возможность сочетать в себе работу SourceSafe и SVN одновременно. Появилась интересная фича «shelving»– все изменения хранятся на сервере разработки с ежедневным бэкапом, но при всем этом не полностью завершенные/рабочие изменения не доступны другим разработчикам.

Автосборка – TFS, самописная утилита-командный файл

После автоматической сборки на билд-сервере TFS выполняется автоматический запуск UnitTest’ов, реализованных в Visual Studio Team System, и если какой-либо из тестов «провалился», заводится специальный WI-дефект.

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

UnitTest’ирование

Возможность создания группы тестов и отдельного их запуска; мы делили тесты по группам: тестирование БД, тестирование финансового модуля, тестирование изменение профиля пользователя. Возможность задавать порядок выполнения тестов, да и вообще организовывать тесты в древовидной структуре, как хочется. Нагрузочное тестирование в Team System есть, но в виду того, что огромный объем тестирования был уже реализован в MQC, там его и оставили. Кстати, если Вы используйте NUnit, то перевести их всех в UnitTest’ы Team System не составит особого труда, существует утилита которая это делает автоматически, правда после ее работы придется уделить некоторое время на «причесывание» тестов.

 

Вывод

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

О своем опыте использования TFS и MS Project я расскажу в другой раз.