Публикуем доклад Печенкина Григория с предыдущей конференции 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 мая.

Автор: Polazhenko

Источник