Agile: оценка и планирование проектов

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

Прежде чем Фрэнк успел ответить, к нему с Делани подкатил на своем кресле Аллан.

— Привет, — сказал он. — Я невольно подслушал часть вашего разговора. Звучит действительно интересно. А у остальных членов команды будет доступ к результатам твоего опроса?

— Конечно, Аллан.

— Чудесно. Знаешь, мне было бы интересно послушать парочку твоих телефонных интервью, хочу знать, что говорят пользователи. Это осуществимо? — спросил Аллан.

— Без проблем, — ответила Делани. — Понимание нашей аудитории идет на пользу всей команде. Чем больше ты и другие технари хотят участвовать в этом, тем лучше для меня. Я буду больше знать о ваших представлениях, а вы узнаете, о чем говорят клиенты.

— Идет, — сказал Аллан. — Сегодня я не могу сидеть на телефоне, мне нужно устранить ошибки в системе подсчета очков в Deep Black & White. Но в остальные дни этой недели дай мне знать, когда соберешься обзванивать пользователей.

— Непременно, — ответила Делани.

— У тебя, похоже, серьезные планы, — заметил Фрэнк. — Очень интересно. Можно рассчитывать на какие-нибудь результаты на следующей неделе?

— Несомненно. ИТ-группа обещает разместить анкету на нашем сайте уже завтра. После этого предварительные результаты могут появиться в любой момент.

— Чудесно. Спасибо тебе за информацию, — сказал Фрэнк и откланялся.

Планирование итерации и релиза, раунд 1

Через две недели после совещания, посвященного формулированию и оценке пользовательских историй, команда вновь собралась в конференц-зале. К 9:00 пришли все, даже Роуз, которая стала отвозить Брук в школу на пять минут раньше, чтобы успевать в офис к началу ежедневных летучек.

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

Саша выждала несколько секунд, чтобы понять, есть ли вопросы. Вопросов не было.

Планирование первой итерации

— Так с чего мы начнем разработку? — спросила Роуз.

— Я хочу начать с генератора ходов, — сказал Аллан. — Это наш самый большой источник риска.

— У меня возражений нет, — заметила Саша, другой программист команды. — Чем я могу помочь, Аллан? Обычно все, что касается искусственного интеллекта, твоя доля работы.

— Да, но кое-что можешь сделать ты. Спасибо, — ответил Аллан. — Твоя помощь очень кстати, поскольку меня беспокоит сложность разработки сильного движка.

— Так давайте начнем с истории «Как игрок я могу играть против слабого движка, распознающего только кольца». Ты ведь это хотел сделать в первую очередь, Аллан? — спросила Делани.

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

— Окей. Сколько времени, на твой взгляд, это займет? Пару дней?

— Пару полных дней. Лучше сказать, 16 часов, — ответил Аллан.

— Аллан, давай будем записывать каждую задачу на отдельной карточке. Напиши это на карточке и укажи 16 в углу, чтобы не забыть оценку, — сказал Карлос.

Аллан заполнил карточку задачи (23.1).

— Может быть, поставить на ней мои инициалы, чтобы не забыть, чья это карточка?

— Нет. Иначе будет казаться, что этим занимаешься ты один. Лучше, если мы на текущем этапе не будем распределять работу между исполнителями.

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

Он заполнил карточку задачи 23.2.

— Карлос, в прошлый раз ты говорил, что мне нужно разбить работу на небольшие части, — сказал Аллан. — Я ведь не могу сказать, что разработка генератора ходов для колец займет две недели, так ведь?

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