Просмотр исходного текста страницы Техники аналитика - CATWOE, H-METHOD, MOSCOW, SQUARE (Екатерина Макаренко, AnalystDays-2012)

== Аннотация ==
;Докладчик: {{Speaker|Екатерина Макаренко}} 
<blockquote>
В начале проекта бизнес-аналитику  нужно ответить на множество вопросов о том,  с чего начать общение с заказчиком, как провести интервью, как выяснить требования заказчика.

Целью доклада является рассмотреть, с чего начать работу с заказчиком, как какие техники можно использовать, какие вопросы задать на интервью.  Среди техник остановимся на контрольном списке CATWOE, H-методе, методе приоритезации MoSCoW и методологии по работе с требованиями к безопасности системы SQUARE.

Тезисы:
* Долгое время особенностью бизнес-анализа в аутсорсинге являлось то, что его либо не было, либо бизнес-аналитик подключался в проекте после того, как основная работа по бизнес-анализу была выполнена заказчиком.
* В последнее время доверие заказчиков к подрядчикам растет, и как следствие растет и доверие к бизнес-аналитикам со стороны подрядчиков. Все чаще заказчики предпочитают заказывать полный цикл бизнес-анализа, многие аутсорсинговые компании начинают предоставлять бизнес-анализ как сервис.
* В связи аналитики все чаще сталкиваются с проблемой, как начать проект с нуля. Какие вопросы задать заказчику  при первой встрече, как убедится в том, что все темы были рассмотрены, как работать с представителями бизнеса, которые не мыслят категориями спецификаций и компонентов.

При первой встрече следует концентрироваться на бизнесе, выясняя миссию проекта, бизнес потребности и цели, роль проекта в их достижении.  На этом этапе создается видение проекта.
Существуют ключевые вопросы, на которые отвечает видение проекта. Кроме того можно использовать контрольный список CATWOE. Он будет также полезен при анализе бизнес-процессов, особенно при согласовании ключевых требований от разных стейкхолдеров.
Выявляя требования к бизнес-процессам можно использовать Н-метод, который с одной стороны позволяет структурировать интервью, а с другой помогает целостно описать бизнес-процесс.
После первых аналитических сессий формируется множество требований в формате User Stories или Use Cases (в зависимости от того, работает ли аналитик по SCRUM или RUP). Эти требования необходимо отсортировать по приоритету и выбрать, в какие итерации они будут включены.
Для этого можно использовать  технику MoSCoW.
Помимо бизнес-правил и функциональных требований, необходимо выяснить нефункциональные требования. Отдельной группой нефункциональных требований выступают требования к безопасности, которые зачастую не выявляются на ранних стадиях проекта. Чтобы этого избежать, можно включить методологию SQUARE в выбранный процесс бизнес-анализа, использование которой обеспечит своевременное включение требований к безопасности и связанных с ними задач в проект.

</blockquote>


== Видео ==

{{vimeoembed|43210197|800|340}}
{{youtubelink|XGfnknt56k8}}{{letscomment}}

== Слайды ==
[[Файл:Техники аналитика - CATWOE, H-METHOD, MOSCOW, SQUARE (Екатерина Макаренко, AnalystDays-2012).pdf|left|page=-|256px]]

{{----}}
== Примечания и отзывы ==
<blockquote>
Начало доклада я пропустил, а зря. Екатерина рассказывала о большом  количестве конкретных методов аналитика, которые, собственно, перечислены  в названии доклада. Например, MOSCOW, который по ее опыту позволил  обеспечить реальную приоретизацию требований в контексте релизов. А  SQUARE представляет собой фреймворк для требований по безопасности,  который позволяет перевести эти требования в разряд функциональных. Эта  часть рассказа была на примере конкретного проекта, который изначально  был сделан вообще без требований по безопасности, а потом оказалось что  они есть и жесткие, проект — банковский. Что ценно — это не методика, а  фреймворк, имеющий шаблоны и поддерживающие средства, что позволяет  пользоваться даже новичками, набираясь опыта. А еще в методе есть  довольно много практик, которые применимы не только к требованиям по  безопасности, а могут использоваться для других видов требований. А еще —  был рассказ про способ трейсинга требований и их изменений по функциям,  причем в условиях. когда за время развития проекта было использовано  несколько вики-систем и систем ведения дел, и там были конкретные  приемчики, сильно облегчающие работу. Например, при изменениях не только  ссылаться в новом деле на предыдущее, но и цитировать формулировки —  чтобы поиск это подхватывал.

[http://blogs.uml2.ru/post/AnalystDays-1 ©]</blockquote>
<references/>



[[Category:Бизнес-анализ]]
[[Category:AnalystDays-2012]]
{{stats|disqus_comments=0|refresh_time=2021-08-31T18:31:23.142781|vimeo_comments=0|vimeo_plays=442|youtube_comments=0|youtube_plays=136}}