ПРОДЕМОНСТРИРОВАТЬ ПРАКТИКИ СКРАМА ИПОКАЗАТЬ, ГДЕ И КАК МОЖЕТ РАБОТАТЬ АНАЛИТИК
Для начала предлагаю установить правила. Во-первых, переводим телефоны в бесшумный режим. Во-вторых, участвуют все. Если кто-то не хочет участвовать, поднимите руки, чтобы мы о вас знали и ненароком не вовлекли в процесс. Спасибо.
Немного о себе. Свою первую коммерческую программу я разработал в 1991 году. С 2000 года я начал заниматься управлением проектами и людьми, а также впервые столкнулся с Agile-практиками. Мне удалось поработать в разных ролях – причем и на стороне производства и на стороне заказчика.Итак, я представился. А сейчас я хочу, чтобы мы познакомились получше. Для начала, просьба поднять руку тех, у кого рядом сидит незнакомый человек. Отлично. А сейчас пусть поднимут руку те, кто знает, зачем сюда пришли те люди, которые сидят рядом. Вот это мы сейчас и исправим.
Немного о себе. Свою первую коммерческую программу я разработал в 1991 году. С 2000 года я начал заниматься управлением проектами и людьми, а также впервые столкнулся с Agile-практиками. Мне удалось поработать в разных ролях – причем и на стороне производства и на стороне заказчика.Итак, я представился. А сейчас я хочу, чтобы мы познакомились получше. Для начала, просьба поднять руку тех, у кого рядом сидит незнакомый человек. Отлично. А сейчас пусть поднимут руку те, кто знает, зачем сюда пришли те люди, которые сидят рядом. Вот это мы сейчас и исправим.
Давайте сейчас поднимемся на одну минуту и все обменяетесь визитками (или просто перепишитеe-mail друг друга), скажете, какая у Вас цель посещения и выслушаете цель посещения своих коллег. Те, кто сделают это, могу сесть и понаблюдать за процессом.Ждем минуту.Спасибо. Мы только что потренировали одну из Scrum-практик, которая называется Daily Standup. Мы все синхронизировались, получили новую информацию и передали информацию тем, с кем нам еще общаться. Из группы разрозненных личностей мы за это время получили мини-команду, которой дальше сможет работать эффективнее.
Скрам – это набор таких простых практик и требований, которые полезны и сами по себе, но вместе они усиливаются кумулятивно. Если есть желание, могу показать на примере.Отлично.Вы обменялись контактной информацией и целью посещения данной конференции. Одно только это уже имеет ценность, так как вы смогли завести новые знакомства. А сейчас я попрошу всех, кто согласился участвовать (помним же правило), после конференции написать письмо с информацией, достиг ли собственной цели и как и вопросом, что по этому поводу может сказать собеседник. Хорошо?Этим самым мы увеличили мотивацию каждого конкретно человека достичь цели. Те, кто не верит, можем отдельно подискутировать после выступлений, но потратив всего несколько минут, общая эффективность повысилась. Притом то, что все об этом знают, не мешает, так как прозрачность лишь повышает доверие.
Скрам – это просто. 3 роли, 4 церемонии и 3 артифакта. Причем все это присутствуют в любом процессе, только функции распределены по другому.3 роли: Product Owner, ответственный за продукт и бюджет.Scrum Master, ответственный за процессы. Команда – ответственная за разработку.4 церемонии: Планирование – что будет делаться и с какой скоростью, Daily Standup – синхронизация текущих активностей и контроль за выполнением активностей, Демонстрация – релиз готового продукта и показ его заинтересованным лицам и Ретроспектива – работа над постоянным улучшением процесса3 артифакта: Product Backlog – спецификация на весь продукт, Sprint Backlog – спецификация на ближайший релиз и Burndown chart – визуально средство контроля за тем, попадаем ли мы в срок с запланированным функционалом.Я считаю, что Agile-практики используются везде, правда, часто они достаточно сильно усложнены.Но мы здесь не для того, чтобы рассматривать все аспекты Scrum, поэтому давайте перейдем к тому, что касается аналитика.
Пользовательские истории. Это то, как специфицируется функционал, который команад потом оценивает и делает. По русски это звучит так:Как посетитель данной конференции, я хочу золотой бэджик, чтобы похвастаться им потом на работе.Причем часть «чтобы» – очень важна, хотя часто опускается в обычной работе. Согласитесь, что запрос «как посетитель конференции, я хочу золоту бэджик» звучит непонятно, но когда он приходит от клиента, мы начинаем делать золотые бэджики.А зная конечную цель – «понты на работе», можно уже предложить что-то иное. Серебряный вполне подойдет.
Пользовательские истории. Это то, как специфицируется функционал, который команад потом оценивает и делает. По русски это звучит так:Как посетитель данной конференции, я хочу золотой бэджик, чтобы похвастаться им потом на работе.Причем часть «чтобы» – очень важна, хотя часто опускается в обычной работе. Согласитесь, что запрос «как посетитель конференции, я хочу золоту бэджик» звучит непонятно, но когда он приходит от клиента, мы начинаем делать золотые бэджики.А зная конечную цель – «понты на работе», можно уже предложить что-то иное. Серебряный вполне подойдет.
Одной из важных частей такого специфицирования является написание критериев приемки. Пока команда и Product owner не договорится, как будет приниматься история, нормальная работа не пойдет. Во всяком случае, на демонстрации такой истории очень вероятно будут проблемыПричем Scrum не определяет, как эти критерии приемки должны быть описаны. Могут использоваться Use cases, может писаться подробная спецификация. Зависит от того уровня, на который согласятся и Product Owner и команда. И писать все это лучше всего аналитику. Особенно, если это...
Аналитик и Scrum Master в одном лице. Это – достаточно неплохой вариант, хотя имеет недостатки. Основная проблема в том, что Scrum Master должен защищать команду и процессы от внешних проблем. А аналитику необходимо понимать проблемы вне команды и помочь в их решении. Для тех из вас, кто может решить такую диллему, есть хорошая возможность заниматься также контролем процессов. Причем надо понимать, что это не уровень Project Manager’aсо всей аналогичной ответственностью. Достаточно лишь любить людей и процессы и быть в готовности все это защищать.
Изучая Scrum, многие забывают, что Product Owner – это часто не один человек, а целая команда. Кроме аналитика там могут понадобиться и графический дизайнер, и маркетолог, и конечные пользователи. SK (я бы лучше сказал, что за спиной Product Owner’а стоят графический дизайнер, маркетолог, доменные эксперты, конечные пользователи, команда поддержки и менеджмент). В случае, если Product Owner в первую очередь определяет стратегическое направление развития продукта: его видение и дорожную карту, а для оперативной работы с бэклогом ему на помощь приходит аналитик. Также, в случае, если у POи команды разработки отсуствует возможность общаться лично, существенно возрастают коммуникативные риски. В этом случае PO необходим свой человек на стороне разработки, который будет отстаивать интересы заказчика. В таком случае БА выполняет свою традиционную роль – создание моста через пропасть между заказчиком и командой. В связи с тем, что плотное взаимодействие между стейкхолдерами и командой является ключевым аспектом гибкой методологии разработки, задачей аналитика становится не только моделирование требований, но и обеспечение эффективной коммуникации между обеими сторонамиВ этом случае аналитик будет писать не только критерии приемки, но и сами пользовательские истории. Тут как раз и начнется наиболее интересная работа, так как присутствует и общение с пользователями системы, и изучение того, что предлагает рынок. И, конечно, общение с командой, чтобы описание историй и критериев приемки было понятно всем.
Но тут есть две стороны. Если это не Вы, то работы для аналитика тут будет достаточно мало (это хороший вариант для тренировки начинающих аналитиков). А если Вы смогли оказаться на данной позиции, то можно реализоваться все свои аналитические сбособности по максимуму. Однако тут важно понимать, что бОльшие права означают бОльшую ответственность. В этом амплуа аналитик отвечает не только за установление эффективной коммуникации между командой и заинтересованными лицами. На него ложится большая отвественность за приоретизацию требований, а от этого напрямую зависит успех проекта. Здесь, помимо привычных для аналитика задач, может появиться необходимость участия в политических играх на поле заказчика, в этом случае постарайтесь обзавестись союзниками и заручиться их поддержкой. И для завершения хотелось бы рассказать о наиболее частых (и маленьких) граблях, на которые постоянно наступаем в новых проектах.
Задача аналитика заключается в том, чтобы помогать команде преодолевать следующие препятствия:Ни стейкхолдеры, ни разработчики не обладают методиками моделирования требований в scrumКогда команда географически удалена от заказчика (offshore и near-shore development), и/или есть разница в часовых поясах – путем взаимодействия с обеими сторонами быть готовым ответить на вопросы и одних, и другихРазработчики обладают недостаточными коммуникативными навыкамиОсобые требования к документации (государственный заказчик, отраслевые стандарты и т.д.) –выделенный аналитик с соответствующей экспертизойСложность домена – разработка сложных технологических систем сильно отличается от разработки вебсайтов. С возрастанием сложности домена возрастает сложность анализа в нём, без аналитика не обойтись.