Конференция Req-Labs в Киеве прошла хорошо. Есть мелкие проблемы, которые я перечислю сразу - чтобы организаторы их учли, если прочтут мой отзыв. WiFi практически не работает, так что за докладчиков - я так и не голосовал. Залы - очень длинные и экран сзади видно плохо и мелко, можно, наверное, было попробовать повернуть расположение, повесив 2-3 экрана. А еще - не хватало указателей на улице к конференции для новичков в Киеве - в парк Пушкина в первый день и к нужной двери бизнес-центра во второй. А так - организация достойная. Два трека, большие перерывы для общения. Отдельный зал для общения с докладчиками, правда там было не слишком много народа.

А главное - достойное качество докладов. Много практических докладов, мало теоретиков. При этом, что характерно, эти авторы практических докладов теорию знают на высоком уровне. Поэтому рассказ практик идет в контексте современных теорий. Или наоборот, теории сильно иллюстрируются практиками. Что на современных конференциях встречается не так часто, как хотелось бы. О ценности докладов говорит то, что я очень много конспектировал на ноуте. Может быть, кончено, что я просто был на лучшей половине докладов. Но, с другой стороны, лучший по итогам голосования на facebook в день конференции докладе я пропустил. Это "Бизнес-аналитик или бизнес-синтетик? Или как сделать бизнес-анализ чуть менее унылым" Артёма Сердюка (ISM Ukraine, Украина), который шел параллельно с докладом Пола Тернера. Буду будет смотреть видео.

Что интересно - организаторы говорят, что при организации Конференции были воплощены многие идеи, высказанные участниками мозгового штурма на мастер-классе в рамках AnalystDays в Минске.

Дальше - краткий обзор докладов.

Содержание

1 Что особенно понравилось
2 Остальные доклады
3 Тренинг Создание концепции решения Дима Безуглый

Что особенно понравилось

Business Architecture. Paul Turner

Why is an understanding of Business Architecture important to Requirements Engineers? Paul Turner (AssistKD, Business & IS Skills, Великобритания).

В докладе много схем, структурирующих область ведения проектов и работы бизнес-аналитика с разных точек зрения. И эта структура отличается от того, который у меня лично сформирован преимущественно IT-шыми источниками, и это - интересно, потому что расширяет и дополняет представления. Правда, примерно до середины эти представления были на достаточно высоком уровне абстракции, что не столь интересно. Но потом - было несколько более глубоких схем. Существенным недостатком этого доклада была быстрая речь докладчика. которую я понимаю только полностью концентрируясь. Поэтому когда на слайдах возникала интересная схема, в которую вчитывался - я терял часть доносимого устно смысла. Так что тоже буду смотреть видео.

Схемы пересказывать глупо и бесполезно - надо смотреть презентацию. Но кое-что отмечу тезисами.

Метаформа строительной архитектуры - она понятна. Но, в отличие от многих докладов с рассуждениями о прекрасном - раскрыта, при чем неожиданно. В строительстве - строят вместе, и нужна конструкция, а в бизнесе - работают вместе, и тоже нужна конструкция.
Бизнес-архитектура существует независимо от нашего знания о ней - поскольку бизнес работает.
Область: Бизнес-архитектура, Архитектура приложений, Архитектура данных и Архитектура инфраструктуры. И это - отличается от других моделей наличием Архитектуры данных.
Архитектура приложений и данных - должны выводится из архитектуры бизнеса, а не из технологий. Ну, это понятно.
Архитектура - это модель, между стратегическим уровнем и исполнением.
Aspects of Business: Capability, Organization, Information, Stream Value
POPIT - holistic approach. IT - center, Organization, People, Process. Тут надо смотреть слайд.
Надо помнить. Map is not territory!

Enterprise Analysis. Adrian Reed

Enterprise Analysis: The importance of the ‘why’ and the ‘what’. Adrian Reed (Blackmetric Business Solutions, Великобритания).

