{"id":9280,"title":"\u0422\u0435\u043b\u0435\u043f\u043e\u0440\u0442\u0430\u0446\u0438\u044f \u0440\u0435\u043a\u043b\u0430\u043c\u043d\u044b\u0445 \u043a\u0430\u043c\u043f\u0430\u043d\u0438\u0439 \u0438\u0437 \u00ab\u042f\u043d\u0434\u0435\u043a\u0441\u0430\u00bb \u0432 Google","url":"\/redirect?component=advertising&id=9280&url=https:\/\/vc.ru\/promo\/321806-kak-ne-zamorachivatsya-s-reklamnoy-kampaniey-i-bystro-nastroit-ee-v-google-obyasnyaem-v-5-50-i-500-slovah&placeBit=1&hash=99a73b9041aba100376a41bce39d118cf714c283ce1c8288a963bcb51cdcdade","isPaidAndBannersEnabled":false}

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

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

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

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

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

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

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

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

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

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

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

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

А потом?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Развернуть ветку

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

Развернуть ветку
Коммунистический чувак

Комментарий удален по просьбе пользователя

Ответить
2
Развернуть ветку

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

Развернуть ветку
Коммунистический чувак

Комментарий удален по просьбе пользователя

Ответить
–3
Развернуть ветку

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

Развернуть ветку
Коммунистический чувак

Комментарий удален по просьбе пользователя

Ответить
0
Развернуть ветку
Виталий Бирюков

Возьмите меня джуном

Ответить
0
Развернуть ветку
Max Leontiev

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

Ответить
4
Развернуть ветку
XageRu

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

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

Ответить
4
Развернуть ветку

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

Развернуть ветку
Yan Varskii

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

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

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

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

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

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

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

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

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

Ответить
2
Развернуть ветку
Коммунистический чувак

Комментарий удален по просьбе пользователя

Ответить
0
Развернуть ветку
Yan Varskii

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

Пробует каждый в меру заинтересованности и потребности.

Ответить
0
Развернуть ветку
Коммунистический чувак

Комментарий удален по просьбе пользователя

Ответить
0
Развернуть ветку
Сергей Зубов

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

Ответить
2
Развернуть ветку
Alexander Kuzmin

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

Ответить
0
Развернуть ветку
Prolis Labkk

@Голь на выдумки хитра. Вы предпочтете, чтобы вам загородный дом построили за год и сто денег, или попросите копать пока фундамент на сколько денег хватило?

Ответить
1
Развернуть ветку

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

Развернуть ветку
Alexander Pavlyut

Хороший пример полного непонимания сути и фактического его понимание в рф - аджайл это по понятиям.

Важнее != отсутсвие документации. То есть - нехер ссылаться на заведомо тупую запись требования которая фактически противоречива или блокирует/портит/замедляет работу/искажает рабочий продукт, что выявляется на "регулярных проверках" (ретроспективах) где идет моментальная корректировка докумнтации в верную сторону и работа от точки проявления дефекта реальностью в этой документации.

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

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

Именно в этом и заключается слово "важнее" - то есть приоритетнее, но не отсутсвие живых докуменов по - а) концепции б) архитектурынм требованиям в) рабочим проектированиям г) отчетам по факту прорерок (Это было норм, это хуйня - выпиливаем, потому то и потому то, число подпись) д) фактом "ввода в эксплуатацию" релиза актами / церемониями и прочими формальностями.

Нахуй понятия - весь мир держится на бумагах и фиксациях информации вне голов людей у которых семь пятниц на неделе.

Ответить
0
Развернуть ветку

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

Развернуть ветку
Alexander Pavlyut

В общем аджайл это когда работа идёт "по понятиям", а неаджайл это работа "по закону", "по бумажке".

бумажка - это документ.

Ваш ход коллега.

Ответить
0
Развернуть ветку

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

Развернуть ветку
Alexander Pavlyut

у меня значит

Спасибо что приоткрыли свой личный тезаурус.

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

К этому в дополнение погуглите про управление требованиями.

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

Где-то это прокатывает (много где) - и ваш аджайл (это вы так бардак и неорганизованные работы по созданию систем называете) встает в копейку не вам а тому кто это "заказывает".

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

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

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

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

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

Именно крепким юридическим и экономическим пограничным условиям и обстоятельствам в развитом мире обязан aglie - посмотрите как организован труд разработчиков на родине agile на западе и тут, и ответьте себе на вопрос есть ли разница в этой организации труда.

А выдавать бардак и отсутствтие мыследеятельности и анализа (результатами которой всегда являюстя строгие документы как основы для начала и завершения любых работ) за agile (с вашим личным тезаурусом что такое документ) не стоит - не надо так ))

Ответить
2
Развернуть ветку
Коммунистический чувак

Комментарий удален по просьбе пользователя

Ответить
1
Развернуть ветку
Alexander Pavlyut
Ответить
0
Развернуть ветку
Roman

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

Ответить
1
Развернуть ветку
WikiExpert

Не зря часто пишут что Эджайл не нужен для крупных и ресурсодостаточных корпораций, там надо РМ.
Но тем не менее судя по прессе все от Сбера и т.п. ломанулись в Эджайл.
Хотя у некоторых топ банков и РМ-а то не было нормального, точнее никакого не было.... :-)
зы: у Сбера был..

