Впечатления о REQ-Labs 2011 - Макс Цепков

Общие впечатления

25.03 в Киеве прошла конференция Req Labs 2011. Если кратко выразить мое впечатление о конференции, то она была очень живая, с хорошими докладами и очень заинтересованными слушателями. Конференция шла один день, три трека, полные залы: там где аншлаг народ стоит в проходах или вообще не может войти в зал, и это при залах на 100 человек. Сами залы, кроме Зимнего сада, не слишком удобны - вытянуты, а экран не очень большой. Перерывы сделаны достаточно грамотно.

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

От нашей компании выступал Миша Заборов, но я на его докладе я не был - решил, что лучше послушаю других. По отзывам, принимали хорошо.

Не очень удалось с круглым столом. Потому что превратился в монологи экспертов на очевидную тему, например, что декомпозировать надо так, чтобы поместить в спринт бэклог. Диалогов и обсуждений - не было. Так что тайм боксинг на круглых столах и запрет монологов - критично.

А в целом, организаторы и программный постарались и им спасибо.

Замечательные доклады

Это - доклады, которые мне понравились и формой и содержанием. Их, естественно, не слишком много.

Ефименко Дмитрий. Метод от целей при анализе требований и управлении рисками программного обеспечения

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

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

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

Далее - заметки.

• Весьма живо и по делу. Хорошо. Но про более формализованные процессы и ситуации, с вопросами кто виноват?
• Обратная связь от команды на бизнес-аналитиков. Выделяя роль мы усложняем процесс, бизнес-аналитик у заказчика, но надо, чтобы он не отрывался от команды.
• Мало программистов могут работать в постановке проблемы. а не в постановке решения
• Не верит в agile и самоорганизующуюся команду. Считает, что это - тактика малых групп. Очень выгодно, пришло еще из военных. Продажа воздуха со стороны agile потому что он продает команду без конфликтов. Считает, что противоречия ролей неизбежны, не надо совмещать... А итерации - PERT 60х.
• Идет и дальше - на любые методологии, которые обещают серебряный молоток. Их нет. Формальности есть в том объеме. в котором упрощают жизнь. Я: На самом деле у него частично agile мышление - гибкость есть. Но вот сотрудничество - не верит, процесс-война.
• Проблема RUP - процесс снаружи совсем не то, как видят внутри.
• XP - ему очень нравятся инженерные практики, и очень не нравится работа с заказчиком. Потому что там идеальный заказчик, которого реально не бывает. И они все риски переваливают на заказчика.
• Реально у него скепсис такой, что он не стремиться узнать и понять детали. Он смотрит корни, типа канбан - из логистики тойоты, и не смотрит на смысл именно в программном обеспечении.
• Идея ТМ - расхолаживает команду. Воспринимает fix как способ держать команду в тонусе.
• Идея - не работать с требованиями вообще. На самом деле - не работать с техническими требованиями. use case - недоступная заказчику вещь (не ИТ-заказчика, а бизнес)...
• software development disasters - попил откат ФБР ЦРУ и т.п. слив несмотря на квалификацию персонала ссылки здесь
• Нельзя говорить в терминах методологий, надо работать на уровне здравого смысла.
• Бизнесмен не говорит на языке требований, он говорит на языке целей. Если бы он мог представить пути достижения - он бы просто зарядил в Калькутту.
• Коммуникация. Программеры на нее не идут, и заказчик вынужден защищаться своими ит-шниками, с которых он требует драконовскими методами.
• Цели, в отличие от требований - не протухают и понятно приоритеты.
• Хотя спуск по дереву целей, для сложных конструкций, на мой взгляд не слишком понятно. Сильно перекликается с FDD - это его слова. Цели меняются редко - меняется способ достижения. Превращаем цели в feature set
• Любит рисовать на доске - это на вопрос об инструменте.
• Пример реального проекта - хотим повысить управляемость, для этого внедрить планирование. Чтобы план не фикция. Как сделать - чтобы был простым и актуальным и прочее. Некоторая понятная цель рассуждений, но как это с ПО связано неясно.
• Надо ли участвовать команде в круглые столы с заказчиком - да надо, чтобы единое понимание и вовлеченность.
• Но цели надо детально ставить. Был вопрос про 1С типа, цель - получить отчет. Да, можно, но для этого же первичка - она тоже становится целью. И надо эргономику ввода первичных данных тоже ставить в цели.
• Вопрос против расширения темы - не суйтесь в бизнес-консалтинг. Давайте заниматься своей отраслью.