Я третий раз слушаю доклад Адириана и, надо сказать, их уровень растет, этот доклад был лучше и живее. В этот раз он достаточно плотно рассказывал про Enterprise Analysis - subset of BA, и создание project concept.

Problem description frame.

The problem of -- What
Affects is -- Stakeholder, it's important
Impact of which is -- Why care
Succesfull solution

И далее анализ целей.

Техники:

Brainstorming, Focus group, Survey/Quest.
Работа с целями: CFS (Core Success Factor) and KPI (Key Perfomance Indicator)
What if EACH stakeholder achieve thir result? Area of contradiction.
Transfer from partial satisfied goal of project to UNsatisfied.
Use case diagram for goals.
Gap analysis. Compare "fit". Eliminate some solutions...

В докладе был пример, достаточно хороший. Неожиданный успех маркетинга привел к тому, что call-центр по приему заказов захлебнулся, и был придуман несимметричный ответ - переход к заказам по e-mail. Интересно, что Адриан попытался показать, как возникает эта трансформация, поднимается уровень целей - потому как в начальной задаче речь, естественно, шла о мерах по повышению производительности call-центра.

Requirements Engineering in Automotive Industrie. Irene Koschel, Sergej Schmidt

Requirements Engineering in Automotive Industrie: From the practice – for the practice. Irene Koschel (XTRONIC, Германия), Sergej Schmidt (SMR Automotive Mirrors Stuttgart, Германия). Докладчики - двое русских, работающих в Германиском автопроме в разных фирмах, но на совместном проекте. Была только Irene, Сергей приехать не смог.

Интересно, что кроме гигантов производства в Германии, множество (700+) небольших фирм, которые аутсорсят, в том числе - дизайн и тому подобное. Она - в небольшой фирме, которая подрядчик Даймера, плюс выпускает e-roller. Их E-roller 20 км/ч и это - уникальная скорость для электромобилей. А еще - бортовые компьютеры. Фирам интернациональная, 18 национальностей. А он - из немецкой фирмы, которую пару лет назад купили индусы. Производят зеркала и смежные системы - сенсоры, видеокамеры с выводом на бортовой комп, и там тоже много софта, надо отслеживать парковку, движение в мертых зонах и прочее. Совместный проект возник потому, что SMR умел делать зеркала, а XTRONIC - нужные сертификаты по процессам для серийного проекта.

Современный автомобиль - это не только hardware, это более 2М строк кода, который обеспечивает работу двигателя, тормозов и всего остального - без софта он не едет. Вообще самолеты уже давно ведет автопилот. А сейчас - тренд к автоводителю. Потому что без него - плохо для людей с плохим зрением и прочими проблемами, плюс больше рисков. В 15 году Германия вводит правило - система автоторможения автомобиля по препятствиям (и еще что-то?).

К софту автомобиля - очень жесткие требования, это работа в реальном времени и без ошибок. При этом там много процессоров в разных устройствах, но все они должны работать согласованно. И идеей доклада было рассказать о схеме работы с требованиями в этих проектах. К сожалению, в тайминг уложиться не получилось. Была большая вводная историческая и общая часть, очень интересная, но из за этого слайды про ведение требований пришлось проходить в бешеном темпе, а на живую демнострацию вообще времени не было. Но интересующиеся могли найти докладчицу в перерывах и посмотреть.

В докладе была интересная история старой пикировки GM vs Microsoft. Ее надо посмотреть на слайдах. А всерьез на автомобиль 500 документов, около 300 страниц в каждом.

Требования:

Все разработчики должны говорить на одном языке - чтобы обеспечить понмиание
Требования - обязательно в DOORS. Она хотела показать, но не успела. И там реально две модели, одна - требования, другая - уровень модели, дальше в тесты CRS - SRS - TS. И обеспечивается трассировка, соответствие и прочее - они нужны.
Сертификация SPICE 2-3 минимум уровень (общий стандарт), в целом аналогичен CMMI. Вариант Automotive SPICE - адптированный и сокращенный (из 48 - оставили 15). Очень разумно.
Предписание - обязательна V-модель со стадиями, с передачей и тестированием.
Описание процессов - есть ссылка в презентации. В частности - процессы по требованиям.
Производитель реально пишет спецификацию. И реально идет доработка спецификации в процессе конкурса. Процесс доработки и согласования спецификации - описан.

