Заметки консультанта

Шамрай Александр Владимирович

Как создать отчеты по умолчанию в Reporting Services для проекта Team Foundation Server

Posted by Shamrai Alexander на Февраль 16, 2018

<< Перейти в раздел «Team Foundation Server Admin FAQ»

По умолчанию, когда проект создается в TFS из веб-интерфейса, отчеты на основе Reporting Services не создаются. Однако отчеты дают неплохие возможности для подключения внешних заинтересованных лиц, включая возможность экспорта отчетов и подписки на отчеты, без необходимости обеспечения непосредственного доступа к проектам. Для того, чтобы «вернуть» набор отчетов по умолчанию, необходимо воспользоваться командой TfsConfig addProjectReports с параметрами:

/collection:’url к колекции проектов’

/teamProject:’имя проекат’

/template:’Шаблон для отчетов: CMMI, Agile или Scrum’

Пример выполнения команды:

Детальная информация о команде: AddProjectReports

Реклама

Posted in Admin FAQ, Microsoft, Team Foundation Server, Team Foundation Server FAQ, Visual Studio | Отмечено: , , | Leave a Comment »

Создание WCF сервиса для обработки событий из Team Foundation Server или Team Services

Posted by Shamrai Alexander на Январь 24, 2018

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

Данная функция очень полезна, если необходимо добавить дополнительною автоматизацию, которую TFS/VSTS не поддерживают. Например, создание пула дочерних задач, при переводе рабочего элемента в определенное состояние, или установка критической даты рассмотрения дефекта в зависимости от его важности и т.д.

В этой статье мы рассмотрим возможность создания wcf сервиса, который будет в состоянии «слушать» сообщения, которые приходят из TFS или VSTS.

Пример, как создать wcf сервис, который способен принимать входящие сообщения через метод POST, можно посмотреть здесь: https://www.codeproject.com/Articles/275279/Developing-WCF-Restful-Services-with-GET-and-POST.

Основные моменты, которые стоит отметить при создании сервиса:

  • В файле определения сервиса «имя_сервиса.svc» добавить атрибут:

Factory=»System.ServiceModel.Activation.WebServiceHostFactory»

  • Для метода, который будет в дальнейшем использовать для приема сообщений от TFS/VSTS указать атрибуты, которые будут укажут, что метод POST и работать он будет в json формате.

[OperationContract]

[WebInvoke(Method = «POST», RequestFormat = WebMessageFormat.Json, BodyStyle = WebMessageBodyStyle.Bare)]

  • Указать входящий параметр для метода как поток, который в дальнейшем будет преобразован в строку, а потом в нужный класс:

void WorkItemChangedEvent(Stream EventData);

Для конвертирования некоторой базовой информации можно использовать следующий пример класса:

public class WorkItemEventCore

{

[JsonProperty(«subscriptionId«)]

public string subscriptionId;

[JsonProperty(«notificationId«)]

public int notificationId;

[JsonProperty(«id«)]

public string id;

[JsonProperty(«eventType«)]

public string eventType;

[JsonProperty(«publisherId«)]

public string publisherId;

[JsonProperty(«message«)]

public MessageClass message;

[JsonProperty(«resourceVersion«)]

public string resourceVersion;

[JsonProperty(«createdDate«)]

public string createdDate;

}

Данный класс используется в методе при десериализации строки в экземпляр с помощью библиотек Newtonsoft.Json:

StreamReader _reader = new StreamReader(pEventData, Encoding.UTF8);

string _eventStr = _reader.ReadToEnd();

WorkItemEventCore _wieventcorre = JsonConvert.DeserializeObject<WorkItemEventCore>(_eventStr);

После развертывания решения на IIS можно выполнить тестирование метода. В моем случае создается подписка на VSTS на создание рабочего элемента:

Указывается адрес, на который отсылать сообщения, включая сервис и метод:

И после нажатия кнопки Test, можно получить информацию об успешности исполнения и пример отправленной нотификации:

Если выполнить отладку через подключение к сервису IIS, то можно увидеть следующий пример, который включает в себя экземпляр с информацией о событии и рабочем элементе:

Пример решения данной статьи находится здесь: https://github.com/ashamrai/tfevents

Posted in Microsoft, Team Foundation Server, Visual Studio | Отмечено: , , , , | Leave a Comment »

Как синхронизировать GIT репозитории между TFS, VSTS и GitHUB

Posted by Shamrai Alexander на Январь 17, 2018