Калугин Александр. Коммуникация нефункциональных требований в небольших проектах по заказной разработке ПО

Доклад был о нечетких требованиях, с которыми есть проблемы ввиду нечетких постановок, которые нельзя реализовать формально и вообще не всегда можно внести ясность. Я: В целом все правильно, просто для меня - очевидно, ситуация нечетких требований, которые надо выявлять и уточнять - типовая. Более того, с функциональными требованиями тоже не все ясно, если плотно работать.

Далее - заметки.

• Есть ситуации, когда все ясно: понятная ограниченная платформа, разработка по аналогии с конкурентами, портирование.
• Требования или пожелания: требования суть ограничения, а если жесткого ограничения нет, можно считать пожеланием. Одно и то же в одних условиях - требование, а в других - пожелание, например, следование стандарту. Или юзабилити - если сделать как у конкурентов и лучше - это требование.
• Разработка "как у конкурента" полагает хорошей штукой. Во всяком случае, потому что можно проверить и т.п.
• Хотя пожелания и нечетко, не следование им тоже может привести к провалу проекта. А может - и не привести. Нужен баланс, надо договариваться с заказчиком. Нельзя подходить формально - берем метрику и говорим "не ниже". Потому что оно не физично. И есть сложность обсуждения. Плюс требования в метриках - подстава для подрядчика, сложность доказывать. То есть пожелания не надо так работать. Разве что мы в архитектуру встраиваем ограничения: пользователей не более 100тыс. А вот с быстродействием сложно. Оптимизировать сразу - лишнее. надо потом. Плюс еще вопросы тестирования. Например "бесперебойная работа".
• Поэтому избегайте таких формулировок. Я: собственно, все правильно, но на мой взгляд очевидно.
• Хотя есть детали. Например, как требования совместимости - из доли рынка разных устройств или броузеров. И т.п. Идентификаторы по-русски с пробелами - надо или нет? И разрешение экрана.
• Качать требования, дихотомии. Например, удобство веба - это что? работа с разными типами браузеров или чтобы все летало? десктоп: красота - кастомные контролы или под всеми системами быстро? Канал: оффлайн или наоборот сохранение как можно быстрее? Дольше не падает или быстрее восстанавливается а данные не теряются? Word - падает, но файл - сохраняется.
• Большие объемы данных - таблицы с автофильтром не катят, нарушение нефункционального требования в угоду функциональному ("автофильтры") - меняйте, договаривайтесь. Аналогично - заполнение формы объявления на машину - полные дропдоун списки, на объемах и каналах плохо.
• Прямые запросы за списками, сохранение файлов - функциональный кейс нарушает производительность, много синхронных запросов. Меняйте последовательность работы.
• Но в целом тут он говорит не о функциональных ТРЕБОВАНИЯХ а о сценариях их реализации. Впрочем, клиенты и аналитики любят их писать, а разработчики - тогда по ним реализовывают.
• Идея борьбы - чеклисты ограничений, дихотомии - набирать опыт. В целом понятно. И библиотека преобразований юскейсов, по-сути решения проблем. Это сложнее.

Якима Александр. Lean: Эффективное управление требованиями

Докладчик - украинец, но сейчас работает в Индии, Германии, США. Продуктовая разработка, компании десятки-сотни команд. Хороший рассказ, но негладкий по речи и до Книберга ему далеко. Поскольку я хорошо представляю процесс, то, как мне кажется, понял и оценил содержимое доклада. Однако, по отзывам других слушателей, они эти мысли не уловили, на мой взгляд - как раз из-за сумбурности изложения.

Далее - заметки.