В конце был headhunting на работу в Германию в автопром, облегченный greencard. И замечательная врезка о женщинах в автопроме. Первые права - женщина, первый штраф за превышение скорости - тоже, и первый автопробег вокруг Земли... В общем, женщины - рулят. Она - в чужой стране и мужской отрасли.

И пара штрихов.

Консультант - это человек, который снимает с вашей руки часы и говорит который час. Шеф сказал, что это не анекдот, а жизнь. Правда из контекста было неясно, поняли ли они, что консультант не отдает часы. сказав который час.
Ее наблюдение: в Киеве больше хороших и дорогих автомобилей, чем, например, в Штутгарте.

Тестирование требований: кто, когда и как? Наталья Руколь (Лаборатория Качества, Россия)

Как всегда, очень живой и доклад. Я, правда, был не сначала - общение затянуло. Идея - про улучшение процесса. Которое всегда должно начинаться с анализа причин. А кроме мер - должно быть понимание, как будем оценивать успех.

И все это - на конкретном кейсе, проект в котором 2.5 разработчика, а аналитик занят сильно не полностью. И в какой-то момент - обнаруживаем что слишком много багов на проекте. Как способ - классификация багов: Ошибка/Не понял/Не было требования/Изменение требования.

Вопрос был - а не будет ли читерства? В их коллективе - не будет. Но если подозреваете - можно двухстороннее ревью.

Навели статистику, поняли измеримо, что проблемы - не в 2.5 разработчиков, а в том, что всего 20% аналитика. И тут получается реальный ROI. Правда пока с этим примером - ROI не подтвержден, но проблема - уже решена.

Методы:

Проверка по чеклисту. Их можно делать и по требованиям. Хотя бы копипастом из вики на уровне общеизвестных - от этого можно стартовать, укоротив до разумного набора - нормативно обычно дофига признаков.
Определение цели для каждой фичи. Очень часто аналитики предоставляют требования "как", но не делятся "зачем" и разработчики ходят не туда. Плюс - демотивация и прочее. Надо: какую и чью проблему решаем, критерии успеха, хорошо бы проверяемые.
Презентация требований. Вообще это тренд, все больше появляется. Зачем, как анализировал, предложенное решение. Важно начинать с цели. И надо как мероприятие, а не поболтаем за жизнь.
Разный подход к требованиям. НЕТ стандартам представления - потому что очень широкий спектр требований. Одно очевидно, другое - требует текста, третье - картинки. После презентации - можно понять, насколько детальная проработка нужна. И на ней можно спросить формат.
Фиксация требования исполнителем (разработчиком) - очень хорошая практика. И на том маленьком проекте они добавили Презентацию плюс фиксацию разработчиком - а аналитик только делал review. В принципе техника "повтори как ты меня понял". Правда, разработчиков заставить писать почти нереально. Зато тестировщики это делают охотно.
Трассировка требований - связывание с багами, тестами, задачи на разработку, статусы, согласование с заказчиком. Новое требований сложно потерять, а изменения - теряются на ура.

Выводы. Все компании - разные, и проекты тоже, поэтому требования - разные. Но вот улучшения - общее. Начинаем с анализа, и потом - придумываем решения, а потом - проверяем эффективность.

Люди, методология, процесс и культура в обеспечении качества работы аналитика. Дмитрий Безуглый (System Approach, Россия)

Дима рассказывал о том, что говоря о качестве работы с требованиями, люди часто подразумевают поиск ответа на вопрос "кто виноват". И даже когда формулируют "как улучшить?", подразумевают, что это просто надо что-то сделать с аналитиком, чтобы от него получались хорошие требования. А реально качество требований имеет четыре составляющих:

