Частина 2. Управління життєвим циклом додатка за допомогою ClearQuest 7.1.0.0

Ця стаття, яка складається з трьох частин, являє собою опис концепцій і проектних завдань готового рішення для управління життєвим циклом додатків (application lifecycle management, ALM) для IBM Rational ClearQuest.


Управління завданнями


Проекти задають контекст для нашої роботи, а ми повинні виконувати завдання, щоб завершити роботу над проектом. На всьому протязі розробки програмного рішення, щоб забезпечити виконання всіх завдань за проектом, необхідно виконувати безліч діяльностей. Робочі записи в пакеті ALMWork надають спосіб моніторингу вимог і завдань, які повинна вирішувати робоча група по ходу циклу розробки. У попередніх версіях ClearQuest управління завданнями здійснювалося за допомогою створення типів записів для кожного елемента, нужденного в управлінні (Дефект, Запит на зміну і т.п.). Однак у ALM-схемою основна увага приділяється розподілу завдань між співробітниками робочої групи. AML-схема надає основні типи записів для управління завданнями, а саме: Request (Запит), Task (Завдання) і Activity (Діяльність).



Кожній з цих трьох типів записів можуть також бути присвоєні “типи” (про яких розповідається нижче), що дозволяють додатково уточнити характер завдання.


Крім розподілу завдань часто виникає питання про коментарі з приводу завдання. Отже, надається також запис Comment (Коментар).



На малюнку 1 показані відносини між типами Requests (Запити), Tasks (Завдання), Activity (Діяльність) і Work Types (Типи завдань).


Відношення між типами requests, task, activities і work types

Малюнок 1. Основні записи для завдань. Запити визначають, яка “потреба” і де була “виявлена”. Завдання визначають, які завдання повинні бути виконані для задоволення запиту за проектом. Діяльності розподіляються між окремими виконавцями і спільно виконують завдання. Запис Work Types визначає характер завдання


Будь-яке завдання починається з Запиту певного виду. Запит описує ідентифіковану потреба і належить будь-якій зацікавленій в проекті особі, а Задачі і Діяльності являють собою записи для моніторингу ходу виконання завдання, яке було доручено виконавцям і повинно бути виконано для задоволення Запиту. Це дозволяє порівняти кількість запитів з кількістю доручених завдань. Крім того, це дозволяє проект-менеджеру оцінити обсяг роботи, пов’язаний з кожним запитом, а також обсяг завершених або незавершених завдань. Можливі також ситуації, в яких один запит надає вплив більш ніж на один проект. Такий поділ запитів на виконання завдань і доручень на виконання завдань дозволяє управляти Завданнями кожного проекту щодо виконання Запиту в специфічному для даного проекту контексті.


Схема потоку діяльностей за запитом

Малюнок 2. Використання записів для завдань. Спочатку сортуються запити і створюються завдання для проекту. Діяльності виконують завдання, після чого виконана робота аналізується, а запит закривається


На малюнку 2 показана схема потоку для роботи з цими новими типами записів. Стрілки позначають батьківські / дочірні відносини між записами.



Завдання починається з Запиту


Запис Request є вихідною точкою для початку роботи. Будь-яка зацікавлена ​​особа, направила Запит, регулярно перевіряє його стан і відповідає на будь-які питання або коментарі. Повноваження користувача схеми визначають, хто (тобто які користувачі, групи або ролі) може передати новий Запит (малюнок 3). Запис Request:



Знімок екрана

Малюнок 3. Новий запис Request


Деякі з показаних на малюнку 3 полів є обов’язковими. Якщо вказано значення в поле “project found in …”, то в полі security context (контекст безпеки) на вкладці history автоматично вибирається цей проект. Інші обов’язкові поля – це Headline, Type і Severity.


Переходи Запиту між станами дуже прості, як показано нижче. Запит може бути або виконаним, або невиконаним (малюнок 4).


Потік запиту

Малюнок 4. Потік для запиту


Приймання запиту переводить його в стан виконаний (completed)


Запит може бути відкликаний (withdrawn) або відхилений (rejected). Після переведення у стан rejected або withdrawn запит може бути знову відкритий. Завдання виконують запити в контексті проекту.











Поділіться думкою …




















digg Опублікуйте його на digg.com
del.icio.us Розмістіть на del.icio.us
Slashdot і на Slashdot!


