Впечатления о REQ-Labs 2011 - Макс Цепков — различия между версиями

Материал из Uml2Wiki
Перейти к: навигация, поиск
(Новая страница: «Категория:Внешние события = Общие впечатления = 25.03 в Киеве прошла конференция [http://www.req-...»)
 
Строка 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-шникам туда лезть. Но зал докладчика в целом поддерживал.    
+
Что касается позитивных предложений, то на общем уровне идея в том, чтобы знакомиться со всеми методологии и извлекать полезные и уместные практики, пытаться их применять. На уровне конкретной идеи предлагалось проектирование по бизнес-целям, и заявленное в названии доклада. Думаю, именно потому. что погружаться в бизнес-область до уровня понимания и бизнес-целей и способов их достижения больше всего не любят. Более того, из зала были возгласы, что нельзя оттяпывать хлеб бизнес-консультантов, это их поляна и незачем IT-шникам туда лезть. Но зал докладчика в целом поддерживал.
  
'''Далее - заметки'''.
+
'''Далее заметки'''.
 
* Весьма живо и по делу. Хорошо. Но про более формализованные процессы и ситуации, с вопросами кто виноват?
 
* Весьма живо и по делу. Хорошо. Но про более формализованные процессы и ситуации, с вопросами кто виноват?
 
* Обратная связь от команды на бизнес-аналитиков. Выделяя роль мы усложняем процесс, бизнес-аналитик у заказчика, но надо, чтобы он не отрывался от команды.
 
* Обратная связь от команды на бизнес-аналитиков. Выделяя роль мы усложняем процесс, бизнес-аналитик у заказчика, но надо, чтобы он не отрывался от команды.
 
* Мало программистов могут работать в постановке проблемы. а не в постановке решения
 
* Мало программистов могут работать в постановке проблемы. а не в постановке решения
* Не верит в agile и самоорганизующуюся команду. Считает, что это - тактика малых групп. Очень выгодно, пришло еще из военных. Продажа воздуха со стороны agile потому что он продает команду без конфликтов. Считает, что противоречия ролей неизбежны, не надо совмещать... А итерации - PERT 60х.  
+
* Не верит в agile и самоорганизующуюся команду. Считает, что это тактика малых групп. Очень выгодно, пришло еще из военных. Продажа воздуха со стороны agile потому, что он продает команду без конфликтов. Считает, что противоречия ролей неизбежны, не надо совмещать… А итерации PERT 60х.
* Идет и дальше - на любые методологии, которые обещают серебряный молоток. Их нет. Формальности есть в том объеме. в котором упрощают жизнь. '''Я:''' На самом деле у него частично agile мышление - гибкость есть. Но вот сотрудничество - не верит, процесс-война.
+
* Идет и дальше на любые методологии, которые обещают серебряный молоток. Их нет. Формальности есть в том объеме. в котором упрощают жизнь. '''Я:''' На самом деле у него частично agile мышление гибкость есть. Но вот сотрудничество не верит, процесс-война.
* Проблема RUP - процесс снаружи совсем не то, как видят внутри.
+
* Проблема RUP процесс снаружи совсем не то, как видят внутри.
* XP - ему очень нравятся инженерные практики, и очень не нравится работа с заказчиком. Потому что там идеальный заказчик, которого реально не бывает. И они все риски переваливают на заказчика.
+
* XP ему очень нравятся инженерные практики, и очень не нравится работа с заказчиком. Потому что там идеальный заказчик, которого реально не бывает. И они все риски переваливают на заказчика.
* Реально у него скепсис такой, что он не стремиться узнать и понять детали. Он смотрит корни, типа канбан - из логистики тойоты, и не смотрит на смысл именно в программном обеспечении.
+
* Реально у него скепсис такой, что он не стремиться узнать и понять детали. Он смотрит корни, типа канбан из логистики тойоты, и не смотрит на смысл именно в программном обеспечении.
* Идея ТМ - расхолаживает команду. Воспринимает fix как способ держать команду в тонусе.
+
* Идея — «Time and Material» расхолаживает команду. Воспринимает «Fix Price» как способ держать команду в тонусе.
* Идея - не работать с требованиями вообще. На самом деле - не работать с техническими требованиями. use case - недоступная заказчику вещь (не ИТ-заказчика, а бизнес)...
+
* Идея не работать с требованиями вообще. На самом деле не работать с техническими требованиями. Use case недоступная заказчику вещь (не ИТ-заказчика, а бизнес)
* software development disasters - попил откат ФБР ЦРУ и т.п. слив несмотря на квалификацию персонала ссылки [http://en.wikipedia.org/wiki/List_of_software_engineering_topics#Disasters здесь]
+
* ''Software development disasters'' — попил-откат ФБР/ЦРУ и т. п. слив несмотря на квалификацию персонала ссылки [http://en.wikipedia.org/wiki/List_of_software_engineering_topics#Disasters здесь]
 
* Нельзя говорить в терминах методологий, надо работать на уровне здравого смысла.
 
* Нельзя говорить в терминах методологий, надо работать на уровне здравого смысла.
* Бизнесмен не говорит на языке требований, он говорит на языке целей. Если бы он мог представить пути достижения - он бы просто зарядил в Калькутту.  
+
* Бизнесмен не говорит на языке требований, он говорит на языке целей. Если бы он мог представить пути достижения он бы просто зарядил в Калькутту.
 
* Коммуникация. Программеры на нее не идут, и заказчик вынужден защищаться своими ит-шниками, с которых он требует драконовскими методами.
 
* Коммуникация. Программеры на нее не идут, и заказчик вынужден защищаться своими ит-шниками, с которых он требует драконовскими методами.
* Цели, в отличие от требований - не протухают и понятно приоритеты.
+
* Цели, в отличие от требований не протухают и понятно приоритеты.
* Хотя спуск по дереву целей, для сложных конструкций, на мой взгляд не слишком понятно. Сильно перекликается с FDD - это его слова. Цели меняются редко - меняется способ достижения. Превращаем цели в feature set
+
* Хотя спуск по дереву целей, для сложных конструкций, на мой взгляд, не слишком понятно. Сильно перекликается с FDD это его слова. Цели меняются редко меняется способ достижения. Превращаем цели в ''feature set''.
* Любит рисовать на доске - это на вопрос об инструменте.
+
* Любит рисовать на доске это на вопрос об инструменте.
* Пример реального проекта - хотим повысить управляемость, для этого внедрить планирование. Чтобы план не фикция. Как сделать - чтобы был простым и актуальным и прочее. Некоторая понятная цель рассуждений, но как это с ПО связано неясно.
+
* Пример реального проекта хотим повысить управляемость, для этого внедрить планирование. Чтобы план не фикция. Как сделать чтобы был простым и актуальным и прочее. Некоторая понятная цель рассуждений, но как это с ПО связано неясно.
* Надо ли участвовать команде в круглые столы с заказчиком - да надо, чтобы единое понимание и вовлеченность.
+
* Надо ли участвовать команде в круглые столы с заказчиком да надо, чтобы единое понимание и вовлеченность.
* Но цели надо детально ставить. Был вопрос про 1С типа, цель - получить отчет. Да, можно, но для этого же первичка - она тоже становится целью. И надо эргономику ввода первичных данных тоже ставить в цели.
+
* Но цели надо детально ставить. Был вопрос про 1С типа, цель получить отчет. Да, можно, но для этого же первичка она тоже становится целью. И надо эргономику ввода первичных данных тоже ставить в цели.
* Вопрос против расширения темы - не суйтесь в бизнес-консалтинг. Давайте заниматься своей отраслью.
+
* Вопрос против расширения темы не суйтесь в бизнес-консалтинг. Давайте заниматься своей отраслью.
  
 
== Калугин Александр. Коммуникация нефункциональных требований в небольших проектах по заказной разработке ПО ==
 
== Калугин Александр. Коммуникация нефункциональных требований в небольших проектах по заказной разработке ПО ==
  
Доклад был о нечетких требованиях, с которыми есть проблемы ввиду нечетких постановок, которые нельзя реализовать формально и вообще не всегда можно внести ясность. '''Я:''' В целом все правильно, просто для меня - очевидно, ситуация нечетких требований, которые надо выявлять и уточнять - типовая. Более того, с функциональными требованиями тоже не все ясно, если плотно работать.  
+
Доклад был о нечетких требованиях, с которыми есть проблемы ввиду нечетких постановок, которые нельзя реализовать формально и вообще не всегда можно внести ясность. '''Я:''' В целом все правильно, просто для меня очевидно, ситуация нечетких требований, которые надо выявлять и уточнять типовая. Более того, с функциональными требованиями тоже не все ясно, если плотно работать.
  
'''Далее - заметки'''.
+
'''Далее заметки'''.
* Есть ситуации, когда все ясно: понятная ограниченная платформа, разработка по аналогии с конкурентами, портирование.  
+
* Есть ситуации, когда все ясно: понятная ограниченная платформа, разработка по аналогии с конкурентами, портирование.
* Требования или пожелания: требования суть ограничения, а если жесткого ограничения нет, можно считать пожеланием. Одно и то же в одних условиях - требование, а в других - пожелание, например, следование стандарту. Или юзабилити - если сделать как у конкурентов и лучше - это требование.
+
* Требования или пожелания: требования суть ограничения, а если жесткого ограничения нет, можно считать пожеланием. Одно и то же в одних условиях требование, а в других пожелание, например, следование стандарту. Или юзабилити если сделать как у конкурентов и лучше это требование.
* Разработка "как у конкурента" полагает хорошей штукой. Во всяком случае, потому что можно проверить и т.п.
+
* Разработка «как у конкурента» полагает хорошей штукой. Во всяком случае, потому что можно проверить и т. п.
* Хотя пожелания и нечетко, не следование им тоже может привести к провалу проекта. А может - и не привести. Нужен баланс, надо договариваться с заказчиком. Нельзя подходить формально - берем метрику и говорим "не ниже". Потому что оно не физично. И есть сложность обсуждения. Плюс требования в метриках - подстава для подрядчика, сложность доказывать. То есть пожелания не надо так работать. Разве что мы в архитектуру встраиваем ограничения: пользователей не более 100тыс. А вот с быстродействием сложно. Оптимизировать сразу - лишнее. надо потом. Плюс еще вопросы тестирования. Например "бесперебойная работа".
+
* Хотя пожелания и нечетко, не следование им тоже может привести к провалу проекта. А может и не привести. Нужен баланс, надо договариваться с заказчиком. Нельзя подходить формально берем метрику и говорим «не ниже». Потому что оно не физично. И есть сложность обсуждения. Плюс требования в метриках подстава для подрядчика, сложность доказывать. То есть пожелания «не надо так работать». Разве что мы в архитектуру встраиваем ограничения: пользователей не более 100тыс. А вот с быстродействием сложно. Оптимизировать сразу лишнее, надо потом. Плюс еще вопросы тестирования. Например «бесперебойная работа».
 
* Поэтому избегайте таких формулировок. Я: собственно, все правильно, но на мой взгляд очевидно.
 
* Поэтому избегайте таких формулировок. Я: собственно, все правильно, но на мой взгляд очевидно.
* Хотя есть детали. Например, как требования совместимости - из доли рынка разных устройств или броузеров. И т.п. Идентификаторы по-русски с пробелами - надо или нет? И разрешение экрана.
+
* Хотя есть детали. Например, как требования совместимости из доли рынка разных устройств или броузеров. И т.п. Идентификаторы по-русски с пробелами надо или нет? И разрешение экрана.
* Качать требования, дихотомии. Например, удобство веба - это что? работа с разными типами браузеров или чтобы все летало? десктоп: красота - кастомные контролы или под всеми системами быстро? Канал: оффлайн или наоборот сохранение как можно быстрее? Дольше не падает или быстрее восстанавливается а данные не теряются? Word - падает, но файл - сохраняется.
+
* Качать требования, дихотомии. Например, удобство веба это что? работа с разными типами браузеров или чтобы все летало? десктоп: красота кастомные контролы или под всеми системами быстро? Канал: оффлайн или наоборот сохранение как можно быстрее? Дольше не падает или быстрее восстанавливается а данные не теряются? Word падает, но файл сохраняется.
* Большие объемы данных - таблицы с автофильтром не катят, нарушение нефункционального требования в угоду функциональному ("автофильтры") - меняйте, договаривайтесь. Аналогично - заполнение формы объявления на машину - полные дропдоун списки, на объемах и каналах плохо.
+
* Большие объемы данных таблицы с автофильтром не катят, нарушение нефункционального требования в угоду функциональному («автофильтры») меняйте, договаривайтесь. Аналогично заполнение формы объявления на машину полные дропдоун списки, на объемах и каналах плохо.
* Прямые запросы за списками, сохранение файлов - функциональный кейс нарушает производительность, много синхронных запросов. Меняйте последовательность работы.
+
* Прямые запросы за списками, сохранение файлов функциональный кейс нарушает производительность, много синхронных запросов. Меняйте последовательность работы.
* Но в целом тут он говорит не о функциональных ТРЕБОВАНИЯХ а о сценариях их реализации. Впрочем, клиенты и аналитики любят их писать, а разработчики - тогда по ним реализовывают.
+
* Но в целом тут он говорит не о функциональных ТРЕБОВАНИЯХ, а о сценариях их реализации. Впрочем, клиенты и аналитики любят их писать, а разработчики тогда по ним реализовывают.
* Идея борьбы - чеклисты ограничений, дихотомии - набирать опыт. В целом понятно. И библиотека преобразований юскейсов, по-сути решения проблем. Это сложнее.
+
* Идея борьбы чеклисты ограничений, дихотомии набирать опыт. В целом понятно. И библиотека преобразований юскейсов, по сути, решения проблем. Это сложнее.
  
 
== Якима Александр. Lean: Эффективное управление требованиями ==
 
== Якима Александр. Lean: Эффективное управление требованиями ==
  
Докладчик - украинец, но сейчас работает в Индии, Германии, США. Продуктовая разработка, компании десятки-сотни команд. Хороший рассказ, но негладкий по речи и до Книберга ему далеко. Поскольку я хорошо представляю процесс, то, как мне кажется, понял и оценил содержимое доклада. Однако, по отзывам других слушателей, они эти мысли не уловили, на мой взгляд - как раз из-за сумбурности изложения.  
+
Докладчик украинец, но сейчас работает в Индии, Германии, США. Продуктовая разработка, в компании десятки-сотни команд. Хороший рассказ, но негладкий по речи и до Книберга ему далеко. Поскольку я хорошо представляю процесс, то, как мне кажется, понял и оценил содержимое доклада. Однако, по отзывам других слушателей, они эти мысли не уловили, на мой взгляд как раз из-за сумбурности изложения.
  
'''Далее - заметки'''.
+
'''Далее заметки'''.
* Lean. Ему не нравится "бережливое производство", потому как производства в ПО нет. И акцент смещается - от минимизации затрат к использованию вариабельности и управлению очередями. lean generation 2.
+
* Lean. Ему не нравится «бережливое производство», потому как производства в ПО нет. И акцент смещается от минимизации затрат к использованию вариабельности и управлению очередями. lean generation 2.
 
* david anderson. etc. poppendic вчерашний день (но книга про cash и что-то).
 
* david anderson. etc. poppendic вчерашний день (но книга про cash и что-то).
* Принципы lean-потока.  
+
* Принципы lean-потока.
 
** Экономическая перспектива, не только в моменте, но и со временем. Стоимость задержки. Помощь бизнесу.
 
** Экономическая перспектива, не только в моменте, но и со временем. Стоимость задержки. Помощь бизнесу.
** Активное управление очередями. Разница: очередь и пакет, в чем разница. Пакет - параллельное исполнение, пакет историй.
+
** Активное управление очередями. Разница: очередь и пакет, в чем разница. Пакет параллельное исполнение, пакет историй.
 
** Понимание и использование изменяемости
 
** Понимание и использование изменяемости
 
** ограничение пакетов
 
** ограничение пакетов
** wip-ограничения
+
** WIP-ограничения
** управление потоком в условиях неопределенности - каденции и синхронизация
+
** управление потоком в условиях неопределенности каденции и синхронизация
** ...
+
**
* agile - пример lean в софте. Хотя возник самостоятельно. Канбан - другой пример. Все есть леан :) Правда он путает agile и scrum, а может считает что по управлению в agile кроме scrum ничего нет.
+
* agile пример lean в софте. Хотя возник самостоятельно. Канбан другой пример. Все есть леан :) Правда он путает agile и scrum, а может считает что по управлению в agile кроме scrum ничего нет.
* Очереди... Часто их не видим и это - проблемы. Очереди - между разными этапами. Большая очередь - это плохо, большая вариабельность в оценке сроков.
+
* Очереди… Часто их не видим и это проблемы. Очереди между разными этапами. Большая очередь это плохо, большая вариабельность в оценке сроков.
 
* Чем больше очередь (PBL), тем неопределеннее сроки.
 
* Чем больше очередь (PBL), тем неопределеннее сроки.
* Тезис - делайте короче релизы, будет короче очередь. Лучше меньше полгода, от 3 месяцев и ниже.
+
* Тезис делайте короче релизы, будет короче очередь. Лучше меньше полгода, от 3 месяцев и ниже.
* Закон Литтла. Время ожидания в очереди пропорционально ее средней длине. Если у вас в середине есть очереди между этапами, то там оно будет стоять. w=L/лямбда 1/лямбда - тик цикла, выход.
+
* Закон Литтла. Время ожидания в очереди пропорционально ее средней длине. Если у вас в середине есть очереди между этапами, то там оно будет стоять. w=L/лямбда 1/лямбда тик цикла, выход.
 
* Собственно, в этом смысл уменьшения количества элементов в очередях.
 
* Собственно, в этом смысл уменьшения количества элементов в очередях.
* Детализация требования JIT - когда нужно, а не когда хотим. Метафора - требование есть контейнер, который мы наполняем деталями. Например Эпос-Фича-История. Еще есть minimum marketable feature - квант, который можно доставить.  
+
* Детализация требования JIT когда нужно, а не когда хотим. Метафора требование есть контейнер, который мы наполняем деталями. Например Эпос-Фича-История. Еще есть ''minimum marketable feature'' — квант, который можно доставить.
* business owner - любой стейкхолдер выдвигающий требования, влияющий на roadmap
+
* ''business owner'' — любой стейкхолдер выдвигающий требования, влияющий на ''roadmap''
* Эпос: работа с комюните в ворд. Фича - одновременная работа с документами и т.п., дальше в истории  
+
* Эпос: совместная работа в ворд. Фича одновременная работа с документами и т. п., дальше в истории.
 
* Идея: твиттер-постановки. Из требований по 60 символов :)
 
* Идея: твиттер-постановки. Из требований по 60 символов :)
* INVEST. первая буква - независимость историй. S - small.  
+
* INVEST. первая буква независимость историй. <tt>S</tt> — small.
* Большие пакеты - приводят к еще большим. Большой проект раздувается, к ним легко добавить еще немного.
+
* Большие пакеты приводят к еще большим. Большой проект раздувается, к ним легко добавить еще немного.
* Методика define-build-test по кругу итерации. Кусочек - маленький, но по всем уровням системы, это важно. Плюс - уменьшает очереди, компактизация.
+
* Методика ''define-build-test'' по кругу итерации. Кусочек маленький, но по всем уровням системы, это важно. Плюс уменьшает очереди, компактизация.
* Про синхронизацию - когда несколько команд над одним продуктом - итерации синхронны. И интеграция в конце. В общем-то типовой подход. Точки синхронизации - планирование релиза; внутри спринта - интегрироваться несколько раз с другими командами, а потом - выход. Еще есть инфраструктурные ортогональные команды, например, верхнеуровневая архитектура.
+
* Про синхронизацию когда несколько команд над одним продуктом итерации синхронны. И интеграция в конце. В общем-то типовой подход. Точки синхронизации планирование релиза; внутри спринта интегрироваться несколько раз с другими командами, а потом выход. Еще есть инфраструктурные ортогональные команды, например, верхнеуровневая архитектура.
* Децентрализация. Менеджеры (PO) говорят, что надо делать, а команда - за сколько смогут сделать. Децентрализация и доверие должно быть. иначе леан и agile не работают.
+
* Децентрализация. Менеджеры (PO) говорят, что надо делать, а команда за сколько смогут сделать. Децентрализация и доверие должно быть. иначе леан и agile не работают.
* Общий большой бэклог - не обязательство. Обязательство - то, что вошло в релиз. Хотя на верхнем уровне есть некоторые общий роадмап  
+
* Общий большой бэклог не обязательство. Обязательство то, что вошло в релиз. Хотя на верхнем уровне есть некоторые общий роадмап.
  
 
== Веденин Юрий. Опыт разработки и внедрения системы квалификации аналитиков ==
 
