Как объяснить бабушке что такое agile

Как объяснить бабушке, что такое Agile за 15 минут с картинками

«Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.»
— закон Хофштадтера

Самый просматриваемый ролик на YouTube по теме agile. 744 625 просмотров на момент публикации данной статьи. Легкий стиль изложения, картинки и всего 15 минут — лучшее что я видел. TED отдыхает.

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

Это заинтересованные лица. Они будут использовать продукт, поддерживать его или будут как-то еще вовлечены в разработку.

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

У заинтересованных лиц много идей, и Пэт помогает сделать из идей пользовательские истории.

Это команда разработчиков. Те, кто будет строить рабочую систему.

Пропускная способность

Так как команда использует гибкую методологию разработки, они не копят все эти истории до большого релиза, наоборот, они выпускают их сразу и как можно чаще. Обычно они выпускают 4-6 пользовательских историй в неделю. Это их пропускная способность. Ее очень просто измерить — количество пользовательских историй за 7 дней.

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

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

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

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

Что произойдет, если мы будем делать все, о чем они нас просят? У нас будет перегруз.

Допустим, команда возьмется сделать 10 новых историй за эту неделю.Если на входе 10 а на выходе 4-6, то команда будет перегружена. Будет спешить, переключаться между задачами, терять мотивацию, в итоге снижается производительность и качество. Это заведомо проигрышная стратегия.

Scrum и XP в этом случае используют метод “вчерашняя погода”. Команда говорит: “За последнее время мы делали 4-6 фич в неделю, какие 4-6 фич мы будем делать на следующей неделе?”

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

Kanban рекомендует ограничиться несколькими задачами — WIP limit. Допустим команда решает, что 5 — это приемлемое количество пользовательских историй, над которыми они смогут работать одновременно без перегруза, не перескакивая с одной на другую.

Оба эти подхода хорошо работают и оба они создают очередь задач, которые в Scrum называется Backlog, или приоритезированный список задач.

Этой очередью тоже необходимо управлять.Если заинтересованные лица запрашивают 10 историй в неделю, а команда реализует 4-6 историй, то эта очередь будет становиться все больше и больше. И скоро ваш Backlog будет расписан на полгода вперед. То есть одна история будет ждать выхода 6 месяцев.

Есть только один способ держать список задач под контролем — это слово “нет”

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

Сказать “да” — легко. Но более важная задача — решать, что не надо делать и нести за это ответственность. Владелец продукта так же определяет последовательность, что делаем сейчас, а что позже. Это сложная работа и выполнять ее следует вместе с командой разработки и минимум одним заинтересованным лицом.

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

Принятие решений

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

Как соотносится размер истории и ее ценность? Никак. Больше не значит лучше. Ценность и сложность задачи — вот что помогает Пэт расставлять приоритеты.

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

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

Одной приоритезации недостаточно. Чтобы выпускать истории быстро и часто, нужно разбивать на кусочки, которые можно сделать за пару дней. Мы хотим чтобы в начале воронки были маленькие и четкие истории а в конце — большие и неопределенные. Вовремя делать такую разбивку мы можем воспользоваться нашими последними открытиями относительно продукта и нужд пользователя. Это все называется очистка Backlogа.

Пэт проводит встречу по очистке Backlogа каждую среду с 11 до 12. Обычно на ней собирается вся команда и иногда несколько заинтересованных лиц. Содержание встреч бывает разным. Фокусировка на оценке, на разбивке историй, на критериях приемки.

Владелец ИТ-продукта должен постоянно со всеми общаться

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

Баланс между сложностью разработки и ценностью пользовательской истории

На ранней стадии балансу угрожает неопределенность и сразу несколько рисков.

Риски

Бизнес риск: «Правильную ли вещь мы делаем?»

Социальный риск: «Сможем ли мы сделать то что нужно?»

Технический риск: «Будет ли проект работать на данной платформе?»

Риски со стоимостью и сроками реализации: «Успеем ли и хватит ли денег?»

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

Компромисс между ценностями знания и ценностями для клиента

С точки зрения заказчика кривая выглядит вот так:

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

Компромисс между краткосрочным и долгосрочным мышлением

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

Делать правильные вещи, делать вещи правильно или делать быстро?

В идеале — все три одновременно, но в реальности приходится выбирать.

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

Мы делаем быстро прототип продукта. Для краткосрочной перспективы это неплохо. В долгосрочной — мы получаем технический риск. И скорость разработки снизится до нуля.

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

Между ролями в Scrum существует здоровое противостояние