При категоризації Запиту вказується, яка робоча група буде ним займатися. Ця робоча група аналізує Запит і вирішує, чи може він бути задоволений і до якого терміну. Якщо Запит буде виконуватися в рамках певного проекту, то в цьому проекті створюється Задача, яка асоціюється з Запитом, як показано на малюнку 5. Будь-який фахівець, який переглядає Запит, відразу побачить, які Завдання необхідно виконати для його задоволення. Будь-якому фахівцеві або зацікавленій особі при перегляді Завдання відразу видно, для задоволення якого Запиту вона призначена.


Запис Task:



Знімок екрана

Малюнок 5. Якщо Запит буде виконуватися в рамках певного проекту, то в цьому проекті створюється Задача, яка асоціюється з Запитом


Поля, виділені червоним шрифтом на малюнку 5, є обов’язковими. Якщо вказано значення в поле “project assigned …”, то в полях security context (контекст безпеки) і roles (ролі) на вкладці history автоматично вибирається цей проект. Інші обов’язкові поля – це Headline, Type, Severity і related Request (на вкладці Related Records).


Схема потоку завдання

Малюнок 6. Потік завдання


Переходи між станами для Завдання дуже прості (малюнок 6). Завдання може бути Opened (Відкрита), Activated (Активовано) або Completed (Виконано). Коли Завдання передається виконавцю, вона переходить в стан Open. Активація завдання означає початок її виконання. Завдання можна відкрити повторно.


Діяльності виконують Завдання


Керівники групи аналізують Завдання та визначають, які Діяльності необхідні для її виконання. Часто для виконання однієї Завдання вимагається праця декількох користувачів. Діяльності створюються і розподіляються таким чином, щоб один співробітник робочої групи виконував дискретну одиницю роботи, як показано на малюнку 7. Запис Activity:



Знімок екрана

Малюнок 7. Діяльність створюється і розподіляється таким чином, щоб один співробітник колективу виконував дискретну одиницю роботи


Деякі з показаних на рисунку 7 полів є обов’язковими. Інші обов’язкові поля – це Headline, Type, Severity і related Request (на вкладці Related Records). Поле Security Context на вкладці History успадковує значення з поля related Task. Діяльності також характеризуються простими переходами між станами, як показано на малюнку 8. В даному випадку таких станів чотири, як у UCM. Діяльності можуть мати стану Submitted (доручила), Opened (Відкрита), Activated (Активовано) і Completed (Виконано). Діяльність може перейти в стан Activated зі стану Submitted.


Потік діяльності

Малюнок 8. Діяльності характеризуються простими переходами між станами


Перемикання контексту


Поняття “перемикання контексту” заслуговує того, щоб йому приділили трохи уваги. У попередніх версіях ClearQuest запис використовувалася для документування всієї інформації в полях, а переходи між станами – для “просування” записи по процесу. У ряді випадків переходи між станами також вимагали перепризначення володіння записом іншому співробітникові робочої групи. У результаті кожне стан могло бути призначене для представлення однієї одиниці роботи, виконуваної окремим співробітником робочої групи (це досі працює в даних продуктах і підтримується виробником).


ALM-рішення надає альтернативний підхід. Щоб проілюструвати перемикання контексту, давайте візьмемо для прикладу запис “Defect”.


У попередніх версіях ClearQuest запис Defect використовувалася для керування всіма дефектами, виявленими в системі (малюнок 9). Вона мала набір змін стану. Наприклад, першим станом могло бути стан “Develop” (Розробити), яке доручалося розробнику. Наступним станом могло бути “Validate” (Перевірити), яке доручалося Тестувальник.


переходи станів

Малюнок 9. Переходи станів і існуючі записи ClearQuest


Після того як розробник закінчував свою роботу, запис Defect переходила в наступний стан, в результаті чого володіння записом переходило до Тестувальник. Ця модель працює до тих пір, поки у вас не з’являться дві окремі робочі групи, для кожної з яких потрібен свій набір переходів. Що робити в цьому випадку? У вас є три варіанти: створити новий тип запису для другої робочої групи, змінити переходи між станами в існуючому типі запису Defect і жорстко прив’язати кожний стан до однієї з робочих груп або повністю проігнорувати запит. У схемі ALM використовується інша модель (рисунок 10). Робота по новій моделі починається з Запиту типу Дефект. Цей тип запису можуть використовувати всі робочі групи. Він має просту модель переходу між станами і використовується для збору інформації про дефект і проекті, в якому він виявлений.


Потім створюється Завдання та визначається Проект, в рамках якого вона буде виконуватися. Вибір проекту визначає, які типи Завдань будуть доступні. Вибір типу Завдання визначає, який набір діяльностей необхідний для її виконання.