• Lean. Ему не нравится "бережливое производство", потому как производства в ПО нет. И акцент смещается - от минимизации затрат к использованию вариабельности и управлению очередями. lean generation 2.
• david anderson. etc. poppendic вчерашний день (но книга про cash и что-то).
• Принципы lean-потока.
  • Экономическая перспектива, не только в моменте, но и со временем. Стоимость задержки. Помощь бизнесу.
  • Активное управление очередями. Разница: очередь и пакет, в чем разница. Пакет - параллельное исполнение, пакет историй.
  • Понимание и использование изменяемости
  • ограничение пакетов
  • wip-ограничения
  • управление потоком в условиях неопределенности - каденции и синхронизация
  • ...
• agile - пример lean в софте. Хотя возник самостоятельно. Канбан - другой пример. Все есть леан :) Правда он путает agile и scrum, а может считает что по управлению в agile кроме scrum ничего нет.
• Очереди... Часто их не видим и это - проблемы. Очереди - между разными этапами. Большая очередь - это плохо, большая вариабельность в оценке сроков.
• Чем больше очередь (PBL), тем неопределеннее сроки.
• Тезис - делайте короче релизы, будет короче очередь. Лучше меньше полгода, от 3 месяцев и ниже.
• Закон Литтла. Время ожидания в очереди пропорционально ее средней длине. Если у вас в середине есть очереди между этапами, то там оно будет стоять. w=L/лямбда 1/лямбда - тик цикла, выход.
• Собственно, в этом смысл уменьшения количества элементов в очередях.
• Детализация требования JIT - когда нужно, а не когда хотим. Метафора - требование есть контейнер, который мы наполняем деталями. Например Эпос-Фича-История. Еще есть minimum marketable feature - квант, который можно доставить.
• business owner - любой стейкхолдер выдвигающий требования, влияющий на roadmap
• Эпос: работа с комюните в ворд. Фича - одновременная работа с документами и т.п., дальше в истории
• Идея: твиттер-постановки. Из требований по 60 символов :)
• INVEST. первая буква - независимость историй. S - small.
• Большие пакеты - приводят к еще большим. Большой проект раздувается, к ним легко добавить еще немного.
• Методика define-build-test по кругу итерации. Кусочек - маленький, но по всем уровням системы, это важно. Плюс - уменьшает очереди, компактизация.
• Про синхронизацию - когда несколько команд над одним продуктом - итерации синхронны. И интеграция в конце. В общем-то типовой подход. Точки синхронизации - планирование релиза; внутри спринта - интегрироваться несколько раз с другими командами, а потом - выход. Еще есть инфраструктурные ортогональные команды, например, верхнеуровневая архитектура.
• Децентрализация. Менеджеры (PO) говорят, что надо делать, а команда - за сколько смогут сделать. Децентрализация и доверие должно быть. иначе леан и agile не работают.
• Общий большой бэклог - не обязательство. Обязательство - то, что вошло в релиз. Хотя на верхнем уровне есть некоторые общий роадмап

Веденин Юрий. Опыт разработки и внедрения системы квалификации аналитиков

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

Далее - заметки.