<< Перейти в раздел «Team Foundation Version Control FAQ»

Интересная статья по синхронизации TFS 2015, VSTS и GitHub через сервис сборки: https://blogs.microsoft.co.il/leonj/2017/01/24/synchronizing-tfs-2015-and-vsts-with-github/

Posted in Microsoft, Team Foundation Server FAQ, Uncategorized, Version Control FAQ, Visual Studio | Отмечено: , , , | Leave a Comment »

Salma for Word v2.0.4

Posted by Shamrai Alexander на Декабрь 21, 2017

Выпустил очередное обновление для  Salma for Word: https://github.com/ashamrai/Salma/releases/tag/v2.0.4

Что нового:

1. Отказ от использования TFS Object Model в сторону Microsoft Team Foundation Server Extended Client. Это позволило обеспечить простую поддержку Visual Studio Team Services.

2. Добавлена функция для «устаревания» рабочих элементов. Очень часто возникает вопрос: что делать, если требование устарело? С точки зрения TFS/VSTS можно выполнить следующие шаги:

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

Поэтому из инструмента можно выполнить:

  • Копирование требования со всем содержимым в новое требование.
  • Перенести или скопировать необходимые ссылки в новое требование.
  • Пометить старое требование в его наименовании и/или с помощью тега.
  • Сохранить ссылку на требование источник.

obs_req

3. Автоматически связывать требование и документ. Если документ, находится в сетевом доступе, то можно выполнить настройку, чтоб при создании нового требования, автоматически вставлял ссылка на документ, в котором это требование «родилось». Соответственно, из требования всегда можно открыть документ-источник и просмотреть его контекст.

Posted in Microsoft, Team Foundation Server, Uncategorized, Visual Studio | Отмечено: , , , , | Leave a Comment »

Вебинар «Организация конвейера по производству ПО на основе VSTS» — Видео

Posted by Shamrai Alexander на Декабрь 13, 2017

Posted in Microsoft, Team Foundation Server, Team System, Uncategorized, Visual Studio | Отмечено: , | Leave a Comment »

Отчет по возрасту ошибок в TFS

Posted by Shamrai Alexander на Апрель 3, 2017

«Борьба» с техническим долгом команды является неотъемлемой частью любого процесса разработки. Команда всегда старается минимизировать количество существующих проблем, но зачастую для нового релиза устанавливаются пороги качества, которым он должен соответствовать, и в него входит пограничное количество ошибок определенной важности. Пороги могут варьировать в зависимости от сложности проекта, а иногда приходится выпускать релиз с превышением установленных порогов, находясь под давлением различных обстоятельств (дедлайны, требования заказчика или прямого руководства). В случае если выпущенный релиз содержит ошибки с высокой важностью, то команда старается описать ее как «известную проблему» и в ближайшее время старается ее решить. TFS обеспечивает необходимые отчеты, которые позволяют акцентировать внимание на текущие проблемы качества и их тренды. Но, к сожалению, нет отчетов, которые бы показали насколько старыми являются наши ошибки или насколько долго они находятся в определенном состоянии. Такие отчеты позволяют шире посмотреть на существующие ошибки:

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

Ниже рассмотрим пример создания подобного отчета. Для этих целей мы воспользуемся возможностями Report Server. Чтобы получать информацию о последнем изменении состояния, нам понадобится соответствующее поле. Такое поле в принципе в TFS поставляется из коробки, но оно не попадает в отчетную базу данных, т.к. не нас троен соответствующий атрибут. Пройдемся по шагам для создания нашего отчета.

  1. Поле для отслеживания изменения состояния. Это поле «Microsoft.VSTS.Common.StateChangeDate», которое обновляется при изменении состоянии соответствующей датой. Для того, чтобы оно попадало в отчетную базу, ему нужно установить атрибут Reportable в значение dimension. Для этого мы воспользуемся TFS Power Tools. На скриншотах ниже отображена последовательность шагов для обновления. После изменения атрибута сохраняем результаты работы.

Рисунок 1. Изменение свойства отчетности для поля

  1. Шаблон отчета. ALM Ranger-ы выпустили Руководство по отчетности TFS, которое было переведено в рамках данного блога. Данное руководство содержит предварительно подготовленный шаблон отчета на английском языке. Тут можно получить шаблон на русском языке. Шаблон отчета открываем в Report Builder и сохраняем в необходимом каталоге проекта на сервере отчетности.
  2. Параметры отчета. Для отчета можно установить параметры, которые позволят сузить количество выдаваемой информации, например, по состояниям. Для этого мы добавим новый параметр, установим для него возможные значения, установим значение по умолчанию.

