Просмотр исходного текста страницы ReqLabs-2011

[[Категория:Конференции]]

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

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

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

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

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

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

= Отдельные полезные мысли =

До обзора докладов я хочу зафиксировать несколько идей, которые вынес с конференции.

О ведении доклада.
* Идея — представиться по специализациям —  аналитик/разработчик/ПМ, аутсорсинг/продукты, и так далее. Понятно, что докладчик ничего особого не вынесет, но налаживается взаимодействие с аудиторией. Хотя, эксперты, наверное, могут чего-нибудь на лету перестроить в докладе.
* У Тернера это было в развитом варианте, чтобы всех вовлечь — встаньте все, а потом садитесь по категориям. Правда, при таком подходе теряются совместители.
* Ключевой слайд идет через весь доклад и постепенно заполняется мозаикой, по мере того, как проходят другие слайды.

Некоторые общие идеи.
* Метафора: твиттер-постановки. Из требований по 60 символов :)
* Практика: фокус-группы оценки интерфейса.

У Ефименко была отсылка на проекты, закончившиеся провалом — любопытные истории можно посмотреть [http://en.wikipedia.org/wiki/List_of_software_engineering_topics#Disasters здесь] и [http://en.wikipedia.org/wiki/List_of_software_bugs здесь].

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

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

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

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

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

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

'''Далее — заметки'''.
* Весьма живо и по делу. Хорошо. Но про более формализованные процессы и ситуации, с вопросами кто виноват?
* Обратная связь от команды на бизнес-аналитиков. Выделяя роль мы усложняем процесс, бизнес-аналитик у заказчика, но надо, чтобы он не отрывался от команды.
* Мало программистов могут работать в постановке проблемы. а не в постановке решения
* Не верит в agile и самоорганизующуюся команду. Считает, что это — тактика малых групп. Очень выгодно, пришло еще из военных. Продажа воздуха со стороны agile потому, что он продает команду без конфликтов. Считает, что противоречия ролей неизбежны, не надо совмещать… А итерации — PERT 60х.
* Идет и дальше — на любые методологии, которые обещают серебряный молоток. Их нет. Формальности есть в том объеме. в котором упрощают жизнь. '''Я:''' На самом деле у него частично agile мышление — гибкость есть. Но вот сотрудничество — не верит, процесс-война.
* Проблема RUP — процесс снаружи совсем не то, как видят внутри.
* XP — ему очень нравятся инженерные практики, и очень не нравится работа с заказчиком. Потому что там идеальный заказчик, которого реально не бывает. И они все риски переваливают на заказчика.
* Реально у него скепсис такой, что он не стремиться узнать и понять детали. Он смотрит корни, типа канбан — из логистики тойоты, и не смотрит на смысл именно в программном обеспечении.
* Идея — «Time and Material» расхолаживает команду. Воспринимает «Fix Price» как способ держать команду в тонусе.
* Идея — не работать с требованиями вообще. На самом деле — не работать с техническими требованиями. Use case — недоступная заказчику вещь (не ИТ-заказчика, а бизнес)…
* ''Software development disasters'' — попил-откат ФБР/ЦРУ и т. п. слив несмотря на квалификацию персонала ссылки [http://en.wikipedia.org/wiki/List_of_software_engineering_topics#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. первая буква — независимость историй. <tt>S</tt> — 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а. самое важное — разрабатывайте то, что хочет заказчик. '''Я:''' весьма любопытное понимание.
* юзкейс == текст, читается всеми. надо чтобы было понятно всеми.
* юзкейс — синтез, а не анализ.
* юзкейс — скачок воображения, способ соединить мнение всех стейкхолдеров.
* Два подхода
*# От Якобсона. Битнер и Спенсер (2002). Игнорируя Коберна, хотя она вышла в 2000. Сам Якобсон считает, что «подход Коберна не противоречит его подходу». Но игнорирует развитие.
*# Коберн как принципиальное развитие юзкейсов. Только его книга — намного тяжелее, чем у Битнера и Спенсера. Ее тяжело читать. То есть — придумал, но не описал.
* У Якобсона акцент на диаграммы, а не на текстовое представление.
* Ключевые моменты: actor цель ценность
* Переписал пример Битнера из книги по Коберну — он получается лучше.
* Коберн — добавил стейкхолдера == носителя знаний. Внутри кейса ничего, кроме знаний стейкхолдера. ввел primary actor, actor с системой — два актора.
* Выделение сценариев — это Коберн. формальное.
* Проекция интересов стейкхолдеров на юзкейс. И это — важно.
Тут я выходил на другой доклад…
* Для итеративной разработки задача — выделить мелкие итерации. При нарезке юзкейсов на сценарии и разделении на минитранзакции — можно делить.
* Ларман — понятие системного события и системной итерации. Которые суть запросы. Он дальше делает на фичи.
* Фичи из Rational sweet в MS project с диаграммой ганта, а затем — планирование и управление.
* Вообще говоря юзкейсы получаются детальные, практически алгоритмы! Сложный язык. И с этим заказчик будет работать??
* Я: Идеи примерно понятны, но это конструкция, когда кодер — просто исполнитель.
* Ближе к концу — пошли явные антипатерны. Схема справочника, которую понимал только он. Схема написания юзкейсов, где качество написания критично, и умеет писать (только он).
* Он представил их знания и начал представлять систему лучше них самих. До прихода они представляли абы как. а он — свел воедино. Он может добраться. А они?
* Проверки — несколько сотен включены в юзкейс…
* Дерево трассировки…
* Поддерживать юзкейсы это трудоемко. Пользоваться месяцы и годы — они же сгниют…
* Интересно, а почему он не использовал html для ссылок, а работал с текстами?

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

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

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

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

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

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