Привет, Хабр! Я — Михаил Персианов (Данила Мастер), разработчик 1С в ИТ-холдинге Т1.

Сегодня мы с Оппонентом обсудим вечную тему. Конечно же, в контексте 1С, и с неожиданным выводом.

Для тех, кто вдруг не в курсе, поясню:

• «Водопад» (waterfall) — классический метод выполнения проекта, при котором строится чёткий план этапов и действий, их зависимостей и сроков.

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

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

Сравнение

Каноничное представление о водопаде выглядит так: запланировали, сформулировали этапы, нарисовали диаграмму Ганта и идём по ней, строго соблюдая сроки и стоимость.

Но в жизни так не бывает: иногда приходится и перемещать этапы, и менять их размеры. По легендам, с точки зрения каноничного водопада — это отрицательные события, но нигде об этом прямо не говорится, хотя жизнь диктует свои условия. В связи с легендарной неизменностью водопад считается наиболее удобным в случаях, когда бюджет и сроки ограничены, а так бывает чуть реже, чем всегда. Именно поэтому большинство проектов в 1С ориентированы на этот метод. Например, на нём основана Технология стандартного внедрения.

Agile ассоциируется со стаей «улиток». Документация и планирование — где-то на втором плане, главное — шлифовка: непрерывные обращения к заказчику вплоть до «хватит вам, всё прекрасно».

Как и в случае с водопадом, в жизни часто всё происходит не совсем так, и бюджет с планированием — такая же часть жизни, как и изменения: сколько их не задвигай, всё равно вылезут. Agile-технология 1С — это Технология быстрого результата. И, конечно, сопровождение — это тоже Agile.

Достоинства подходов

Водопад — это стабильность. Заказчик получает огромную экономию на коммуникациях: помог написать ТЗ, и до приёмки полностью свободен. Он не заплатит больше, чем планировал, и получит результат в срок. Исполнитель тоже работает в запланированном режиме — всё спокойно и хорошо.

Но в жизни идеальных ситуаций мало, а в сфере 1С… Нет, они есть. Когда одно и то же делаешь в сотый раз, то это срабатывает. Но и то не всегда, какая-нибудь особенность да вылезет.

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

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

Оппонент: Вот и не томи, расскажи. Сейчас все за Agile: «Отличная проектная технология, всё супер, новая». А про водопад — поди найди похвалу! Но вот только почему-то все проекты — на водопаде!

Отвечаю: Во-первых, Agile ну совсем не технология. Это образ жизни в проекте, принятие ценностей из манифеста. Есть много технологий, основанных на Agile. Его основное достоинство в том, что декларированы четыре основные проблемы проектов и предложены направления путей их решения. Признаю я эти проблемы? Да! Готов решать их предложенными способами? Да! Вот поэтому я за Agile. Против ли я водопада в связи с этим? Нет! Покажи мне, где и в каком описании водопада указана вся его железобетонность? Тут уж правильнее было бы привести PMBOK[1] .

Недостатки подходов

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

Agile не даёт ответа на вопрос: «А как планировать?» Там нет ни слова про бюджет. Недостаток Agile в сравнении с водопадом в том, что это не система ведения проекта. Если же взять технологию — Scrum, например, — то там нет глобальных планов, связи между задачами учесть сложнее.

Оппонент: А что делать, если бюджет или сроки закончились, а результат нужного качества не показал? Agile говорит: «Продукт важнее», но вот докажи потом это Заказчику!

Отвечаю: Неожиданно, но тут уже есть ответ: взаимодействуйте с Заказчиком, и, желательно, заранее. Он должен понимать риски. Так что Agile ответ даёт, но и жизнь вносит коррективы: идеально работающая рассылка поздравлений не нужна после Нового года.

Оппонент: К следующему пригодится. Давайте уж тогда до конца по Agile: «доделаем».