• Градации: Интерны - сист анал - старш сис.анал - бизнес системный аналитик - старший бизнес.
• Бизнес-аналитики - уровень, с которого начинают разбираться в бизнесе. системные в бизнесе не разбираются. старшие - несколько областей или проектов.
• День карьерного роста - что достиг + направления развития.
• Подготовка к дню - менджер + два эксперта, заполняют матрицу компетенций и определяют возможные направления. Дальше ему это посылали, он готовился к обсуждению и дальше обсуждение с фиксацией результатов.
• Оценки - от заказчика, от тестировщиков и прочее, нарекания...
• Забавный пример - зачем нужна подтвержденная оценка... Вдруг взял и случайно написал хорошую спецификацию - повезло :)
• Реально - подтвержденные неоднократные успехи.
• Системные аналитики, компетенции: SRS, URS; прототипирование интерфейсов; английский по своим уровням (бизнес-общение: reader writer mailer speaker presenter); производственный опыт на проекте в аналит.активностях.
• 11 точек роста для уровня системного аналитика. что человек должен делать, чтобы рости. Например: теория требований; самостоятельность разработки требований; точность оценки времени своей работы - они до 30%; качество документирования (без метрик, по нареканиям); ... Что он делает для роста - отдельный вопрос (книги, задачи, еще что-то)
• Они не откатали, может ли бизнес-аналитик быть без системного. В принципе может, но навыки системного аналитика - по любому должны быть.
• Система развивается. И они систему образования дальше будут развивать.
• Очень хочет общего понимания отрасли - что есть бизнес-аналитик. Потому что в каждой компании - все по-своему.
• Есть версии квалификации IIBA. Читал вторую версию, получил третью. Они становятся лучше, но сложнее, и с его точки зрения - чрезмерно.
• Проактивная позиция...
• К уровням привязаны медианы.
• Квалификация раз в полгода, хочет квартально ДКР.
• А еще - менторинг. тренинги - все будут делать.
• Точки роста и грейды - не обязательно закрыть все для повышения квалификации.
• Саму систему сделали в связи с ростом компании. отвечать на вопрос можно ли конкретного аналитика ставить на проект, как справедливо платить...
• Какой-то странный вопрос - а вдруг аналитики вырастут и уйдут, они же будут свои знания представлять и прочее.
• Есть старая версия системы для всех ролей - разработчики, руководители групп. Но стройная - для аналитиков.

Банасевич Алексей. Разработка тиражного коммерческого программного продукта. Опыт выживания

Основная идея доклада - работая по scrum надо быть последовательным и требования тоже получать инкрементально. Собственно, в этом основной смысл. Хотя многие известные ему команды применяя скрам, хотят требования сразу. Может быть, страхуются на проектах с жадными заказчикамИ, торгующимися за каждую копейку, а может не умеют разделять риски. Во всяком случае, не любят работать с неполными требованиями. И теряют основное преимущество agile - быструю реакцию на изменения. Поэтому он и сделал доклад о своем опыте. В целом доклад мне понравился, хотя сам материал для меня был очевидным.

Далее - заметки.

• Риск переписывания надо исключать. Для этого желательно описать весь спектр - широко. Но - поверхностно. Не надо погружаться глубоко. Более того, глубокое погружение сначала - вредит. И приоритеты хотя бы изначальные.
• Почему глубоко вредно? Потому что команда (или потом) можно придумать лучше. Пример когда по эскизу исполнитель сделал olap-решение. А заказчик его не знал, и если бы он конкретизировал - получил бы конечные решения.
• Подробно написанное требование устаревает в момент написания. Да и потом можно не делать, а реализовывать, только на это надо идти сознательно. Например, риск что команда вдруг разбежится.
• Фактор успеха
  • wear customer hat. особенно в продуктовой модели
  • командное продуктовое мышление
  • брейнсторым. только надо использовать результаты
  • фокус-группы рулят. пример - когда по впечатлению от дизайна получить впечатление. только ее надо подобрать.
  • обратная связь. не забивать на нее Это вы думаете, что пользователь сказал фигню, реально вы просто его не поняли, а он вещь предложил
  • нужно чтоб люди не боялись высказывать мнения.
• Как идти
  • первый прототип как можно быстрее, две недели
  • как можно быстрее все компоненты. пусть заглушки
  • каждые 2 недели - деливери. хоть фокус-группе
  • обязательно побуждать ознакомиться ("выпустили кайфную фичу") инфоподготовка. можно презентации
  • ревью скоупа и требований после каждого деливери обязательно. в процессе тоже можно
• цель - выпустить целостный продукт. Нет цели выпустить скоуп начальных требований.
• Хоть один должен держать целостную картину. В идеале - вся команда.
• И куча всего практик (известных, понятных)
• Гибкий треугольник. Запланировать больше. чем можем. сознательно снизив качество чтобы показать сырые прототипы важных фич. Наоборот, снизить темп вытягивая качество.
• Контролировать скоуп.
• Дальше 7 месяцев вперед - только намерения, не планы.
• При итерациях - не всегда получается то о чем думали вначале. Потому что каждый раз корректируем курс. И это классно - продукт в целом лучше, все довольны
• Итерации с фиксед кост - плохо совместимы. Если можно заложиться, тогда работает. Но если торгуются до копейки и подушки нет - не получится Я: но и другими способами, если не заложиться - не выйдет
• Очень многие известные ему команды ведут по скраму разработку. но требования требуют сразу. Он за работу с требованиями по скраму, и именно поэтому сделал доклад.