Владелец продукта фокусируется на построении правильных вещей. Команда фокусируется на том, чтобы строить вещи правильно. Scrum-мастер или agile-тренер фокусируется на сокращении цикла обратной связи.

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

Компромисс между разработкой нового продукта и улучшением старого

Продукт никогда не может быть полностью завершен, потому что ему постоянно нужны изменения. Когда команда начинает работу над новым продуктом, что происходит со старым? Передача продукта от одной команды к другой — очень затратно и рискованно. Обычно команда поддерживает старый продукт, разрабатывая новый. Поэтому скорее понятие “Backlog” относится не к продукту а к команде. Backlog — это список вещей, которые хочет владелец продукта от команды. И набор историй для разных продуктов. Владельце продукта нужно постоянно выбирать актуальные для реализации.

График уничтожения историй

Время от времени, заинтересованные лица будут спрашивать у Пэт: “Когда выпустят мою фичу?” или “Сколько фич выпустят к рождеству?”. Владелец продукта должен уметь управлять ожиданиями пользователя. И управлять ожиданиями реалистично.

Два тренда — оптимистичный и пессимистичный (можно на глаз). Расстояние между трендами показывает насколько нестабильна скорость работы команды. Со временем эти тренды стабилизируются и конус неопределенности будет уменьшаться.

Предположим, заинтересованное лицо спрашивает, когда вот эта фича будет сделана?

Это вопрос с фиксированным содержанием и неопределенным сроком. Для ответа Пэт использует две линии тренда. Ответ — в апреле или мае.

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

Заинтересованное лицо спрашивает :«Успеем ли мы сделать вот эти фичи к рождеству?» Это вопрос с фиксированными временными рамками и фиксированным содержанием. Ориентируясь на тренды, Пэт отвечает: «Нет». Добавляя: «К рождеству мы успеем сделать столько, а вот столько времени нам понадобится чтобы завершить всю эту работу полностью.»

Обычно лучше уменьшать содержимое проекта, чем увеличивать время. Если мы уменьшаем содержание, у нас будет возможность отодвинуть сроки. Мы можем выпустить кое-что здесь, а остальное — позже.

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

Несколько команд

Пусть у нас несколько владельцев продукта и несколько команд. Модель та же — управление пропускной способностью, коммуникация с заинтересованными лицами, принятие решений по поводу отклонения пользовательских историй. Скорость равна сумме скоростей всех команд. Прогнозирование может быть общее или по каждой команде. У владельцев продуктов появляется дополнительная задача — общение с другими владельцами продукта. Нужно организовать работу над Backlogами так, чтобы минимизировать зависимости и обеспечить синхронизацию. В больших проектах требуется Главный владелец продукта (CPO), чтобы синхронизировать всех остальных.

Источник

«Представьте, что праздничный ужин — это ваш проект»: как объяснить бабушке, что такое Agile

Рассказывает Юлия Селюкова из образовательной онлайн-платформы «Лифт в будущее»

Ag­ile — ме­то­ди­ка гиб­ко­го управ­ле­ния про­ек­та­ми, ко­то­рая по­мо­га­ет быст­ро до­би­рать­ся от стар­то­вой точ­ки до ито­го­во­го ре­зуль­та­та. Суть в том, что­бы мак­си­маль­но эф­фек­тив­но ис­поль­зо­вать вре­мя и силы ко­ман­ды, раз­ло­жив весь про­цесс на эта­пы. Из­на­чаль­но эта ме­то­ди­ка при­ме­ня­лась для раз­ра­бот­ки про­грамм­но­го обес­пе­че­ния, но се­го­дня успеш­но ис­поль­зу­ет­ся в лю­бых ко­манд­ных про­ек­тах. По­дроб­но о том, как ра­бо­та­ет Ag­ile, рас­ска­зы­ва­ет Юлия Се­лю­ко­ва — со­вет­ник об­ра­зо­ва­тель­ных про­грамм в об­ра­зо­ва­тель­ной он­лайн-плат­фор­ме «Лифт в бу­ду­щее».