== Веденин Юрий. Опыт разработки и внедрения системы квалификации аналитиков ==
  
Вполне понятный рассказ о формальной системе. Правда 5 уровней при 10 аналитиков, причем высшая не заполнена - как-то этого чересчур, по-моему. А еще - система совсем свежая, 3 месяца. По ней еще не нанимали внешних людей. Так что пионерский доклад в этом смысле. Но - они сделали, договорились с руководством, начальную оценку получили - повод для доклада есть. И он не стесняясь говорит, что система новая, и многое впереди. Мы сами это делали на первом этапе работы с разрядами, и сейчас в сторону большой формализации не копаем, а используем как повод для разговора - а они пока копают именно в формальную часть. Но это может быть уместно в их компании.  
+
Вполне понятный рассказ о формальной системе.
 +
Правда 5 уровней при 10 аналитиков, причем высшая не заполнена как-то этого чересчур, по-моему. А еще система совсем свежая, 3 месяца. По ней еще не нанимали внешних людей. Так что пионерский доклад в этом смысле. Но они сделали, договорились с руководством, начальную оценку получили повод для доклада есть. И он не стесняясь говорит, что система новая, и многое впереди. Мы сами это делали на первом этапе работы с разрядами, и сейчас в сторону большой формализации не копаем, а используем как повод для разговора а они пока копают именно в формальную часть. Но это может быть уместно в их компании.
  
