ReqLabs-2011
Содержание
[убрать]- 1 Общие впечатления
- 2 Отдельные полезные мысли
- 3 Замечательные доклады
- 3.1 Ефименко Дмитрий. Метод от целей при анализе требований и управлении рисками программного обеспечения
- 3.2 Калугин Александр. Коммуникация нефункциональных требований в небольших проектах по заказной разработке ПО
- 3.3 Якима Александр. Lean: Эффективное управление требованиями
- 3.4 Веденин Юрий. Опыт разработки и внедрения системы квалификации аналитиков
- 3.5 Банасевич Алексей. Разработка тиражного коммерческого программного продукта. Опыт выживания
- 3.6 Turner Paul The Evolving role of the Business Analyst
- 3.7 Горенко Ольга. Интерфейс бизнес-целей
- 4 Остальные доклады
- 4.1 Бондаренко Мария. Управление требованиями в условиях неопределенности
- 4.2 Евграшин Тимофей. От Agile управления требованиями к глобальным изменениям в компании
- 4.3 Reed Adrian. Stakeholder Engagement: Delivering projects in the face of advers
- 4.4 Новичков Александр, Галина Карабанова. Коммуникации и психология межличностных отношений в проектной команде
- 4.5 Erasmus Michiel The Real World Business Analyst
- 4.6 Хлебников Сергей. Представление знаний о предметной области на основе эффективных юзкейсов
- 4.7 Котельников Александр. Особенности разработки требований для систем бухгалтерского и финансового учета
- 4.8 Зезин Василий. Онтологический взгляд на инженерию требований
Общие впечатления
25.03 в Киеве прошла конференция Req Labs 2011. Если кратко выразить мое впечатление о конференции, то она была очень живая, с хорошими докладами и очень заинтересованными слушателями. Конференция шла один день, три трека, полные залы: там где аншлаг народ стоит в проходах или вообще не может войти в зал, и это при залах на 100 человек. Сами залы, кроме «Зимнего сада», не слишком удобны — вытянуты, а экран не очень большой. Перерывы сделаны достаточно грамотно.
Доклады — достаточно хорошие. Хотя я лично в докладах ничего существенно нового не услышал, основной массе участников было интересно их слушать. А еще лично я очень скептически отношусь к работе с требованиями мелкой россыпью, в которой многие работают, и это тоже повлияло на оценки. Но на моих впечатлениях, которые будут дальше, это скажется — получается, что я оценивал не столько содержание доклада, сколько форму его подачи. И много докладов было представлено в хорошей форме, во всяком случае практически на всех слотах мне было кого слушать.
На Мишином докладе я не был — решил, что лучше послушаю других. По отзывам, принимали хорошо.
Не очень удалось с круглым столом. Потому что превратился в монологи экспертов на очевидную тему, например, что декомпозировать надо так, чтобы поместить в спринт бэклог. Диалогов и обсуждений — не было. Так что тайм боксинг на круглых столах и запрет монологов — критично.
А в целом, организаторы и программный постарались и им спасибо.
Отдельные полезные мысли
До обзора докладов я хочу зафиксировать несколько идей, которые вынес с конференции.
О ведении доклада.
- Идея — представиться по специализациям — аналитик/разработчик/ПМ, аутсорсинг/продукты, и так далее. Понятно, что докладчик ничего особого не вынесет, но налаживается взаимодействие с аудиторией. Хотя, эксперты, наверное, могут чего-нибудь на лету перестроить в докладе.
- У Тернера это было в развитом варианте, чтобы всех вовлечь — встаньте все, а потом садитесь по категориям. Правда, при таком подходе теряются совместители.
- Ключевой слайд идет через весь доклад и постепенно заполняется мозаикой, по мере того, как проходят другие слайды.
Некоторые общие идеи.
- Метафора: твиттер-постановки. Из требований по 60 символов :)
- Практика: фокус-группы оценки интерфейса.
У Ефименко была отсылка на проекты, закончившиеся провалом — любопытные истории можно посмотреть здесь и здесь.
Замечательные доклады
Это — доклады, которые мне понравились и формой и содержанием. Их, естественно, не слишком много.
Ефименко Дмитрий. Метод от целей при анализе требований и управлении рисками программного обеспечения
Этот доклад мне понравился больше всего, поэтому я и поставил его первым. Докладчик — достаточно харизматичный человек, а сам доклад был о том, что не надо сотворять кумира из любой методологии.
Я слушал не сначала, и такую цель в явной формулировке не услышал. А услышал прилично подтвержденные тезисы, касающиеся конкретных методологий, о том, что они не работают. Но в провокационной форме с сильным преувеличением — следы этого есть в заметках далее. И у меня периодически создавалось впечатление, что докладчик видит методологию поверхностно — которое во многих случаях оказывалось неверным там где начиналось детальное рассмотрение.
Что касается позитивных предложений, то на общем уровне идея в том, чтобы знакомиться со всеми методологии и извлекать полезные и уместные практики, пытаться их применять. На уровне конкретной идеи — предлагалось проектирование по бизнес-целям, и заявленное в названии доклада. Думаю, именно потому. что погружаться в бизнес-область до уровня понимания и бизнес-целей и способов их достижения больше всего не любят. Более того, из зала были возгласы, что нельзя оттяпывать хлеб бизнес-консультантов, это их поляна и незачем 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а. самое важное — разрабатывайте то, что хочет заказчик. Я: весьма любопытное понимание.
- юзкейс == текст, читается всеми. надо чтобы было понятно всеми.
- юзкейс — синтез, а не анализ.
- юзкейс — скачок воображения, способ соединить мнение всех стейкхолдеров.
- Два подхода
- От Якобсона. Битнер и Спенсер (2002). Игнорируя Коберна, хотя она вышла в 2000. Сам Якобсон считает, что «подход Коберна не противоречит его подходу». Но игнорирует развитие.
- Коберн как принципиальное развитие юзкейсов. Только его книга — намного тяжелее, чем у Битнера и Спенсера. Ее тяжело читать. То есть — придумал, но не описал.
- У Якобсона акцент на диаграммы, а не на текстовое представление.
- Ключевые моменты: actor цель ценность
- Переписал пример Битнера из книги по Коберну — он получается лучше.
- Коберн — добавил стейкхолдера == носителя знаний. Внутри кейса ничего, кроме знаний стейкхолдера. ввел primary actor, actor с системой — два актора.
- Выделение сценариев — это Коберн. формальное.
- Проекция интересов стейкхолдеров на юзкейс. И это — важно.
Тут я выходил на другой доклад…
- Для итеративной разработки задача — выделить мелкие итерации. При нарезке юзкейсов на сценарии и разделении на минитранзакции — можно делить.
- Ларман — понятие системного события и системной итерации. Которые суть запросы. Он дальше делает на фичи.
- Фичи из Rational sweet в MS project с диаграммой ганта, а затем — планирование и управление.
- Вообще говоря юзкейсы получаются детальные, практически алгоритмы! Сложный язык. И с этим заказчик будет работать??
- Я: Идеи примерно понятны, но это конструкция, когда кодер — просто исполнитель.
- Ближе к концу — пошли явные антипатерны. Схема справочника, которую понимал только он. Схема написания юзкейсов, где качество написания критично, и умеет писать (только он).
- Он представил их знания и начал представлять систему лучше них самих. До прихода они представляли абы как. а он — свел воедино. Он может добраться. А они?
- Проверки — несколько сотен включены в юзкейс…
- Дерево трассировки…
- Поддерживать юзкейсы это трудоемко. Пользоваться месяцы и годы — они же сгниют…
- Интересно, а почему он не использовал html для ссылок, а работал с текстами?
Котельников Александр. Особенности разработки требований для систем бухгалтерского и финансового учета
В целом грамотный доклад, докладчик представляет вопрос. Народ это в целом интересует. Хотя это больше ликбез с нашей точки зрения, но и на этом уровне слушателям интересно. Людей интересует — насколько легко взаимодействовать со Сбером и госзаказчиками и т. п.
Далее — заметки — не с начала.
- Некоторая конкретика внутренних механизмов 1С, устройство учета — регистры остатков, регистры вычислений и прочее.
- Проект — в центре инфраструктуре, важные пользователи — психологические навыки, документоориентированный интерфейс.
- Особенности требований — законодательство + внутренние регламенты. И это самая неприятная ловушка, потому как в контракте оно всегда есть и оно будет.
- Бухгалтеры ожидают что аналитики владеют предметом. Вопросы были из серии нельзя ли подложиться от этого, снять риски, ответ — нельзя.
- Бух.учет стандартный, поэтому. как правило. это внедрение и настройка, а не разработка с нуля.
- Управленческий учет — под себя, единых стандартов не существует — полноценная разработка системы.
Зезин Василий. Онтологический взгляд на инженерию требований
Докладчик — из INCOSE. В целом это рассказ про системную сложность систем как таковую, но без самого понятия сложности, а описывая конкретные следствиях и проявлениях этой сложности. Доклад хороший, но специалиста по системной инженерии я ожидал большего. А еще оставалось впечатление умозрительности доклада и апелляции к достаточно старым материалам.
Далее — заметки.
- Способов классификации — много, вопрос полезности.
- Около 30 % разработки связано с требованиями, и эта цифра не меняется.
- Чем дальше проект зашел, тем сложнее вносить изменения…
- Как-то оно водопадно-умозрительно… Это обзор по достаточно старым работам…
- Много точек зрения. Про сложность и снижение — не говорил.
- Не надо забывать, что за моделями, диаграммами — система.
- Модели жизненного цикла. Их много. Не надо забывать, что за ними.
- Комп был в каком-то хитром режиме. не зеркало, и не видно что на экране-то слайд не меняется :)
- URML. Чтобы формально, не тексты.
- Договориться с клиентом о практиках, используемых в работе…