Как мы адаптируем Agile в Ozon?
Привет, Хабр! Меня зовут Антон, я — тимлид в 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 ценности, любой запомнит:
Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.
И более того, «не отрицая важности того, что в конце мы всё-таки больше ценим то, что в начале».
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 — это лишь манифест, философия, которую сформировали в горах несколько человек. Идея манифеста — помочь вам в достижении главной цели — создании ценности для пользователя, но не больше. И нет ничего страшного, что в каких-то проектах вы не сможете его использовать, а в каких-то придётся комбинировать с другими методиками.
У вас в арсенале есть не только молоток, а все вокруг — не обязательно гвозди.
Habrahabr.ru прочитано 1248 раз