'''Далее - заметки'''.
+
'''Далее заметки'''.
* Градации: Интерны - сист анал - старш сис.анал - бизнес системный аналитик - старший бизнес.
+
* Градации: Интерны → системные аналитики → старш системные аналитики → бизнес-системный аналитик старший бизнес.
* Бизнес-аналитики - уровень, с которого начинают разбираться в бизнесе. системные в бизнесе не разбираются. старшие - несколько областей или проектов.
+
* Бизнес-аналитики уровень, с которого начинают разбираться в бизнесе. Системные в бизнесе не разбираются. Старшие — несколько областей или проектов.
* День карьерного роста - что достиг + направления развития.
+
* День карьерного роста что достиг + направления развития.
* Подготовка к дню - менджер + два эксперта, заполняют матрицу компетенций и определяют возможные направления. Дальше ему это посылали, он готовился к обсуждению и дальше обсуждение с фиксацией результатов.
+
* Подготовка к дню — менеджер + два эксперта, заполняют матрицу компетенций и определяют возможные направления. Дальше ему это посылали, он готовился к обсуждению и дальше обсуждение с фиксацией результатов.
* Оценки - от заказчика, от тестировщиков и прочее, нарекания...
+
* Оценки от заказчика, от тестировщиков и прочее, нарекания…
* Забавный пример - зачем нужна подтвержденная оценка... Вдруг взял и случайно написал хорошую спецификацию - повезло :)
+
* Забавный пример зачем нужна подтвержденная оценка… Вдруг взял и случайно написал хорошую спецификацию повезло :)
* Реально - подтвержденные неоднократные успехи.
+
* Реально подтвержденные неоднократные успехи.
* Системные аналитики, компетенции: SRS, URS; прототипирование интерфейсов; английский по своим уровням (бизнес-общение: reader writer mailer speaker presenter); производственный опыт на проекте в аналит.активностях.
+
* Системные аналитики, компетенции: SRS, URS; прототипирование интерфейсов; английский по своим уровням (бизнес-общение: reader writer mailer speaker presenter); производственный опыт на проекте в аналит.активностях.
* 11 точек роста для уровня системного аналитика. что человек должен делать, чтобы рости. Например: теория требований; самостоятельность разработки требований; точность оценки времени своей работы - они до 30%; качество документирования (без метрик, по нареканиям); ... Что он делает для роста - отдельный вопрос (книги, задачи, еще что-то)
+
* 11 точек роста для уровня системного аналитика. что человек должен делать, чтобы рости. Например: теория требований; самостоятельность разработки требований; точность оценки времени своей работы они до 30 %; качество документирования (без метрик, по нареканиям); Что он делает для роста отдельный вопрос (книги, задачи, еще что-то)
* Они не откатали, может ли бизнес-аналитик быть без системного. В принципе может, но навыки системного аналитика - по любому должны быть.
+
* Они не откатали, может ли бизнес-аналитик быть без системного. В принципе может, но навыки системного аналитика по любому должны быть.
* Система развивается. И они систему образования дальше будут развивать.  
+
* Система развивается. И они систему образования дальше будут развивать.
* Очень хочет общего понимания отрасли - что есть бизнес-аналитик. Потому что в каждой компании - все по-своему.
+
* Очень хочет общего понимания отрасли что есть бизнес-аналитик. Потому что в каждой компании все по-своему.
* Есть версии квалификации IIBA. Читал вторую версию, получил третью. Они становятся лучше, но сложнее, и с его точки зрения - чрезмерно.
+
* Есть версии квалификации IIBA. Читал вторую версию, получил третью. Они становятся лучше, но сложнее, и с его точки зрения чрезмерно.
* Проактивная позиция...
+
* Проактивная позиция…
* К уровням привязаны медианы.  
+
* К уровням привязаны медианы.
 
