7023
правки
Изменения
м
== Артём Митропольский. Digital Design. Уязвимости мышления ==
Первое место. Артем делал доклад рассказывал не тему, которая, казалось бы, не относится к аналитике непосредственно, но реально очень важна для построения коммуникаций. Речь идет о тех уязвимостях, которые имеет наше мышление и которые срабатывают, если на них не обращать специального внимания. О том, что формулировка вопроса влияет на ответ и читерский вопрос дает заданное искажение. Про эффект привязки, заключающийся в том, что любая посторонняя информация, которая присутствовала в момент принятия решения — на него влияет. О том, что по умолчанию люди склонны считать свои знания репрезентативными. Про то, как включение деталек неявно повышает оценку обоснованности и надежности текста. И про фундаментальную ошибку атрибуции, которая кратко формулируется как «все уроды, а я д’Артаньян».
И многое другое, здесь перечислено далеко не все, что было в докладе, а там был рассказ лишь про часть, остальное представлено ссылками. Потому что информация, на самом деле, доступна, но вот многие ли знакомились ли с ней для того, чтобы реально применять в работе и жизни, а не просто как с любопытными исследованиями? И, я надеюсь, исходя из высокой оценки доклада, что таких людей станет больше.
Второе Первое место. Любопытный доклад про сравнение аналогичных по функционалу проектов, отличающихся подходом Заказчиков: в первом был «раздолбай», а второй — «формалист», любил вникать в детали и мелочи. И это различие очень сильно сказалось на ходе обоих проектов, оно существенно влияет на риски, и для успешного продвижения необходимо применять существенно разные приемы.
Нет описания правки
<enableheadshift><noinclude>{{Conf-Ref}}</noinclude>
В субботу 24.05 был на конференции [http://analystdays.ru/ru/talk/21107 AnalystDays-2014] в Москве. Уровень конференции был выше предыдущей, и она собрала больше участников, неожиданно даже для организаторов — около 500 человек. А для аналитиков это много, потому что их не так много в современном ИТ. Web-разработка и разработка небольших проектов обходится без них, функции проектирования выполняют квалифицированные разработчики или дизайнеры интерфейсов. И в некоторых докладах приводили примеры, что спрашивая на форуме об организации процесса «кто должен проектировать интерфейсы» — аналитиков даже не упоминают — про такую специализацию вопрошающий не знает :)
= Мой доклад =
<blockquote>[https://twitter.com/Attsik/status/470156835371356160 Из твиттера] Максим Цепков на #analystdays рассказывает о Domain Driven Development как Николай Дроздов :) Не очень понятно, но слушать приятно :))) - Alexander Attsik
</blockquote>
Начну я со своего доклада, не потому что он лучший, а потому что обзор — мой. И тут будет не оценка, а рефлексивная аннотация. Я рассказывал про метод Domain-Driven Design — о том, как модель на едином языке заменяет традиционные требования, с примерами построения и модели и единого языка для проекта и фреймом модели для корпоративных приложений, разработанном у нас в компании.
В этом разделе — о трех докладах, которые участниками были признаны лучшими. Авторы получили ценные призы, за первое место был робот-пылесос.
== Юлия Ерина. i-Sys. Клинический случай в коммуникациях с заказчиком ==
Юлия сказала, что это — достаточно типичные случаи и большинство заказчиков относится к одной из этих категорий, поэтому здесь изложена достаточно общий подход. Но при этом изложен на конкретных примерах, что делает его гораздо более выпуклым.
Интересно отметить, что в целом проект с заказчиком-раздолбаем был гораздо более успешным и по соблюдению сроков и бюджета, и по темпам дальнейшего развития. Так что мелочный интерес заказчика и стремление к тотальному контролю играет против него самого.
== Артём Митропольский. Digital Design. Уязвимости мышления ==
Второе место. Артем делал доклад рассказывал не тему, которая, казалось бы, не относится к аналитике непосредственно, но реально очень важна для построения коммуникаций. Речь идет о тех уязвимостях, которые имеет наше мышление и которые срабатывают, если на них не обращать специального внимания. О том, что формулировка вопроса влияет на ответ и читерский вопрос дает заданное искажение. Про эффект привязки, заключающийся в том, что любая посторонняя информация, которая присутствовала в момент принятия решения — на него влияет. О том, что по умолчанию люди склонны считать свои знания репрезентативными. Про то, как включение деталек неявно повышает оценку обоснованности и надежности текста. И про фундаментальную ошибку атрибуции, которая кратко формулируется как «все уроды, а я д’Артаньян».
И многое другое, здесь перечислено далеко не все, что было в докладе, а там был рассказ лишь про часть, остальное представлено ссылками. Потому что информация, на самом деле, доступна, но вот многие ли знакомились ли с ней для того, чтобы реально применять в работе и жизни, а не просто как с любопытными исследованиями? И, я надеюсь, исходя из высокой оценки доклада, что таких людей станет больше.
== Татьяна Васильева. CUSTIS. Analyst’s Guide to GUI: Проектирование интерфейсов как элемент системного анализа ==
Инструментом Управления требованиями у них является TFS. Не потому, что он лучший, а потому, что он принят в компании как общая система ведения дел и поддержки разработки — ведения кодовой базы, поддержки интеграции. Поэтому использование его для управления требованиями — логично. Но при этом сами требования, содержательно — ведутся в другом инструменте, Enterprise Architect. Это было принять еще до внедрения TFS, но отказываться они от EA не собираются — Ира перечисляла, что именно в TFS их не устраивает по ведению требований. Основные претензии — к версионированию и нормальной выгрузке в word-документы. Если бы для WorkItem была такая же поддержка версий, как для кода — проблем бы не было, выгрузку, думаю, они бы допилили. Но этого нет, и содержание требование остается в EA.
И у них наработались шаблоны, применяемые на многих проектах. Если кратко, то устроено оно так. Все начинается от бизнес-требований, которые фиксируются в TFS и представляют собой некоторое требование уровня бизнеса, некоторая фича. Которая попадает к системным аналитикам в EA и они ее декомпозируют на функциональные системные требования. Функциональные Системные требования попадают назад в TFS как подчиненные, для этого налажена синхронизация. А еще по ним из EA можно выгрузить содержательный документ.
Производится маппинг требуемых изменений на компоненты, и далее. , независимо от декомпозиции на функциональные системные требования, бизнес-требование делится на change request к компонентам. При этом связь системных требований и change request тоже присутствует. По ним change request в командах, отвечающих за компоненты, с учетом описания функциональных системных требований, делается оценка. При этом могут порождаться подчиненные change request к библиотечным компонентам и инфраструктуре. С запросами к инфраструктуре — отдельная ветка, потому что там около 150 сервисов, и команды не очень представляют внутреннее устройство. Поэтому была сделана «служба единого окна», маршрутизирующая change request к инфраструктуре.
Отдельная ветка контроля — учет в релизах требований, исходящие из позиционирования продукта Касперского, такие как «топ-3 по детектированию вирусов». Или требований от юристов. Для поддержки таких требований все продукты должны обладать определенными фичами, заключающимися в исполнении бизнес-требований, и их реализация должна быть вставлена в релизы.
После получения совокупности оценок и с их учетом происходит планирование релиза. А потом, по этой же структуре — контролируется ход работ. При этом, естественно, работы декомпозируются на отдельные задачи, которые выполняются. И добавляются тест кейсы. Получается трассировка полного цикла. Что касается изменения требований в ходе работ, что структура верхнего уровня, сформированная при оценки, меняется редко — потому что она верхнеуровневая. А вот содержание функциональных системных требований изменяется, EA это поддерживает, и влечет изменение декомпозиции на задачи.
Вокруг TFS накручены
* роботы: проходят по всем требованиям и пушат «берете-не берете». Пишут PM’ы
После доклада был интересный вопрос про унификацию требований. Ответ: для целей управления требованиями это не важно, достаточно. , чтобы скоуп проекта был суммой соответствующих item’ов независимо от формы, и совпадал смысл ключевых статусов прохождения.
== Антон Семенченко. ISSoft / CoherentSolutions. BDD or DSL как способ построения коммуникации на проекте — опыт комплексного внедрения ==
Я слушал кусочек, и в нем для меня лично ничего нового не прозвучало, поэтому я ушел послушать Семенченко. Но это для меня. И, возможно, я ошибался, и в неуслышанной части интересное было.
=Там где я не был - [[AnalystDays-2014 - отчет Тани Васильевой|отчет Тани Васильевой]]=
{{:AnalystDays-2014 - отчет Тани Васильевой}}
{{wl-publish: 2014-05-26 02:00:59 +0400 | MaksTsepkov }}