Ответить
0
Развернуть ветку
Victor Andreev

Про Agile всё понятно. Но не везде приживается... У меня в подразделении Kanban. Так мало того весь HR-блок на него перетащил. Красота. Как-нибудь напишу как)

Ответить
0
Развернуть ветку
Владислав Воробьёв

То чувство, когда люди( в том числе и комментаторы выше), вообще не понимаю что такое Agile.
Agile - это 4 ценности и 12 принципов. По сути, это культура. Скрам\Канбан - это фреймворки, которые накладываются на инкрементно-итерационную модель разработки. Теоретически, у Вас может быть в компании Скрам, но не быть Agile-культуры.

Ответить
0
Развернуть ветку
Фомушка Фома

А можно я попробую объяснить:
Чтобы было хорошо, нужно делать все правильно. это долго, заумно и дорого, но всем понятно.
Кто-то решил делать не сильно хорошо, но зато не надо соблюдать правила, учиться, да еще быстрее и дешевле получается.
Но кто смекалистый решил заверить, что те кто по правилам делают, на самом деле не все по правилам делают и получается у них не так и хорошо. Так что наше неплохо и дешево можно продавать задорого.
И вот смотрит теперь Заказчик и думает, что эти agile должны сделать так же все классно как и старые умные дорогие. Но только это не так. раньше заказчик понимал ответственность своего выбора. В примере про подоконник, он заранее подписывался что он будет выступать/вровень. А теперь его зачем-то убедили, что эту проблему можно решить потом.
А еще все страдают из-за MVP, потому что у любого продукта есть потолок функциональности. Но в сегодняшних рамках всем приходиться делать все новое и новое и говорить что мы тока в начале роста. Так и получаем новый мобильный скайп и прочее.
Потребитель всегда ждет полный готовый продукт за бесплатно. Остальное дело маркетинга в умении договориться с потребителем.

Ответить
0
Развернуть ветку
Федор Пинега

Статья понравилась.
Одним предложением я бы это сказал так: "в неизвестных или непредсказуемо меняющихся условиях нужно отходить от жесткого PM и включать демократические модели управления".

Ответить
0
Развернуть ветку
Alexander Korchagin

"Принцип «су-ха-ри» негласно запрещает использовать здравый смысл" это ведь верно только на первом этапе.

Ответить
0
Развернуть ветку
Сергей Лавренев

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

Ответить
–1
Развернуть ветку
Pavel Popov

что вы бля все несете??? делайте свое дело качественно, и да прибудет с вами ваш дзен.

Ответить
–1
Развернуть ветку
Читать все 27 комментариев
Лидерские качества. 30 полезных материалов для их развития

Наверняка вы не раз слышали фразу: «Саша — прирожденный лидер». Но разве лидерство «дается» с рождения? Конечно, нет. Как и многие навыки и soft skills, лидерские качества можно в себе развить. В этой статье я расскажу, с чего начать путь к лидерству, а еще поделюсь полезными материалами.

Проект Федерации креативных индустрий Creative Russia Map получил Премию Рунета
Сайт Tor заблокировали в России после публикации обращения с призывом к пользователям поднять у себя серверы Статьи редакции

Команда сообщила о начале блокировки всей сети с 1 декабря.

Увлечение самолётами, которое переросло в бизнес

Предприниматель из Волгограда производит и продаёт по всему миру симуляторы дополненной реальности.

«Купи сейчас, плати потом»: новая классика или мимолетная мода

Сервис рассрочек рассказывает о новом финтех-тренде.

Потерять канал в телеграме и заодно репутацию? Это легче, чем вы думаете

Всем привет! Меня зовут Альберт Базалеев, я эксперт в сфере информационной безопасности бизнеса. Одно из моих направлений — проект Варежка, это софт, который защищает telegram-каналы и корпоративные telegram-аккаунты от злоумышленников. Сегодня расскажу, какие «дырки» есть в telegram-каналах (которые так любят пиарить здесь на vc.ru) и к чему…

Вкратце: что показал «Яндекс» на презентации YaC 2021 Статьи редакции

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

Устройства «Яндекса»
Статья дополняется
Как сделать работу компаний и фрилансеров удобной

С помощью сервиса «Рокет Ворк».

Apple подписала тайное соглашение с Китаем на $275 млрд взамен на послабления регуляторов — The Information Статьи редакции

Компания пока никак не прокомментировала расследование издания.

Ускорение на пути к будущему электромобильности и устойчивому развитию: Нико Росберг стал амбассадором Jungheinrich

Концерн Jungheinrich и Нико Росберг (Nico Erik Rosberg) объединят свои усилия в поддержку развития экологически чистой мобильности. Предприниматель в сфере экологичных технологических решений, потомственный немецкий автогонщик и чемпион мира Формулы-1 2016 года, Нико становится официальным амбассадором бренда Jungheinrich — ведущего мирового…

«Яндекс» представил «Станцию» второго поколения с новым дизайном и улучшенным звуком Статьи редакции

Колонка поступит в продажу в первой половине 2022 года.

null