Agile для дедушки: гибкие методологии на простом примере

Маркетолог Наталья Бабаева об интуитивности Agile и ситуациях, когда необходим Scrum.

Когда что-то нельзя объяснить просто, невольно начинаешь подозревать неладное. Особенно если для того, чтобы понять что-то, нужно изобрести это заново.

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

Стоп, Наташа. Не надо думать. Ты прочитала три книги на эту тему, послушала пару двухдневных семинаров, прошла Agile-курс, посмотрела несколько видео и провела несколько стратегических сессий с Agile-тренерами. И пару лет поработала в Scrum-процессе (и это не был настоящий Scrum). Да что ты можешь понимать. Не смей искать ответ на свой вопрос. Записывайся и жди консультации с Agile-тренером.

Мне не нравится, когда нельзя думать. Принцип «су-ха-ри» негласно запрещает использовать здравый смысл. Прямо как в советской школе — думать не нужно, учи. Это выглядит подозрительно.

Присоединиться к лагерю противников Agile — не мой вариант. Все внутри меня принимает принципы Agile. Я меняющийся человек, и без гибкости никак.

Agile и Scrum — довольно интуитивные вещи, которые важно включать. И вовремя выключать.

Зовите дедушку и поехали.

Объясняем дедушке Agile

Дедушка, представь. Ты молод, недавно женился. Кто-то приютил вас с женой на лето. Но скоро зима, нужно успеть построить дом. Что бы ты сделал?

Построил бы маленький дом, но с хорошим фундаментом, лишь бы въехать до зимы. Накрыл бы крышу просто, чтобы перезимовать.

А потом?

На следующее лето сделал бы пристройку, поставил хорошую крышу. На третий год построил бы веранду. На четвертый — может, и второй этаж. Вместе с женой мы решили бы, что делать в первую очередь.

Молодец, дедушка. Теперь запоминай:

  • Дом мы будем называть «продуктом». Да, не смейся.
  • Твой домик «лишь бы въехать» — это MVP, «минимальный жизнеспособный продукт». Дом с пристройкой, дом с верандой — это инкременты, новые функции.
  • Ты — Product Owner, отвечаешь за то, каким именно будет дом. Жена — стейкхолдер, заинтересованная сторона. Ее мнение важно, в этом доме ей придется жить.
  • Список будущих функций (пристройка, веранда, второй этаж, хорошая крыша и все, что вам нужно) —  это бэклог, описание необходимой работы.
  • Когда вы с женой решаете, что делать дальше, вы проводите бэклог-груминг, заботитесь о том, чтобы спланировать работу.

А теперь расскажи, как ты строил бы дом.

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

Отлично, пиши:

  • ​Твой брат и дядя Вова — команда разработчиков дома-продукта. Их сила в том, что они могут заменять друг друга. Они —  «Т-образные люди», то есть что-то умеют хорошо, а в остальном готовы помогать друг другу.
  • Ваша соседка — Scrum-мастер. Ее задача — поддерживать работоспособность команды.

А как бы ты следил, чтобы они делали все правильно? Как узнавал бы, какие стройматериалы им нужны?

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

Так вот, дедушка:

  • Разговор в начале недели — это планинг, определение и оценка предстоящей работы.
  • Ваш утренний кофе — это стендап, ежедневная планерка.
  • Напиться и поругать друг друга значит провести ретроспективу, оценить, что и как было сделано.

А как же жена? Ей тоже интересно поучаствовать в строительстве дома.

Я привозил бы жену раз в две недели. Вдруг и вправду что-то не так.

Cмотри, что получается:

  • Двухнедельные промежутки между приездами жены — это длина спринта, периода вашей работы над домом-продуктом.
  • Приезд жены — это показы. Лучше планировать работу в спринте так, чтобы каждый раз было что показать.
  • Новоселье — запуск продукта.

Дедушка, ты только что заново изобрел Agile и большую часть Scrum. Когда нужно сделать что-то быстро и дешево, люди интуитивно изобретают гибкие вещи и методы. Так часто происходило и в прошлом.

Историческая справка для дедушки

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

В первый год они строили себе маленькое жилище из дерна ( слоя почвы с корнями растений) с печкой из камней и грязи. Это был их минимально жизнеспособный продукт (MVP). На второй год они сооружали себе домик из грубо отесанных бревен (вторая версия продукта). И только на третий год обычно начиналось строительство настоящего дома.

1883 год, штат Небраска. Дом из дерна, бык вместо собаки
1883 год, штат Небраска. Дом из дерна, бык вместо собаки

У жителей фавел в Латинской Америке времени побольше, зимой тепло. Но они крайне ограничены в деньгах.

Они строят свою комнату из больших кирпичей почти по Agile. На сколько хватит купленных кирпичей — столько стен и ставят. Потом достраивают, ставят окна, накрывают крышу, а иногда штукатурят и красят. Когда семья растет, пристраивают следующую комнату.

Фавелы как иллюстрация интуитивности гибких методологий
Фавелы как иллюстрация интуитивности гибких методологий

Когда у программистов было мало времени и средств, они тоже пришли к гибкости и назвали такой подход Agile («гибкий», «подвижный»).

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

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

Зачем это нужно

Дедушка, представь, если бы у тебя было достаточно денег и времени на строительство большого дома?

Тогда зачем мне так напрягаться. Я нанял бы строительную компанию и заказал дом «под ключ». Мы разработали бы проект, подписали договор. Я приезжал бы на стройку больше из любопытства, ведь большое строительство идет точно по плану.

Но ведь строить большой дом нужно дольше. Тогда ты не смог бы поселиться в сентябре.

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

А если бы ты не был уверен, что хочешь жить в доме, а не в квартире?

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

Выводы для внука

Дедушка все понял. А внук?

  1. Принципы Agile интуитивны. Если ресурсы ограничены, все мы становимся более гибкими. Я бы добавила к Agile-манифесту один пункт: «Включая Agile, сохраняйте здравый смысл».
  2. Экспериментальному проекту нужен Agile-подход. Если мы не знаем, нужен ли нам продукт или какой он должен быть, лучше строить его по принципам Agile. Даже если есть ресурсы.
  3. Если ресурсов достаточно, а мы точно знаем, чего хотим, то нужно забыть про MVP и Agile и просто строить по рецептам хорошего проектного менеджмента. В таких условиях мы будем переплачивать за Agile, а не экономить. Мы не сможем оптимизировать сроки и расходы по проекту: будем строить три года вместо шести месяцев и заплатим за две крыши вместо одной.
2525
28 комментариев
Комментарий удалён модератором

Комментарий недоступен

2
Ответить

Жду материал "Варим борщ по Agile" для девули-маркетолога.

4
Ответить

У меня с Аджайлом проблема.
Всю жизнь делали проекты (как оказалось по Аджайлу), просто из здравого смысла не понимаю, а как оно может по-другому строиться?

Подскажите плс, а что я пропустил и как по-другому то делать проекты если у тебя свои деньги, а не анлимит от Газпрома какого-то?

4
Ответить

Я не особо силен в Аджайл или Скрам. Все это интересно, но чересчур заморочено и называют казалось бы обыкновенные вещи новыми терминами, указывая на то что ранее все делалось через ж*пу, а тут "по-новому" с заправленными штанами.

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

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

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

Таким образом я вывел производство приборов с 50 штук/месяц до 300 штук. Сроки производства варьировались от 6 месяцев до максимально двухнедельных.

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

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

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

Агил/Скрам надо пробовать и брать лучшее и эффективное под свой проект.

2
Ответить