Отвечаю: А вот такое упорство достойно лучшего применения. Расскажу об одном случае. В давние времена, когда слова ИНН ещё никто не слышал, а при регистрации названия фирмы требовалась уникальность, мне нужно было зарегистрировать предприятие. Заказал я эту услугу у юристов, и они исчезли. Неделю их нет, две… Сроки уже поджимают, моему Заказчику выручку некуда платить, а юристы отписываются, что им всё время отказывают. Взял у них документы и сам в налоговую поехал. Выяснилось, что выбранное наименование уже есть в реестре и надо было его поменять. Но у меня прописано требование, и надо его выполнить. Курьер ездил в налоговую несколько раз. Если бы Заказчик спросил меня, то поменяли бы одно слово и все уже получили бы деньги — и они, и я. Agile в этой ситуации помог бы, но его тогда ещё не было. А твой случай — обратный: сначала про Agile забыли, а потом рвёмся его применять, да ещё в какой-то странной форме, вместо того, чтобы к Заказчику прийти. В проектах нередко встречается неоправданное упорство и нежелание коммуницировать. Именно это — одна из главных причин появления Agile.

Мои рекомендации

Правила

Главная моя мысль: все перечисленные здесь понятия — это инструменты, а в кабине сидит человек, который этими инструментами пользуется по своему разумению. И это правильно. Нет смысла спорить — Agile, WaterFall или PMBOK. Возьмите лучшее для вашего конкретного случая и пользуйтесь. Моё правило: «применяй инструменты».

Оппонент: Так почему же при сертификации PMBOK ответы по Agile считаются ошибками?

Отвечаю: Конкуренция, однако. Авторы PMBOK спрашивать будут про правила PMBOK. Но мы не на экзамене, мы в жизни. К чему приводит упорное применение одного инструмента во всех случаях, я показал выше. На месте Заказчика внедрения 1С полное соответствие PMBOK меня бы насторожило, ибо налицо лишние расходы. То же скажу и про другие инструменты, Sonar, например. Но и полное несоответствие насторожило бы ничуть не меньше.

Именно поэтому принимаем ценности Agile, используем планирование по водопаду, контролируем бюджет по PMBOK и распределяем команды по Scrum, разбавляем своим опытом и логикой. Что получается? В руках мастера инструменты заработают. В глазах теоретика это будет адская смесь из жизненных принципов и разных инструментов. И повод создать что-то новое, вроде SAFe, или — из технологий 1С — Технологию корпоративного внедрения.

«Команда, которая сосредотачивается только на отдельных практиках, может упустить из виду более общие цели, такие как улучшение коммуникации и реагирование на изменения» (Дженнифер Грин).

Оппонент: А если я не мастер? Да и ошибки бывают у всех. Не раз видел, как по Agile такой техдолжище нарастили. А почему? Потому что понабрали хотелок немеренное количество. Вот вам и коммуникации.

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

Оппонент: Но есть же и явные противоречия! Возьмём документацию. PMBOK: «делайте подробно», Agile: «делайте, как получится, хоть никак», а закон-таки говорит, что акт подписанный обязателен. Что делаем?

Отвечаю: Закон надо соблюдать. Документацию по требованиям я рекомендую составлять минимально. Весь список составляйте, когда:

• требований много, чтобы ничего не потерять;

• требования сложные, чтобы не забыть формулировки;

• требования дорогие в реализации, чтобы подстраховаться.

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

Выводы

• Agile и водопад не противоречат друг другу. Более того, у них разное назначение.

• PMBOK, SAFe, SCRUM, ТКР, ТБР, ТСВ, Agile, водопад, наш опыт, жизненная логика и ум — это инструменты. Используйте их все в своём контексте. Ум — неограниченно, а остальное — ровно настолько, насколько этого требует контекст.

• Не сотвори себе кумира. Может быть любимый инструмент, но не должно быть единственного.

• Придерживайся правил «применяй инструменты и голову» и «интерфейс важнее инструкции».

 [1]Всплывающее пояснение:

PMBOK (Project Management Body of Knowledge) — свод знаний по управлению проектами