Привет, Хабр! Меня зовут Антон, я — тимлид в Ozon. За более чем 20 лет работы в IT, где свыше 15 из них выпало на управленческие должности, меня покидало по разным проектам разработки ПО. Познавая управленческое мастерство, я нередко замечал, как на проектах игнорировали самую важную часть — ориентированность на Клиентов, то есть для кого мы, собственно, эти проекты и продукты реализуем.

Методология Agile как раз и была призвана решить проблему фокуса на Клиенте, где в тесном сотрудничестве с ним создаётся первоклассный продукт. Люди и коммуникации выведены в Agile на первый план, а технологии, можно сказать, не упомянуты вообще.

Проблемы Agile отмечают не только рядовые пользователи, но и такие мастера, как Роберт С. Мартин и Кент Бек — двое из тех, кто составил Agile Manifesto. Как отмечает Ален Холуб, Agile в последнее время стал означать: делать половину задач (активностей) из Scrum плохо с использованием Jira.

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

Проблемы я стараюсь рассматривать равнозначно как со стороны бизнеса, так и со стороны IT, поэтому надеюсь, что данная статья будет полезна не только техническим менеджерам, но и представителям бизнес-подразделений.

Подслушано в баре об Agile: некомедия в 5 актах

Действующие лица:

PM — то ли Project, то ли Product manager, его руководство пока не определилось, но работает за обоих. В нашей истории является представителем бизнеса. Довольно молодой сотрудник компании. Очень любит Agile и верит: «Если данную методологию правильно применять — всё получится». Он считает (или так заведено в компании), что IT часто виноваты в срывах сроков проектов. Бизнес-ориентированный, стремится приносить пользу Клиентам и бизнесу, нацелен на результат. Хорошо подкован в теории, и любитель позанудствовать. Технический бэкграунд практически отсутствует.

TL — Team Lead, довольно-таки опытный руководитель, вырос из разработчиков. Очень много работал на проектах, где требований практически не было и коммуникации с бизнесом носили односторонне-принудительный характер. Понимает Agile и другие методики разработки ПО. В прошлом был небольшой опыт работы PM, но потом вернулся обратно в разработку. Хочет работать в компании, где бизнес адекватный и тесно взаимодействует с IT. Постоянно учится и готов слышать собеседников, признаков неадекватности за последние три года не проявлял.

DEV — сеньор, разработчик, которому в целом параллельно на методологии проектов, и чихал он на весь менеджмент, стратегии и корпоративную культуру. Делает задачи и периодически меняет компании, где платят больше. Ковыряет дома Pet-проект, который так и не может запустить. Любитель троллинга и мемчиков. При этом готов прийти на помощь коллегам и решать сложные технические вопросы. Обладает глубокой технической экспертизой и не раз спасал компании в критические моменты, когда системы вот-вот должны были обрушиться. Сторонник красивого кода, паттернов проектирования и его величества рефакторинга.

Случайный слушатель — бизнес-консультант в сфере IT, спикер, автор статей. Делает заметки об услышанном, надеюсь, корректно.

Все герои работают в разных командах или компаниях. TL, PM, DEV знакомы друг с другом давно.

ВАЖНО! Описанная ситуация является гипотетической. Персонажи не являются обобщающими, они фантазия автора и созданы лишь с целью более остро передать излагаемый текст. В общем, все персонажи вымышленные, а любые совпадения случайны.

Акт первый. В баре за стойкой после напряжённого рабочего дня.

PM: ...А я считаю, что Agile — вообще отличная штука. Постулаты были заложены аж в 2001 году, но до сих пор актуальны и работают. И там всего 4 ценности, любой запомнит:

1. Люди и взаимодействие важнее процессов и инструментов.

2. Работающий продукт важнее исчерпывающей документации.

3. Сотрудничество с заказчиком важнее согласования условий контракта.

4. Готовность к изменениям важнее следования первоначальному плану.

И более того, «не отрицая важности того, что в конце мы всё-таки больше ценим то, что в начале».

