Что такое Agile и какая роль бизнес-аналитика в Agile?
Что такое agile (аджайл/эджайл)? Какие существуют agile фреймворки? Какая роль бизнес-аналитика в agile? Что такое юзер стори?
Об этом и не только, пойдет речь в этой статье.
Agile – это методология управления проектами, которая позволяет быстро и гибко реагировать на изменения в требованиях и условиях работы. Agile и означает - гибкий.
В аджайл существует несколько фреймворков, которые помогают применить agile наиболее удобно, принимая во внимание потребности проекта/команды. Каждый из них определяет свои практики и держит в фокусе разные ценности. Но у них есть общие черты, принципы гибких методологий разработки, которые опубликованы на сайте agile манифеста.
Вообще, "официальный" эджайл возник в 2001 году, когда 17 специалистов-практиков из ИТ среды собрались на горнолыжном курорте в штате Юта. Кроме катания на лыжах, они собрались обсуждать положение дел в разработке программного обеспечения, и решать проблемы принятых в то время подходов.
Несмотря на то, что мнения о том, как правильно подходить к разработке программного обеспечения, сильно разнились, все согласилась одном: существовала потребность в альтернативе тяжеловесному и сложному процессу разработки ПО с большим количеством документации, сложном планировании, тестировании только в конце и пр.
Группа назвала себя "The Agile Alliance". После их встречи в штате Юта зимой того года появился "Agile Манифест" - краткий документ, построенный на 4 ценностях и 12 принципах гибкой разработки программного обеспечения.
Но, в отличие от "официальной" даты создания аджайл манифеста и принципов agile, сам по себе agile родился не тогда. До этого его создатели и многие другие специалисты по разработке программного обеспечения уже давно применяли различные ценности и принципы agile по частям. Но "Agile Манифест" сделал конкретными идеи, которые пронизывали мир разработки программного обеспечения в течение последнего десятилетия.
4 ценности agile с сайта аджайл манифеста -
- Люди и взаимодействие важнее процессов и инструментов.
- Работающий продукт важнее исчерпывающей документации.
- Сотрудничество с заказчиком важнее согласования условий контракта.
- Готовность к изменениям важнее следования первоначальному плану.
То есть, "не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева." (http://agilemanifesto.org/iso/ru/manifesto.html)
Также, в аджайл манифесте прописаны 12 принципов agile, вот некоторые из них:
Но, это не про анархию, не про то, что можно теперь ничего не документировать, не планировать и пр. Как сказал Бенджамин Франклин, «Если вы не смогли составить план, вы планируете потерпеть неудачу» (“If You Fail to Plan, You Are Planning to Fail”). Agile про гибкость, способность постоянно улучшаться и адаптироваться к изменениям вреды, даже не смотря на то, что изначально что-то планировалось по-другому.
Наиболее популярные фреймворки в agile:
- Scrum - это, наверное, самый популярный фреймворк в Agile, который используется для управления разработкой программного обеспечения, и также применяется и в других проектах, например, разработке дизайнов и пр. Он помогает командам удобно и гибко планировать работу, принимая во внимание определенные ценности, принципы и практики. Скрам описывает основные роли (например, скрам мастер, продакт оунер, команда разработки), церемонии и артефакты, которые помогают команде достигать целей проекта быстрее и эффективнее.
- Kanban - это фреймворк, который помогает команде управлять потоком работы и повышать производительность. В Kanban используется доска задач, на которой отображается весь поток работы команды (по сути, это доска с задачами, разделенная по статусам). Одновременно в работе не может быть задач больше, чем было оговорено. Канбан помогает управлять рабочим процессом, снижать время нахождения ошибок и улучшать качество продукта.
- Extreme Programming (XP) - это фреймворк, который акцентирует внимание на разработке высококачественного кода, улучшении коммуникации внутри команды и снижении времени на разработку. XP включает в себя такие практики, как парное программирование, тестирование на каждом этапе разработки и непрерывную интеграцию.
Используются и сочетания фреймворков, если это более уместно на проекте - например, Scrumban, а также встречала использование парного программирования в скраме.
Бизнес-аналитик в Agile
Бизнес-аналитик в Agile играет важную роль, так как помогает определить потребности заказчика и выстроить правильную стратегию разработки продукта, собственно, как и в Waterfall (негибкая методология управления проектом - она же каскадная). Но - если в вотерфолле все требования максимально скрупулезно выявляют и прописывают до начала разработки, потом их утверждают, оценивают, и разрабатывают согласно ним, не имея гибкости отклониться от них, то в agile достаточно расписать требования "крупными мазками", оценить приблизительно, и уточнять уже по ходу разработки.
Поэтому в каскадной методологии чаще всего бизнес-аналитик пишет требования и не участвует в проекте далее, то в эджайл бизнес-аналитик может быть членом команды, который выявляет, документирует, представляет требования команде постоянно. Иногда бизнес-аналитик выполняет роль продакт оунера или прокси продакт оунера.
Кто такой продакт оунер и как получить сертификат профессионального продакт оунера - описала в статье PSPO - как получить сертификат?
К примеру, возьмем скрам. В нем есть 3 основных роли - команда разработчиков, владелец продукта и скрам мастер. Где же бизнес-аналитик? Какова роль бизнес-аналитика в scrum?
Бизнес-аналитик в scrum может быть как владельцем продукта, если он достаточно опытен, чтобы определять направление развития продукта, как и частью команды разработки, работая с владельцем продукта и помогая ему наполнять задачами (юзер стори) бэклог продукта, презентовать и обсуждать с командой новые задачи, разъяснять задачи команде разработки, когда их уже взяли в работу. Часто встречается именно второй вариант, т.к. владельцем продукта все же часто выступает клиент, но он часто недоступен, не создает задачи, не расписывает и не выявляет все важные зависимости, которые выясняет бизнес-аналитик.
Прим. - Бэклог продукта — это упорядоченный список того, что необходимо сделать для улучшения продукта. Это единственный источник задач, выполняемой скрам-командой. (то есть, это список юзер стори, упорядоченных по приоритету разработки).
То есть, самая частая история, которая встречается в ИТ - бизнес-аналитик - это участник команды, который постоянно работает с заказчиком, чтобы выявить требования, работает с дизайнером, чтобы оформить их в интерфейсе правильно, обсуждает требования с командой, чтобы команда знала, что их ждет в будущем, и дала свои ценные замечания и советы по части технических ограничений и вариантов реализации (и не только технических, конечно).
Более подробно писала про задачи бизнес-аналитика тут, беря за основу именно работу бизнес-аналитика scrum.
Давайте рассмотрим, какие инструменты используют бизнес-аналитики в agile, и с какими условиями и терминами чаще сталкиваются в своей работе в гибких методологиях разработки.
Пользовательские истории (user story - юзер стори)
Одним из основных инструментов бизнес-аналитика в Agile являются юзер стори (пользовательские истории).
Вообще, написание юзер стори - это одно из важнейших умений бизнес-аналитика, особенно в начале пути. Если начинающий бизнес-аналитик умеет правильно проанализировать задачу, хорошо ее описать в юзер стори, правильно разделить ее на части, если она большая - то это уже большая составляющая успеха. Ведь в начале это и будет основной задачей. Это уже потом сложность и разнообразие задач будет нарастать, хотя, скажу честно, написание юзер стори - это то еще искусство. Несмотря на кажущуюся простоту, есть достаточно много деталей, которые нужно знать и учитывать.
Итак, что же такое юзер стори? История пользователя - это короткое, простое описание функции, рассказанное с точки зрения человека, который желает получить новую возможность, обычно это пользователь системы.
Пользовательские истории обычно следуют простому шаблону:
Я, как <тип пользователя>, я хочу <действие или результат>, чтобы <получить ценность>.
Например,
- Я, как покупатель, хочу иметь возможность оплатить заказ картой, чтобы при доставке не беспокоиться о наличии у меня нужной суммы наличными.
- Я, как покупатель, хочу иметь возможность добавить товар в избранное, чтобы не искать его каждый раз, когда я хочу его купить.
- Я, как покупатель, хочу получать уведомление об отправке товара, чтобы не переживать, отправили ли его.
- Я, как владелец аудиокниги, хочу, чтобы продолжать слушать книгу с места, на котором я прервал слушание, чтобы не запоминать время и не перематывать каждый раз, когда я ее включаю.
Цели могут разниться, например, во 2м примере в избранное можно добавлять, чтобы иметь возможность еще и быстро проверять цену товара в данный момент. Но - выбирается самая важная цель.
Но это не единственная часть, также в стори еще прописывают приемочные критерии (acceptance criteria), т.к., согласитесь, оплатить картой можно по-разному, например, через PayPal, GooglePay, или, вводя номер, срок действия и cvv. Также, к истории еще можно приложить схемы, дизайны и пр детали, которые не входят в критерии приемки юзер стори.
Приемочные критерии и сами юзер стори, при этом, должны удовлетворять основным критериям качества требований, писала о них здесь.
Этот формат описания помогает команде лучше понять, кому и зачем они будут делать определенную функциональность, задать правильные вопросы, предложить лучшее решение и четко понимать, какая проблема должна быть решена в итоге. Это очень хорошая подстраховка, т.к. если просто описать техническое задание, и где-то ошибиться, то команде не будет понятно, сделали ли они то, что нужно, т.к. они не понимали главного - цели. (но технически - команда сделала то, что просили). В случае с юзер стори, команда с большей вероятностью поймет, что в задании что-то не так и придет с вопросами, и ошибку исправят вовремя, а не когда продукт уже сдали.
Более подробная статья - Как писать Юзер Стори?
Спринты
В Agile-среде проекты разбиваются на короткие временные отрезки – спринты, которые длительностью обычно от 1 до 4 недель. Каждый спринт завершается релизом новой версии продукта. (это в идеале, но, на практике, в конце спринта не всегда проиходит релиз. К чему надо стремиться - чтобы в конце спринта можно было зарелизиться - т.е. все задачи сделаны, протестированы, ошибки исправлены). Спринты постоянно повторяются, пока не закончатся задачи (или деньги :) ), но каждый раз в спринте должны быть: планирование, разработка, тестирование, ревью (презентация результатов), ретроспектива (что шло хорошо, что плохо? что сделать, чтобы положение дел улучшалось?).
Бизнес-аналитик в Agile-среде должен следить за выполнением задач в рамках каждого спринта и управлять изменениями требований, которые могут возникнуть в процессе работы.
Разработка MVP
Минимально жизнеспособный продукт (MVP) – это первая версия продукта, которая содержит только самые необходимые функции. MVP помогает быстро вывести продукт на рынок и получить обратную связь от пользователей.
Бизнес-аналитик в Agile отвечает за определение, какие функции должны быть включены в MVP, и какие требования можно отложить на будущее. Для этого бизнес-аналитик должен провести анализ рынка и потребностей пользователей, чтобы определить, какие функции будут наиболее востребованы. (начинающему аналитику этого не придется делать, но все равно нужно понимать этот важный принцип)
Декомпозиция задач
Декомпозиция задач - это разбиение большой задачи на меньшие подзадачи. Это помогает команде лучше понимать, что нужно делать, и помогает улучшить планирование работы.
Если в waterfall, например, аналитик пишет документ с требованиями, который потом разбивают на более мелкие задачи, в agile бизнес-аналитик чаще пишет требования сразу по частям. Как говорят, "Как съесть слона?" - "Ешьте его по кусочкам." То есть, требования к ПО в вотерфолле - это слон, а юзер стори в agile - это уже кусочки. (а вообще, слона жалко!)
Бизнес-аналитик в Agile должен уметь разбивать задачи на более мелкие, чтобы облегчить их выполнение, получение результатов тестирования раньше, чтобы команда могла более точно сказать, сколько времени потребуется на ее выполнение. Умение декомпозировать задачи в agile - это составляющая умения писать юзер стори (ведь чаще всего описывают задачи именно как истории пользователя).