Люди
Методология
Процесс
Культура

И важны все четыре, поэтому на этапе анализа они должны быть рассмотрены, и выявлены наиболее проблемные места, с которыми нужно работать. Особенно часто забывают культуру, а именно она обеспечивает что делаем то, что нужно. Без нее будет идеальная поставка качественного ненужного продукта.

В докладе было много историй и примеров из опыта.

Упоминавшиеся техники и подходы.

SWEBOK. 4+2 процесса работы с требованиями.
Проблема дивергертного и конвергентного мышления.
1. Конвергенция. Задача выбора правильного задача, транспортная. Все обучение строится на нем, и это - задача аналитика. Работает когда информации достаточно.
2. Когда информации недостаточно - нужно дивергентное мышление, с вариантами выбора. Но к нему способны далеко не все.
Stanford Design Thinking Process. В слайдах - картинка. И на одних шагах идет дивергенция, расширение возможностей, на других - конвергенция, фокусировка. Важно их не смешивать.

И отдельные тезисы.

Повышение уровня абстракции решает все проблемы, кроме слишком большого количества уровней. Тем не менее, решает много проблем. Однако, много людей не умеют повышать уровень абстракции. Реально, у него на тренинге 15 человек в группе - не могут сформулировать проблему и концепцию уровня продукта, только уровня маленькой фичи.
Культура. Решает ли аналитик ту проблему, которую необходимо решать. Часто анализируют не ту проблему.
У буржуев есть подход upfront - сначала проработать альтернативы, а потом выбрать. Увы, для этого надо быть большой и толстой компанией.
Процесс определяет не КАК, он задает точки контроля. Которые обеспечивает, что аналитики не создают невидимых розовых единорогов. А культура - определяет как раз получение лучшего решения и т.п.
Ненавидит слова "эффективность" и "правильность". Потому как вне контекста - они бессмысленны. То же - с определением качества. Нужна цель.
Есть культуры, в которых генерация идей - роль между менеджером и богом.
Успешность программистов не связана с MBTI-типом
Был вопрос - а если надо мерить качество чтобы найти крайнего. Ответ - измерения по дефектам надо отслеживать до источника в процессе. Надо делать раз в полгода по компании.
Понятие горячести проекта. Есть проекты, где лучшее, что может сделать аналитик - не задерживать на себе. Надо не только померить косяки, надо еще провести анализ.
Дополнение из зала. А еще есть неправильный проект. Ответ. При правильном процессе правильный проект кончится сразу. Если компания ввязалась, но продолжает делать - значит другие критерии успеха. В некоторых проектах смысл - ввязаться в драку, а не победить.
Если мой софт никто использовать не будет, я могу доставить неограниченное количество в единицу времени.

Практика разработки требований на больших проектах продуктовой разработки. Ирина Сурова (Лаборатория Касперского, Россия)

Ирина достаточно детально рассказывала, как устроено у них ведение требований. Без особых обоснований. Но от уважаемой фирмы этот детальный процесс интересен сам по себе.

Продукт в Касперском, опыт за 3 года, когда перестали вести требования в Word. За это время вышли три релиза. Продукт - входит как часть в большой продукт.

Первый этап - надо было организовать репозиторий требований, которые ранее вели в Word. Надо поделить по функциональным областям (например, родительский контроль), и соотноситься требования из разных областей. Выбрали EAP, это до нее и почему - сказать не может. Он используется до сих пор, и требования - покрывает.

Слайд - структура модели, дерево. С учетом релизов. Источник - трекер бизнес-требований их дивизиона. В корневом требовании - ссылка и краткое содержание, полностью - в исходной системе.

Основа ведения требований - usecase модель, а функциональные и нефункциональные требования ее дополняют. Каждая фича по ним разложена. Еще есть инфраструктурные требования - другой слой, он представляет требования самого продукта к инфраструктуре. Например, требования к серверам и софту раздачи обновлений. Бизнес-требования - в контексте релиза, инфраструктурные - к системе целиком, так проще. В этой же модели у них описаны требования на само ведение требований.

