Адаптуємо процеси 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>

*

*