Если процесс невозможно остановить

То, как известно, надо его возглавить. И привести к нужному результату. Явно отрицать эффективность Agile рискнут немногие, но есть много способов развалить процесс внедрения гибких методов разработки. Журналист Боб Льюис (Bob Lewis) собрал самые популярные из них. Которые, вдобавок, позволят прослыть не ретроградом, а руководителем, заботящемся об успехе компании и экономии средств. Последнее сегодня важно, как никогда.

1. Просто назовите происходящее «Agile»

При запуске очередного проекта настаивайте на том, чтобы он выполнялся «гибким способом». Например, чтобы все члены команды каждое утро выясняли, что они могут сделать в этот день, чтобы продвинуть проект.

Когда команда будет готова протестировать какой-либо функционал, дайте знать владельцу продукта, что вам понадобятся сотрудники, которые завтра займутся этим процессом. Если «завтра» тестировщиков не найдется, то ничего страшного. Это просто означает, что сдача в эксплуатацию этого функционала перейдет в следующий спринт.

А если владелец продукта начнет жаловаться на то, что проект не укладывается в график, объясните, что «гибкие проекты» не имеют графиков. В конце концов, Agile означает «без плана», не так ли?

2. Не заморачивайтесь архитектурными вопросами

Не тратьте время на определение архитектуры приложения на ранних этапах проекта. Если гибкость означает, что требования постоянно развиваются, не должна ли непрерывно развиваться и архитектура приложения?

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

А если разработчики творят еще и на разных языках... Ну, так для этого и нужны контейнеры, не так ли?

3. Ответ — Scrum. Простите, а какой был вопрос?

Agile — это не методология. Это семейство методологий, каждая из которых подходит для разных проектов. Scrum стал самой популярной не потому, что это «лучшая практика», а, скорее, потому, что это наиболее жестко структурированный гибкий вариант. Это делает его родственным привычному «водопадному» методу.

Из-за этого Scrum плохо подходит для создания и «коробочного» программного обеспечения, и программного обеспечения как услуги (SaaS), которые разрабатываются в большинстве софтверных проектов.

Есть лучшие альтернативы, но слышали ли вы когда-нибудь аббревиатуры CRP или ATTD? Но это и неважно. Перефразируя старое выражение про технику IBM, никого еще не уволили за выбор наиболее популярного варианта. Даже ваши злейшие оппоненты — и это если они сами в курсе существования альтернатив, что далеко не факт.

Поэтому когда ваш проект, управляемый по методологии Scrum, пойдет «не так», то все можно свалить на то, что использование Agile само по себе — не слишком хорошая идея.

4. От «водопада» до SAFe одним прыжком

Очарование Agile и его главная сила — в его простоте. А его самая большая слабость в том, что он не очень хорошо масштабируется. Да, есть SAFe — Scaled Agile Framework. Однако SAFe довольно сложен, в нем много потенциальных точек отказа, он строится на явных или неявных предположениях о будущем, как «водопадная» конструкция (слабое место которой, что в ИТ, что в бизнесе — будущее меняется к тому времени, когда предположениям приходит время сбываться, порой — и не один раз).

На самом деле, SAFe неплох. Но для внедрения этого фреймворка требуются опытные практики. При попытке решить проблемы масштабирования «с ходу» проект провалится, но вы же предупреждали, что Agile не масштабируется.

5. Agile за фиксированную цену

Но при этом их предложения должны включать в себя заранее фиксированную цену. Иначе у них будет стимул нарушать бюджет и сроки проекта.

Гибридная рабочая среда вызывает привыкание Бизнес

А если партнер укажет, что начинать с фиксированного объема и изменять его только с помощью «жесткого» управления изменениями — это полная противоположность Agile, что ж, хорошо, что вы узнали, насколько сложно будет работать с этим поставщиком до подписания каких-либо договоров.

6. Удаленная работа в тренде. Будем ему следовать

Удаленная работа дала нам возможность привлекать специалистов из самых разных регионов — говорят сейчас все. Это позволяет экономить.

Прекрасно. Пусть разработчики живут и работают во всех 11 часовых поясах страны. Или даже дальше. Да, принципы Agile подчеркивают важность личного общения — как между разработчиками, так и между разработчиками и бизнес-пользователями.

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

А если модули, созданные «удаленными из дискуссий» разработчиками не будут удовлетворять задачам, поставленным бизнесом, то всегда можно объяснить, что «бизнес» сам не знает, чего хочет. А эти модули намного дешевле.

То, что требования бизнес-заказчиков оказались непонятыми из-за недостатка личного общения с разработчиками, не придет в голову никому из тех, чье мнение имеет значение.

7. Планирование, планирование и еще раз...

Мы знаем, что Agile Manifesto ставит «… людей и взаимодействие выше процессов и инструментов». Но также из практики мы знаем, что успех в бизнесе зависит от внедрения четко определенных повторяемых процессов.

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

В общем, если добавить Agile-процессу сложности, детальности и «структурированности», то, в конечном счете, вы получите тот же «водопад», хоть и под другим названием.

Альтернатива: внедрить Agile настоящим образом

Как отмечает Боб Льюис, если семь описанных здесь стратегий покажутся вам непривлекательными, то есть еще вариант. Признать, что Agile действительно работает лучше, чем «водопад», и честно попробовать его внедрить. Да, это нелегко, однако, полагает он, переход на гибкие методы разработки неизбежен.