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?». В дальнейшем мы расскажем вам о ценностях и практиках различных методологий. С их помощью вы поймете, что значит быть гибким, а также узнаете о том, как такие, казалось бы, разные методы могут быть гибкими.
Предлагаем несколько вариантов действий, которые вы можете предпринять уже сегодня (самостоятельно или вместе с командой):
• Запишите все методы, которые вы используете при создании программного обеспечения. Это может быть описание спецификации, проверка кода в системе контроля версий, использование диаграммы Ганта для документирования плана проекта или ежедневные митинги.
• Попросите кого-нибудь из вашей команды также составить перечень методов, которые вы используете. Сравните списки. Какие методы есть только в одном из них? Обсудите их. Можете ли вы в будущем найти разницу между двумя списками?
Ниже перечислены ресурсы, которые помогут вам узнать больше об идеях, описанных в этой главе.