Адаптуємо процеси TFS під свої потреби, Різне, Програмування, статті

Введення


Хоч Microsoft Visual Studio Team Foundation Server (TFS) і поставляється з готовими шаблонами процесів, але задовольнити вони можуть не всіх. Для нових і молодих команд в принципі стандартний набір шаблонів процесів TFS може покрити всі потреби процесу розробки, особливо для команд використовують гнучкі (Agile) підходи до розробки. Деякі при впровадженні TFS намагаються пристосуватися під те, що є, і в деяких випадках це проходить. Але пристосуватися під стандартні шаблони TFS не завжди представляється можливим, та й не завжди правильно. Адже у кожної компанії є свої сформовані традиції в розробці, своя культура виробництва ПЗ, які описують поточні процеси розробки ПЗ в компанії. Застосувавши існуючі стандарти до процесів компанії можна отримати якийсь гібрид процесу розробки, який буде найбільш підходити для компанії. У цій статті ми постараємося пояснити, як можна реалізувати такі нестандартні процеси за допомогою шаблонів TFS.


 


Що маємо?


Як я вказувалося вище, з TFS поставляється два вбудовані шаблону процесів:



Т.к. обидва шаблону процесів спрямовані на покриття потреби двох різних методів роботи, то і набори робочих елементів, якими можна оперувати в ході проекту розробки використовуючи ці методи, для цих шаблонів різні (див. Таблиця 1). Основними робочими елементами в Agile-методології є сценарії використання або взаємодії з системою, за допомогою яких описуються можливості системи і навколо яких і будується розробка. Крім того, використовуються завдання для ідентифікації роботи розробників і помилки, які були виявлені при тестуванні системи. CMMI в свою чергу використовує більш широкий набір робочих елементів: окремо виділені вимоги для визначення та документування можливостей системи, запити на зміну для обробки запитів від зацікавлених осіб, помилки для ідентифікації та виправлення помилок в системі, і т.д.


Таблиця 1. Список робочих елементів для Agile і CMMI















































MSF for Agile MSF for CMMI Опис
Завдання Завдання Визначає потребу у виконанні якої-небудь роботи.
Помилка Помилка Використовується для управління та документування виявлених помилок в розробляється.
Ризик Ризик Робочі елементи використовуються для опису можливих ситуацій або умов, які можуть негативно вплинути на успіх проекту.
Вимоги якості обслуговування   Вимоги не пов’язані безпосередньо з функціональними можливостями системи. Ці робочі елементи описують вимоги до безпеки, продуктивності системи і т.д.
Сценарій   Робочий елемент використовується для опису методів взаємодії користувачів в системі.
  Вимога За допомогою цих робочих елементів документуються вимоги, яким повинна відповідати система. Ці вимоги включають в себе як функціональні, так і нефункціональні характеристики системи.
  Запит на зміну Використовується для реєстрації та управління входять запитами від зацікавлених осіб, які мають на увазі внесення змін до проектовану систему.
  Проблема Цей робочий елемент призначений для виявлення і вирішення проблем, які вже негативно впливають на успішний хід проекту.
  Перевірка Робочий елемент описує роботи пов’язані з оглядом (рецензуванням) готового вихідного коду, програмних моделей і т.д.

Крім того, що між шаблонами Agile і CMMI різний набір робочих елементів, схожі робочі елементи мають різний життєвий цикл. Якщо, наприклад, взяти завдання (див. Рисунок 1), то набір станів для шаблонів буде наступний:




Рисунок 1. Завдання в Agile (ліворуч) і в CMMI (праворуч)


Будь-яка команда, яка хоче використовувати один з цих шаблонів, повинна ознайомитися з їх змістом, посібниками по процесу, які поставляються разом з TFS і після цього вирішити які правила по процесу для неї буде прийнятні.


Крім процесного підходу, тобто використання одного процесу на всю організацію, можна використовувати проектно-процесний підхід, тобто відповідно від типу і важливості проекту можна комбінувати процеси, які будуть в ньому використовуватися. Адже не обов’язково застосовувати важкий і формальний процес на проект, який буде тривати півроку і в якому братимуть участь п’ять осіб. І в іншому випадку, якщо є тривалий проект або проект з високою ступінь важливості, наприклад система управління кораблем, то зрозуміло, що застосування Agile-методологій в ньому вітатися не будуть. Якщо в організації присутні обидва типи проектів, то вона може для одного проекту використовувати Agile-шаблон, а для іншого – CMMI.


 