TL: Ну да, ну да, слышал эту историю, люди зависли высоко в горах и сторговались на этих 4 принципах, которые вроде всех поначалу устраивали. А нам теперь за ними разгребать.

DEV: Вполне неплохо для тусовки на горнолыжном склоне. Мы максимум пили горячий чай из термосов…

Несмотря на какой-либо интерес со стороны TL и DEV, PM продолжил про пользу и ценность Agile Manifesto.

PM: Ну смотрите, манифест действительно фокусируется на людях и результатах работы, но тем не менее не забивает на такие вещи, как процессы, документация и планы. Если не впихивать сюда всякую отсебятину, то он действительно хорош.

DEV: Может, хорош о работе?

TL (продолжает, не замечая DEV): Слушай, но мы же работаем с людьми, и впоследствии понимание этих ценностей изменилось до неузнаваемости, а какие-то элементы предпочли проигнорировать. Вот мой прошлый PM говорил: «Ой, да кому нужна эта документация, вы же код не на шумерском пишете».

DEV: Понятно, мнение разработчика опять проигнорировано...

TL (продолжает, не обращая внимания): А другой мой PM говорил, что сроки — это для галочки, пока он не лишился премии за срывы этих галочек... Естественно, после такого возникает негатив, и виноват во всём Agile, а не менеджмент проекта.

DEV: Ладно, тогда и я вставлю свои пять копеек. Некоторые мои коллеги просто ненавидят Agile, для них это синоним бардака. Вроде план есть, а вроде и нет. Вроде роли поделены, а по факту никто ни за что не отвечает. Мои друзья из другой компании вообще заморочены чисто на сторипойнтах и диаграммах сгорания! А вообще код писать всё равно мне, пусть хоть «фигаджайл» назовут — суть не поменяется: пиши, переделывай, пиши. Пойдём за столик — фришки закажем.

IT страдает от менеджмента

Акт второй. Те же, уже за столиком в баре с вкусной картошкой фри и чесночными гренками.

TL (вприкуску с картошкой полуразборчиво продолжил): Плохие менеджеры любят Agile, так как он полностью переопределяет баланс полномочий и ответственности. Внезапно у вас, пиэмов, появляется «классическая» власть давать прямые указания команде разработки, что и как делать, над чем работать, а что бросить прямо сейчас. При этом ответственности-то никакой. Вообще ни-ка-кой. (Жестикулирует и вытирает кетчуп салфеткой.) Во всём виноваты разработчики и тестировщики, чаще тестеры, конечно, но это опустим. Ну типа дейлик или ретро для вас как ритуал привлечения к ответственности, где фразы «что мы сделали не так и что мы можем улучшить» воспринимаются всеми как «что ты сделал не так и как ты собираешься это исправить в ближайшие две недели».

DEV: Во-во, лично я тщательно выбираю тикеты по принципу, чтобы успеть в спринте потенциально минимально накосячить. Что-то неохота потом оправдываться на ретро, почему я не успел или зафакапил релиз.

TL: А как же ценность для пользователя? (Хохочет.)

DEV что-то невнятное пробормотал, сделав глоток из бокала…

TL: Ну и у меня есть ощущение, что наш PM — какой-то фильтр между нами и реальными пользователями. В конечном счёте мы имеем слабую обратную связь от пользователей, трансформированную через его понимание. Ну а наши замечания и вопросы как будто просто уходят в песок. В итоге из команды крутых и способных спецов у меня получается команда инфантильных ребят, которые делают только то, что нужно ему.

PM: Кому ему, бизнесу?

TL: Какому бизнесу? Пиэму, говорю же. Я вообще начал замечать, что мои разрабы всё с большой неохотой берут тикеты в работу, если там предстоит о чём-то подумать, напрячься. Шляпа какая-то… (С досадой покрутил бокал.)