* Квалификация раз в полгода, хочет квартально ДКР.
 
* Квалификация раз в полгода, хочет квартально ДКР.
* А еще - менторинг. тренинги - все будут делать.
+
* А еще менторинг, тренинги все будут делать.
* Точки роста и грейды - не обязательно закрыть все для повышения квалификации.
+
* Точки роста и грейды не обязательно закрыть все для повышения квалификации.
* Саму систему сделали в связи с ростом компании. отвечать на вопрос можно ли конкретного аналитика ставить на проект, как справедливо платить...
+
* Саму систему сделали в связи с ростом компании, отвечать на вопрос можно ли конкретного аналитика ставить на проект, как справедливо платить…
* Какой-то странный вопрос - а вдруг аналитики вырастут и уйдут, они же будут свои знания представлять и прочее.  
+
* Какой-то странный вопрос а вдруг аналитики вырастут и уйдут, они же будут свои знания представлять и прочее.
* Есть старая версия системы для всех ролей - разработчики, руководители групп. Но стройная - для аналитиков.
+
* Есть старая версия системы для всех ролей разработчики, руководители групп. Но стройная для аналитиков.
  
 
== Банасевич Алексей. Разработка тиражного коммерческого программного продукта. Опыт выживания ==
 
== Банасевич Алексей. Разработка тиражного коммерческого программного продукта. Опыт выживания ==
 
   
 
   
Основная идея доклада - работая по scrum надо быть последовательным и требования тоже получать инкрементально. Собственно, в этом основной смысл. Хотя многие известные ему команды применяя скрам, хотят требования сразу. Может быть, страхуются на проектах с жадными заказчикамИ, торгующимися за каждую копейку, а может не умеют разделять риски. Во всяком случае, не любят работать с неполными требованиями. И теряют основное преимущество agile - быструю реакцию на изменения. Поэтому он и сделал доклад о своем опыте. В целом доклад мне понравился, хотя сам материал для меня был очевидным.
+
Основная идея доклада работая по scrum надо быть последовательным и требования тоже получать инкрементально. Собственно, в этом основной смысл. Хотя многие известные ему команды применяя скрам, хотят требования сразу. Может быть, страхуются на проектах с жадными заказчикамИ, торгующимися за каждую копейку, а может не умеют разделять риски. Во всяком случае, не любят работать с неполными требованиями. И теряют основное преимущество agile быструю реакцию на изменения. Поэтому он и сделал доклад о своем опыте. В целом доклад мне понравился, хотя сам материал для меня был очевидным.
  