Як все влаштовано?


Вся робота в проекті TFS будуватися на основі шаблонів процесу. Шаблони містять в собі такі основні складові:




Рисунок 2. Опис завдання на web-порталі


Крім цього, шаблони процесів включають в себе налаштування версійність контролю, настройки інтеграції з MS Project, групи доступу і т.д. В TFS з шаблонами процесів можна виконувати наступне (див. Рисунок 3):




  1. Завантажити. Всі шаблони, які використовує TFS, можна зберегти на локальний диск, переглянути і відредагувати.


  2. Відправити. Нові або відредаговані шаблони можна завантажити на сервер TFS для подальшого використання.


  3. Видалити. Якщо шаблон процесу не актуальне і не використовується, то його можна видалити.


  4. Використовувати за замовчуванням. Якщо для більшості нових проектів використовується якийсь один шаблон процесів, то його можна зробити обраним за замовчуванням. І при створенні нового проекту, він буде завжди першим у списку.


Рисунок 3. Операції з шаблонами процесів


Тобто всі описи робочих елементів можна завантажити на локальний диск, причому, як разом з шаблоном процесу, так і окремо. Опис робочого елементу представлено у вигляді спеціального xml-файлу (див. Малюнок 4), яке можна проаналізувати, змінити і назад зберегти на сервер TFS. Опис робочих елементів містить:




Рисунок 4. Опис завдання


Нижче на малюнку (див. Рисунок 5) зображені варіанти, які TFS підтримує для редагування властивостей робочих елементів:




  1. Робочі елементи можна редагувати безпосередньо в описі шаблону процесів. В цьому випадку всі зміни, які були зроблені, фіксуються тільки в шаблоні процесів і будуть застосовані тільки для проектів, які будуть створюватися після застосування змін.


  2. Робочі елементи можна редагувати в функціонуючому проекті. В цьому випадку всі зміни будуть застосовані тільки для одного проекту. Для цього методу застосовуються спеціальні утиліти для окремого експорту та імпорту описів робочих елементів, які поставляються разом з TFS, – witexport і witimport.


Рисунок 5. Методи редагування робочих шаблонів


Тобто можна застосовувати зміни через шаблон процесу тільки для нових проектів або через утиліти імпорту / експорту для поточних проектів. Якщо ж зміни необхідні і для загального шаблону і для деяких робочих проектів, то можна виконати зміна в шаблоні процесу, а потім на основі тих же файлів шаблону процесу виконати оновлення за допомогою утиліт імпорту / експорту для всіх необхідних проектів.


 


Як адаптувати?


Після того, як в організації вирішили який шаблон процес використовувати, то швидше за все в найближчому часі з’явиться бажання щось змінити, адаптувати під свої потреби. Зміни можуть бути будь-якими, хтось захоче поле додати, елементи перегрупувати або змінити життєвий цикл робочого елементу. І після того, як шаблон процесу вивантажений на локальний диск, можна приступати до внесення змін. Але розбиратися із структурою xml-файлу, нехай навіть задокументованого, не завжди хочеться. Тому рекомендується в цих випадках використовувати набір утиліт, що забезпечують доступ до більш широкого набору функцій TFS, – Power Tools. Ці утиліти містять все, що необхідно для зміни робочих елементів:



Крім цього, утиліти дозволяють редагувати робочі елементи як в завантаженому на локальний диск шаблоні процесів, так і безпосередньо в робочих проектах.


Спробуємо розглянути зміна робочого елементу на невеликому простому прикладі. Припустимо, команда вибрала для своїх проектів шаблон процесів CMMI. Після тривалої і копіткої роботи з використанням цього шаблону команда зрозуміла, що їм не вистачає окремого стану для статусу завдання “Відкладено”. Тобто підхід до вирішення цієї проблеми в шаблоні, коли завдання переводиться в “Закрито” з переходом “Відкладено”, перестав розробників задовольняти, тому що в цьому випадку трохи складніше коштувати звіти по статусах завдань у проекті. Крім цього з’явилася необхідність додати поле “Відкласти до” містить дату, до якої роботи будуть відкладені. Використання цього поля дозволить команді організувати поштову нотифікацію, яка буде сигналізувати про те, що відкладені роботи вже необхідно починати при закінченні відкладеного терміну, і дозволить краще організувати управління відкладеними завданнями.


