Менеджмент рисков и ожиданий

В случае правильной реализации Agile-проекты должны быть избавлены от типичных проблем, которые преследуют обычные проекты. Менеджмент рисков и ожиданий является неотъемлемой частью Agile-подходов, которые построены на максимальной прозрачности рабочего процесса. Основной риск для Agile-проектов заключается в отсутствии понимания того, как именно функционирует гибкая разработка, поэтому повторите это еще раз.

• Не забрасывайте испробованные и надежные практики. Многие разработчики пытаются менять слишком многое слишком часто. Придерживайтесь плана и вносите изменения по одному. Если изменения не работают, откажитесь от них.

• Говорите. Говорите. ГОВОРИТЕ. Отсутствие взаимодействия между людьми – источник всех зол. Отсутствие информации является не менее губительным, чем плохая информация. Используйте регулярные отчеты о проделанной работе для гарантии того, что вы обсуждаете что нужно и когда нужно.

• Избегайте чрезмерно масштабных задач. Чем больше требований, тем сложнее их понять. Всегда старайтесь разбить большие задачи на несколько маленьких и более доступных задач.

• ПРОДОЛЖАЙТЕ ГОВОРИТЬ. Лучший способ избежать рисков при использовании гибкой системы разработки – это постоянно поддерживать контакт с окружающими вас людьми.

Блистательная мысль

Лучший способ привести все к краху – это формально адаптировать проект под Agile, продолжая работать с ним, как с обычным проектом. Бойтесь овец в волчьих шкурах.

Ведение журнала требований

Значение журнала требований невозможно переоценить. Это краеугольный камень вашего проекта. Тем не менее даже самый лучший журнал требований будет бесполезен, если вы его не ведете. Журнал требований – это живой организм, требующий внимания. Если использовать его должным образом, то журнал требований поможет вам понять, что происходит, найти общий язык с другими участниками проекта, уменьшить риски и контролировать ожидания. Если вы не уделяете журналу достаточно внимания, он будет просто отнимать время и сбивать с верного пути. Ведите ваш журнал требований!

В начале проекта журнал будет полон функциональных требований и характеристик, записанных в виде пользовательских историй. По мере развития проекта там будут появляться новые записи и пользовательские истории – это лишь один из возможных примеров создания элементов журнала. Основная задача журнала – сделать работу над проектом видимой, включая неудачи, бесполезные характеристики, возможные улучшения, новые идеи – вообще все. Записывайте и перерабатывайте их, а затем сортируйте в зависимости от их ценности.

Журнал требований принадлежит владельцу продукта, который несет за него ответственность. Владелец продукта не должен прекращать работу над журналом, он должен постоянно обновлять и использовать его как основу для ведения дел со всеми заинтересованными сторонами. Вносить изменения в журнал постоянно нелегко, но плюсы перевешивают неудобства. Прозрачность разработки – залог доверия, и лучший способ ее добиться – вести открытый для всех журнал.

Лучше всего, если владелец продукта и команда просматривают журнал каждый день. Это может быть частью постоянной рабочей практики или частью любой презентации, посвященной проделанной работе. Иногда ведение журнала занимает часы, а иногда минуты, однако важно обновлять записи постоянно.

Создание рабочей среды

Успех проекта, использующего Agile, в наибольшей степени зависит от его участников и того, как они взаимодействуют друг с другом. Нередко заставить людей эффективно взаимодействовать друг с другом довольно трудно, и рабочая среда играет в этом процессе ключевую роль. Самые успешные проекты – это те, участники которых сфокусированы на результате, работают в одном офисе и не имеют проблем с доступом к владельцу продукта. Не менее важно, чтобы у разработчиков перед глазами всегда была доска с задачами и, что особенно важно, журнал требований продукта. Работа в одном помещении снимает основную часть проблем, связанных с коммуникацией, позволяя не только эффективно взаимодействовать, но и налаживать личные связи, обсуждая то, кто и как провел выходные.

Блистательная мысль

Статичный журнал требований – признак грядущих неудач. Стоит обеспокоиться, если журнал не обновляется.

Впрочем, давайте будем реалистами. В идеальном мире мы все работаем в одном офисе, часто смеемся, остроумно шутим и не имеем проблем с зубами, но на практике некоторые из нас регулярно опаздывают на работу, мы часто работаем в разных городах и нередко целыми днями пропадаем в офисе заказчика. Независимо от обстоятельств, видимость и прозрачность взаимодействия является залогом успеха, но добиться этого на практике часто оказывается нелегко. Видеозвонки, электронные списки задач на гигантских тачскринах и переговоры в Скайпе далеки от идеала, однако лучше иметь что-то, чем ничего. Если, и это действительно очень важно, при всем при этом мы регулярно делаем записи в журнал, то все эти ухищрения могут сработать.

Для тех команд, которые не уверены в достижимости целей проекта и члены которых не знают своих точных обязанностей и последовательности выполнения задач, нет оправданий. Если между собой команда не разговаривает, значит, что-то пошло не так, и горькая правда состоит в том, что из-за этой рабочей среды падает производительность. Значимость эффективной коммуникации сложно переоценить; если у команды есть желание обсуждать рабочий процесс, они обязательно найдут способ, как это сделать.

Если вы не знаете, куда идете, то и придете куда-нибудь.

Йоги Берра (американский бейсболист)

 

Завершающие слова

Любая попытка начать проект без четкого видения приведет к неудаче, так как в этом случае вам придется вырабатывать видение на лету. Прочный фундамент исключительно важен для любого созидательного процесса. Даже самая лучшая команда не сможет добиться успеха, не имея точной цели с самого начала. Выработать представление о конечном результате до начала проекта нелегко, но это единственный вариант.

Однако даже при наличии фундамента реализация проекта не похожа на легкую прогулку. Для успешной реализации поставленных задач вам понадобится журнал требований продукта; к счастью, для его создания вам не нужно составлять полный и детальный список требований. Не имеет смысла тратить время на создание гор документации для проекта, который, возможно, не увенчается успехом. Создание журнала требований может быть относительно быстрым примером коллективной работы, которая, при должной реализации, может оказаться интересной.

В случае с Agile-проектами сдача первых результатов не должна восприниматься как приговор. Первый результат представляет собой тот минимум, который необходим для того, чтобы запустить бизнес. Чем быстрее вы сможете реализовать последующие этапы проекта, тем продуктивнее будут первые результаты. Не откладывайте на завтра то, что можно сделать сегодня. Следите за развитием бизнеса и с удовольствием включайтесь в новый мир Agile.

Блистательный итог

• Начните с конкретного и рационального видения. Избегайте неясных и нереалистичных целей.

• Бизнес-ценность превыше всего, поэтому убедитесь, что вы и ваши коллеги имеют общее представление о том, что это такое.

• Любите ваш журнал требований продукта. Поддерживайте журнал на должном уровне и убедитесь, что в нем хватает пользовательских историй, понятных всем.

• Определитесь с MVP! Успех проекта зависит от того, как хорошо и быстро вы справитесь с этой задачей.

• Выработайте критерии принятия и всегда держите в голове конечный результат.