Отделено хранение требований от представления требований. Для представления для большинству заказчиков - генерация документов, Word и заметки к нему. И для разработчиков - тоже Word. А аналитики работают с моделью. UML-профиль требований инструмента - они доточили, дополнительные поля и еще местами. И подготовили шаблоны на общий (полный документ) и частный (по фиче и т.п.) SRS.

SRS публикуются в SharePoint портал как doc-файлы, контроль версий ведет Sharepoint и история - поддерживается. Программистам идут частные SRS, и есть дополнительные настройки - кому-то больше картинок, другим - текст. Диаграмма трассировок: Бизнес-требование - UseCase - Дополнения. Еще есть html-генерация, фактически получается readonly-копия базы.

У них PDK - с их продуктом поставляется набор библиотек, версионируются вместе. Разрабатывают отдельные команды, и надо согласовывать. Где будет реализовано требование, в продукте или PDK - это зона ответственности архитектора, а не аналитика. Требование посылается архитектору, он их мапирует - на 1-3 части (продукт и PDK). Компонентные требования - в этом же репозитарии, но в отдельных продуктах. И получается нормальная трассировка. Внешние взаимодействия с инфраструктурой. Выявляют инфраструктурно-зависимые требования. И требования к инфраструктуре учитываются. Инфраструктура - она ведет требования по-разному.

Когда идут изменения - учитывают область влияния, это обеспечивают трассировки в инструменте. Генерят документ и выкладывают на Sharepoint как новую версию. А Sharepoint - он умеет сравнивать версию. Поскольку один шаблон - структура сохраняется, левых изменений не появляется. Так что в целом - удобно.

Требования на задачи в этом проекте не трассируются, Задачи - комплексные. И на тесты тоже. У нее опыт проекта, где трассировка полноценная, но это - отдельно.

Как происходит переход на новую версию продукта? Тестировщики и Заказчик - хочет видеть все полностью. А разработчики - хотят только изменения. Они выделяют цветом - добавление, изменение и удаление на диаграмме. Раскрашенная диаграмма, цвета - жестко. Важно, что на диаграмме есть и удаленные элементы. А в тексте - новые требования синим плюс курсивом. До настроили шаблоны, а версии по релизам - выкладывают snapshot. И после фиксации версии делают обесцвечивание.

Планы на будущее - массовый переход на TFS, работа разработчиков с атомарными требованиями там.

PechaCucha

Это был эксперимент. Формат предполагает доклад из 20 слайдов по 20 секунд на каждый, итого меньше 7 минут, а слайды переключаются автоматически. Формат хороший и содержательный. И я хочу высказать уважение дкладчикам, которые это сделали, независимо от того, что получилось внутри.

А еще - идеальный формат для холиварных тем. С каждого участника стола по такой презентации. И для презентации методологий и стандартов - тоже хорошо :) А модератор говорил, что он знает компании, где такой формат применяли для годовых отчетов подразделений.

Записывать во время докладов невозможно - большой темп. Так что я лишь оценю результат.

Ирина Сурова "За что я люблю свою профессию" - блеск
Алексей Зарецкий "Specification by example" - неплохая идея
Марина Савицкая "Особенности национальной коммуникации" - хорошо
Евгений Сафроненко "Use Case 2.0 – универсальный подход к документированию функциональных требований" - не убедил совершенно
Дмитрий Приймак "Много документации – это сколько?" - мысль непонятна, а истории - ну да,так тоже бывает, и что?
Андрей Янишевский "BABoK – свод законов или рекомендации к работе" - неплохо, по делу

Остальные доклады

Противоречивые требования: проблема или возможность? Андрей Курьян (Team International, Беларусь)