'''Далее - заметки'''.
+
'''Далее заметки'''.
* Риск переписывания надо исключать. Для этого желательно описать весь спектр - широко. Но - поверхностно. Не надо погружаться глубоко. Более того, глубокое погружение сначала - вредит. И приоритеты хотя бы изначальные.
+
* Риск переписывания надо исключать. Для этого желательно описать весь спектр широко. Но поверхностно. Не надо погружаться глубоко. Более того, глубокое погружение сначала вредит. И приоритеты хотя бы изначальные.
* Почему глубоко вредно? Потому что команда (или потом) можно придумать лучше. Пример когда по эскизу исполнитель сделал olap-решение. А заказчик его не знал, и если бы он конкретизировал - получил бы конечные решения.
+
* Почему глубоко вредно? Потому что команда (или потом) можно придумать лучше. Пример когда по эскизу исполнитель сделал OLAP-решение. А заказчик его не знал, и если бы он конкретизировал получил бы конечные решения.
* Подробно написанное требование устаревает в момент написания. Да и потом можно не делать, а реализовывать, только на это надо идти сознательно. Например, риск что команда вдруг разбежится.  
+
* Подробно написанное требование устаревает в момент написания. Да и потом можно не делать, а реализовывать, только на это надо идти сознательно. Например, риск, что команда вдруг разбежится.
 