Уди­ви­тель­но, но «но­вой и со­вре­мен­ной» ме­то­ди­ке Ag­ile око­ло 50 лет. В 70-х уче­ный Уин­стон Ройс из США за­явил, что про­цесс раз­ра­бот­ки ПО не мо­жет быть си­сте­ма­ти­зи­ро­ван так же, как про­цесс сбор­ки ав­то­мо­би­ля на за­во­де. Дело в том, что раз­ра­бот­ка ПО не все­гда про­ис­хо­дит ли­ней­но — в ней мо­гут воз­ни­кать вне­зап­ные кор­рек­ти­ров­ки (ме­ня­ют­ся ожи­да­ния поль­зо­ва­те­лей или тех­но­ло­гии ра­бо­ты). Все они при­во­дят к тому, что ра­бо­чие пла­ны при­хо­дит­ся ме­нять «на ходу», а это весь­ма бо­лез­нен­но для про­ек­та. В деле сбор­ки ав­то­мо­би­лей та­ко­го быть не мо­жет: эта­пы и ре­зуль­та­ты ра­бо­ты все­гда чет­ко опре­де­ле­ны и не ме­ня­ют­ся в про­цес­се.

Мысль о том, что жи­вой и гиб­кий про­ект тре­бу­ет мак­си­маль­но адап­тив­но­го и гиб­ко­го управ­ле­ния, ста­ла ос­но­вой прин­ци­пов Ag­ile. Се­го­дня эти прин­ци­пы под­хо­дят для управ­ле­ния лю­бы­ми жи­вы­ми про­ек­та­ми, над ко­то­ры­ми тру­дят­ся ко­ман­ды.

Прин­ци­пы Ag­ile

В 2001 году в США (Юта) раз­ра­бот­чи­ки со­зда­ли офи­ци­аль­ный мани­фест Ag­ile.

Они вы­де­ли­ли 4 идеи, на ко­то­рых ос­но­ва­на эта ме­то­ди­ка управ­ле­ния про­ек­та­ми.

1 идея. При­о­ри­тет ко­манд­но­го об­суж­де­ния над про­цес­сом и ин­стру­мен­та­ми.

2 идея. При­о­ри­тет ра­бо­че­го ре­зуль­та­та над до­ку­мен­та­ци­ей.

3 идея. При­о­ри­тет вза­и­мо­дей­ствия с кли­ен­том, а не об­суж­де­ния усло­вий с ним.

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

4 идея. Го­тов­ность ме­нять план, а не сле­до­вать из­на­чаль­ным на­ра­бот­кам.

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

Как ра­бо­та­ет Ag­ile

Как функ­ци­о­ни­ру­ет гиб­кая си­сте­ма управ­ле­ния на прак­ти­ке? План ра­бот все-таки со­став­ля­ет­ся: ра­бо­чий про­цесс раз­би­ва­ют на при­мер­но рав­но­знач­ные от­рез­ки вре­ме­ни. По­сле каж­до­го эта­па оце­ни­ва­ет­ся про­ме­жу­точ­ный ре­зуль­тат. Если нуж­но вне­сти из­ме­не­ния, это де­ла­ют до на­ча­ла сле­ду­ю­ще­го эта­па. Вот про­стой при­мер при­ме­не­ния Ag­ile в по­все­днев­ной жиз­ни:

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

Но мож­но при­ме­нить прин­ци­пы Ag­ile. И то­гда, что­бы при­го­то­вить празд­нич­ный обед, необ­хо­ди­мо раз­бить про­цесс на эта­пы:

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

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

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

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

Как объ­яс­нить ба­буш­ке, что та­кое Ag­ile?

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

Есть непло­хие кур­сы по Ag­ile от он­лайн-уни­вер­си­те­тов вро­де Нето­ло­гии и Скилл­бокс, у он­лайн-плат­фор­мы «Лифт в бу­ду­щее» так­же есть та­кой курс. По этой теме на­пи­са­но нема­ло книг, в ос­нов­ном это аме­ри­кан­ские ав­то­ры-прак­ти­ки. Вот что бу­дет по­лез­но по­чи­тать:

Это не весь спи­сок, мож­но (и нуж­но!) ис­кать еще. Од­на­ко чи­тать и слу­шать недо­ста­точ­но. Для того что­бы по­стро­ить це­лост­ное пред­став­ле­ние о том, что та­кое Ag­ile, и успеш­но внед­рить эту фи­ло­со­фию в еже­днев­ную ру­ти­ну, ну­жен план по­лу­че­ния зна­ний. На­при­мер, сле­ду­ю­щие пунк­ты:

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

Эти зна­ния при­но­сят гран­ди­оз­ную поль­зу ме­не­дже­рам и управ­лен­цам лю­бо­го зве­на, по­мо­га­ют вы­ве­сти ра­бо­ту ко­ман­ды и ре­зуль­та­ты про­ек­тов на но­вый уро­вень. Но, по­ми­мо это­го, Ag­ile по­дой­дет всем, кто хо­чет струк­ту­ри­ро­вать свою жизнь и на­ве­сти по­ря­док в обыч­ных бы­то­вых про­цес­сах.