Был рассказ о ТРИЗ - как он может помочь бизнес-аналитику. Если по требованиям получается придумать решения - хорошо, даем задание разработчику. проблема, когда известные решения - не позволяют удовлетворить требования. И тогда уместен ТРИЗ. Правда, с примерами и конкретными техниками - было не слишком хорошо, были ссылки на сайт, где "все написано" (докладчиком?). И это - печалит, потому что если нечто докладчик может рассказать только длинно, значит оно смутно и непонятно. Из техник был упомянут RCA+ (Root Conflict Analysis Plus) и Идеальный конечный результат. Примеры - были, но тоже не слишком хорошие, по ним докладчика тролили. Потому что проблема, веременного регламента для обработки документа из-за необходимости ответа контрагента - она известная, и решения - известны, то есть это уже не проблема.

Разработка ПО – командный спорт. Дмитрий Лапыгин (IBM, Россия)

На мой взгляд, получился весьма нечеткий доклад, наполненный формальными аналогиями, которые были поверхностными. Например, о том, что команда программистов - как спортивная команда и есть роли, а дело передается как мяч. Ну и что? О паттернах, но при этом докладчик легко переходил между design pattern, ALM process pattern, или шаблонами представления требований, смешивая их и перенося вещи, справедливые для одних, на другие виды паттернов без всяких обоснований (они же тоже паттерны). Увы.

Круглый стол Менеджер продукта и аналитик: зоны ответственности и взаимодействие

Я заходил фрагментами, параллельно слушая доклады. Хорошего обсуждения не получилось. Потому что тема - холиварная, у людей - есть свои мнения и понятия, и перейти на общие термины, пусть в рамках данного обсуждения - они не готовы, готовы говорить только в своих терминах (у нас аналитик - тот кто делает это, а PO - тот кто делает то). При этом очень хотят некоторого "оптимального" и "правильного" решения, освященного если не методологами, то хоть экспертами круглого стола. Кстати, это желание у некоторых экспертов - тоже было.

Если говорить о проблемном поле, то вопрос в том что есть Product Owner, Product Manager, Product Director - со своими ответственностями. А есть бизнес-аналитик, и другие аналитики, и области перекрываются. Дима высказывал радикальное мнение: аналитик готовит информацию, аргументирует, но не принимает решения - они за другими. Но такая постановка не нравилась: одни ее не понимали: "как так, не принимает решения?", другие - хотели какой-то ответственностью обязательно нагрузить, рассказывая как у них.

В целом, такие обсуждения надо проводить гораздо более сфокусировано и с жесткой модерацией - если это вообще возможно.

Аналитик - технарь или психолог. Дмитрий Приймак

Этот доклад был заменой Григорию Печенкину в связи с болезнью. Основной идеей было то, что от аналитика требуется много коммуникативных, психологических аспектов. Умение учиться, умение разговаривать на разных языках, вживаться в разные языки - заказчик, разработчик. Свобода от стереотипов, чтобы не влияло кривое зеркало личных предпочтений. Умение излагать мысли доходчиво. Правильно структурировать, выдержать терминологию. Выдерживать нотацию - и в диаграммах и в письмах и в контрактах. Орфография, осторожно использовать слэнг. И так далее. Мысли правильные, но, на мой взгляд, поверхностные и очевидные. По-моему, аналитиков, ориентированных исключительно на "правильное проектирование" уже нет. А может у меня слишком идеализированное представление.

Тренинг Создание концепции решения Дима Безуглый

Тренинг был на следующий день, в субботу. Очень содержательный, как и было обещано в программе. К сожалению, у Димы не получилось сделать сбалансированный тайминг: первые два модуля заняли почти 6 часов, и остальные четыре Дима рассказывал в бешеном темпе, за 3.5 часа. Но рассказал, хотя общее время увеличилось и закончили в полдевятого, а потом еще были ответы на вопросы. Но все равно, тренинг получился очень хороший и ценный. А рассказывать его я не буду. Потому что программа - она подробная, и упомянутые методики - они легко ищутся. А наполнение примерами и личным опытом - его воспроизвести нельзя.

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 00:28, 12 ноября 2012 • нет комментариев

2012-11-12: ReqLabs-2012 в Киеве