Передусім необхідно додати нове поле до існуючого робочого елементу. Для зміни складу і характеристик полів робочого елементу використовується спеціальний редактор полів (див. Рисунок 6). Цей редактор дозволяє створити нове поле, визначити йому необхідний тип (рядковий, цілочисельний, текстовий, дата і т.д.), поведінка полів (реакція на зміну значення в іншому полі), визначити можливі значення для полів. TFS також дозволяє використовувати списки для значень полів. Це можуть бути постійні списки, які не повинні змінюватися в процесі розробки, наприклад, значення типу так / ні або дерево ієрархії системи система / підсистема / модуль, значення типів дефектів і т.д. Також можуть бути непостійні значення, які реалізовані на основі спеціальних глобальних списків. Глобальні списки дозволяють організувати зміну значень у списку поле без необхідності зміни самого робочого елемента, наприклад, це може бути список версій системи, список конфігурацій для тестування і т.д.



Малюнок 6. Створення нового поля


Після того як поле додано, його необхідно відобразити на формі за допомогою редактора форм (див. Рисунок 7). Цей редактор дозволяє організувати всі поля на формі робочого елементу в зручному для використання вигляді. На формі поля можна об’єднувати в групи, якщо вони описують якісь загальні характеристики, поля та групи полів можна виносити на окремі вкладки, якщо полів багато. Для кожного поля, яке буде відображено на формі, можна визначити найбільш підходящий елемент користувацького інтерфейсу, тобто якщо це строкове поле, то це буде звичайне текстове поле, якщо це дата, то це буде поле з можливістю завдання дати з календаря і т.д.



Малюнок 7. Редактор форм


І останній крок – це формування нового стану і переходів для нього. Утиліти Power Tools надають можливість візуального редагування життєвого циклу для робочих елементів (див. Рисунок 8). За допомогою такого редактора можна просто і наочно змінювати життєвий цикл робочого елементу. Він дозволяє додавати, видаляти стану і переходи між ними, змінювати їх характеристики. Кожен стан може мати обов’язкові поля, наприклад, “Відкласти до” для нового стану “Відкласти”. Також можна визначити тільки певний склад учасників проекту, які можуть виконувати необхідні переходи, наприклад, закрити завдання може тільки менеджер проекту, перевіривши її виконання.



Рисунок 8. Редактор життєвого циклу


Результатом змін є форма (див. Рисунок 9), яка відповідає всім визначеним у робочому елементі правилам. Вносити зміни в робочі проекти або шаблони процесів потрібно уважно. Хоч в TFS і присутній механізм перевірки внесених змін, але ніхто не застрахований від помилок при реалізації логіки роботи робочого елементу. Наприклад, якщо вносились зміни до поведінки полів для створення динамічних списків і якийсь пункт був невірно виконано, то при збереженні такого робочого елементу в робочий проект, це невідповідність буде видно всім, що може викликати негативну реакцію серед співробітників, що працюють проекті. Тому, вважається хорошою практикою використовувати тестові проекти, тобто проекти, в яких ніхто не працює крім співробітника вносить зміни в опис робочих елементів і які він використовує для перевірки коректності змін. І тільки після того як всі зміни були протестовані і узгоджені з необхідними людьми, робочий елемент може бути збережений в робочий проект.



Малюнок 9. Готова форма


 


Підсумок


Поставляються шаблони процесів з TFS для Agile і CMMI дозволяють ініціювати проекти розробки для будь-якої команди малої або великий. Однак практика показує, що стандартні рішення не завжди можуть відповідати всім очікування компанії впроваджує готові рішення. В будь-якій компанії є свої сформовані стандарти, свої правила і методи роботи. Тому TFS передбачена можливість редагування шаблонів процесів, що дозволяє адаптувати їх під свої потреби. Команда розробки може взяти будь-який готовий шаблон, будь-то Agile, CMMI або шаблон, скачаний з інтернету, яких зараз велика уже кількість, і довести його до своїх вимог. Якщо ж жоден шаблон не влаштовує, можна піти більш радикальним шляхом, тобто виконати розробку свого власного процесу з нуля. У будь-якому випадку TFS забезпечує всім необхідним для того, щоб допомогти організувати в компанії якісний і задовольняє використовує TFS організацію процес.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*