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

Материал из MaksWiki
Перейти к: навигация, поиск

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

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

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

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

Содержание

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

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 не подтвержден, но проблема - уже решена.

Методы:

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

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

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

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

  1. Люди
  2. Методология
  3. Процесс
  4. Культура

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

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

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

  • 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 часа. Но рассказал, хотя общее время увеличилось и закончили в полдевятого, а потом еще были ответы на вопросы. Но все равно, тренинг получился очень хороший и ценный. А рассказывать его я не буду. Потому что программа - она подробная, и упомянутые методики - они легко ищутся. А наполнение примерами и личным опытом - его воспроизвести нельзя.


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

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

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