Turner Paul The Evolving role of the Business Analyst

Живой и экспрессивный рассказ, с выражением. Но, к сожалению, в том темпе английского, когда я не успевают рефлексировать. Поэтому записи бедны...

• balance between
  • demand - scope of role and competence
  • supply - people, prof, proof, qual
• Шутка. Модель областей (процессы, люди, ...) где опущено ядро - inform and technology
• V-модель реализации.... с уровнями. Бизнес-аналитик наверху, и он - принимает работу ОК.
• SFIA skill set: Skills Framework for the Information Age

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

Большинство докладов можно было оценить как приличные. Одни я слушал все, другие - частично. Потому что когда не было замечательного доклада, то я старался побывать на всех трех треках.

Бондаренко Мария. Управление требованиями в условиях неопределенности

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

Далее - заметки.

• Идея: две базы, оригинальные запросы, и требования на основе их. Исходные не склеивать. Понимать "зачем" для решений. приоритеты у источников запросов, веса конкретных запросов.
• Вообще говоря, кейс работы с множеством небольших слабозависимых требований, типа усовершенствований.
• Правильные слова про зашоренность клиентов, не делайте что просят а творчески преобразовывать. Типа бронировать == отправить на email, хотя реальная фича - гейт бронирования.
• Перекрестное опыление опыта клиентов за счет продуктов. Конкретные рекомендации, типа справочников заполняемых клиентами при настройке экземпляра и т.п.

Евграшин Тимофей. От Agile управления требованиями к глобальным изменениям в компании

Лекция. Ровная. Скорее по чужим учебникам. Слайды отсутствуют... Народу было интересно, и докладчик, наверное, разбирается в материале, но все это можно прочитать в книгах, и лучше - у того же Книберга. Может быть, я не досидел до того места, где пошел личный опыт.

Reed Adrian. Stakeholder Engagement: Delivering projects in the face of advers

Речь как журчание ручейка. В целом все правильно, но без вдохновения... Может быть, я пристрастен - потому что язык чужой, и для понимания нужно больше энергии, чем для доклада на русском - соответственно, требования для меня выше.

Новичков Александр, Галина Карабанова. Коммуникации и психология межличностных отношений в проектной команде

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

Erasmus Michiel The Real World Business Analyst

Рассказ весьма не по делу. С детства и со школы, и об этом долго... Это не для начинающих бизнес-аналитиков, а для школьников, по-моему... Я ушел достаточно быстро, а резюме тех, кто слушал до конца, потому что стеснялся вылезать из полного зала - на начало доклада пришли очень многие: "Докладчик родился в южной африке и делился трудным детством без компов. Сейчас приехал в Голландию и работает бизнес-аналитиком, и ему хорошо 0 о чем он и рассказывал".

Хлебников Сергей. Представление знаний о предметной области на основе эффективных юзкейсов

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

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

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

Зато в целом в докладе был достаточно хороший обзор истории развития практики usecase, это большой плюс. Идея тут следующая. Как известно, usecase придумал Якобсон. Но потом Коберн внес много принципиально нового. А Якобсон его не оценил, сказав лишь, что "подход Коберна не противоречит его подходу". Классическая книга по usecase, признанная Якобсоном очень хорошей - Битнер и Спенсер (2002), также игнорирует новое от Коберна. А книга Коберна (2000) - очень тяжелая, поэтому ее не слишком читают. Вот так.

Далее - заметки.

• Считает use case представлением знаний. Типа, представление требований - "более привычно"
• стейкхолдер == носитель знаний == заинтересованное лицо
• Сведения можно представить в виде требований. но оно будет коряво.
• Очень много информации, которые сложно представить требованиями, зато представляется через use case и он придумал некоторую методику. Задача - представить знания. Причем в доступном всем стейкхолдерам варианте.
• Канонической теории нет, есть два варианта, к одной из которых каждый склоняется
• use case == buzzword.
• Познакомился с usecase, когда читал Якобсона. Но не понял, что use case - тексты прежде всего. Понял, когда прочитал Коберна и в его струе работает. Потом Ларман. Соединить
• Его методология позволяет любую предметную область "влет".
• Перескочил на РУП. РУП: подход + процесс + фреймворк
• Киты: итерации, юзкейс, архитектура. И что-то он добавил
• Дух рупа. самое важное - разрабатывайте то что хочет заказчик. Я: весьма любопытное понимание.
• юзкейс == текст, читается всеми. надо чтобы было понятно всеми.
• юзкейс - синтез, а не анализ.
• юзкейс - скачок воображения, способ соединить мнение всех стейкхолдеров.
• Два подхода
  1. От Якобсона. Битнер и Спенсер (2002). Игнорируя Коберна, хотя она вышла в 2000. Сам Якобсон считает, что "подход Коберна не противоречит его подходу". Но игнорирует развитие.
  2. Коберн как принципиальное развитие юзкейсов. Только его книга - намного тяжелее, чем у Битнера и Спенсера. Ее тяжело читать. То есть - придумал, но не описал.
• У Якобсона акцент на диаграммы, а не на текстовое представление.
• Ключевые моменты: actor цель ценность
• Переписал пример Битнера из книги по Коберну - он получается лучше.
• Коберн - добавил стейкхолдера == носителя знаний. Внутри кейса ничего, кроме знаний стейкхолдера. ввел primary actor, actor с системой - два актора.
• Выделение сценариев - это Коберн. формальное.
• Проекция интересов стейкхолдеров на юзкейс. И это - важно.

Тут я выходил на другой доклад...

• Для итеративной разработки задача - выделить мелкие итерации. При нарезке юзкейсов на сценарии и разделении на минитранзакции - можно делить.
• Ларман - понятие системного события и системной итерации. Которые суть запросы. Он дальше делает на фичи.
• Фичи из Rational sweet в MS project с диаграммой ганта, а затем - планирование и управление.
• Вообще говоря юзкейсы получаются детальные, практически алгоритмы! Сложный язык. И с этим заказчик будет работать??
• Я: Идеи примерно понятны, но это конструкция, когда кодер - просто исполнитель.
• Ближе к концу - пошли явные антипатерны. Схема справочника, которую понимал только он. Схема написания юзкейсов, где качество написания критично, и умеет писать (только он).
• Он представил их знания и начал представлять систему лучше них самих. До прихода они представляли абы как. а он - свел воедино. Он может добраться. А они?
• Проверки - несколько сотен включены в юзкейс...
• Дерево трассировки...
• Поддерживать юзкейсы это трудоемко. Пользоваться месяцы и годы - они же сгниют...
• Интересно, а почему он не использовал html для ссылок, а работал с текстами?

== Котельников Александр. Особенности разработки требований для систем бухгалтерского и финансового учета

В целом грамотный доклад, докладчик представляет вопрос. Народ это в целом интересует. Хотя это больше ликбез с нашей точки зрения, но и на этом уровне слушателям интересно. Людей интересует - насколько легко взаимодействовать со Сбером и госзаказчиками и т.п.

Далее - заметки - не с начала.

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

Зезин Василий. Онтологический взгляд на инженерию требований

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

Далее - заметки.

• Способов классификации - много, вопрос полезности.
• Около 30% разработки связано с требованиями, и эта цифра не меняется.
• Чем дальше проект зашел, тем сложнее вносить изменения...
• Как-то оно водопадно-умозрительно... Это обзор по достаточно старым работам...
• Много точек зрения. Про сложность и снижение - не говорил.
• Не надо забывать, что за моделями, диаграммами - система.
• Модели жизненного цикла. Их много. Не надо забывать, что за ними.
• Комп был в каком-то хитром режиме. не зеркало, и не видно что на экране-то слайд не меняется :)
• URML. Чтобы формально, не тексты.
• Договориться с клиентом о практиках, используемых в работе...