Блок-схема

Малюнок 10. Заміна переходу станів за допомогою діяльностей


У цьому підході замість використання складних діаграм переходу станів для переміщення окремої запису через декілька наборів користувачів можна просто створити набір діяльність. Оскільки Завдання і Діяльності конфігуруються для кожного проекту в самому проекті, адміністраторам ClearQuest більше не доведеться змінювати схему для кожного варіанту процесу, необхідного робочим групам проекту. Керівники проекту можуть просто конфігурувати набір діяльності, які, на їхню думку, необхідні для виконання кожного типу задачі (інформація про конфігуруванні завдання і діяльність відповідно до їх типом наводиться нижче).


Про типи завдань (запис Work Types)


Як вже говорилося раніше, Запити, Завдання і Діяльності можна додатково уточнити за допомогою атрибуту Type, що ідентифікує характер завдання. Наприклад, у вас може бути Запит з типом “Дефект” Завдання з типом “Виправити дефект” і Діяльність з типом “Реалізувати” або “Протестувати”.


Визначення запису Work Type можна налаштовувати; вони доступні в рамках всієї системи. Для налаштування типу завдання досить просто створити новий запис ALMType:



  1. Спочатку необхідно визначити ALMTypeLabels для типів. Кожен запис ALMTypeLabel просто визначає “ім’я” типу, наприклад, “Удосконалення”.
  2. Потім створюється запис ALMType. Зверніть увагу на те, що TypeLabels можна створювати безпосередньо із запису ALMType, як показано на малюнку 11.

Знімок екрана

Малюнок 11. Запис ALMType



  1. У полі ALMType виберіть Request (Запит), Task (Завдання) або Activity (Діяльність). Потім виберіть мітку для типу. Збережіть запис; тепер у вас є новий тип, який можна використовувати в будь-якому проекті під управлінням AML-системи.

Після визначення типів їх потрібно пов’язати з проектом за допомогою ALMWorkConfiguration; про це ми поговоримо трохи пізніше.


Простий приклад


Атрибути ALMType і TypeLabel дозволяють створити вельми настроюється систему для вашої робочої середовища. Якщо ваша організація використовує стандартний процес, наприклад, RUP або IT Infrastructure Library (ITIL ®), то ви можете додати в визначення типу відповідний глосарій.


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


Ви можете здійснити такий мінімалістський підхід, створивши мітки типу (Type Label) General і типи для Request, Task і Activity, присвоївши всім їм тип General. Якщо потрібно розрізняти Діяльності, то можна створити для них додаткові типи:



  1. Спочатку створіть проект та ролі.
  2. Створіть Запит, вказавши для атрибуту типу значення “General,” і асоціюйте його з проектом.
  3. Створіть Завдання, вказавши для атрибуту типу значення “General”, і асоціюйте її з Проектом та Запитом, які ви тільки що створили. Схема описаного підходу представлена ​​на малюнку 12.

Блок-схема

Малюнок 12. Діяльності, об’єднані в рамках однієї Завдання, створюють модель для малих проектів або динамічних груп



  1. Відкрийте запис Project і перейдіть на вкладку ALMWork Configurations. Додайте записи Request і Task як записи за замовчуванням для цього проекту (рисунок 13).

Фрагмент знімка екрана

Малюнок 13. Додавання записів за замовчуванням Request і Task в даний проект



  1. І, нарешті, для кожної порції завдань, яка повинна бути виконана, створіть Діяльність (будь-якого типу). Ця діяльність автоматично буде асоційована з Завданням, що була задана як запис по замовчуванням в даному проекті.

У даному прикладі усіма завданнями управляють Діяльності. Діяльності виконуються як черга завдань, в якій кожне завдання передається на виконання, а потім виконується. У проекті може бути багато Діяльностей, але всього лише одна Завдання і один Запит. Усі користувачі цього проекту будуть обізнані лише про діяльність і зможуть взаємодіяти саме з ними, однак їм не потрібна інформація про задачу або запит.


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


Ефективність “конфігурації завдань”


Описане раніше поділ на Запити, Завдання і Діяльності створює нову ефективну модель управління завданнями. Однак у попередньої моделі ClearQuest для визначення особливих переходів між станами використовувалося кілька типів записів. У результаті можна було керувати процесами за допомогою типів записів і їх станів. Виникає наступне питання: як можна керувати такими процесами в новій моделі? Чи доведеться для цього вручну створювати завдання та діяльності для кожного запиту? У первісній моделі потрібно було просто створити запис, а стану були вже визначені в цьому записі. У новій моделі одна діяльність являє одна зміна стану. Можливо, вам доведеться створити безліч діяльностей; як можна гарантувати, що в кожному випадку буде використовуватися одна і та ж діяльність?