Рисунок 2. Добавление нового параметра

Рисунок 3. Список выбора для параметра

  1. Набор данных отчета. Набор данных включает в себя запрос, который должен отобрать необходимые ошибки согласно заданным параметрам и при этом установить соответствующий атрибут его возраста. В рамках данного запроса устанавливаются атрибуты 1 неделя, 2 недели, 3 недели, 4 недели и более. Пример запроса:
SELECT

CurrentWorkItemView.System_Id

,CurrentWorkItemView.System_Title

,CurrentWorkItemView.System_State

,CurrentWorkItemView.System_AssignedTo

,CurrentWorkItemView.Microsoft_VSTS_Common_Priority

,CurrentWorkItemView.Microsoft_VSTS_Common_Severity

,CurrentWorkItemView.Microsoft_VSTS_Common_StateChangeDate

,CurrentWorkItemView.System_CreatedDate

,CASE WHEN (DATEDIFF(day, CurrentWorkItemView.Microsoft_VSTS_Common_StateChangeDate, GETDATE())>0) AND (DATEDIFF(day, CurrentWorkItemView.Microsoft_VSTS_Common_StateChangeDate, GETDATE())<8) THEN 1 ELSE 0 END One_Week

,CASE WHEN (DATEDIFF(day, CurrentWorkItemView.Microsoft_VSTS_Common_StateChangeDate, GETDATE())>7) AND (DATEDIFF(day, CurrentWorkItemView.Microsoft_VSTS_Common_StateChangeDate, GETDATE())<15) THEN 1 ELSE 0 END Two_Weeks

,CASE WHEN (DATEDIFF(day, CurrentWorkItemView.Microsoft_VSTS_Common_StateChangeDate, GETDATE())>14) AND (DATEDIFF(day, CurrentWorkItemView.Microsoft_VSTS_Common_StateChangeDate, GETDATE())<22) THEN 1 ELSE 0 END Three_Weeks

,CASE WHEN (DATEDIFF(day, CurrentWorkItemView.Microsoft_VSTS_Common_StateChangeDate, GETDATE())>21) AND (DATEDIFF(day, CurrentWorkItemView.Microsoft_VSTS_Common_StateChangeDate, GETDATE())<29) THEN 1 ELSE 0 END Four_Weeks

,CASE WHEN (DATEDIFF(day, CurrentWorkItemView.Microsoft_VSTS_Common_StateChangeDate, GETDATE())>28) THEN 1 ELSE 0 END Very_Old

FROM

CurrentWorkItemView

WHERE

CurrentWorkItemView.System_WorkItemType = N’Ошибка’

AND CurrentWorkItemView.System_State IN (@State)

AND CurrentWorkItemView.ProjectNodeGUID = @ProjectGuid

  1. Отображение отчета. Отчет может быть представлен в табличном или графическом виде. Мы же воспользуемся столбиковой диаграммой. Шаги установки атрибутов диаграммы отображены ниже.

Рисунок 4. Выбор набора данных для диаграммы

Рисунок 5. Тип диаграммы

Рисунок 6. Выбор полей для диаграммы

Рисунок 7. Стиль диаграммы

  1. Отчет готов. Можно оценить его результат.

Рисунок 8. Отчет «Возраст ошибок»

Готовый отчет можно скачать здесь.

Posted in Microsoft, Team Foundation Server, Visual Studio | Отмечено: , | Leave a Comment »

Работа с контейнерами и сервисами на основе Docker и Visual Studio Team Services

Posted by Shamrai Alexander на Март 22, 2017

Posted in Microsoft, Team Foundation Server, Uncategorized, Visual Studio | Отмечено: , , , , , | Leave a Comment »

Возможности по интеграции Team Foundation Server и Oracle — Видео

Posted by Shamrai Alexander на Январь 18, 2017

Posted in Microsoft, Team Foundation Server, Uncategorized, Visual Studio | Отмечено: , , | Leave a Comment »

Использование TFS REST API на примере решения для учета времени, потраченного на задачи

Posted by Shamrai Alexander на Июль 14, 2016