PM: О, парни, я, кажется, вспомнил, как это называется — «выученная беспомощность». На каких-то курсах по мотивации проходил. Сейчас погуглю. О! Нашёл: «в состоянии выученной беспомощности индивид, испытывающий неудобства, боль и тому подобные негативные факторы, не предпринимает попыток к улучшению своего положения, хотя имеет такую возможность». Смотри (показывает телефон TL): по мнению Мартина Селигмана, у людей выученная беспомощность сопровождается потерей чувства свободы и контроля, неверием в возможность изменений и в собственные силы, подавленностью воли и депрессией вплоть до наступления смерти. Ахахах, мы тут, кажись, подобрались к раскрытию великой тайны быстрого выгорания в IT.

Бизнес страдает от IT

Акт третий. Те же, вышли на улицу перед баром подышать.

PM: Слушайте, а как так вышло, что если раньше разработкой занимались только программисты, то сейчас это разрослось на несколько ролей? Теперь вы просите бизнес-аналитика, системного аналитика, ну и тестировщика, конечно. И все это для той работы, которую раньше выполнял один человек? О дизайнерах вообще заикаться не буду.

DEV: Эм… Ну каждый должен заниматься своей работой, я вот код пишу, а на остальное… Не моя задача бизнес-требования собирать, а уж тем более думать за бизнес.

TL (обращаясь к PM): Ну ты не думаешь, что выросла сложность проектов, а бизнес всегда хочет вчера.

PM: А раньше-то вы как справлялись? Ну не вы вдвоём конкретно... Ну лиды, разрабы. Кстати, лидов недавно вообще не существовало вроде. Откуда они взялись?

TL: Известно откуда. (Смеётся.)

PM (продолжает рассуждать): Мы тут все уверенно шагаем в микросервисы с выделенной зоной ответственности, и вроде проекты, наоборот, упрощаются. В общем, не понимаю… (Задумался на немного.) Ну вот скажите: а вам не кажется, что за всем этим раздутием штата скорость внедрения изменений замедлилась? Мой более опытный товарищ рассказывал, как они за пару дней реализовывали целые подсистемы ERP без аналитиков и тестировщиков, на которые сейчас бы ушли месяцы. И багов было точно не больше, чем бы делали сейчас.

DEV: Ну плохокод писать — ума не надо…

TL: А сейчас ты его не пишешь?

DEV: Ой, всё!

PM: Хорошо, предположим, вы правы, тогда, возможно, продукты стали лучше, релизы выходят без багов? И-и-и перегруженного UI в 2025-м не существует как явления?

DEV, TL и PM молча засмотрелись на проезжающую мимо дорогую машину…

PM (прервал тишину): Поймите, я не возражаю против аналитиков и тестировщиков. Я возражаю, когда разработчики сознательно вешают на себя шоры и остаются беспомощными во время отсутствия этих самых аналитиков и тестировщиков. Фокусировка исключительно на коде, возможно, хороша, когда ты пишешь алгоритмы, но выходит боком, когда сталкиваешься с бизнес-требованиями.

TL: Кстати, я знаю одного руководителя разработки, который делит разработчиков на кодеров и бизнес-программистов.

DEV: Ну удачи ему с подбором…

TL: Я сказал «руководитель разработки» вместо «тимлида»?

PM: Попался! (Смеется.)

TL: Не, ну знаешь, я, может, и соглашусь, что при увеличении ролей усложняются коммуникации, а отсюда и большие сроки. Попробуй всех собери на синк или груминг. У меня столько встреч по разным тематикам, что иногда я плавлюсь и путаю проекты. Бывало, даже задачи заводил не на тот проект, а их реализовывали и принимали. Забавно…

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

PM: Ну естественно. Теперь каждый сотрудник, выполняющий роль бывших программистов, должен отчитываться за себя как за обособленную единицу. Откуда, вы думали, возникают нелепые функции, дыры в безопасности и убежденность, что их пользователь — человек с хорошей компьютерной подготовкой? Лично я уверен, что раздутие штата и деление на микророли. Это основная причина бардака в системах и интерфейсах, а не менеджеры.

DEV: Попридержи коней, вас, манагеров, тоже попилили на микророли. Это проблемой не считаешь?

PM: Хм… ну, возможно, и в этом тоже…

Спринт как повод сделать больше