* Фактор успеха
 
* Фактор успеха
** wear customer hatособенно в продуктовой модели
+
** ''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 - scope of role and competence
+
** demand scope of role and competence
** supply - people, prof, proof, qual
+
** supply people, prof, proof, qual
* Шутка. Модель областей (процессы, люди, ...) где опущено ядро - inform and technology
+
* Шутка. Модель областей (процессы, люди, ) где опущено ядро 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 о чем он и рассказывал".
+
Рассказ весьма не по делу. С детства и со школы, и об этом долго… Это не для начинающих бизнес-аналитиков, а для школьников, по-моему… Я ушел достаточно быстро, а резюме тех, кто слушал до конца, потому что стеснялся вылезать из полного зала на начало доклада пришли очень многие: «Докладчик родился в южной африке и делился трудным детством без компов. Сейчас приехал в Голландию и работает бизнес-аналитиком, и ему хорошо 0 о чем он и рассказывал».
  
== Хлебников Сергей. Представление знаний о предметной области на основе эффективных юзкейсов ==  
+
== Хлебников Сергей. Представление знаний о предметной области на основе эффективных юзкейсов ==
  
Докладчик рассказывал собственный опыт, с помощью которого он систематизировал знания о сложной предметной области при работе над проектом Сбербанка. Знания представлял в виде описания usecase в достаточно сложной формлаьной форме, в результате - овладел предметной областью лучше многих специалистов заказчика. Но в этом для меня ничего особо удивительного - хороший аналитик так или иначе овладеет предметной областью, с которой он работает. А вот про то, что знаниями предметной области овладел кто-то другой, базируясь на его описании - в докладе не было. Равно как и о том, что его сложной формальной системой пользовался кто-то из заказчиков. Так что есть сильное ощущение, что все это было системой одного человека-автора.
+
Докладчик рассказывал собственный опыт, с помощью которого он систематизировал знания о сложной предметной области при работе над проектом Сбербанка. Знания представлял в виде описания usecase в достаточно сложной формлаьной форме, в результате овладел предметной областью лучше многих специалистов заказчика. Но в этом для меня ничего особо удивительного хороший аналитик так или иначе овладеет предметной областью, с которой он работает. А вот про то, что знаниями предметной области овладел кто-то другой, базируясь на его описании в докладе не было. Равно как и о том, что его сложной формальной системой пользовался кто-то из заказчиков. Так что есть сильное ощущение, что все это было системой одного человека-автора.
  