Додайте запис Work Configuration (Конфігурація завдання), яка показана на малюнку 14. Саме тут повною мірою проявляється гнучкість нової моделі. Щоб адаптувати модель до робочого потоку кожної робочої групи, тепер можна призначити за замовчуванням набір діяльності, необхідних для виконання завдань для кожного проекту. У розумінні ефективності цього запису найбільшою мірою зацікавлені проект-менеджер та / або менеджер процесів. Іншим користувачам у робочій групі про це знати необов’язково.


Блок-схема

Малюнок 14. Запис Work Types визначає характер завдання; запис Work Configuration визначає рекомендований процес


Для визначення конфігурації завдання (Work Configuration):



  1. Створіть мітки типів завдань (Work Type Label);
  2. Створіть типи завдань (Work Types). Як вже говорилося раніше, атрибути Work Type визначають для того щоб описати характер завдання;
  3. Асоціюйте типи завдань (Work Type) з проектом за допомогою запису Work Configuration. Запис Work Configuration визначає, які типи завдань (Work Type) використовуються даним проектом. Крім того, їх можна використовувати для додавання рекомендованих процесів шляхом визначення набору завдань для даного типу за замовчуванням.

Записи Work Configuration дозволяють проект-менеджеру налагодити настроюється процес управління завданнями по кожному проекту окремо. Найкраще показати це на прикладі, тому давайте повернемося до нашого Приміром із записом Defect.


Проект “A” має запит типу “Проблема”. Для цього проекту створена наступна конфігурація завдань (малюнок 15):



Блок-схема

Малюнок 15. Два Проекту – два процеси для вирішення проблеми. Тут ми замінили одноразові переходи станів певними для всього проекту наборами діяльностей


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



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


На малюнку 16 показана конфігурація завдання для робочої групи проекту B.


Блок-схема

Малюнок 16. Конфігурація завдання для управління дефектом. Тип запиту може зажадати створення особливого типу Завдання, яка може мати власний набір діяльностей. У записі Work configurations визначаються всі ці політики процесу для проекту


Ми показали тільки один приклад, проте потенціал сценаріїв використання записи Work Configurations воістину безмежний. Наприклад, можна створити Завдання “Почати роботу по Проекту”. Ця задача може мати наступні Діяльності: “Визначити ролі”, “Підібрати співробітників для робочої групи”, “Визначити ітерації” і т.д. Ще одне завдання може бути пов’язана з уточненням вимог і мати окремі діяльності для створення контрольних прикладів, визначення тестів продуктивності і т. д.


Запис Work Configuration дозволяє проект-менеджерам налагодити процеси для кожного проекту окремо. Приклад AML-бази даних для “OpenUP” (який ми розглянемо трохи пізніше) ілюструє використання записи Work Configurations для реалізації процесу OpenUP.


Складання й релізи


Після кожної зміни вихідного коду додаток збирають і перевіряють, чи має воно достатню якість, що дозволяє перейти до тестування. Після перевірки виконується “розгортання” зборки на тестових серверах для тестування. Ця послідовність здачі змін вихідного коду, збірки і тестування додатка виконується незалежно від охоплення або розміру релізу, будь то нове, створюване з нуля додаток або крупний перегляд уже наявної програми, виправлення. При виявленні помилки реєструються дефекти, а у вихідний код вносяться зміни для виправлення дефекту. Після цього додаток знову має бути зібрано і розгорнуто на тестових серверах для тестування. Часто лише окремі фахівці в робочій групі знають, яку збірку необхідно протестувати, тому проект-менеджер повинен точно знати, хто ці люди.


ALM-схема підтримує таку модель робочих потоків, в якій має місце паралельність розробки і тестування. Після того як розробник зробить свою роботу і виконає діяльності з розроблення, він здає зміни в репозиторій. Інженер з релізам створює релізи (базові лінії), виконує збірки, перевіряє та передає зборки на тестування. Тестувальник виконує діяльності, пов’язані з тестуванням.