Акт четвертый. Те же. Вернулись в бар, чтобы доесть, допить и выдвинуться домой.

DEV: У меня часто возникает ощущение, что единственное важное для вас, пиэмов, — это сроки. Вы нас загнали в спринты, конец которых мы воспринимаем как маленькую смерть. И чем ближе к концу спринта, тем больше от вас вопросов: «Когда? Когда?» Давление, давление… Один мой TL любил говорить: исходя из законов физики, под давлением всё ухудшается.

TL: Вот-вот, а на ретро начинается перекладывание ответственности на нас за срыв сроков.

PM: Да ладно, мы же спрашиваем вас о сроках, вы там что-то как-то оцениваете и говорите нам. Чего обижаться, когда мы приходим к вам по окончании этих сроков и спрашиваем за результат.

DEV: Конечно оцениваем, только потом.

TL: Только потом приходит PM, которого этот срок не устраивает, и просит сделать небольшую часть из всей задачи или проекта за половину срока, а может, и ещё раньше. Причём оценка на эту часть задачи уже идет не совсем пропорционально, ведь оценивалась задача целиком, а не её часть.

DEV: А за эту половину срока ждут готовый продукт.

PM: Не, ну вы ИМХО передергиваете.

TL: Скажи ещё, что у тебя такого не случалось.

Официант прерывает беседу, наши герои расплачиваются и начинают собираться.

DEV: Всё, что мне остаётся, — сидеть по выходным и вечерам и впиливать дикие костылины. Б-р-р, меня аж трясёт от такого. А может, работу поменять? Чёт я уже подустал.

TL: Ага, переработки или вон…

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

TL: Да, только мой PM не понимает, что можно попробовать заставить людей работать больше, но заставить думать быстрее не получится. Отсюда замкнутый круг — переработки, они не спасают, ещё больше переработок — тотальное недовольство у всех.

PM: Многие мои знакомые так это и называют — «запихнуть слона в коробку». Грустно, конечно, но что, если это дает результаты?

TL: В какой перспективе? Разово — возможно, но в долгосрочной — не думаю.

Зашли в метро и расположились молча на эскалаторе.

Игнорирование технического долга

Акт пятый. Те же, едут домой на метро, стоят в вагоне.

TL: PM, подскажи, плиз, почему бизнес не воспринимает техдолг?

PM: Ну, ребят, бизнес летит вперёд бешеным темпом. Нам нужны фичи, возможно, и пользователям тоже, тут как-то не до вашего техдолга.

DEV: Забавно, если бизнес вообще не знает, что он существует.

PM: Ну давайте на чистоту: ваш техдолг не особо интересен, так как мы мыслим категориями «плохой код — не приносит денег, хороший код — приносит». А чего у вас там под капотом… да вообще как-то... Бизнес считает, что через полгода ваш код в любом качестве уже будет не нужен.

TL: Забавно. А ты не задумывался, чей это долг?

PM: Ясен пень, ваш, он же технический. Вот и выкраивайте время на исправление где хотите. Вы накосячили — вам и чинить!

TL: Я вот считаю, что это долг бизнеса перед IT за то, что нужно было срочно сделать, игнорируя все принципы разработки ПО, качество и паттерны.

PM: Ага, я прям вижу, как ты приходишь и говоришь CEO: у нас тут техдолг есть, но он не наш, а ваш — давайте капаситет, бюджеты и приоритеты.

TL: Долг не просто так назван, его могут попросить вернуть обратно, и вряд ли кто-то простит. А что хуже всего — могут попросить отдать этот долг во время сезона распродаж в два ночи. Безусловно, в конечном итоге это скажется на всех, но на бизнесе — в первую очередь. Я думаю, что в такой формулировке CEO бы понял.

DEV: О да, обожаю фиксить костыли на проде по ночам.

PM: Блин, конечно, это в первую очередь бьёт по бизнесу, хм. (Задумался и посмотрел на схему метро.) Следуя логике, существует ли бизнесовый долг — долг IT перед бизнесом?

TL: Конечно, просто обычно его называют проектами.

