Чого я хочу від інструментів розробки вимог. Затички, милиці та граблі СУТ

  Публікуємо доповідь Печенкина Григорія з попередньою конференції Analyst Days 2013.
 
 

Анотація:

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

Відео доповіді:

 
 
 

Презентація:

 www.slideshare.net/VLDCORP/ss-21934097
 
 

Вступ

Ми розглянемо затички, милиці та граблі систем управління вимогами (СУТ) для того, щоб зрозуміти, чого я хочу від систем управління вимогами. На початку зроблю 2 оголошення.
В одному з анонсів доповіді, який попередньо розсилався, говорилося про те, що буде зроблений фундаментальний огляд СУТ. Огляду не буде. Насправді була така ідея: кілька реальних завдань СУТ пропустити через кілька систем, але коли я за це взявся, то зрозумів, що сильно переоцінив свої сили (пізніше я скажу, чому). Хороша новина в тому, що у мене є, куди вас послати :).
  
У минулому році в Києві проходила конференція REQ Labs, де відмінно була реалізована ідея: аналітичні поєдинки. На конференції були присутні три експерта, які, на відміну від мене, добре знають СУТ, тому що вони постійно ними користуються і проводять тренінги. У процесі роботи конференції перед експертами ставилося реальне завдання роботи з вимогами, і вони демонстрували, як це робиться в різних системах. Було запропоновано роботу з трьома системами: RequisitePro, Enterprise Architect, Sybase PowerDesigner. Якщо це питання когось зацікавив, відеозапис є на сайті компанії REQ Labs (http://www.req-labs.ru/conf2012/agenda/530/).
 
 
 
Друге оголошення (див. скріншот 2 презентації) вже належить до анонсу, який я надрукував в програмі.
  
 
 
А саме, я написав, що аналітики самий пригноблений клас серед IT-фахівців, тому що у них немає хороших інструментів. Але в процесі написання доповіді я зрозумів, що в аналітиків навпаки, занадто багато гарних іграшок, в які ніхто більше просто не хоче грати. Проблема в цьому, і про неї зараз буде вестися мова. Я розповім, чому виникла ідея доповіді, і яка проблема виникла перед аналітиками.
Я не є професійним аналітиком. Я був програмістом, потім менеджером, зараз моя посада називається — аналітик — і, виходить, я з чистою совістю можу сказати, що став аналітиком. Але був період, коли я раз на рік міняв роботу. Працював у трьох різних місцях. В одній компанії я працював технічним директором. Компанія була невелика, всього п'ять чоловік. В іншій компанії — вона була більше і складалася з тридцяти осіб — я керував напрямком. Зараз я працюю на проекті з розробки банківської системи. І кожен раз замовник (роботодавець) переді мною ставив проблему впровадження системи управління вимогами (СУТ) і було потрібно вибирати, які інструменти використовувати. Стаття присвячена саме темі, з якими проблемами мені довелося зіткнутися, і висновків, до яких я прийшов в процесі даної роботи.
В основному на проектах користуються такими СУТ: Excel Word, Polarion, Enterprise Architect, TFS, Wiki, Caliber, Jira.
  
  
  
У багатьох компаніях досі використовується пакет MS Office для розробки та управління вимогами. До того ж, зараз все більше поширюється Sharepoint, т.к. він дозволяє внести деякий порядок в хаос документів Office, плюс є можливість вести версійність контроль і порівняння. Дана система дозволяє на базі існуючих напрацювань компанії, які вони вели до цього в Word і Excel, організувати щось схоже на СУТ. І плюс додають до цього веб-інтерфейс, в якому можна програмувати (зараз, я знаю, програмісти Sharepoint є самими затребуваними і найбільш високооплачуваними, і якщо ви не знали, то рекомендую вивчити цю програму на всякий випадок). Розглянемо і інші системи.
 
 

Засоби візуального моделювання

У всіх на слуху програма Sparx Enterprise Architect, який дозволяє моделювати все, що завгодно. Спеціалізовані засоби розробки — IBM Rational RequisitePro, є й інші. Перераховані інструменти призначені саме для розробки вимог.
Є також інструменти командної роботи — ALM (Application Lifecycle Management). Зараз дуже активно набирає популярність MS TFS (Team Foundation Server). Я сам його дуже люблю і працюю з ним постійно. Це розробка компанії Microsoft — система управління «всім» в команді, іншими словами, інструмент командної взаємодії.
Засоби Wiki також набирають популярність. Wiki зазвичай інтегрують з task-tracker'амі, найпоширенішою з яких є система Jira. Я працюю в компанії, де використовується засіб Confluence Wiki в зв'язці з TrackStudio. Є ще варіанти, наприклад MediaWiki з Bugzilla.
Насправді, що з цього списку призначене для управління вимогами? Щоб відповісти на це питання, потрібно відповісти ще на одне питання: в чому різниця між розробкою та управлінням вимогами.
 
 

Розробка або управління

 
 
Ви, напевно, чули про модель зрілості CMMI (Capability Maturity Model Integration). У даній моделі управління вимогами відноситься до другого рівня, а розробка вимог — до третього рівня, тобто розробка вимог — це процес більш високого рівня, відповідного більш зрілого процесу в компанії.
Насправді, це взагалі різні процеси. Розробка — це те, чим займаються аналітики (або люди, яких зазвичай називають аналітиками). А управління — це те, чим зазвичай займаються менеджери: взаємозв'язок вимог з різними робочими артефактами: тест-кейси, завдання, код, та ін У кінцевому підсумку, вони пов'язують всі, що розробляє команда, з вимогами. На їх основі відслідковуються статуси, трасування і т.д.
З моєї точки зору, всі ці процеси нероздільні (хоч і в CMMI це не зовсім так). Проблема в тому, що для аналітиків створюються інструменти саме для розробки вимог, а для решти команди — інструменти для управління вимогами. У спробі їх зістикувати і відбуваються проблеми. Перш ніж ми перейдемо до аналітики, давайте визначимося з термінами: граблі, милиці, затички.
  
 
 
 

Визначення
 

Що таке «граблі»? Граблями я називаю якісь елементи, успадковані з інших галузей, застосування яких створює проблеми. Наприклад (цей приклад зараз не дуже актуальне, але 10 років тому, коли всі розробки велися в Word — це було дуже актуально), вимогам присвоюється якийсь ідентифікатор (засобами Word в тексті), на який ми в іншому місці посилаємося, потім змінюємо вихідний текст, внаслідок чого змінюється і номер, і далі вся структура зв'язків ламається. Сподіваюся, що у вас немає таких проблем.
На поточний момент бази даних впоралися з цією проблемою: більш-менш. Всі ми знаємо, що ідентифікатор присвоюється зараз по-іншому. Цей випадок я навів як приклад граблів. Насправді, в інших галузях таку ідентифікацію використовують і зараз: юристи, бухгалтера, коли оформляють договір, потім до нього додаткову угоду, яке посилається на якийсь пункт договору. Або, наприклад, виходить Закон або зміни до Закону, посилаючись на певний пункт до Закону. У реальному світі це працює, але спроба застосувати це в IT — це перенесення старого досвіду або граблі, на які хтось наступив і настає знову.
Що таке «милиці»? Це дуже поширений термін в IT — підпірки або тимчасові рішення. Як приклад, будь-яка інтеграція однієї системи з іншою є милицею: одна система не здатна щось вирішувати, інша система теж не може робити щось, і для того щоб їх синтегріровать, доводиться будувати милиці.
 
 
  
Що таке «затички»? Затички виникають у випадках, коли програма повинна виконувати певні дії сама, але перекладає ці дії на вас. Дуже поширене явище. Всі юзабіліті складається з затичок. Існує навіть анекдот про «узбецький вірус».
 
 
Анекдот. По електронній пошті до вас приходить лист, в якому написано: «Здрастуйте, я« узбецький вірус ». Мій розробник не встиг мене дописати, тому, будь ласка, відправте мене по всій адресній книзі і відформатуйте диск С. Спасибо. »
 
 
Багато програм поводяться саме так, але ми просто до цього звикли і навіть не звертаємо на це уваги. Отже, я дав визначення термінам, продовжимо далі тему.
 
 
 
 

Як вимоги розробляються зараз

Я пропоную розглянути приклад проекту, над яким працюю в даний момент, — це проект внутрішньої розробки. Я розробляю вимоги в Confluence Wiki (після того, як не зміг вибрати нормальний інструмент в рамках свого дослідження).
Для прикладу я вибрав досить примітивний старий варіант. Для розробника я даю таку сторіночку: контекст у складі діаграми варіантів використання інструменту (для того щоб вони розуміли, для чого цей проект створюється). Потім текстом описуються якісь конкретні вимоги.
 
 
  
У даному проекті розробляється візуальна панель, з неї користувачі можуть виконувати деякі операції (я вказую ті операції, які повинні реалізувати). І далі дається макет інтерфейсу — уявлення про те, як це все має виглядати.
 
 
  
Досвід показав, що ось така сторінка для розробників — це нормально. Вони розуміють, що вони роблять панель, яка буде виглядати приблизно так (у прикладі запропонований не реальний інтерфейс, а прототип), перераховані фактичні вимоги, що вони повинні зробити, і деякі контекстні подання у вигляді діаграми.
Звичайно, виникає питання: «У якій програмі, крім Wiki таке подання можна зробити ще?» Word мало чим відрізняється. Але пізніше вам стане зрозуміліше, чому я вибрав саме Wiki.
 
 
  
 

Учасники процесів управління вимогами

Я звернув вашу увагу на те, що управління вимогами — процес, який зачіпає інтереси всієї команди. Ви, як аналітик, розробляєте вимоги, потім ці вимоги використовуються різними людьми. Залежно від розміру компанії, масштабу проекту, технології, якісь з цих людей можуть бути, якісь не можуть, наприклад, можуть з'явитися юристи. Сенс у тому, що в центрі процесу управління вимогами знаходяться вимоги, які розробляє аналітик.
Нижче я представлю від імені цих людей деякі побажання.
  
 
 
 
1. Аналітик хоче вводити вимоги у вигляді тексту
Хочу звернути увагу, що не всі аналітики хочуть розробляти вимоги у вигляді тексту — в даному випадку це моя особиста перевагу. Більшість аналітиків з текстом працювати не люблять і вважають за краще працювати з візуальними моделями, особливо ті, хто працює в Enterprise Architect. Пояснюю, чому мені зручніше працювати у вигляді тексту: у такому вигляді мені зручніше працювати з командою — вони розуміють контекст.
 
 
 
 
2. Розробник хоче розуміти контекст
Весь мій досвід роботи в IT показує, що головна проблема програмістів в тому, що вони не розуміють контексту того, що вони розробляють. Вони іноді програмують, не приходячи до тями. Наприклад, у проекті розробки банківської системи багато програмістів. Вони абсолютно не розуміють, які процеси за цим стоять: при чому тут бухгалтерія, навіщо потрібні звіти. Вони отримують установку, що потрібно додати такий-то код у таку-то папку і в таку-то функцію. І люди роками так працюють.
Це, природно, призводить до проблем: відсутність розуміння контексту того, що вони розробляють, призводить до великої кількості проблем, досить дорогих. А для того щоб людей у ​​цей контекст занурювати, їм необхідно давати вимоги в зрозумілому для них вигляді. Нас дитячого садка і школи вчать працювати з текстом — для всіх це природний спосіб представлення інформації.
 
 
Текст або база даних?
 
Є протиприродний спосіб подання інформації — це база даних. Потрібно відзначити, що СУТ з'явилися тільки тоді, коли з'явилися бази даних, де можна розкласти все по поличках і відстежувати життя кожного елемента. Але ось тут і протиріччя: люди працюють з текстами, а зберігати їх потрібно в базі, приводить багатьох до легкої шизофренії.
 
 
  
Тому в більшій частині СУТ схиляються до текстового поданням СУТ, як це організовано в Wiki і Word, т.к. вони працюють з текстами, а системи професійні частіше схиляються до баз даних.
До чого це призводить? Припустимо, мені потрібно додати вимогу. Те, що я зараз розповім, багато з слухачів сприймають, як щось природне, тому що інших способів не знають. Коли ви створюєте нову вимогу, вас просять ввести його в діалогове вікно. На слайді представлено діалогове вікно з Enterprise Architect, тому що він не орієнтований на роботу з текстом і там це може бути виправдане.
 
 
Діалогові вікна
 
 
Наступний скріншот з TFS, тут інакше. У мене був знайомий, який звик працювати в Word, який категорично відмовлявся працювати в TFS-системі. Ця система дозволяє використовувати різні шаблони проектування (Scrum, MSF): з'являються вимоги, баги, change request, та ін У кожному випадку свій життєвий цикл.
А в чому сенс? Коли ставиться шаблон за замовчуванням, там кожен новостворений артефакт має статус proposed. Я не знаю, навіщо це було зроблено, напевно, з точки зору CMMI це було потрібно. Суть в тому, що коли людина додає нову вимогу, йому потрібно ще раз зайти в діалогове вікно і ще раз поміняти статус. Таким чином, він в діалог заходить два рази (звичайно, шаблон настроюється і це можна прибрати). Суть в тому, що потрібно кожен новий елемент вводити в діалогове вікно, а деякі системи ще змушують всі атрибути ручками виставляти — це свого роду бар'єр для впровадження СУТ.
 
 
3. Аналітик не хоче робити нічого зайвого
 
Я не хочу вводити кожен абзац в окремому вікні (а тим більше повторювати одні й ті ж дії для кожного з них). Я не хочу вручну виставляти всі статуси і постійно перемикатися між мишкою і клавіатурою (всім відомий синдром зап'ястного каналу). Це все вибиває аналітика з потоку.
 
 
 
Сподіваюся, що слухачі розуміють, про що я говорю. Коли ти сидиш і генерішь потік з тексту вимог, а тут: створив вікно, мишкою двинув, потім ще раз і т.д. Це дуже заважає працювати і дуже стомлює. Тому я вважаю, систему діалогових вікон одним із прикладів затичок, коли система на вас перекладає свій внутрішній устрій: ось у мене є база даних і зволь кожну запис зберігати окремо.
 
 
4. Аналітик хоче включати у вимоги візуальні моделі й зображення
 
Ще один приклад. Я вважаю найпотужнішим засобом представлення вимог — візуальні діаграми. Без цього просто ніяк не виходить.
 
 
 
В даному випадку, приклад, який був наведений вище в моїх вимогах — це mockup — макет користувача інтерфейсу (розроблений в програмі Pencil).
 
 
 
Сенс у тому, що для того, щоб картинку з вимогами вставити в Wiki, мені доводиться спочатку її експортувати в якийсь файл jpg-png-bpm і т.п., і тільки потім вставити його туди. І я завжди ще (раптом у когось виникне бажання поміняти щось без мене) туди вставляю посилання на використане засіб і посилання на файл. По-моєму досвіду, ні у кого і ніколи не виникає бажання встановити програму, щоб поміняти картинку. Насправді таких програм на диво багато.
 
 
5. Аналітик: не хочу виконувати експорт моделей в jpg-png-bmp-ітп
 
Він не хоче запускати руками свої редактори і зберігати моделі в окремих файлах.
 
 
  
 І якщо ви працюєте з Wiki, то вам доводиться в такому вигляді вставляти зображення. Це величезна проблема. Я не хочу, як аналітик цього робити. Я не хочу запускати інші редактори. Я не розумію, чому це не реалізовано в середовищі розробки вимог. Це прекрасно реалізовано в MS Office, коли ви малюєте діаграму в Visio, а потім вставляєте її в MS Office, після чого ви її тут же можете правити, не виходячи з Word.
 Іншими словами — це милицю.
 
 
 
6. Аналітик — не програміст і не хоче описувати картинки у вигляді коду
 
Інший варіант цікавий для тих, хто розробляє вимоги в Wiki (Media Wiki, та ін.) Для них буде зрозумілий наступний скріншот. Це плагіни до Wiki, які дозволяють створювати діаграми у вигляді тексту або у вигляді малюнка: PlantUML — простіший плагін і дозволяє малювати звичайні діаграми, а GraphViz — більш широкого призначення, там є можливість малювати будь діаграми, але мова програмування складніший (схожий на асемблер). Насправді це дуже зручна програма з точки зору представлення інформації. Ви можете змінювати свої діаграми, не використовуючи якесь зовнішнє засіб, більше того, ви можете відстежувати зміни (це теоретично, бо практично я жодного разу не бачив, щоб це було зроблено).
 
 
  
 Але я не хочу кодіть, хоча програмісти люблять цю програму. Насправді, якщо раптом користувачеві захочеться поміняти стрілочки або посунути фігури юзкесов та ін, то на це піде дуже багато часу на розуміння, як це зробити. Якщо ви в програмі Enterprise Architect це робите — там простіше, пов'язав те, що потрібно стрілочками і все, різниця зрозуміла.
  
 
 
Взагалі це можна розглядати по-різному. Можна розглядати як затичку, тому що я не бачу ніяких проблем, чому не можна зробити редактор безпосередньо на вебі. Його можна розглядати і як милицю, тому що я хочу в Wiki включати зображення і діаграми, але у мене немає інших засобів, і доводиться користуватися цим.
 
 
  
 
Хтось пам'ятає, що таке OLE?
Коли з'явився Windows 3.0 або Windows 95 і OLE просувалася компанією Microsoft саме як можливість вбудовувати один документ в інший: як я вже сказав, створюємо діаграму в Visio, потім вставляємо в Word і далі редагуємо вже в Word. Я до сих пір не розумію, чому в WEB немає такого стандарту. Щось є в Word, щось є в Flash, але єдиного способу немає. Ви розумієте, про що я говорю? Ви заходите на веб сторінку і прямо на ній редагуєте і щось малюєте. У мене великі надії на HTML5, тому що там вже з'являлося щось до цього, але знову ж таки не розумію, з яких причин це ще не стало мейнстрімом.
 
 
 
Існує сервіс draw.io, який дозволяє це робити дуже зручно і красиво, але при цьому діаграми зберігаються на їх сервері, ви їх можете вставити в свої сторінки, але не у себе. Можливо, це скоро зміниться. Саме тому зараз Microsoft Office так популярний — там всі ці проблеми інтеграції вирішені давно і зручно, і, крім того, існує безліч напрацювань.
  
 
7. Аналітик хоче знати, що змінилося у вимогах і моделях
Порівнювати тексти ми більш-менш навчилися. Програмісти вже освоїли системи управління вихідних кодів, є безліч засобів порівняння текстів, однак, порівняння моделей поки стоїть на місці, поки труба, хоча мені кажуть, що в десятому Enterprise Architect вже є можливість порівнювати дві версії, але я вважав, що так було спочатку.
  
 
 
Я не хочу запускати сторонні програми, а порівнювати двійкові файли безглуздо. Що нам пропонують власне системи управління вимогами, які я згадував на початку? Всі, хто презентує СУТ, вважають своєю перевагою експорт в Word. На це є кілька причин, це дуже затребуване, в тому числі тому, що Word дозволяє порівнювати тексти.
 
 
  
З картинками взагалі все погано. Якщо необхідно порівняти дві картинки, то вам потрібно вирішувати завдання «Знайди 10 відмінностей» — тобто порівнювати візуально. Інших способів немає.
 
 
  
 
8. Аналітик хоче обговорювати вимоги так, щоб результати обговорень завжди були під рукою
Аналітику доводиться обговорювати вимоги. Найбільш звичні способи — в Word і поштою. Ще можна зібрати нараду або роздрукувати на папері і поїхати до нього в гості з пачкою паперів.
Це все дістає. Я не хочу тягати пачки. Я не хочу нікуди їхати. І крім того, я хочу в процесі обговорення вносити правки.
 
 
 
Таку можливість надає Wiki.
 
 
9. Аналітик не хоче тягати з собою пачки паперу і не хоче нікуди їхати
 
Він хоче вносити зміни до вимоги прямо в процесі обговорення.
У нас на літньому аналітичному фестивалі (www.lafest.ru), який я весь час рекламую, виступала технічний директор фірми Human Factor Labs Олена Журавльова. Вона розповідала, як вони ведуть вимоги в Confluence. У них замовники дуже різні, в тому числі і державні, в тому числі і великі банки. І коли я намагався випитати у неї, як же вони експортують все це в Word, щоб з ними узгоджувати. Вона сказала, що вони нічого не експортують, а беруть сторіночку і вони (замовники) самі з нею працюють.
  
 
 
Люди до хорошого звикають дуже швидко. Головне, щоб їм хтось показав це хороше, але, на жаль, наша система управління вимогами, крім Word і Wiki, спеціально налаштована, цього робити не вміє. Що ми використовуємо? Єдиний спосіб — поштою.
 
 
 
Я взяв картинку з Інтернету, тому свою не зміг — там занадто багато конфіденційної інформації. Що бачимо: починають вносити коментарі до кожного слова, в кожному рядку. Все це швидко виростає в різнокольорову «локшину». Один абзац і до нього п'ятдесят коментарів від різних фахівців. Потім що робить аналітик? Перечитує все це, викидає і якось переписує. Тобто всі ці обговорення — милицю.
Або другий варіант, який ще гірше. Їде до замовника, де все обговорює, закреслює на папері. А потім з цим повертається в офіс, обробляє і викидає, бо з тим, що було за результатами обговорення, працювати неможливо.
 
 
10. Аналітик хоче пов'язувати вимоги один з одним
 
 
  
 Я не буду говорити про трасуванні: вимоги треба пов'язувати один з одним, різні компоненти, вимоги доводиться пов'язувати за рівнями (див. доповідь Ірини Суровой ). Знову ж нам доводиться використовувати для цього милиці.
 
 
 
 
Ієрархія в моделях
 
Я показую не дуже гарні приклади. В даному випадку це модифікований приклад з TrackStudio, де ми спробували вести вимоги. А для того, щоб встановити зв'язки між ними, спробували придумати ієрархію. Ієрархія сама по собі — це хороший милицю. Зараз це не тема для розмови, тому що це дуже багато особливостей: ми заздалегідь намагаємося придумати, які зв'язку з'являться у вимогах, а коли ми залазимо в предметну область і починаємо її моделювати, то виявляється, що ієрархія не працює. Загалом, ієрархія — це затичка!
 
 
Матриця трасування
Подивіться на наступний скріншот. З цим, хтось працює? Так, для планування тестування, відстеження змін.
 
 
 
Як я вже говорив, я не та людина, яка любить працювати з таблицями. Є люди, на жаль, які зомбовані таблицями. Наприклад, мій начальник: він відкрив для себе «чарівну» матрицю в Excel і потім вимагав всі документи розробляти в Excel, включаючи протоколи нарад, вимоги, і звіти. Я такий інтерфейс називаю: кишками назовні, тому що якщо ви хочете з'ясувати, які вимоги у вас покриті тест-кейсами, вам простіше вивести список тестованих робіт. Але деяким подобається. Але, тим не менш, це милицю.
 
 
11. Розробник хоче знати, які вимоги йому потрібно реалізувати, а менеджер проекту — які вимоги ще не реалізовані
  
 
 
 
Ми говорили про управління вимогами, а саме про зв'язуванні вимог один з одним. Це один момент. Але вся міць системи управління командною роботою полягає в тому, що вона дозволяє пов'язувати різні артефакти. Розробник бачить, які вимоги йому потрібно реалізувати в залежності від поставлених завдань. Менеджер проекту хоче знати, що там залишилося в проекті невиконаного і хоче знати (це особливо актуально, коли багато клієнтів), що вже встановлено у замовника. Спочатку ви посилаєте йому версії з різних гілок, а потім приходять запити, і ви намагаєтеся зрозуміти, що у нього вже є. Зокрема, в банківській сфері я постійно з цим стикався: потрібно визначити, які вимоги в поточній версії у клієнта вже реалізовані, а які ні. СУТ дозволяє на це питання відповісти.
  
 
 
 
12. Тестувальник хоче знати, які вимоги не протестовані
 
А тестувальника потрібно знати тест-кейси, які йому залишилося виконати.
  
 
 
У цьому і полягає завдання СУТ: всі процеси побудовані навколо управління вимогами, коли потрібно відстежити ті самі зв'язки між артефактами.
 Найкраще це зроблено в TFS, який дозволяє зв'язати що завгодно, з чим завгодно, яким завгодно способом, але при цьому інтерфейс виглядає ось так.
 
 
Зв'язки між артефактами
 
 
  
Тобто якщо ви хочете пов'язати одну сутність з іншого, вам потрібно ввести її номер. А 2 кольорових блоку в нижній частині вікна вони глумливо називають візуалізацією. Тобто TFS як-би каже: у нас, знаєте, реляційна база даних, тому всі реляції опишіть ручками. Це не нормально.
Наприклад, у програмі Enterprise Architect це реалізовано візуально: у вас є два квадратики і ви протягуєте між ними стрілочку.
Це затички, причому та самі, які поводяться, як «узбецька вірус». З одного боку, є багата можливість установки похідних зв'язків, а з іншого боку, слабкий інтерфейс створення таких зв'язків.
 
 
13. Замовник хоче, щоб його вимоги були зрозумілі правильно
 
Він хоче знати, що зроблено з його вимогами.
  
 
 
Ми вже говорили про узгодження вимог.
 
 
 
Я постійно це повторюю.
 
 
 
Для того щоб спілкуватися з замовником, ми постійно використовуємо експорт в MS Office, тому що ми вважаємо, що замовник дурень (хоча іноді це дійсно так), але в цілому, це призводить до проблем. Це сигнал про те, що вистачить використовувати затички.
 
 
  
 
Підсумок: який інструмент використовувати?
Загалом, я все вищесказане представив як діаграму варіантів використання СУТ, щоб підсумувати тему розмови. Насправді варіантів може бути набагато більше.
 
 
 
Є ще одна проблема, про яку я сказав на самому початку. Я — аналітик. Я приходжу в нову компанію, я хочу впровадити процес управління вимогами, включає в роботу і хочу використовувати свій інструмент, а що мені пропонують?
  
 
 
Дивимося варіанти.
 
 
 
Знаєте, що це? Це продукт Rational (інструмент керування вимогами IBM Rational RequisitePro, картинку взяв з Інтернету), призначений для всього: для тестування, для вимог. Простіше кажучи, як у приказці: коготок загруз — всій пташці прірву. Всі вони інтегровані між собою, дещо інтегрується і з чимось іншим (але це, в нашому випадку, граблі).
Є ще один варіант — Confluence (програма Atlassian Confluence) — магазин плагінів: Візьми кубики і збери те, що тобі потрібно.
  
 
 
Підсумуємо проблему.
 
 Команда хоче використовувати іграшки аналітиків
 
Цікаво, вдавалося кому-небудь загнати програмістів в Enterprise Architect з моделями працювати? Чим все закінчилося? Звичайно, програмісти бувають різні.
Але що я хочу сказати: навчити всю команду інструментів, утримуваних для аналітиків — не правильний підхід. З іншого боку, якщо ми спробуємо загнати аналітика в TFS — як ви пам'ятаєте, він може працювати тільки з текстами. Значить, пропадає вся зв'язок з візуальними діаграмами і виникає проблема зв'язків, про яку я говорив.
 
 
 
Хоча є досвід лабораторії Касперського — вони з'єднали TFS з Enterprise Architect, але це насправді мало, хто може собі дозволити, тому що в даному випадку виходить дуже дорогий проект.
Відомо, що інтеграція завжди виходить унікальною і аналітик не може перенести свій інструментарій в новий проект. У нас в компанії, наприклад, на підтримці зв'язки Confluence з Track Studio працює спеціальна команда, яка називається «Група підтримки корпоративного порталу», де чоловік п'ять і це найкваліфікованіші фахівці. Тобто це дорого обходиться.
 
 
Мрії
Як підсумок хочеться помріяти. Добре б взяти все найкраще з усіх інструментів і звести все в одному інструменті.
  
 
 
Я спробував створити оптимальну систему вимог до документів. Точніше, дані вимоги до системи народилися в клубі системного аналізу.
• Генерація документів в різних форматах
• Спільна дистанційна робота
• Облік впливу і трасування
• Версійність контроль
• Інтеграція з інструментами моделювання
• Зовнішні надбудови
 
 
 
Однак, в процесі роботи над своєю доповіддю я ці вимоги виправив.
Вимоги до системи документування розробки та управління вимогами
Генерація документів в різних форматах Зручне для всіх уявлення вимог
• Спільна дистанційна робота, в тому числі із замовниками
Облік впливу і трасування Зв'язаність моделей і артефактів
Версійність контроль Відстеження змін
Інтеграція з інструментами моделювання Вбудовані інструменти моделювання
Зовнішні надбудови Готовність до використання з коробки
 
 
  
І хочу показати, що вийшло.
 1. Введення вимог
Ось я вводжу текст в Confluence. Чому я повинен вводити дані в якусь форму? Можна ж машину це робити.
 
 
  
Виходячи з форматів вводяться вимог, машина сама повинна розкладати запису в базу даних. Нехай тут буде можливість корекції, якщо я вважаю, що вона щось зробила неправильно, я натисну Backspace, і вона прибере запис. Подібні системи є: Rational RequisitePro (в якості засобу введення тексту тут використовує MS Word) — тут вимоги набираються у вигляді тексту, які потрапляють в базу даних з граблями і косяками, що навіть на демонстрації видно. Технічних проблем це реалізувати я не бачу.
 
 2. Установка ієрархії і взаємозв'язків
Після введення тексту система сама повинна будувати зв'язки виходячи зі структури. Зрозуміло, що буде потрібно створити макет зв'язків, шаблон. Я за шаблоном в Confluence вводжу вимоги, а в базу даних запис потрапляє відразу з усіма зв'язками, як показано на діаграмі скриншота. Я не бачу в цьому жодних проблем. Звичайно, це треба програмувати.
 
 3. Побудова діаграм
Я хочу, щоб установлені зв'язку виглядали ось так. Я хочу змінювати діаграму, зробіть мені її на вебі.
 
 
  
Чому веб?
  
 4. Відображення змін
Якщо ми вже зберігаємо діаграми у вигляді запису в базі даних, як правило, запис зберігається в XML. XML — це текст, звідки ми завжди можемо вичленувати всі зміни. Чому це не можна показати на діаграмі я не розумію. Приклад: на скріншоті показано дві версії діаграми, де я відразу можу показати, що змінилося в останній моделі, в порівнянні з попередніми версіями.
 
 
  
 5. Узгодження з замовником
Питається, а навіщо взагалі потрібен текст? Але ідея в тому, що ми залишаємо текст в якості основного способу ведення вимог. Давайте працювати з цим текстом і дайте таку можливість замовнику: нехай він дивиться вимоги і ставить у пунктах, де згоден: like (нехай «лайкати»).
Насправді це дуже зручно. Замість того щоб їхати до нього з роздруківкою вимог у Word, ви даєте йому ось таку сторінку в Wiki. У нього свій інтерфейс для роботи з текстом і він зазначає: погодив — не погодив. Якщо потрібно обговорити — будь ласка, зазначив, що потрібно обговорити і тут же обговорюємо. Як це виглядає в сучасних засобах управління вимогами в TFS? Довгі й нудні обговорення.
 
 
  
 
6. Засіб для менеджерів
З текстом можна робити все, що завгодно. Зрозуміло, що можна налаштувати уявлення залежно від того, хто дивиться. Наприклад, для менеджерів проектів.
 
 
  
Спочатку він призначає, в який реліз це вимога піде, а потім стежить за зміною статусів. Таких прикладів можна навести багато.
 
 7. Створення зв'язків.
  
Що таке створення зв'язків? В даному випадку я спробував продемонструвати, як вимоги створити з тестовими сценаріями. Тобто тестувальник працює з контекстом вимог (у текстовому вигляді) і тут же може створювати необхідні зв'язки (вони відразу ж лягають в базу даних).
Зрозуміло, що для цього потрібна добре опрацьована модель спочатку. Іноді потрібно зв'язати щось з чимось, щоб в кінцевому підсумку ваш проект не страждав.
 
 8. Візуалізація зв'язків
  
 
Дану картинку я взяв з Інтернету. Сенс її ось у чому: замість того, щоб, як у TFS, все реляції забивати руками, зв'язку показувати візуально.
 
 
 
 9. Висновки
І, нарешті, найголовніше. Я все вищесказане про граблі, милицях і затички піднесено саме з точки зору аналітиків, але з моєї точки зору, потрібно брати інструменти командної роботи і до них прикручувати людський інтерфейс для аналітиків. Тоді проблема була б вирішена.
 
 
  
Тобто я хочу інструмент для всієї команди, але так все, щоб все, що напрацьовано в інших іграшках аналітиків, було зручно і для нього. З моєї точки зору, всі передумови для створення такого інструменту є. Як тільки такий інструмент з'явиться, він відразу, по-моєму, отримає високу популярність. Може бути, вони вже і з'явилися, тоді скажіть про них. (Дана хатинка на скріншоті символізує, щоб веб повернувся до аналітиків особою).
 
На цьому все. Спасибі всім.
 
Зустріти Григорія можна на наступній конференції Analyst Days в Москві 24 травня.
  
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.