Все са­мое важ­ное и ин­те­рес­ное со­би­ра­ем в на­шем Telegram

Источник

Как объяснить дедушке эджайл и скрам за 5 минут без картинок. И самому лучше понять

Пост об интуитивности эджайла

Aug 18, 2017 · 6 min read

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

В эджайле, если у меня возникал бытовой вопрос и приходило решение, то каждый раз я себе говорила (а если не я, то команда):

Ты всего лишь прочитала три книги на эту тему, послушала пару двухдневных семинаров, прошла эджайл-кемп, посмотрела несколько видео и провела несколько стратсессий с эджайл-коучами. Ну и пару лет поварилась в скрам-процессе (в «недо»! недо-скрам-процессе!).

Очевидно же, Наташа, что — ха-ха — да ты что ты можешь понимать. Не смей искать ответ на свой вопрос. Записывай и жди консультации с эджайл-коучем.»

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

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

Я р ешила, что позволю себе такую наглость, как написать пост о том, что эджайл и скрам — довольно интуитивные штуки, которые важно вовремя включать. И вовремя выключать. Once again:

Итак, зовите дедушку и поехали.

Объясняем дедушке эджайл

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

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

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

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

Дом мы будем называть « продукт». Да-да, не смейся.

Твой домик «лишь бы въехать» — это MVP. То есть минимальный жизнеспособный продукт.

Дом с пристройкой, дом с верандой — это инкременты.

Ты — продакт оунер, отвечаешь за то, каким именно будет дом.

Жена — стейкхолдер, ее мнение важно, ей в доме жить.

Список из пристройки, веранды, второго этажа, хорошей крыши и что вы еще захотите — это беклог.

Когда вы с женой сидите и решаете, что делать, вы делаете беклог груминг.

— Теперь расскажи, дедуля, как бы ты дом строил.

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

Твой брат и дядя Вова — команда разработчиков дома.

Их сила в том, что они могут друг друга заменять. То есть они — ти-шейпт-пипл (T-shaped people) — что-то умеют хорошо, но в остальном готовы друг другу помогать.

— А как бы ты следил, чтобы они делали все правильно? И чтобы у них были стройматериалы?

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

Разговор в начале недели — это планинг.

Ваш утренний кофе — это стендап.

Напиться и поругаться значит провести ретроспективу.

— Дедушка, а как же жена? Ей же тоже интересно было бы, наверное, участвовать в строительстве дома.

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

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

Двухнедельные промежутки между приездами жены — это длина вашего спринта.

Когда жена приезжает — это показы. Лучше планировать спринт так, чтобы каждый раз было что ей показать.

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

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

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

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

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

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

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

Нужен — не нужен…

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

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

— Но ведь строить сразу большой дом — это дольше. Тогда ты не смог бы заехать в сентябре!

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

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

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

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

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

1.Принципы эджайла интуитивны. Если ресурсы ограничены, все мы становимся более гибкими. Нет денег или времени—нам нужно стать эджайл. Я бы добавила к эджайл-манифесту один пункт: «Здравый смысл важнее всего, включая эджайл».

2. Если мы не знаем, нужен ли нам продукт или какой он должен быть, лучше строить его по принципам эджайла. Даже если есть ресурсы. Экспериментальному проекту нужен эджайл-подход.

3. Если ресурс есть и мы знаем, что продукт нам нужен и знаем в каком виде — забываем про MVP и эджайл и просто строим. Рецепт — хороший проектный менеджмент. В этой ситуации на эджайл-подходе мы будем переплачивать, а не экономить — не сможем оптимизировать сроки (будем строить 3 года вместо 6 месяцев) и расходы по проекту (заплатим за две крыши вместо одной).

P.S. У истории про любопытного дедушку появилось продолжение: Как объяснить дедушке веб-аналитику за 5 минут с картинками.

→ Как следить за Бабаевой и Школой ченджеров

Меня зовут Наташа Бабаева. Я пишу про маркетинг, продукт и инновации. В Facebook лично, в Telegram кратко, на Медиум детально.

Помогаю прокачивать навыки инноватора в Школе ченджеров. В чем идея? / Подписаться→

Копаю тему инноваций в платной рассылке «Бабаева копает инновации». В чем идея? / Подписаться→

Запустила Change Basics, курс-сериал о пути неинноватора в инновациях.

Источник