DEV: Забавно, игра слов… Может, бизнесу и IT следовало бы изначально договориться о терминах, прежде чем открывать ящик «разработки»?

PM: Проблемы нашего мира — это проблемы коммуникаций, а не следование инструкциям, конечно… Эх.

TL вышел на своей станции, а PM и DEV уткнулись в телефоны…

Наша адаптация к Agile

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

Для этого мы выработали некий флоу, которого придерживаемся при разработке проектов. Однако команды имеют права на адаптацию элементов этого флоу под особенности своих сервисов, проектов и продуктов.

Верхнеуровневый флоу

- Что вы хотите: выиграть или не проиграть?

- А в чём отличие?

- Это две разные стратегии!

Все категории задач стратегически можно разделить на удержание доли рынка, наращивание доли рынка и создание нового рынка.

Задачи в таких категориях обычно представляются в виде проекта или продукта, который приоритезируется на специальных встречах. У каждого направления разработки есть свой капаситет под разные категории задач. Например, на техдолг выделяется 20%, на стратегические проекты — 40%, средние проекты — 40%. Для приоритезации задач внутри выделенного капаситета используется множество критериев: деньги, имидж, удобство, сроки и многие другие. Но самое важное, что приоритезация на таких встречах осуществляется совместно представителями бизнесовых подразделений и IT.

Вышеупомянутый техдолг можно отнести в категорию удержания, ведь от стабильности и качества текущих решений напрямую зависит удовлетворенность наших Клиентов. Хотя, если отнести его в категорию наращивания, тоже ошибки не будет, ведь бывают случаи, когда объём обслуживаемых Клиентов ограничивается возможностями информационных систем. Бизнес понимает, что техдолг берётся не на ровном месте, а чаще вызван решением задач в сжатые сроки или изменениями в бизнес-процессах. Время на устранение данных пробелов тоже нужно выделять.

Эти мероприятия являются не чем иным, как точкой взаимодействия между бизнесом и IT.

Для IT такие задачи представлены в виде царь-эпиков, а их комбинация с учётом приоритетов — не что иное, как роадмап направления, отдела или группы. Таким образом, каждая команда понимает приблизительный объём работы, который необходимо выполнить к определенным периодам, включая техдолговые задачи.

Если проект состоит не из одного шага, то мы делаем ещё одно упражнение: рисуем верхнеуровневую реализацию в виде диаграммы Ганта. Это здорово помогает, особенно для выявления критических путей проекта. Если проект небольшой, то сразу разбиваем царь-эпик на подэпики, или истории. В случае ультрабольшого проекта мы выделяем в нём этапы, или майлстоуны, и рассматриваем их как отдельные проекты по вышеописанному флоу.

Планы — бесполезны, планирование — бесценно. Дуайт Эзенхауэр

Реализация задач выполняется уже по Agile и зависит от принятых методик работы конкретной команды. Может случиться так, что одна команда работает по Scrum, другая по Kanban, а третья, как, например, у меня, комбинирует эти две методологии сразу, где спринт выступает в качестве мини-вехи, а задачи выполняются внутри по методологии Kanban.

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

Если в ходе реализации бизнес-требований возникают вопросы, сложности и предложения, то мы можем спокойно обратиться к бизнес-подразделениям. Например, для новой приоритезации задач или сокращения рамок проекта. Бизнес часто идёт навстречу, и мы отвечаем взаимностью, когда нужно сделать что-то ещё, что не было оговорено вначале. Бизнес слушает нас, а мы — бизнес, особенно когда возникают «метеориты». «Метеориты» — это экстренные внеплановые задачи, часто вызванные изменением со стороны регулирующих органов или реакцией на обратную связь от наших Клиентов и операционных подразделений, от которых зависит скорость доставки и выдачи долгожданных заказов Клиенту.

-Что убило динозавров: астероид или куча метеоритов?

-Теперь я уже не уверен…

Активности

Теперь немного пройдёмся по активностям, которые сопровождают практически любой проект (как я уже упоминал ранее, команда трудится над несколькими проектами одновременно, включая техдолг).

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