Так что у меня лично большие сомнения в эффективности написания и, главное, сопровождения таких тяжелых usecase. Потому что дорого. Практически я бы видел только при реализации силами неквалифицированных кодеров по низкоуровневым постановкам - то есть не на современных языках, которые не допускают неквалифицированных кодеров ввиду сложности заложенных концепций.
+
Так что у меня лично большие сомнения в эффективности написания и, главное, сопровождения таких тяжелых usecase. Потому что дорого. Практически я допускаю такое только при реализации силами неквалифицированных кодеров по низкоуровневым постановкам то есть не на современных языках, которые не допускают неквалифицированных кодеров ввиду сложности заложенных концепций.
  
Со слайдами у него очень плохо, слайдоменты. И не слишком хорошо по логике. И с мировой терминологией - очень творчески перерабатывает термины, работает почти по своими.  
+
Со слайдами у него очень плохо, слайдоменты. И не слишком хорошо по логике. И с мировой терминологией очень творчески перерабатывает термины, работает почти по своими.
  
Зато в целом в докладе был достаточно хороший обзор истории развития практики usecase, это большой плюс. Идея тут следующая. Как известно, usecase придумал Якобсон. Но потом Коберн внес много принципиально нового. А Якобсон его не оценил, сказав лишь, что "подход Коберна не противоречит его подходу". Классическая книга по usecase, признанная Якобсоном очень хорошей - Битнер и Спенсер (2002), также игнорирует новое от Коберна. А книга Коберна (2000) - очень тяжелая, поэтому ее не слишком читают. Вот так.
+
Зато в целом в докладе был достаточно хороший обзор истории развития практики ''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 с системой - два актора.
+
* Коберн добавил стейкхолдера == носителя знаний. Внутри кейса ничего, кроме знаний стейкхолдера. ввел primary actor, actor с системой два актора.
* Выделение сценариев - это Коберн. формальное.
+
* Выделение сценариев это Коберн. формальное.
* Проекция интересов стейкхолдеров на юзкейс. И это - важно.
+
* Проекция интересов стейкхолдеров на юзкейс. И это важно.
Тут я выходил на другой доклад...
+
Тут я выходил на другой доклад…
* Для итеративной разработки задача - выделить мелкие итерации. При нарезке юзкейсов на сценарии и разделении на минитранзакции - можно делить.
+
* Для итеративной разработки задача выделить мелкие итерации. При нарезке юзкейсов на сценарии и разделении на минитранзакции можно делить.
* Ларман - понятие системного события и системной итерации. Которые суть запросы. Он дальше делает на фичи.
+
* Ларман понятие системного события и системной итерации. Которые суть запросы. Он дальше делает на фичи.
* Фичи из Rational sweet в MS project с диаграммой ганта, а затем - планирование и управление.
+
* Фичи из Rational sweet в MS project с диаграммой ганта, а затем планирование и управление.
* Вообще говоря юзкейсы получаются детальные, практически алгоритмы! Сложный язык. И с этим заказчик будет работать??  
+
* Вообще говоря юзкейсы получаются детальные, практически алгоритмы! Сложный язык. И с этим заказчик будет работать??
* Я: Идеи примерно понятны, но это конструкция, когда кодер - просто исполнитель.
+
* Я: Идеи примерно понятны, но это конструкция, когда кодер просто исполнитель.
* Ближе к концу - пошли явные антипатерны. Схема справочника, которую понимал только он. Схема написания юзкейсов, где качество написания критично, и умеет писать (только он).  
+
* Ближе к концу пошли явные антипатерны. Схема справочника, которую понимал только он. Схема написания юзкейсов, где качество написания критично, и умеет писать (только он).
* Он представил их знания и начал представлять систему лучше них самих. До прихода они представляли абы как. а он - свел воедино. Он может добраться. А они?
+
* Он представил их знания и начал представлять систему лучше них самих. До прихода они представляли абы как. а он свел воедино. Он может добраться. А они?
* Проверки - несколько сотен включены в юзкейс...
+
* Проверки несколько сотен включены в юзкейс…
* Дерево трассировки...
+
* Дерево трассировки…
* Поддерживать юзкейсы это трудоемко. Пользоваться месяцы и годы - они же сгниют...
+
* Поддерживать юзкейсы это трудоемко. Пользоваться месяцы и годы они же сгниют…
 
