Только ленивый еще не писал о различиях двух наиболее популярных подходов к разработке программного обеспечения. А мы не ленивы, поэтому ниже вы найдете взгляд на работу аналитика в этих двух подходах.
Сбор требований
Самый первый этап, с которого начинается работа аналитика на проекте либо в команде разработки продукта, - это сбор требований. И уже здесь мы наблюдаем ряд отличий в работе аналитика.
Методологию Waterfall команды чаще всего выбирают при разработке проектов с четко заданными сроками и ясным пониманием желаемого результата. Обычно это проекты по разработке ПО для внешнего Заказчика.
В этом случае самые верхнеуровневые требования к разрабатываемой Системе вы можете найти в обязательном приложении к Договору с Заказчиком - Техническом задании. Этот документ формализован по структуре, и должен содержать:
- краткое изложение требований к реализуемой программе и документации на нее;
- этапы работ;
- порядок приемки результата.
Все задачи при работе по методологии Waterfall должны проходить предварительную аналитику, поэтому сразу после получения ТЗ от Заказчика необходимо начать его детальную проработку.
Информация из ТЗ задаст первичное направление, сроки и этапы работы, а основные требования вам предоставят специалисты Заказчика, которые будут работать с продуктом.
Зачастую отдельный этап Договора, предусматривающий проведение аналитических работ, не закладывается, либо закладывается, но ограниченный по срокам. Поэтому прорабатывать требования вам нужно будет параллельно с разработкой. В условиях ограниченного времени нужно очень быстро выдавать максимально корректную информацию, оформляя ее в детальные постановки.
Содержащийся в составе ТЗ список представляемой в ходе сдачи работ документации позволит вам оценить внутренние ресурсы и соответствующим образом скорректировать структуру создаваемых требований. Если в вашей команде присутствует технический писатель, вы сможете получить от него запрос на предоставление необходимой для оформления документации информации. Если технического писателя в команде нет, обязанность по подготовке технической документации менеджер проекта может возложить на вас. В этом случае, например, вы сразу начнете добавлять в постановки должным образом оформленные пользовательские сценарии. Из этих сценариев в дальнейшем вы сможете собрать приложение к Программе и методике испытаний Системы.
Переговоры с представителями Заказчика помогут вам понять его потребности, однако для успешной реализации Системы вам также потребуются и другие знания - положений нормативной документации по рассматриваемому вопросу, технологического окружения Системы, автоматизируемой предметной области т.д.
Методологии, построенные на принципах Agile, применяются в проектах с неопределенным сроком разработки и конечным результатом, поэтому здесь ТЗ на первых этапах разработки проекта вы не получите. Да, собственно, и никогда не получите, если только вам самому не нужно будет оформить все, что было разработано по продукту, в целостный документ.
Здесь Владелец Продукта в самом начале работ продемонстрирует команде дорожную карту развития продукта. На этой карте будут крупными мазками определены ожидаемые функциональные блоки продукта и сроки, в которые эти блоки должны быть разработаны. Далее сразу же начинается процесс разработки продукта, и в рамках спринта разработки вам необходимо будет прорабатывать требования для него, либо (если повезет) - для следующего спринта. Далее цикл повторится. Собирать пожелания вы будете от Владельца Продукта, продумывать требования по реализации - на основании знания предметной области, требований нормативной документации, обратной связи пользователей, данных мировых тенденций, аналогичных существующих на рынке решений. Достаточно распространено совместное обсуждение планируемых к реализации функций (или, как здесь принято говорить, - фич) командой в рамках командных мероприятий.
Подготовка задач
Сбор информации вы осуществляете не потому, что безумно это любите (ну или не только потому), а, в основном, для того, чтобы сформировать качественную, продуманную задачу для разработчика.
Waterfall предполагает, что для успешной разработки функциональности вам необходимо создать как можно более подробную постановку, которую разработчик никоим образом не сможет трактовать двояко. Здесь важно, чтобы разработка добуквенно соответствовала постановке, ведь именно такой вариант реализации вы согласовали с Заказчиком. Поэтому для Waterfall`а характерна детализированная постановка, в описании которой могут быть представлены, в частности, следующие элементы:
- роль пользователя;
- место расположения функциональности в пользовательском интерфейсе;
- описание автоматизируемого бизнес-процесса;
- основной и альтернативные пользовательские сценарии;
- тексты информационных сообщений;
- техническая информация;
- макеты и прототипы;
- ссылки на связанные постановки и материалы первоисточников.
Сформулированное требование рекомендуем проверить на соответствие критериям хорошего требования.
Для Agile-методологий характерно представление команде большей свободы в реализации требований, а также большее включение всей команды в понимание цели реализации данной функциональности. Именно поэтому задачи здесь чаще всего формируются в виде пользовательских историй (User Story), построенных таким образом, чтобы их можно было обсудить с командой.
Пример классической формулировки подобной US: “Как пользователь мобильного банка, я хочу иметь возможность переводить деньги на другую банковскую карту для того, чтобы помогать своим родственникам”.
В “волшебной” формуле US присутствуют:
- указание роли пользователя, что позволяет отсечь ненужные роли от задаваемой функциональности;
- краткое описание самой сути функциональности;
- эмоциональный фрагмент, который позволяет члену команды поставить себя на место пользователя и почувствовать ценность фичи.
Таким образом, помимо чисто продуктовой ценности, US несет в себе ценность психологическую - она мотивирует команду на создание более качественного продукта - “как для себя”.
Эту US уже можно брать из бэклога и обсуждать с командой, а потом - описывать полученную и иную собранную информацию в составе постановки.
Помимо собственно строчки US рекомендуем включить в постановку:
- описание автоматизируемого бизнес-процесса;
- основной и альтернативные пользовательские сценарии;
- тексты информационных сообщений;
- техническую информацию;
- макеты и прототипы;
- приемочные критерии, в идеале - с использованием элементов языка GHERKIN:
- Дано (Given);
- Триггер (When/Когда);
- Результат (Then/Тогда).
- ссылки на связанные постановки и материалы первоисточников.
После оформления US необходимо проверить на соответствие критериям INVEST.
Консультирование команды
Различия процессов работы с командой в разных методологиях разработки нами были описаны ранее в этой статье.
Повторяться мы не будем, только акцентируем внимание на следующих основных моментах:
- при работе по Waterfall`у команда будет задавать вам меньше вопросов, поскольку постановка достаточно подробна; однако если эти вопросы будут задаваться, они будут идти к вам напрямую от разработчика, минуя всю остальную команду;
- при работе в Agile постановка менее подробна за счет ограниченного срока проработки; однако здесь вопросов помогает избежать предварительная командная проработка бэклога, а все вопросы вы можете обсуждать в рамках групповых мероприятий, чтобы все члены команды владели одинаковой информацией.
Итого
Выше была подробно описана специфика работы аналитика на этапах разработки, наиболее различающихся для разных методологий. Помимо этого, работа аналитиков может различаться и другими элементами.
Для Waterfall`а фигура аналитика является одной из ключевых, на него ложится ответственность за реализацию нужной Заказчику Системы. Помимо выявления и формализации требований, от аналитика здесь могут потребоваться:
- участие в переговорах с Заказчиком;
- описание нефункциональных требований;
- подготовка технической документации;
- построение схем бизнес-процессов в нотациях BPMN, UML и т.д.;
- участие в приемо-сдаточных испытаниях;
- проведение презентаций для Заказчика и т.д.
В Agile-команде главной задачей аналитика является трансляция информации о предметной области команде, на которой и лежит ответственность за реализацию продукта. Для роли аналитика в Agile-проекте, помимо стандартных задач, будут характерны:
- посредничество между бизнес-заказчиком и командой;
- участие в планировании разработки и приоритизации бэклога;
- участие в командных мероприятиях;
- проведение презентаций для команд;
- работа в качестве помощника Владельца продукта;
- построение Mind Map, Impact Map, Customer Journey Map, User Story Map, Value Proposition Canvas;
- проведение конкурентного анализа;
- продуктовая аналитика и т.д.
Однако глобальная миссия аналитика в команде разработки не изменяется вне зависимости от того, по какой методологии работает команда, и состоит она в том, чтобы обеспечить полное соответствие разрабатываемого продукта потребностям пользователя.
Текст: Татьяна Величкина
Редакторы: Ирина Ткаченко, Сергей Котович
Фото: найдены на просторах Сети
