Впечатления о REQ-Labs 2011 - Макс Цепков — различия между версиями
Maksiq (обсуждение | вклад) (Новая страница: «Категория:Внешние события = Общие впечатления = 25.03 в Киеве прошла конференция [http://www.req-...») |
Maksiq (обсуждение | вклад) |
||
Строка 3: | Строка 3: | ||
= Общие впечатления = | = Общие впечатления = | ||
− | 25.03 в Киеве прошла конференция [http://www.req-labs.ru/ Req Labs 2011]. Если кратко выразить мое впечатление о конференции, то она была очень живая, с хорошими докладами и очень заинтересованными слушателями. Конференция шла один день, три трека, полные залы: там где аншлаг народ стоит в проходах или вообще не может войти в зал, и это при залах на 100 человек. Сами залы, кроме | + | 25.03 в Киеве прошла конференция [http://www.req-labs.ru/ Req Labs 2011]. |
+ | Если кратко выразить мое впечатление о конференции, то она была очень живая, с хорошими докладами и очень заинтересованными слушателями. Конференция шла один день, три трека, полные залы: там где аншлаг народ стоит в проходах или вообще не может войти в зал, и это при залах на 100 человек. | ||
+ | Сами залы, кроме «Зимнего сада», не слишком удобны — вытянуты, а экран не очень большой. | ||
+ | Перерывы сделаны достаточно грамотно. | ||
− | Доклады | + | Доклады — достаточно хорошие. Хотя я лично в докладах ничего существенно нового не услышал, основной массе участников было интересно их слушать. А еще лично я очень скептически отношусь к работе с требованиями мелкой россыпью, в которой многие работают, и это тоже повлияло на оценки. Но на моих впечатлениях, которые будут дальше, это скажется — получается, что я оценивал не столько содержание доклада, сколько форму его подачи. И много докладов было представлено в хорошей форме, во всяком случае практически на всех слотах мне было кого слушать. |
От нашей компании выступал Миша Заборов, но я на его докладе я не был - решил, что лучше послушаю других. По отзывам, принимали хорошо. | От нашей компании выступал Миша Заборов, но я на его докладе я не был - решил, что лучше послушаю других. По отзывам, принимали хорошо. | ||
− | Не очень удалось с круглым столом. Потому что превратился в монологи экспертов на очевидную тему, например, что декомпозировать надо так, чтобы поместить в спринт бэклог. Диалогов и обсуждений | + | Не очень удалось с круглым столом. |
+ | Потому что превратился в монологи экспертов на очевидную тему, например, что декомпозировать надо так, чтобы поместить в спринт бэклог. Диалогов и обсуждений — не было. Так что тайм боксинг на круглых столах и запрет монологов — критично. | ||
А в целом, организаторы и программный постарались и им спасибо. | А в целом, организаторы и программный постарались и им спасибо. | ||
Строка 15: | Строка 19: | ||
= Замечательные доклады = | = Замечательные доклады = | ||
− | Это | + | Это — доклады, которые мне понравились и формой и содержанием. Их, естественно, не слишком много. |
== Ефименко Дмитрий. Метод от целей при анализе требований и управлении рисками программного обеспечения == | == Ефименко Дмитрий. Метод от целей при анализе требований и управлении рисками программного обеспечения == | ||
− | Этот доклад мне понравился больше всего, поэтому я и поставил его первым. Докладчик | + | Этот доклад мне понравился больше всего, поэтому я и поставил его первым. Докладчик — достаточно харизматичный человек, а сам доклад был о том, что не надо сотворять кумира из любой методологии. |
− | Я слушал не сначала, и такую цель в явной формулировке не услышал. А услышал прилично подтвержденные тезисы, касающиеся конкретных методологий, о том, что они не работают. Но в провокационной форме с сильным преувеличением | + | Я слушал не сначала, и такую цель в явной формулировке не услышал. А услышал прилично подтвержденные тезисы, касающиеся конкретных методологий, о том, что они не работают. Но в провокационной форме с сильным преувеличением — следы этого есть в заметках далее. И у меня периодически создавалось впечатление, что докладчик видит методологию поверхностно — которое во многих случаях оказывалось неверным там где начиналось детальное рассмотрение. |
− | Что касается позитивных предложений, то на общем уровне идея в том, чтобы знакомиться со всеми методологии и извлекать полезные и уместные практики, пытаться их применять. На уровне конкретной идеи | + | Что касается позитивных предложений, то на общем уровне идея в том, чтобы знакомиться со всеми методологии и извлекать полезные и уместные практики, пытаться их применять. На уровне конкретной идеи — предлагалось проектирование по бизнес-целям, и заявленное в названии доклада. Думаю, именно потому. что погружаться в бизнес-область до уровня понимания и бизнес-целей и способов их достижения больше всего не любят. Более того, из зала были возгласы, что нельзя оттяпывать хлеб бизнес-консультантов, это их поляна и незачем IT-шникам туда лезть. Но зал докладчика в целом поддерживал. |
− | '''Далее | + | '''Далее — заметки'''. |
* Весьма живо и по делу. Хорошо. Но про более формализованные процессы и ситуации, с вопросами кто виноват? | * Весьма живо и по делу. Хорошо. Но про более формализованные процессы и ситуации, с вопросами кто виноват? | ||
* Обратная связь от команды на бизнес-аналитиков. Выделяя роль мы усложняем процесс, бизнес-аналитик у заказчика, но надо, чтобы он не отрывался от команды. | * Обратная связь от команды на бизнес-аналитиков. Выделяя роль мы усложняем процесс, бизнес-аналитик у заказчика, но надо, чтобы он не отрывался от команды. | ||
* Мало программистов могут работать в постановке проблемы. а не в постановке решения | * Мало программистов могут работать в постановке проблемы. а не в постановке решения | ||
− | * Не верит в agile и самоорганизующуюся команду. Считает, что это | + | * Не верит в agile и самоорганизующуюся команду. Считает, что это — тактика малых групп. Очень выгодно, пришло еще из военных. Продажа воздуха со стороны agile потому, что он продает команду без конфликтов. Считает, что противоречия ролей неизбежны, не надо совмещать… А итерации — PERT 60х. |
− | * Идет и дальше | + | * Идет и дальше — на любые методологии, которые обещают серебряный молоток. Их нет. Формальности есть в том объеме. в котором упрощают жизнь. '''Я:''' На самом деле у него частично agile мышление — гибкость есть. Но вот сотрудничество — не верит, процесс-война. |
− | * Проблема RUP | + | * Проблема RUP — процесс снаружи совсем не то, как видят внутри. |
− | * XP | + | * XP — ему очень нравятся инженерные практики, и очень не нравится работа с заказчиком. Потому что там идеальный заказчик, которого реально не бывает. И они все риски переваливают на заказчика. |
− | * Реально у него скепсис такой, что он не стремиться узнать и понять детали. Он смотрит корни, типа канбан | + | * Реально у него скепсис такой, что он не стремиться узнать и понять детали. Он смотрит корни, типа канбан — из логистики тойоты, и не смотрит на смысл именно в программном обеспечении. |
− | * Идея | + | * Идея — «Time and Material» расхолаживает команду. Воспринимает «Fix Price» как способ держать команду в тонусе. |
− | * Идея | + | * Идея — не работать с требованиями вообще. На самом деле — не работать с техническими требованиями. Use case — недоступная заказчику вещь (не ИТ-заказчика, а бизнес)… |
− | * | + | * ''Software development disasters'' — попил-откат ФБР/ЦРУ и т. п. слив несмотря на квалификацию персонала ссылки [http://en.wikipedia.org/wiki/List_of_software_engineering_topics#Disasters здесь] |
* Нельзя говорить в терминах методологий, надо работать на уровне здравого смысла. | * Нельзя говорить в терминах методологий, надо работать на уровне здравого смысла. | ||
− | * Бизнесмен не говорит на языке требований, он говорит на языке целей. Если бы он мог представить пути достижения | + | * Бизнесмен не говорит на языке требований, он говорит на языке целей. Если бы он мог представить пути достижения — он бы просто зарядил в Калькутту. |
* Коммуникация. Программеры на нее не идут, и заказчик вынужден защищаться своими ит-шниками, с которых он требует драконовскими методами. | * Коммуникация. Программеры на нее не идут, и заказчик вынужден защищаться своими ит-шниками, с которых он требует драконовскими методами. | ||
− | * Цели, в отличие от требований | + | * Цели, в отличие от требований — не протухают и понятно приоритеты. |
− | * Хотя спуск по дереву целей, для сложных конструкций, на мой взгляд не слишком понятно. Сильно перекликается с FDD | + | * Хотя спуск по дереву целей, для сложных конструкций, на мой взгляд, не слишком понятно. Сильно перекликается с FDD — это его слова. Цели меняются редко — меняется способ достижения. Превращаем цели в ''feature set''. |
− | * Любит рисовать на доске | + | * Любит рисовать на доске — это на вопрос об инструменте. |
− | * Пример реального проекта | + | * Пример реального проекта — хотим повысить управляемость, для этого внедрить планирование. Чтобы план не фикция. Как сделать — чтобы был простым и актуальным и прочее. Некоторая понятная цель рассуждений, но как это с ПО связано неясно. |
− | * Надо ли участвовать команде в круглые столы с заказчиком | + | * Надо ли участвовать команде в круглые столы с заказчиком — да надо, чтобы единое понимание и вовлеченность. |
− | * Но цели надо детально ставить. Был вопрос про 1С типа, цель | + | * Но цели надо детально ставить. Был вопрос про 1С типа, цель — получить отчет. Да, можно, но для этого же первичка — она тоже становится целью. И надо эргономику ввода первичных данных тоже ставить в цели. |
− | * Вопрос против расширения темы | + | * Вопрос против расширения темы — не суйтесь в бизнес-консалтинг. Давайте заниматься своей отраслью. |
== Калугин Александр. Коммуникация нефункциональных требований в небольших проектах по заказной разработке ПО == | == Калугин Александр. Коммуникация нефункциональных требований в небольших проектах по заказной разработке ПО == | ||
− | Доклад был о нечетких требованиях, с которыми есть проблемы ввиду нечетких постановок, которые нельзя реализовать формально и вообще не всегда можно внести ясность. '''Я:''' В целом все правильно, просто для меня | + | Доклад был о нечетких требованиях, с которыми есть проблемы ввиду нечетких постановок, которые нельзя реализовать формально и вообще не всегда можно внести ясность. '''Я:''' В целом все правильно, просто для меня — очевидно, ситуация нечетких требований, которые надо выявлять и уточнять — типовая. Более того, с функциональными требованиями тоже не все ясно, если плотно работать. |
− | '''Далее | + | '''Далее — заметки'''. |
− | * Есть ситуации, когда все ясно: понятная ограниченная платформа, разработка по аналогии с конкурентами, портирование. | + | * Есть ситуации, когда все ясно: понятная ограниченная платформа, разработка по аналогии с конкурентами, портирование. |
− | * Требования или пожелания: требования суть ограничения, а если жесткого ограничения нет, можно считать пожеланием. Одно и то же в одних условиях | + | * Требования или пожелания: требования — суть ограничения, а если жесткого ограничения нет, можно считать пожеланием. Одно и то же в одних условиях — требование, а в других — пожелание, например, следование стандарту. Или юзабилити — если сделать как у конкурентов и лучше — это требование. |
− | * Разработка | + | * Разработка «как у конкурента» полагает хорошей штукой. Во всяком случае, потому что можно проверить и т. п. |
− | * Хотя пожелания и нечетко, не следование им тоже может привести к провалу проекта. А может | + | * Хотя пожелания и нечетко, не следование им тоже может привести к провалу проекта. А может — и не привести. Нужен баланс, надо договариваться с заказчиком. Нельзя подходить формально — берем метрику и говорим «не ниже». Потому что оно не физично. И есть сложность обсуждения. Плюс требования в метриках — подстава для подрядчика, сложность доказывать. То есть пожелания «не надо так работать». Разве что мы в архитектуру встраиваем ограничения: пользователей не более 100тыс. А вот с быстродействием сложно. Оптимизировать сразу — лишнее, надо потом. Плюс еще вопросы тестирования. Например «бесперебойная работа». |
* Поэтому избегайте таких формулировок. Я: собственно, все правильно, но на мой взгляд очевидно. | * Поэтому избегайте таких формулировок. Я: собственно, все правильно, но на мой взгляд очевидно. | ||
− | * Хотя есть детали. Например, как требования совместимости | + | * Хотя есть детали. Например, как требования совместимости — из доли рынка разных устройств или броузеров. И т.п. Идентификаторы по-русски с пробелами — надо или нет? И разрешение экрана. |
− | * Качать требования, дихотомии. Например, удобство веба | + | * Качать требования, дихотомии. Например, удобство веба — это что? работа с разными типами браузеров или чтобы все летало? десктоп: красота — кастомные контролы или под всеми системами быстро? Канал: оффлайн или наоборот сохранение как можно быстрее? Дольше не падает или быстрее восстанавливается а данные не теряются? Word — падает, но файл — сохраняется. |
− | * Большие объемы данных | + | * Большие объемы данных — таблицы с автофильтром не катят, нарушение нефункционального требования в угоду функциональному («автофильтры») — меняйте, договаривайтесь. Аналогично — заполнение формы объявления на машину — полные дропдоун списки, на объемах и каналах плохо. |
− | * Прямые запросы за списками, сохранение файлов | + | * Прямые запросы за списками, сохранение файлов — функциональный кейс нарушает производительность, много синхронных запросов. Меняйте последовательность работы. |
− | * Но в целом тут он говорит не о функциональных ТРЕБОВАНИЯХ а о сценариях их реализации. Впрочем, клиенты и аналитики любят их писать, а разработчики | + | * Но в целом тут он говорит не о функциональных ТРЕБОВАНИЯХ, а о сценариях их реализации. Впрочем, клиенты и аналитики любят их писать, а разработчики — тогда по ним реализовывают. |
− | * Идея борьбы | + | * Идея борьбы — чеклисты ограничений, дихотомии — набирать опыт. В целом понятно. И библиотека преобразований юскейсов, по сути, решения проблем. Это сложнее. |
== Якима Александр. Lean: Эффективное управление требованиями == | == Якима Александр. Lean: Эффективное управление требованиями == | ||
− | Докладчик | + | Докладчик — украинец, но сейчас работает в Индии, Германии, США. Продуктовая разработка, в компании десятки-сотни команд. Хороший рассказ, но негладкий по речи и до Книберга ему далеко. Поскольку я хорошо представляю процесс, то, как мне кажется, понял и оценил содержимое доклада. Однако, по отзывам других слушателей, они эти мысли не уловили, на мой взгляд — как раз из-за сумбурности изложения. |
− | '''Далее | + | '''Далее — заметки'''. |
− | * Lean. Ему не нравится | + | * Lean. Ему не нравится «бережливое производство», потому как производства в ПО нет. И акцент смещается — от минимизации затрат к использованию вариабельности и управлению очередями. lean generation 2. |
* david anderson. etc. poppendic вчерашний день (но книга про cash и что-то). | * david anderson. etc. poppendic вчерашний день (но книга про cash и что-то). | ||
− | * Принципы lean-потока. | + | * Принципы lean-потока. |
** Экономическая перспектива, не только в моменте, но и со временем. Стоимость задержки. Помощь бизнесу. | ** Экономическая перспектива, не только в моменте, но и со временем. Стоимость задержки. Помощь бизнесу. | ||
− | ** Активное управление очередями. Разница: очередь и пакет, в чем разница. Пакет | + | ** Активное управление очередями. Разница: очередь и пакет, в чем разница. Пакет — параллельное исполнение, пакет историй. |
** Понимание и использование изменяемости | ** Понимание и использование изменяемости | ||
** ограничение пакетов | ** ограничение пакетов | ||
− | ** | + | ** WIP-ограничения |
− | ** управление потоком в условиях неопределенности | + | ** управление потоком в условиях неопределенности — каденции и синхронизация |
− | ** | + | ** … |
− | * agile | + | * agile — пример lean в софте. Хотя возник самостоятельно. Канбан — другой пример. Все есть леан :) Правда он путает agile и scrum, а может считает что по управлению в agile кроме scrum ничего нет. |
− | * | + | * Очереди… Часто их не видим и это — проблемы. Очереди — между разными этапами. Большая очередь — это плохо, большая вариабельность в оценке сроков. |
* Чем больше очередь (PBL), тем неопределеннее сроки. | * Чем больше очередь (PBL), тем неопределеннее сроки. | ||
− | * Тезис | + | * Тезис — делайте короче релизы, будет короче очередь. Лучше меньше полгода, от 3 месяцев и ниже. |
− | * Закон Литтла. Время ожидания в очереди пропорционально ее средней длине. Если у вас в середине есть очереди между этапами, то там оно будет стоять. w=L/лямбда 1/лямбда | + | * Закон Литтла. Время ожидания в очереди пропорционально ее средней длине. Если у вас в середине есть очереди между этапами, то там оно будет стоять. w=L/лямбда 1/лямбда — тик цикла, выход. |
* Собственно, в этом смысл уменьшения количества элементов в очередях. | * Собственно, в этом смысл уменьшения количества элементов в очередях. | ||
− | * Детализация требования JIT | + | * Детализация требования JIT — когда нужно, а не когда хотим. Метафора — требование есть контейнер, который мы наполняем деталями. Например Эпос-Фича-История. Еще есть ''minimum marketable feature'' — квант, который можно доставить. |
− | * business owner | + | * ''business owner'' — любой стейкхолдер выдвигающий требования, влияющий на ''roadmap'' |
− | * Эпос: работа | + | * Эпос: совместная работа в ворд. Фича — одновременная работа с документами и т. п., дальше в истории. |
* Идея: твиттер-постановки. Из требований по 60 символов :) | * Идея: твиттер-постановки. Из требований по 60 символов :) | ||
− | * INVEST. первая буква | + | * INVEST. первая буква — независимость историй. <tt>S</tt> — small. |
− | * Большие пакеты | + | * Большие пакеты — приводят к еще большим. Большой проект раздувается, к ним легко добавить еще немного. |
− | * Методика define-build-test по кругу итерации. Кусочек | + | * Методика ''define-build-test'' по кругу итерации. Кусочек — маленький, но по всем уровням системы, это важно. Плюс — уменьшает очереди, компактизация. |
− | * Про синхронизацию | + | * Про синхронизацию — когда несколько команд над одним продуктом — итерации синхронны. И интеграция в конце. В общем-то типовой подход. Точки синхронизации — планирование релиза; внутри спринта — интегрироваться несколько раз с другими командами, а потом — выход. Еще есть инфраструктурные ортогональные команды, например, верхнеуровневая архитектура. |
− | * Децентрализация. Менеджеры (PO) говорят, что надо делать, а команда | + | * Децентрализация. Менеджеры (PO) говорят, что надо делать, а команда — за сколько смогут сделать. Децентрализация и доверие должно быть. иначе леан и agile не работают. |
− | * Общий большой бэклог | + | * Общий большой бэклог — не обязательство. Обязательство — то, что вошло в релиз. Хотя на верхнем уровне есть некоторые общий роадмап. |
== Веденин Юрий. Опыт разработки и внедрения системы квалификации аналитиков == | == Веденин Юрий. Опыт разработки и внедрения системы квалификации аналитиков == | ||
− | Вполне понятный рассказ о формальной системе. Правда 5 уровней при 10 аналитиков, причем высшая не заполнена | + | Вполне понятный рассказ о формальной системе. |
+ | Правда 5 уровней при 10 аналитиков, причем высшая не заполнена — как-то этого чересчур, по-моему. А еще — система совсем свежая, 3 месяца. По ней еще не нанимали внешних людей. Так что пионерский доклад в этом смысле. Но — они сделали, договорились с руководством, начальную оценку получили — повод для доклада есть. И он не стесняясь говорит, что система новая, и многое впереди. Мы сами это делали на первом этапе работы с разрядами, и сейчас в сторону большой формализации не копаем, а используем как повод для разговора — а они пока копают именно в формальную часть. Но это может быть уместно в их компании. | ||
− | '''Далее | + | '''Далее — заметки'''. |
− | * Градации: Интерны | + | * Градации: Интерны → системные аналитики → старш системные аналитики → бизнес-системный аналитик → старший бизнес. |
− | * Бизнес-аналитики | + | * Бизнес-аналитики — уровень, с которого начинают разбираться в бизнесе. Системные в бизнесе не разбираются. Старшие — несколько областей или проектов. |
− | * День карьерного роста | + | * День карьерного роста — что достиг + направления развития. |
− | * Подготовка к дню | + | * Подготовка к дню — менеджер + два эксперта, заполняют матрицу компетенций и определяют возможные направления. Дальше ему это посылали, он готовился к обсуждению и дальше обсуждение с фиксацией результатов. |
− | * Оценки | + | * Оценки — от заказчика, от тестировщиков и прочее, нарекания… |
− | * Забавный пример | + | * Забавный пример — зачем нужна подтвержденная оценка… Вдруг взял и случайно написал хорошую спецификацию — повезло :) |
− | * Реально | + | * Реально — подтвержденные неоднократные успехи. |
− | * Системные аналитики, компетенции: SRS, URS; прототипирование интерфейсов; английский по своим уровням (бизнес-общение: reader writer mailer speaker presenter); производственный опыт на проекте в аналит.активностях. | + | * Системные аналитики, компетенции: SRS, URS; прототипирование интерфейсов; английский по своим уровням (бизнес-общение: reader → writer → mailer → speaker → presenter); производственный опыт на проекте в аналит.активностях. |
− | * 11 точек роста для уровня системного аналитика. что человек должен делать, чтобы рости. Например: теория требований; самостоятельность разработки требований; точность оценки времени своей работы | + | * 11 точек роста для уровня системного аналитика. что человек должен делать, чтобы рости. Например: теория требований; самостоятельность разработки требований; точность оценки времени своей работы — они до 30 %; качество документирования (без метрик, по нареканиям); … Что он делает для роста — отдельный вопрос (книги, задачи, еще что-то) |
− | * Они не откатали, может ли бизнес-аналитик быть без системного. В принципе может, но навыки системного аналитика | + | * Они не откатали, может ли бизнес-аналитик быть без системного. В принципе может, но навыки системного аналитика — по любому должны быть. |
− | * Система развивается. И они систему образования дальше будут развивать. | + | * Система развивается. И они систему образования дальше будут развивать. |
− | * Очень хочет общего понимания отрасли | + | * Очень хочет общего понимания отрасли — что есть бизнес-аналитик. Потому что в каждой компании — все по-своему. |
− | * Есть версии квалификации IIBA. Читал вторую версию, получил третью. Они становятся лучше, но сложнее, и с его точки зрения | + | * Есть версии квалификации IIBA. Читал вторую версию, получил третью. Они становятся лучше, но сложнее, и с его точки зрения — чрезмерно. |
− | * Проактивная | + | * Проактивная позиция… |
− | * К уровням привязаны медианы. | + | * К уровням привязаны медианы. |
* Квалификация раз в полгода, хочет квартально ДКР. | * Квалификация раз в полгода, хочет квартально ДКР. | ||
− | * А еще | + | * А еще — менторинг, тренинги — все будут делать. |
− | * Точки роста и грейды | + | * Точки роста и грейды — не обязательно закрыть все для повышения квалификации. |
− | * Саму систему сделали в связи с ростом компании | + | * Саму систему сделали в связи с ростом компании, отвечать на вопрос можно ли конкретного аналитика ставить на проект, как справедливо платить… |
− | * Какой-то странный вопрос | + | * Какой-то странный вопрос — а вдруг аналитики вырастут и уйдут, они же будут свои знания представлять и прочее. |
− | * Есть старая версия системы для всех ролей | + | * Есть старая версия системы для всех ролей — разработчики, руководители групп. Но стройная — для аналитиков. |
== Банасевич Алексей. Разработка тиражного коммерческого программного продукта. Опыт выживания == | == Банасевич Алексей. Разработка тиражного коммерческого программного продукта. Опыт выживания == | ||
− | Основная идея доклада | + | Основная идея доклада — работая по scrum надо быть последовательным и требования тоже получать инкрементально. Собственно, в этом основной смысл. Хотя многие известные ему команды применяя скрам, хотят требования сразу. Может быть, страхуются на проектах с жадными заказчикамИ, торгующимися за каждую копейку, а может не умеют разделять риски. Во всяком случае, не любят работать с неполными требованиями. И теряют основное преимущество agile — быструю реакцию на изменения. Поэтому он и сделал доклад о своем опыте. В целом доклад мне понравился, хотя сам материал для меня был очевидным. |
− | '''Далее | + | '''Далее — заметки'''. |
− | * Риск переписывания надо исключать. Для этого желательно описать весь спектр | + | * Риск переписывания надо исключать. Для этого желательно описать весь спектр — широко. Но — поверхностно. Не надо погружаться глубоко. Более того, глубокое погружение сначала — вредит. И приоритеты хотя бы изначальные. |
− | * Почему глубоко вредно? Потому что команда (или потом) можно придумать лучше. Пример когда по эскизу исполнитель сделал | + | * Почему глубоко вредно? Потому что команда (или потом) можно придумать лучше. Пример — когда по эскизу исполнитель сделал OLAP-решение. А заказчик его не знал, и если бы он конкретизировал — получил бы конечные решения. |
− | * Подробно написанное требование устаревает в момент написания. Да и потом можно не делать, а реализовывать, только на это надо идти сознательно. Например, риск что команда вдруг разбежится. | + | * Подробно написанное требование устаревает в момент написания. Да и потом можно не делать, а реализовывать, только на это надо идти сознательно. Например, риск, что команда вдруг разбежится. |
* Фактор успеха | * Фактор успеха | ||
− | ** | + | ** ''Wear customer hat'', особенно в продуктовой модели |
** командное продуктовое мышление | ** командное продуктовое мышление | ||
− | ** | + | ** брейнсторм, только надо использовать результаты |
− | ** фокус-группы рулят. пример | + | ** фокус-группы рулят. пример — когда по впечатлению от дизайна получить впечатление. только ее надо подобрать. |
** обратная связь. не забивать на нее Это вы думаете, что пользователь сказал фигню, реально вы просто его не поняли, а он вещь предложил | ** обратная связь. не забивать на нее Это вы думаете, что пользователь сказал фигню, реально вы просто его не поняли, а он вещь предложил | ||
** нужно чтоб люди не боялись высказывать мнения. | ** нужно чтоб люди не боялись высказывать мнения. | ||
Строка 142: | Строка 147: | ||
** первый прототип как можно быстрее, две недели | ** первый прототип как можно быстрее, две недели | ||
** как можно быстрее все компоненты. пусть заглушки | ** как можно быстрее все компоненты. пусть заглушки | ||
− | ** каждые 2 недели | + | ** каждые 2 недели — деливери. хоть фокус-группе |
− | ** обязательно побуждать ознакомиться ( | + | ** обязательно побуждать ознакомиться («выпустили кайфную фичу») инфоподготовка. можно презентации |
− | ** ревью скоупа и требований после каждого деливери обязательно. в процессе | + | ** ревью скоупа и требований после каждого деливери обязательно. в процессе тоже можно |
− | * цель | + | * цель — выпустить целостный продукт. Нет цели выпустить скоуп начальных требований. |
− | * Хоть один должен держать целостную картину. В идеале | + | * Хоть один должен держать целостную картину. В идеале — вся команда. |
* И куча всего практик (известных, понятных) | * И куча всего практик (известных, понятных) | ||
− | * Гибкий треугольник. Запланировать больше. чем можем. сознательно снизив качество чтобы показать сырые прототипы важных фич. Наоборот, снизить темп вытягивая качество. | + | * Гибкий треугольник. Запланировать больше. чем можем. сознательно снизив качество чтобы показать сырые прототипы важных фич. Наоборот, снизить темп вытягивая качество. |
* Контролировать скоуп. | * Контролировать скоуп. | ||
− | * Дальше 7 месяцев вперед | + | * Дальше 7 месяцев вперед — только намерения, не планы. |
− | * При итерациях | + | * При итерациях — не всегда получается то о чем думали вначале. Потому что каждый раз корректируем курс. И это классно — продукт в целом лучше, все довольны |
− | * Итерации с фиксед кост | + | * Итерации с фиксед кост — плохо совместимы. Если можно заложиться, тогда работает. Но если торгуются до копейки и подушки нет — не получится '''Я:''' но и другими способами, если не заложиться — не выйдет |
− | * Очень многие известные ему команды ведут по скраму разработку | + | * Очень многие известные ему команды ведут по скраму разработку, но требования требуют сразу. Он за работу с требованиями по скраму, и именно поэтому сделал доклад. |
== Turner Paul The Evolving role of the Business Analyst == | == Turner Paul The Evolving role of the Business Analyst == | ||
− | Живой и экспрессивный рассказ, с выражением. Но, к сожалению, в том темпе английского, когда я не успевают рефлексировать. Поэтому записи | + | Живой и экспрессивный рассказ, с выражением. Но, к сожалению, в том темпе английского, когда я не успевают рефлексировать. Поэтому записи бедны… |
− | * balance between | + | * balance between |
− | ** demand | + | ** demand — scope of role and competence |
− | ** supply | + | ** supply — people, prof, proof, qual |
− | * Шутка. Модель областей (процессы, люди, | + | * Шутка. Модель областей (процессы, люди, …) где опущено ядро — inform and technology |
− | * V-модель | + | * V-модель реализации…. с уровнями. Бизнес-аналитик наверху, и он — принимает работу ОК. |
* SFIA skill set: Skills Framework for the Information Age | * SFIA skill set: Skills Framework for the Information Age | ||
= Остальные доклады = | = Остальные доклады = | ||
− | Большинство докладов можно было оценить как приличные. Одни я слушал все, другие | + | Большинство докладов можно было оценить как приличные. Одни я слушал все, другие — частично. Потому что когда не было замечательного доклада, то я старался побывать на всех трех треках. |
== Бондаренко Мария. Управление требованиями в условиях неопределенности == | == Бондаренко Мария. Управление требованиями в условиях неопределенности == | ||
− | Некоторый общий ликбез. Опыт явно присутствует, но где-то на заднем плане, излагается обезличено с высоким уровнем абстракции, однако соотнесения с мировым опытом нет. Меня лично не вдохновляет подход работы с требованиями мелкой россыпью, а доклад был об этом. | + | Некоторый общий ликбез. |
+ | Опыт явно присутствует, но где-то на заднем плане, излагается обезличено, с высоким уровнем абстракции, однако соотнесения с мировым опытом нет. | ||
+ | Меня лично не вдохновляет подход работы с требованиями мелкой россыпью, а доклад был об этом. | ||
− | '''Далее | + | '''Далее — заметки'''. |
− | * Идея: две базы, оригинальные запросы, и требования на основе их. Исходные не склеивать. Понимать | + | * Идея: две базы, оригинальные запросы, и требования на основе их. Исходные не склеивать. Понимать «зачем» для решений. Приоритеты у источников запросов, веса конкретных запросов. |
* Вообще говоря, кейс работы с множеством небольших слабозависимых требований, типа усовершенствований. | * Вообще говоря, кейс работы с множеством небольших слабозависимых требований, типа усовершенствований. | ||
− | * Правильные слова про зашоренность клиентов, не делайте что просят а творчески преобразовывать. Типа бронировать == отправить на email, хотя реальная фича | + | * Правильные слова про зашоренность клиентов, не делайте, что просят, а творчески преобразовывать. Типа бронировать == отправить на email, хотя реальная фича — гейт-бронирования. |
− | * Перекрестное опыление опыта клиентов за счет продуктов. Конкретные рекомендации, типа справочников заполняемых клиентами при настройке экземпляра и т.п. | + | * Перекрестное опыление опыта клиентов за счет продуктов. Конкретные рекомендации, типа справочников заполняемых клиентами при настройке экземпляра и т. п. |
== Евграшин Тимофей. От Agile управления требованиями к глобальным изменениям в компании == | == Евграшин Тимофей. От Agile управления требованиями к глобальным изменениям в компании == | ||
− | Лекция. Ровная. Скорее по чужим учебникам. Слайды | + | Лекция. Ровная. Скорее по чужим учебникам. Слайды отсутствуют… Народу было интересно, и докладчик, наверное, разбирается в материале, но все это можно прочитать в книгах, и '''лучше''' — у того же Книберга. Может быть, я не досидел до того места, где пошел личный опыт. |
== Reed Adrian. Stakeholder Engagement: Delivering projects in the face of advers == | == Reed Adrian. Stakeholder Engagement: Delivering projects in the face of advers == | ||
− | Речь как журчание ручейка. В целом все правильно, но без | + | Речь как журчание ручейка. В целом все правильно, но без вдохновения… Может быть, я пристрастен — потому что язык чужой, и для понимания нужно больше энергии, чем для доклада на русском — соответственно, требования для меня выше. |
== Новичков Александр, Галина Карабанова. Коммуникации и психология межличностных отношений в проектной команде == | == Новичков Александр, Галина Карабанова. Коммуникации и психология межличностных отношений в проектной команде == | ||
− | Какие-то известные вещи из книг про коммуникации. Например, что надо комбинировать слух и визуальный канал. Виды восприятия и прочее. Аудиал-визуал и т.п. Для меня | + | Какие-то известные вещи из книг про коммуникации. Например, что надо комбинировать слух и визуальный канал. Виды восприятия и прочее. Аудиал-визуал и т. п. Для меня — все знакомо и достаточно очевидно, я даже подумал, может, слышал их на другой конференции — нет, не слышал. |
== Erasmus Michiel The Real World Business Analyst == | == Erasmus Michiel The Real World Business Analyst == | ||
− | Рассказ весьма не по делу. С детства и со школы, и об этом | + | Рассказ весьма не по делу. С детства и со школы, и об этом долго… Это не для начинающих бизнес-аналитиков, а для школьников, по-моему… Я ушел достаточно быстро, а резюме тех, кто слушал до конца, потому что стеснялся вылезать из полного зала — на начало доклада пришли очень многие: «Докладчик родился в южной африке и делился трудным детством без компов. Сейчас приехал в Голландию и работает бизнес-аналитиком, и ему хорошо 0 о чем он и рассказывал». |
− | == Хлебников Сергей. Представление знаний о предметной области на основе эффективных юзкейсов == | + | == Хлебников Сергей. Представление знаний о предметной области на основе эффективных юзкейсов == |
− | Докладчик рассказывал собственный опыт, с помощью которого он систематизировал знания о сложной предметной области при работе над проектом Сбербанка. Знания представлял в виде описания usecase в достаточно сложной формлаьной форме, в результате | + | Докладчик рассказывал собственный опыт, с помощью которого он систематизировал знания о сложной предметной области при работе над проектом Сбербанка. Знания представлял в виде описания usecase в достаточно сложной формлаьной форме, в результате — овладел предметной областью лучше многих специалистов заказчика. Но в этом для меня ничего особо удивительного — хороший аналитик так или иначе овладеет предметной областью, с которой он работает. А вот про то, что знаниями предметной области овладел кто-то другой, базируясь на его описании — в докладе не было. Равно как и о том, что его сложной формальной системой пользовался кто-то из заказчиков. Так что есть сильное ощущение, что все это было системой одного человека-автора. |
− | Так что у меня лично большие сомнения в эффективности написания и, главное, сопровождения таких тяжелых usecase. Потому что дорого. Практически я | + | Так что у меня лично большие сомнения в эффективности написания и, главное, сопровождения таких тяжелых usecase. Потому что дорого. Практически я допускаю такое только при реализации силами неквалифицированных кодеров по низкоуровневым постановкам — то есть не на современных языках, которые не допускают неквалифицированных кодеров ввиду сложности заложенных концепций. |
− | Со слайдами у него очень плохо, слайдоменты. И не слишком хорошо по логике. И с мировой терминологией | + | Со слайдами у него очень плохо, слайдоменты. И не слишком хорошо по логике. И с мировой терминологией — очень творчески перерабатывает термины, работает почти по своими. |
− | Зато в целом в докладе был достаточно хороший обзор истории развития практики usecase, это большой плюс. Идея тут следующая. Как известно, usecase придумал Якобсон. Но потом Коберн внес много принципиально нового. А Якобсон его не оценил, сказав лишь, что | + | Зато в целом в докладе был достаточно хороший обзор истории развития практики ''usecase'', это большой плюс. Идея тут следующая. Как известно, usecase придумал Якобсон. Но потом Коберн внес много принципиально нового. |
+ | А Якобсон его не оценил, сказав лишь, что «подход Коберна не противоречит его подходу». | ||
+ | Классическая книга по usecase, признанная Якобсоном очень хорошей — Битнер и Спенсер (2002), также игнорирует новое от Коберна. | ||
+ | А книга Коберна (2000) — очень тяжелая, поэтому ее не слишком читают. Вот так. | ||
− | '''Далее | + | '''Далее — заметки'''. |
− | * Считает use case представлением знаний. Типа, представление требований | + | * Считает use case представлением знаний. Типа, представление требований — «более привычно» |
* стейкхолдер == носитель знаний == заинтересованное лицо | * стейкхолдер == носитель знаний == заинтересованное лицо | ||
− | * Сведения можно представить в виде требований | + | * Сведения можно представить в виде требований, но оно будет коряво. |
− | * Очень много информации, которые сложно представить требованиями, зато представляется через use case и он придумал некоторую методику. Задача | + | * Очень много информации, которые сложно представить требованиями, зато представляется через use case и он придумал некоторую методику. Задача — представить знания. Причем в доступном всем стейкхолдерам варианте. |
* Канонической теории нет, есть два варианта, к одной из которых каждый склоняется | * Канонической теории нет, есть два варианта, к одной из которых каждый склоняется | ||
− | * use case == buzzword. | + | * use case == buzzword. |
− | * Познакомился с usecase, когда читал Якобсона. Но не понял, что use case | + | * Познакомился с usecase, когда читал Якобсона. Но не понял, что use case — тексты прежде всего. Понял, когда прочитал Коберна и в его струе работает. Потом Ларман. Соединить |
− | * Его методология позволяет любую предметную область | + | * Его методология позволяет любую предметную область «влет». |
* Перескочил на РУП. РУП: подход + процесс + фреймворк | * Перескочил на РУП. РУП: подход + процесс + фреймворк | ||
* Киты: итерации, юзкейс, архитектура. И что-то он добавил | * Киты: итерации, юзкейс, архитектура. И что-то он добавил | ||
− | * Дух | + | * Дух RUPа. самое важное — разрабатывайте то, что хочет заказчик. '''Я:''' весьма любопытное понимание. |
* юзкейс == текст, читается всеми. надо чтобы было понятно всеми. | * юзкейс == текст, читается всеми. надо чтобы было понятно всеми. | ||
− | * юзкейс | + | * юзкейс — синтез, а не анализ. |
− | * юзкейс | + | * юзкейс — скачок воображения, способ соединить мнение всех стейкхолдеров. |
* Два подхода | * Два подхода | ||
− | *# От Якобсона. Битнер и Спенсер (2002). Игнорируя Коберна, хотя она вышла в 2000. Сам Якобсон считает, что | + | *# От Якобсона. Битнер и Спенсер (2002). Игнорируя Коберна, хотя она вышла в 2000. Сам Якобсон считает, что «подход Коберна не противоречит его подходу». Но игнорирует развитие. |
− | *# Коберн как принципиальное развитие юзкейсов. Только его книга | + | *# Коберн как принципиальное развитие юзкейсов. Только его книга — намного тяжелее, чем у Битнера и Спенсера. Ее тяжело читать. То есть — придумал, но не описал. |
* У Якобсона акцент на диаграммы, а не на текстовое представление. | * У Якобсона акцент на диаграммы, а не на текстовое представление. | ||
* Ключевые моменты: actor цель ценность | * Ключевые моменты: actor цель ценность | ||
− | * Переписал пример Битнера из книги по Коберну | + | * Переписал пример Битнера из книги по Коберну — он получается лучше. |
− | * Коберн | + | * Коберн — добавил стейкхолдера == носителя знаний. Внутри кейса ничего, кроме знаний стейкхолдера. ввел primary actor, actor с системой — два актора. |
− | * Выделение сценариев | + | * Выделение сценариев — это Коберн. формальное. |
− | * Проекция интересов стейкхолдеров на юзкейс. И это | + | * Проекция интересов стейкхолдеров на юзкейс. И это — важно. |
− | Тут я выходил на другой | + | Тут я выходил на другой доклад… |
− | * Для итеративной разработки задача | + | * Для итеративной разработки задача — выделить мелкие итерации. При нарезке юзкейсов на сценарии и разделении на минитранзакции — можно делить. |
− | * Ларман | + | * Ларман — понятие системного события и системной итерации. Которые суть запросы. Он дальше делает на фичи. |
− | * Фичи из Rational sweet в MS project с диаграммой ганта, а затем | + | * Фичи из Rational sweet в MS project с диаграммой ганта, а затем — планирование и управление. |
− | * Вообще говоря юзкейсы получаются детальные, практически алгоритмы! Сложный язык. И с этим заказчик будет работать?? | + | * Вообще говоря юзкейсы получаются детальные, практически алгоритмы! Сложный язык. И с этим заказчик будет работать?? |
− | * Я: Идеи примерно понятны, но это конструкция, когда кодер | + | * Я: Идеи примерно понятны, но это конструкция, когда кодер — просто исполнитель. |
− | * Ближе к концу | + | * Ближе к концу — пошли явные антипатерны. Схема справочника, которую понимал только он. Схема написания юзкейсов, где качество написания критично, и умеет писать (только он). |
− | * Он представил их знания и начал представлять систему лучше них самих. До прихода они представляли абы как. а он | + | * Он представил их знания и начал представлять систему лучше них самих. До прихода они представляли абы как. а он — свел воедино. Он может добраться. А они? |
− | * Проверки | + | * Проверки — несколько сотен включены в юзкейс… |
− | * Дерево | + | * Дерево трассировки… |
− | * Поддерживать юзкейсы это трудоемко. Пользоваться месяцы и годы | + | * Поддерживать юзкейсы это трудоемко. Пользоваться месяцы и годы — они же сгниют… |
* Интересно, а почему он не использовал html для ссылок, а работал с текстами? | * Интересно, а почему он не использовал html для ссылок, а работал с текстами? | ||
− | == Котельников Александр. Особенности разработки требований для систем бухгалтерского и финансового учета | + | == Котельников Александр. Особенности разработки требований для систем бухгалтерского и финансового учета == |
− | В целом грамотный доклад, докладчик представляет вопрос. Народ это в целом интересует. Хотя это больше ликбез с нашей точки зрения, но и на этом уровне слушателям интересно. Людей интересует | + | В целом грамотный доклад, докладчик представляет вопрос. Народ это в целом интересует. Хотя это больше ликбез с нашей точки зрения, но и на этом уровне слушателям интересно. Людей интересует — насколько легко взаимодействовать со Сбером и госзаказчиками и т. п. |
− | '''Далее | + | '''Далее — заметки''' — не с начала. |
− | * Некоторая конкретика внутренних механизмов 1С, устройство учета | + | * Некоторая конкретика внутренних механизмов 1С, устройство учета — регистры остатков, регистры вычислений и прочее. |
− | * Проект | + | * Проект — в центре инфраструктуре, важные пользователи — психологические навыки, документоориентированный интерфейс. |
− | * Особенности требований | + | * Особенности требований — законодательство + внутренние регламенты. И это самая неприятная ловушка, потому как в контракте оно всегда есть и оно будет. |
− | * Бухгалтеры ожидают что аналитики владеют предметом. Вопросы были из серии нельзя ли подложиться от этого, снять риски, | + | * Бухгалтеры ожидают что аналитики владеют предметом. Вопросы были из серии нельзя ли подложиться от этого, снять риски, ответ — нельзя. |
* Бух.учет стандартный, поэтому. как правило. это внедрение и настройка, а не разработка с нуля. | * Бух.учет стандартный, поэтому. как правило. это внедрение и настройка, а не разработка с нуля. | ||
− | * Управленческий учет | + | * Управленческий учет — под себя, единых стандартов не существует — полноценная разработка системы. |
== Зезин Василий. Онтологический взгляд на инженерию требований == | == Зезин Василий. Онтологический взгляд на инженерию требований == | ||
− | Докладчик | + | Докладчик — из INCOSE. В целом это рассказ про системную сложность систем как таковую, но без самого понятия сложности, а описывая конкретные следствиях и проявлениях этой сложности. Доклад хороший, но специалиста по системной инженерии я ожидал большего. А еще оставалось впечатление умозрительности доклада и апелляции к достаточно старым материалам. |
− | '''Далее | + | '''Далее — заметки'''. |
− | * Способов классификации | + | * Способов классификации — много, вопрос полезности. |
− | * Около 30% разработки связано с требованиями, и эта цифра не меняется. | + | * Около 30 % разработки связано с требованиями, и эта цифра не меняется. |
− | * Чем дальше проект зашел, тем сложнее вносить | + | * Чем дальше проект зашел, тем сложнее вносить изменения… |
− | * Как-то оно водопадно- | + | * Как-то оно водопадно-умозрительно… Это обзор по достаточно старым работам… |
− | * Много точек зрения. Про сложность и снижение | + | * Много точек зрения. Про сложность и снижение — не говорил. |
− | * Не надо забывать, что за моделями, диаграммами | + | * Не надо забывать, что за моделями, диаграммами — система. |
* Модели жизненного цикла. Их много. Не надо забывать, что за ними. | * Модели жизненного цикла. Их много. Не надо забывать, что за ними. | ||
* Комп был в каком-то хитром режиме. не зеркало, и не видно что на экране-то слайд не меняется :) | * Комп был в каком-то хитром режиме. не зеркало, и не видно что на экране-то слайд не меняется :) | ||
* URML. Чтобы формально, не тексты. | * URML. Чтобы формально, не тексты. | ||
− | * Договориться с клиентом о практиках, используемых в | + | * Договориться с клиентом о практиках, используемых в работе… |
Версия 21:52, 4 апреля 2011
Содержание
- 1 Общие впечатления
- 2 Замечательные доклады
- 2.1 Ефименко Дмитрий. Метод от целей при анализе требований и управлении рисками программного обеспечения
- 2.2 Калугин Александр. Коммуникация нефункциональных требований в небольших проектах по заказной разработке ПО
- 2.3 Якима Александр. Lean: Эффективное управление требованиями
- 2.4 Веденин Юрий. Опыт разработки и внедрения системы квалификации аналитиков
- 2.5 Банасевич Алексей. Разработка тиражного коммерческого программного продукта. Опыт выживания
- 2.6 Turner Paul The Evolving role of the Business Analyst
- 3 Остальные доклады
- 3.1 Бондаренко Мария. Управление требованиями в условиях неопределенности
- 3.2 Евграшин Тимофей. От Agile управления требованиями к глобальным изменениям в компании
- 3.3 Reed Adrian. Stakeholder Engagement: Delivering projects in the face of advers
- 3.4 Новичков Александр, Галина Карабанова. Коммуникации и психология межличностных отношений в проектной команде
- 3.5 Erasmus Michiel The Real World Business Analyst
- 3.6 Хлебников Сергей. Представление знаний о предметной области на основе эффективных юзкейсов
- 3.7 Котельников Александр. Особенности разработки требований для систем бухгалтерского и финансового учета
- 3.8 Зезин Василий. Онтологический взгляд на инженерию требований
Общие впечатления
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а. самое важное — разрабатывайте то, что хочет заказчик. Я: весьма любопытное понимание.
- юзкейс == текст, читается всеми. надо чтобы было понятно всеми.
- юзкейс — синтез, а не анализ.
- юзкейс — скачок воображения, способ соединить мнение всех стейкхолдеров.
- Два подхода
- От Якобсона. Битнер и Спенсер (2002). Игнорируя Коберна, хотя она вышла в 2000. Сам Якобсон считает, что «подход Коберна не противоречит его подходу». Но игнорирует развитие.
- Коберн как принципиальное развитие юзкейсов. Только его книга — намного тяжелее, чем у Битнера и Спенсера. Ее тяжело читать. То есть — придумал, но не описал.
- У Якобсона акцент на диаграммы, а не на текстовое представление.
- Ключевые моменты: actor цель ценность
- Переписал пример Битнера из книги по Коберну — он получается лучше.
- Коберн — добавил стейкхолдера == носителя знаний. Внутри кейса ничего, кроме знаний стейкхолдера. ввел primary actor, actor с системой — два актора.
- Выделение сценариев — это Коберн. формальное.
- Проекция интересов стейкхолдеров на юзкейс. И это — важно.
Тут я выходил на другой доклад…
- Для итеративной разработки задача — выделить мелкие итерации. При нарезке юзкейсов на сценарии и разделении на минитранзакции — можно делить.
- Ларман — понятие системного события и системной итерации. Которые суть запросы. Он дальше делает на фичи.
- Фичи из Rational sweet в MS project с диаграммой ганта, а затем — планирование и управление.
- Вообще говоря юзкейсы получаются детальные, практически алгоритмы! Сложный язык. И с этим заказчик будет работать??
- Я: Идеи примерно понятны, но это конструкция, когда кодер — просто исполнитель.
- Ближе к концу — пошли явные антипатерны. Схема справочника, которую понимал только он. Схема написания юзкейсов, где качество написания критично, и умеет писать (только он).
- Он представил их знания и начал представлять систему лучше них самих. До прихода они представляли абы как. а он — свел воедино. Он может добраться. А они?
- Проверки — несколько сотен включены в юзкейс…
- Дерево трассировки…
- Поддерживать юзкейсы это трудоемко. Пользоваться месяцы и годы — они же сгниют…
- Интересно, а почему он не использовал html для ссылок, а работал с текстами?
Котельников Александр. Особенности разработки требований для систем бухгалтерского и финансового учета
В целом грамотный доклад, докладчик представляет вопрос. Народ это в целом интересует. Хотя это больше ликбез с нашей точки зрения, но и на этом уровне слушателям интересно. Людей интересует — насколько легко взаимодействовать со Сбером и госзаказчиками и т. п.
Далее — заметки — не с начала.
- Некоторая конкретика внутренних механизмов 1С, устройство учета — регистры остатков, регистры вычислений и прочее.
- Проект — в центре инфраструктуре, важные пользователи — психологические навыки, документоориентированный интерфейс.
- Особенности требований — законодательство + внутренние регламенты. И это самая неприятная ловушка, потому как в контракте оно всегда есть и оно будет.
- Бухгалтеры ожидают что аналитики владеют предметом. Вопросы были из серии нельзя ли подложиться от этого, снять риски, ответ — нельзя.
- Бух.учет стандартный, поэтому. как правило. это внедрение и настройка, а не разработка с нуля.
- Управленческий учет — под себя, единых стандартов не существует — полноценная разработка системы.
Зезин Василий. Онтологический взгляд на инженерию требований
Докладчик — из INCOSE. В целом это рассказ про системную сложность систем как таковую, но без самого понятия сложности, а описывая конкретные следствиях и проявлениях этой сложности. Доклад хороший, но специалиста по системной инженерии я ожидал большего. А еще оставалось впечатление умозрительности доклада и апелляции к достаточно старым материалам.
Далее — заметки.
- Способов классификации — много, вопрос полезности.
- Около 30 % разработки связано с требованиями, и эта цифра не меняется.
- Чем дальше проект зашел, тем сложнее вносить изменения…
- Как-то оно водопадно-умозрительно… Это обзор по достаточно старым работам…
- Много точек зрения. Про сложность и снижение — не говорил.
- Не надо забывать, что за моделями, диаграммами — система.
- Модели жизненного цикла. Их много. Не надо забывать, что за ними.
- Комп был в каком-то хитром режиме. не зеркало, и не видно что на экране-то слайд не меняется :)
- URML. Чтобы формально, не тексты.
- Договориться с клиентом о практиках, используемых в работе…