У проектах розробки програмного забезпечення зборки створюються безперервно. Звичайними питаннями до групи розробників є питання типу “які функції реалізовані в збірці” і “що тестувати в збірці”. ALM-рішення надає запис Build (Збірка), яка вперше з’явилася в пакетах Build і Deployment в ClearQuest 7.0.0.0. Ця запис дозволяє робочій групі документувати інформацію про кожній збірці. Крім того, ALM-рішення використовує запис Baseline (Реліз) щоб відслідковувати, які діяльності здаються в кожній збірці (малюнок 17). Завдяки записам Baseline, Build і Activity тестувальники знають, що необхідно тестувати, і можуть відслідковувати тести, виконані в даній збірці.


Знімок екрана

Малюнок 17. Інтеграція запису Baseline із UCM-рішенням


Основний потік виглядає так: коли інженер по релізам проводить зборку, є можливість зафіксувати, які діяльності по розробці були виконані. Для цього необхідно ідентифікувати діяльності, які були здані з моменту останньої збірки. Запис Baseline (Реліз) використовується для фіксації інформації про стан діяльностей на даний момент часу. Тим, хто вже працював з системами UCM, знаком термін baseline (реліз) і його зв’язок з фіксацією версії вихідного коду в будь-який момент часу. У ALM-рішенні ClearQuest з’явився запис Baseline, яку можна використовувати для відображення на релізи UCM. При створенні релізу в UCM, визначивши відмінності між діяльностями, можна зрозуміти, які діяльності є новими. Цей список діяльностей можна заповнити в запису Baseline, як показано на малюнку 18. Для тих, кому раніше не доводилося працювати з UCM, для ідентифікації списку діяльностей можна використовувати запити ClearQuest, які можна вручну додати до запису Baseline.


Фрагмент знімка екрана

Малюнок 18. Запис Baseline із заповненою секцією Activities


Після створення релізу виконується складання. Запис Build (малюнок 19) використовується для фіксації стану зборки. У цьому записі можна створити посилання на запис Baseline. Це пов’язує реліз і результат збірки. Про стан збірки повідомляє запис Build (збірка). Тепер інші співробітники робочої групи можуть використовувати цей запис, щоб визначити подальший напрямок роботи. Для готових збірок робоча група по тестуванню може проаналізувати запис Baseline і набір виконаних діяльностей. Кожна діяльність включає посилання на вихідну задачу, яка може включати і діяльності по тестуванню. Завдяки цій новій наочності контенту збірки тестувальники можуть більш розумно сконцентрувати свої зусилля.


Знімок екрана

Рисунок 19. Запис Build з новою вкладкою ALM


На перший погляд може здатися, що для цього потрібно занадто багато зусиль. Однак за допомогою скриптів збірки і автоматизації збирання велика частина роботи може бути автоматизована у складі збірки. Можна використовувати скрипт на мові Perl, який виявить відмінності між двома релізами і заповнить запис Baseline. Існує й інший скрипт на Perl, який призначений для створення і заповнення записи BTBuild. Рекомендується використовувати передовий метод, згідно з яким створення записів Build і Baseline включається в скрипти складання або в проект IBM Rational Build Forge ®. У процесі виконання збірки використовуйте пропоновані Perl-скрипти для автоматичного створення запису Baseline і визначення діяльностей для створення запису Build в ClearQuest і заповнення полів відповідною інформацією.


Управління ітераціями


Завдання можуть бути розподілені між ітераціями проекту. Це дозволить робочій групі проекту рівномірно розподілити робоче навантаження між ітераціями. Крім того, можна створити діаграми, аналогічні показаної на рисунку 20. Такі діаграми дозволяють проаналізувати розподіл завдань в робочій групі. Це допоможе проект-менеджеру рівномірно розподілити робоче навантаження між співробітниками робочої групи і уникнути ситуацій “критичного шляху”. Такі діаграми також допомагають проект-менеджеру переконатися в тому, що розподілені всі завдання.


зображення 3-мірної стовпчастий діаграми

Малюнок 20. Діаграма для управління робочим навантаженням


Зверніть увагу, що на малюнку 20 в стовпці “No value” є п’ять Завдань. Це означає, що вони нікому не доручені, і може служити для проект-менеджера сигналом про те, що частина завдань вислизнула від його уваги. Крім того, зверніть увагу, що у фазі конструювання робоче навантаження рівномірно розподілена між співробітниками робочої групи, тоді як у фазі передачі і супроводу, як і слід було очікувати, є зміщення робочого навантаження. Створюючи подібні діаграми, проект-менеджер зможе більш ефективно управляти своїм проектом, гарантуючи виконання усіх завдань та активну роботу всіх своїх співробітників і запобігаючи перевантаження окремих членів робочої групи великою кількістю роботи.

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


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

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

Ваш отзыв

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

*

*