* Интересно, а почему он не использовал html для ссылок, а работал с текстами?
 
* Интересно, а почему он не использовал html для ссылок, а работал с текстами?
  
== Котельников Александр. Особенности разработки требований для систем бухгалтерского и финансового учета
+
== Котельников Александр. Особенности разработки требований для систем бухгалтерского и финансового учета ==
  
В целом грамотный доклад, докладчик представляет вопрос. Народ это в целом интересует. Хотя это больше ликбез с нашей точки зрения, но и на этом уровне слушателям интересно. Людей интересует - насколько легко взаимодействовать со Сбером и госзаказчиками и т.п.
+
В целом грамотный доклад, докладчик представляет вопрос. Народ это в целом интересует. Хотя это больше ликбез с нашей точки зрения, но и на этом уровне слушателям интересно. Людей интересует насколько легко взаимодействовать со Сбером и госзаказчиками и т. п.
  
'''Далее - заметки''' - не с начала.  
+
'''Далее заметки''' не с начала.
* Некоторая конкретика внутренних механизмов 1С, устройство учета - регистры остатков, регистры вычислений и прочее.
+
* Некоторая конкретика внутренних механизмов 1С, устройство учета регистры остатков, регистры вычислений и прочее.
* Проект - в центре инфраструктуре, важные пользователи - психологические навыки, документоориентированный интерфейс.
+
* Проект в центре инфраструктуре, важные пользователи психологические навыки, документоориентированный интерфейс.
* Особенности требований - законодательство + внутренние регламенты. И это самая неприятная ловушка, потому как в контракте оно всегда есть и оно будет.  
+
* Особенности требований законодательство + внутренние регламенты. И это самая неприятная ловушка, потому как в контракте оно всегда есть и оно будет.
* Бухгалтеры ожидают что аналитики владеют предметом. Вопросы были из серии нельзя ли подложиться от этого, снять риски, Ответ - нельзя.
+
* Бухгалтеры ожидают что аналитики владеют предметом. Вопросы были из серии нельзя ли подложиться от этого, снять риски, ответ — нельзя.
 
* Бух.учет стандартный, поэтому. как правило. это внедрение и настройка, а не разработка с нуля.
 
* Бух.учет стандартный, поэтому. как правило. это внедрение и настройка, а не разработка с нуля.
* Управленческий учет - под себя, единых стандартов не существует - полноценная разработка системы.
+
* Управленческий учет под себя, единых стандартов не существует полноценная разработка системы.
  
 
== Зезин Василий. Онтологический взгляд на инженерию требований ==
 
== Зезин Василий. Онтологический взгляд на инженерию требований ==
  
Докладчик - из INCOSE. В целом это рассказ про системную сложность систем как таковую, но без самого понятия сложности, а описывая конкретные следствиях и проявлениях этой сложности. Доклад хороший, но специалиста по системной инженерии я ожидал большего. А еще оставалось впечатление умозрительности доклада и апелляции к достаточно старым материалам.
+
Докладчик из INCOSE. В целом это рассказ про системную сложность систем как таковую, но без самого понятия сложности, а описывая конкретные следствиях и проявлениях этой сложности. Доклад хороший, но специалиста по системной инженерии я ожидал большего. А еще оставалось впечатление умозрительности доклада и апелляции к достаточно старым материалам.
  
'''Далее - заметки'''.  
+
'''Далее заметки'''.
* Способов классификации - много, вопрос полезности.  
+
* Способов классификации много, вопрос полезности.
* Около 30% разработки связано с требованиями, и эта цифра не меняется.
+
* Около 30 % разработки связано с требованиями, и эта цифра не меняется.
* Чем дальше проект зашел, тем сложнее вносить изменения...
+
* Чем дальше проект зашел, тем сложнее вносить изменения…
* Как-то оно водопадно-умозрительно... Это обзор по достаточно старым работам...
+
* Как-то оно водопадно-умозрительно… Это обзор по достаточно старым работам…
* Много точек зрения. Про сложность и снижение - не говорил.
+
* Много точек зрения. Про сложность и снижение не говорил.
* Не надо забывать, что за моделями, диаграммами - система.
+
* Не надо забывать, что за моделями, диаграммами система.
 
* Модели жизненного цикла. Их много. Не надо забывать, что за ними.
 
* Модели жизненного цикла. Их много. Не надо забывать, что за ними.
 
* Комп был в каком-то хитром режиме. не зеркало, и не видно что на экране-то слайд не меняется :)
 
* Комп был в каком-то хитром режиме. не зеркало, и не видно что на экране-то слайд не меняется :)
 
* URML. Чтобы формально, не тексты.
 
* URML. Чтобы формально, не тексты.
* Договориться с клиентом о практиках, используемых в работе...
+
* Договориться с клиентом о практиках, используемых в работе…

Версия 21:52, 4 апреля 2011


Содержание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Turner Paul The Evolving role of the Business Analyst

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Erasmus Michiel The Real World Business Analyst

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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