Постигая Agile

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

Рассматривайте ситуацию в целом

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

Мы видели, как такие действия становятся потерями, но иногда они служат целям, которые могут не принести пользу проекту, однако необходимы для него или для компании в целом. Например, команда можете впустую тратить время (с точки зрения пользы для проекта), заполняя отчеты, не помогающие проекту. Но если они необходимы для регулятора, то нужны и компании. Как мы узнаем, какие виды деятельности действительно полезны?

Вот где проявляется следующая lean-ценность: рассматривайте ситуацию в целом. Чтобы понять, результативна ли ваша команда, оцените всю систему, чтобы иметь объективный взгляд на вещи: слишком легко в процессе решения полностью выложиться эмоционально. Например, менеджер проекта создал систему расписаний, которая требует, чтобы каждый разработчик ежедневно каждые 15 минут заполнял табель учета времени. Он, возможно, будет счастлив, обзаведясь постоянно обновляющимся статусом проекта, которого он так добивался, но при этом даже не догадывается, сколько сил уходит на это у команды. Поэтому намного проще убедить его отказаться от этих дополнительных обновлений, если удастся доказать, что они обходятся команде, скажем, в 5 % от ее производительности.

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

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

Для людей, которые не потратили много времени на измерения систем, особенно систем, которые команда использует для создания программного обеспечения, – эта идея может показаться очень абстрактной. Давайте рассмотрим конкретный пример.

Пользователи очень трепетно относятся к тому, насколько команды учитывают их потребности. Клиенты хотят, чтобы их требования быстро превращались в программное обеспечение. Они чувствуют себя намного счастливее, получая от команды одну новую функцию в месяц вместо трех – но за три месяца. Именно поэтому Scrum и XP используют итерации, а agile-команды – короткие циклы обратной связи.