Активности, которые требуют проработки сложных технических решений, лучше назначать в первой половине дня. Дело в том, что наша мозговая активность начинает снижаться где-то с 11:30, и время после 14:00 больше подходит для несложных работ. А время около 18:00 наиболее эффективно для генерации новых идей. Ретро и демо лучше проводить в пятницу и по вечерам, так как рабочий настрой к концу недели снижается, в голове уже циркулируют планы на выходные, поэтому элемент «шоу» как нельзя лучше вписывается в эту канву. Кроме того, такой тайминг позволяет заканчивать рабочую неделю на позитивной ноте.

Золотое правило: не отъедайте самое продуктивное для разработки время у своей команды разработки.

Установочная встреча. Согласование целей проекта, критериев успеха и остановки. Окончательная синхронизация видения IT и бизнеса. Конечно, со стороны IT больший упор идёт на требованиях и видении проекта и подсвечивания проблем, которые видны со стороны IT. Цели проекта, конечно, больше идут со стороны бизнеса.

Презентация команде разработки. Формирование понимания у команды о самом проекте, вовлечение команды разработки в бизнес-смысл реализуемого проекта. Не забываем про дизайнеров, так как важно, чтобы они варились в проекте с самого начала. В некоторых компаниях я встречал пренебрежение этим правилом, когда дизайнеров привлекали только под конец, и получали кучу проблем в части UX, которые требовали серьёзной переработки системы.

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

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

Дейлики. Регулярные короткие встречи до 15 минут между участниками проекта. Синхронизируемся, делимся достижениями, новыми сведениями, подсвечиваем проблемы. Формат допроса в стиле «что ты делал, что будешь делать» — не наш выбор, тут лучше работать в формате обсуждения открытых вопросов и проблем. Роль ведущего — следить за таймингом и гасить холивары, для этого можно организовывать отдельные встречи. Регулярность зависит от сложности проекта — от ежедневного до нескольких раз в неделю, главное, чтобы хоть один выпадал на понедельник.

Демо. Презентация результатов работы бизнес-подразделениям и будущим пользователям для сбора обратной связи и предложений. На демо также можно презентовать идеи, наработки, чтобы получить фидбэк ещё до окончательной реализации. По сути, демо можно использовать как площадку для обсуждения открытых или спорных вопросов с бизнесом и конечными пользователями.

Ретро этапа. Проведение работы над ошибками, особенно после демо. Сбор проблем и предложений по оптимизации процесса разработки от команды проекта.

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

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

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

Вместо ретро

В конце предлагаю посмотреть ещё раз на Agile Manifesto, но уже сквозь призму адаптации:

1 Уделяйте внимание людям и инструментам, которыми они пользуются в процессе работы.

• Люди создают продукты для других людей, разных людей, очень разных людей.

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

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

2 Основная цель — получить рабочий продукт, который могут, с одной стороны, применять пользователи и, с другой — поддерживать разработчики.

• Продукт должен покрывать запрос пользователей.

• Интерфейс должен быть типовым (Office like), общераспространённым в компании или сопровождаться документацией.

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

• Взаимодействуйте с заказчиком и фиксируйте договоренности для лучшей синергии.

3 У заказчика в проекте есть не только права, но и обязанности. Как пример обязанности — реагировать на замечания и предложения команды разработки, прояснять белые пятна, тестировать результаты разработки.

• Договоренность — это зафиксированный результат переговоров в виде артефакта (например, статьи на портале, оформленной задачи, допсоглашения к контракту и т. д.)

• Используйте принцип Win-Win для достижения синергии, принимайте интересы бизнеса и интересы команды разработки — везде люди.

• Составьте план, по которому будет двигаться разработка, но заложите время на изменения.

• Принцип дерева — твердая основа (корни) и гибкие процессы (ветви).

• Разделяйте и различайте бизнес-требования по нужности и критичности, не всё так однозначно, как кажется.

• Иногда нужно говорить «нет», и это нормально.

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

У вас в арсенале есть не только молоток, а все вокруг — не обязательно гвозди.