На сегодняшний день TFS предоставляет следующие основные механизмы для взаимодействия со своими данными внешним приложениям:

  • TFS API на основе клиентский и серверных моделей взаимодействия, которые обеспечивают доступ ко всем необходимым функциям и объектам TFS. Для работы этого подхода необходимо иметь соответствующие библиотеки, которые позволят выполнять необходимые операции.
  • Командная строка tf, которая обеспечивает взаимодействие с сервером для операций с версионным контролем TFVC.
  • Набор инструментов TFS Power Tools дают дополнительные возможности для работы из командной строки для оперирования с рабочими элементами, запросами, а также дополнительные возможности для использования Power Shell.
  • TFS REST API взаимодействие с сервером TFS на основе запросов в формате Json. Этот механизм не настолько богат набором функций как первый, но является в общем достаточным для обеспечения интеграционных задач. Кроме этого плюсом данного механизма является то, что нет необходимости устанавливать клиентские библиотеки, а в случае с VS 2015 необходимо устанавливать всю студию, т.к. Team Explorer отдельно объектная модель не поставляется.

В рамках данного поста мы рассмотрим, как можно использовать Rest Api, чтоб получить информацию о рабочих элементах и зарегистрировать свои. Пример использования приложен к статье в виде таймтрекер клиента, который позволяет подсчитывать потраченное на активности время и привязывать это к конкретной задаче, ошибке и т.д. Основные операции, которые выполняются приложением через REST API:

  • Получение информации об активных рабочих элементах, назначенных на текущего пользователя.
  • Создание рабочего элемента Активность и его связывание с родительским рабочим элементом из предыдущего пункта.
  • Обновление информации о времени в родительском рабочем элементе.

Выполнение запросов к TFS

Взаимодействие с сервером TFS или службой VSO выполняется на основе HTTP запросов в формате JSON. Вся основная информация о доступных методах находится по следующему адресу: https://www.visualstudio.com/en-us/docs/integrate/api/overview

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

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

  • GET – используется в основном для получения какой-либо информации, например, рабочего элемента или запроса по рабочим элементам.
  • POST – в рамках примера используется для выполнения запроса по рабочим элементам на основе Work item query language.
  • PATCH – для создания и обновления рабочих элементов. Т.к. данный пункт не реализован стандартными методами, то выполняется создание нового метода через new HttpMethod(«PATCH»).

Выполнение запросов на основе WIQL

В рамках примера WIQL используется для получения активных рабочих элементов. Подробнее можно посмотреть здесь: https://www.visualstudio.com/en-us/docs/integrate/api/wit/wiql.

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

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

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

Пример использования классов для получения необходимого списка рабочих элементов отображен ниже:

В начале функции идет формирование строки запроса, которая имеет изначальный следующий вид:

string QueryWisReq = «{Url сервера}/{Имя коллекции}/_apis/wit/wiql?api-version=1.0»;

Далее создается экземпляр класса для запроса по рабочим элементам и его свойству присваивается соответствующее значение, в нашем случае задается запрос, который отбирает все назначенные на исполнителя рабочие элементы в состоянии Активно. Следующим шагом выполняется преобразование класса в JSON формат и его передача в тело запроса к серверу TFS с использованием метода POST. Результат запроса преобразовывается в экземпляр класса FlatQueryResult, из которого мы получаем необходимый для нас список идентификаторов рабочих элементов.

Создание рабочего элемента

Подробную информацию о доступных методах для оперирования с рабочими элементами можно посмотреть здесь: https://www.visualstudio.com/en-us/docs/integrate/api/wit/work-items. При создании нового рабочего элемента задается запрос, который в своем теле несет информацию о новых атрибутах, включающие в себя:

  • Информацию о полях и их значениях:

  • Информацию о ссылках:


Пример использования классов для создания рабочих элементов отображен ниже:

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

  • op – отражает операцию с полем, при присваивании значения можно использовать выражение «add»;
  • path – путь к полю, которое формируется через слияние строк «/fields/» и имя-ссылка на поле;
  • value – содержимое поля при создании рабочего элемента.

Кроме этого добавляется информация о ссылках. В данном случае добавляется ссылка для родительского элемента с системным наименованием «System.LinkTypes.Hierarchy-Reverse», которая также является заблокированной, т.е. ее невозможно удалить стандартными средствами TFS:

_lnks.value.attributes.isLocked = true;

Для создания рабочего элемента формируется запрос:

string urlCreateWI = «{Url сервера}/{Имя коллекции}/{Имя проекта}/_apis/wit/workitems/${Тип рабочего элемента}?api-version=1.0»;

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

