В большинстве случаев решения, которые формируются в рамках этого процесса, на удивление просто воплотить в жизнь. Программисты отлично видят чудовищ, которые притаились за каждой из историй. Бизнесмены часто говорят: Я и не думал, что это будет настолько дорого. Давайте сделаем это же самое, только на треть. Я полагаю, что на текущий момент этого будет достаточно.
Однако в некоторых случаях подобный способ не срабатывает. В некоторых ситуациях наименьшая ценная часть разработки с точки зрения бизнеса выглядит большой и рискованной с точки зрения программиста. Когда такое происходит, вы не должны допускать каких-либо сомнений. Вы обязаны действовать осторожно. Допускается сделать лишь незначительное количество ошибок. Вы можете потребовать большее количество внешних ресурсов, однако может случиться так, что вы получите эти ресурсы только тогда, когда времени будет в обрез. Поэтому с самого начала вы должны сделать все, что в ваших силах, для того, чтобы сократить объем работ. Вы должны сделать все, что в ваших силах для того, чтобы снизить риск. Когда все это будет сделано, вы можете приступать к работе.
Об этом можно сказать и по-другому: разделение полномочий между бизнесом и разработчиком – это не оправдание отказа от выполнения грязной работы. Совсем наоборот. Это способ отделения той работы, которая очевидно является сложной, от той работы, про которую вы просто еще не придумали, как сделать ее простой. В большинстве случаев работа оказывается проще, чем вам кажется с самого начала. Если это не так, вы обязаны сделать работу в любом случае, так как именно за это вам и платят деньги.
Глава 15.
Стратегия планирования
Мы будем планировать нашу работу следующим образом: сначала мы быстро сформируем общий план, затем мы будем постоянно пересматривать его, формируя более конкретные цели для более коротких сроков: лет, месяцев, недель и дней. Мы будем формировать план быстро и с минимальными затратами, поэтому если нам потребуется изменить его, мы должны будем преодолеть минимальную инерцию.
Планирование – это процесс предположения, как будет выглядеть процесс разработки программного продукта для заказчика. Вот некоторые цели, которые достигаются в процессе планирования:
• Собрать команду вместе;
• Определить объем работ и приоритеты;
• Оценить затраты и график работ;
• Добиться появления у каждого заинтересованного лица ощущения того, что система действительно может быть реализована;
• Определить исходные данные для обратной связи.
Давайте взглянем на принципы, которые влияют на планирование. Некоторые из них являются базовыми принципами, о которых шла речь в главе 8. Другие относятся конкретно к планированию.
• Планируйте только то, что вам нужно для реализации очередного этапа – на любом уровне детализации осуществляйте планирование только очередного этапа работ – то есть следующей версии, завершения следующей итерации. Это не означает, что вы не должны выполнять долгосрочное планирование. Вы можете это делать, только не с высокой степенью детализации. Вы можете спланировать текущую версию достаточно скрупулезно, и при этом вы можете обрисовать план пяти следующих версий набором простых тезисов. При этом вам не придется тратить значительных усилий на то, чтобы спланировать все шесть версий с высокой степенью детализации.
• Принимаемая ответственность – ответственность может быть только принята, но не может быть назначена. Это означает, что в рамках ХР не может быть такой вещи, как планирование сверху вниз. Менеджер не может прийти к команде и сказать:
• Предположительные оценки должны выполняться лицом, ответственным за реализацию, – если команда берет на себя ответственность за выполнение некоторой работы, она должна сообщить, какое время для этого потребуется. Если член команды берет на себя ответственность за решение некоторой задачи, он должен сообщить, сколько ему для этого потребуется времени.