Вы уверены? Я точно знаю, что Agile – это значит ничего не писать и не планировать, а сразу переходить к программированию. Разве это не эффективнее?

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

Scrum-команды, например, посвящают обычно целый рабочий день планированию тридцатидневной итерации. Кроме того, они проводят ежедневные совещания (обычно длящиеся 15 минут), на которых вместе рассматривают план. Для пяти человек в команде это составляет 40 человеко-часов планирования в начале итерации и еще столько же в течение ближайших 30 дней. Это гораздо больше, чем многие традиционные команды делают за 30 дней разработки программного обеспечения. Неудивительно, что scrum-команды выполняют такую работу точно в срок! При этом члены команды вовсе не считают, что планирование – это «скучно». Дело в том, что они вовлечены в процесс, заботятся о результате и чувствуют, что усилия, потраченные на планирование проекта, необходимы, чтобы остальные итерации протекали успешно.

(Вы подробнее узнаете о механизмах планирования scrum-проекта в главе 4.)

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

Правда ли, что Agile подходит только очень опытным разработчикам, которые хорошо справляются с планированием?

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

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

Если все члены команды (тестировщики, бизнес-аналитики, UX-дизайнеры, руководители проектов и т. д.) не используют agile-методологию, то могу ли я заниматься гибкой разработкой самостоятельно?

Да. Но, вероятно, это будет не очень эффективно. Когда люди говорят о введении agile-методологий только для разработчиков, значит, они собираются применять только отдельные ее методы. Разработчики получат импульс для улучшения собственной продуктивности, поэтому польза все равно будет (результат «лучше-чем-ничего»). Но команда не изменится и не поменяет взглядов на ведение проектов, а это серьезно ограничивает позитивное влияние гибкого мышления на производительность. Способ работы над проектом, при котором команда работает по сценарию Water-Scrum-Fall (гибридная модель создания ПО), оставляет у ее членов чувство неудовлетворенности agile-методологиями.

Если я не использую Scrum, XP, Lean или Канбан, то значит ли это, что моя команда не гибкая?

Конечно, нет. Существует много гибких методологий – мы сосредоточились на нескольких и используем их, чтобы раскрыть перед вами идеи Agile. К тому же одна из целей этой книги – помочь ответить на вопрос «Что такое Agile?». В дальнейшем мы расскажем вам о ценностях и практиках различных методологий. С их помощью вы поймете, что значит быть гибким, а также узнаете о том, как такие, казалось бы, разные методы могут быть гибкими.

Что вы можете сделать сегодня

Предлагаем несколько вариантов действий, которые вы можете предпринять уже сегодня (самостоятельно или вместе с командой):

• Запишите все методы, которые вы используете при создании программного обеспечения. Это может быть описание спецификации, проверка кода в системе контроля версий, использование диаграммы Ганта для документирования плана проекта или ежедневные митинги.

• Попросите кого-нибудь из вашей команды также составить перечень методов, которые вы используете. Сравните списки. Какие методы есть только в одном из них? Обсудите их. Можете ли вы в будущем найти разницу между двумя списками?