Исходный код приложения для примера

Для того, чтобы посмотреть подробнее как используют приведенные выше примеры, а также другие методы, можно перейти по ссылке https://tfstimetracker.codeplex.com/

Использование приложения, которое приведено для примера

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

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

Рисунок 1.Настройка параметров подключения к TFS

Рисунок 2. Настройка рабочих элементов

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

Рисунок 3. Выбор активных задач с помощью меню

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

Рисунок 4. Сохранение информации о потраченном времени на задачу

Рисунок 5. Новая активность и родительская задача

Итог

Как видно из примера, использование REST API при работе с рабочими элементами обеспечивает достаточную функциональность и при этом невысокую сложность. Отдельным плюсом является то, что данный подход является кроссплатформенным без необходимости использования каких-либо отдельных клиентских библиотек.

Posted in Microsoft, Team Foundation Server, Visual Studio | Отмечено: , | Leave a Comment »

Улучшения TFS 2015 Update 2 на примере работы с проблемами

Posted by Shamrai Alexander на Март 18, 2016

TFS 2015 Update 2 предлагает много различных обновлений, включая релиз менеджер, который теперь доступен через Web-интерфейс, а также работает с VMWare и System Center. Но есть также как, казалось бы, небольшие, но полезные функции. Например, функция подстановки отображаемого имени пользователя через символ «@». С использованием этого нововведения можно улучшить некоторые процессы внутри команды разработки, например, управление проблемами.

Зачастую этот процесс решается по довольно привычному пути — через телефон или корпоративную почту. Например, если возникает какой-либо вопрос, нужно что-либо уточнить, то инициатор в первую очередь пытается как-то решить проблему сразу личным общением, а если не получается, то начинает «писать письма». В больших компаниях таких писем очень много и существует много методик и советов как правильно работать с корпоративной почтой, но вряд ли все им следуют, что превращает почтовый ящик в солидный архив корреспонденции. Исходя из этого появляется небольшой список затруднений, связанных с электронной почтой:

  1. При большом количестве почты, включая обычно еще письма, в которых мы стоим просто в копии, получатель просто может упустить важное для него письмо и проблема долгое время остается незамеченной и нерешенной.
  2. Получатель может откладывать ответ для инициатора ввиду своей занятости, пока просто про него не забудет.
  3. Т.к. письмо в общем случае находится только в почтовых ящиках инициатора и получателя, то о процессе решения возникшей проблемы знает немного людей.
  4. Если в какой-то момент приходит точка Х, в которой нужно понять, что происходило, то это приводит к поиску в почтовом ящике, переборе потоков обсуждений и писем, а сделать это доступным для других участников можно только форвардом или распечатыванием потока обсуждения.
  5. Т.к. почта остается в личном ящике, то полученный опыт при решении проблем не может быть доступен для всех участников команды. А это может привести к повторному прохождению пути при решении схожих или этих же проблем.
  6. Невозможно понять сколько проблем у нас возникает, сколько мы решили, сколько еще нужно решить и сколько мы потратили на это времени.

Использование TFS может помочь упростить этот процесс:

  • Для управления проблемами в различных шаблонах существуют необходимые рабочие элементы, например, CMMI имеет Проблемы, Agile — препятствия, Scrum – также препятствия. Инициатор создает соответствующий рабочий элемент в командном проекте, назначает на исполнителя, который может решить проблему, и она доступна всем участникам разработки, включая руководителя проекта. Использование рабочего элемента позволяет определить правила обработки и эскалации при решении проблем.
  • Через символ «@» к решению проблемы можно привлечь необходимое количество людей, которые могут что-то подсказать или направить по нужному пути. Данную возможность можно использовать в комментариях для рабочего элемента, при этом им будет отправлено системой оповещение.

Рисунок 1. добавление участников к обсуждению

Рисунок 2. Пример нотификации

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

Рисунок 3. Пример запроса по рабочим элементам

  • Использование Report Server позволит собрать отчетную информацию по нашим проблемам, в том числе, если вы используете TimeSheet, что обсуждалось ранее, то вы можете учитывать время, которое было потрачено на их решение.
  • Все проблемы остаются в TFS, поэтому всегда можно организовать писк их решения через запросы по рабочим элементам и через стандартный механизм быстрого поиска TFS.

Posted in Microsoft, Team Foundation Server, Visual Studio | Отмечено: , | Leave a Comment »

 
%d такие блоггеры, как: