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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Весьма живо и по делу. Хорошо. Но про более формализованные процессы и ситуации, с вопросами кто виноват?
• Обратная связь от команды на бизнес-аналитиков. Выделяя роль мы усложняем процесс, бизнес-аналитик у заказчика, но надо, чтобы он не отрывался от команды.
• Мало программистов могут работать в постановке проблемы. а не в постановке решения
• Не верит в agile и самоорганизующуюся команду. Считает, что это — тактика малых групп. Очень выгодно, пришло еще из военных. Продажа воздуха со стороны agile потому, что он продает команду без конфликтов. Считает, что противоречия ролей неизбежны, не надо совмещать… А итерации — PERT 60х.
• Идет и дальше — на любые методологии, которые обещают серебряный молоток. Их нет. Формальности есть в том объеме. в котором упрощают жизнь. Я: На самом деле у него частично agile мышление — гибкость есть. Но вот сотрудничество — не верит, процесс-война.
• Проблема RUP — процесс снаружи совсем не то, как видят внутри.
• XP — ему очень нравятся инженерные практики, и очень не нравится работа с заказчиком. Потому что там идеальный заказчик, которого реально не бывает. И они все риски переваливают на заказчика.
• Реально у него скепсис такой, что он не стремиться узнать и понять детали. Он смотрит корни, типа канбан — из логистики тойоты, и не смотрит на смысл именно в программном обеспечении.
• Идея — «Time and Material» расхолаживает команду. Воспринимает «Fix Price» как способ держать команду в тонусе.
• Идея — не работать с требованиями вообще. На самом деле — не работать с техническими требованиями. 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 — тексты прежде всего. Понял, когда прочитал Коберна и в его струе работает. Потом Ларман. Соединить
• Его методология позволяет любую предметную область «влет».
• Перескочил на РУП. РУП: подход + процесс + фреймворк
• Киты: итерации, юзкейс, архитектура. И что-то он добавил
• Дух RUPа. самое важное — разрабатывайте то, что хочет заказчик. Я: весьма любопытное понимание.
• юзкейс == текст, читается всеми. надо чтобы было понятно всеми.
• юзкейс — синтез, а не анализ.
• юзкейс — скачок воображения, способ соединить мнение всех стейкхолдеров.
• Два подхода
  1. От Якобсона. Битнер и Спенсер (2002). Игнорируя Коберна, хотя она вышла в 2000. Сам Якобсон считает, что «подход Коберна не противоречит его подходу». Но игнорирует развитие.
  2. Коберн как принципиальное развитие юзкейсов. Только его книга — намного тяжелее, чем у Битнера и Спенсера. Ее тяжело читать. То есть — придумал, но не описал.
• У Якобсона акцент на диаграммы, а не на текстовое представление.
• Ключевые моменты: actor цель ценность
• Переписал пример Битнера из книги по Коберну — он получается лучше.
• Коберн — добавил стейкхолдера == носителя знаний. Внутри кейса ничего, кроме знаний стейкхолдера. ввел primary actor, actor с системой — два актора.
• Выделение сценариев — это Коберн. формальное.
• Проекция интересов стейкхолдеров на юзкейс. И это — важно.

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

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

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

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

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

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

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

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

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

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