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

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

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

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

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

«Стоп, Наташа! Не надо думать.

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

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

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

Фото про подозрительность. Источник.

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

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

И вовремя выключать.

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

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

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

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

— А потом?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Соседка у вас была бы скрам-мастер. Ее задача — поддерживать боевой дух команды.

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

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

— Так вот, дедуля:

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

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

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

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

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

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

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

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

Новоселье — запуск.

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

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

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

Секреты Технологии Выбора | Agile для дедушки: гибкие методологии на простом примере «

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

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

Стоп, говорю я себе. Не надо думать. Прочитано аж три книги на эту тему, послушана пара двухдневных семинаров, окончен Agile-курс, посмотрено несколько видео и проведено несколько стратегических сессий с Agile-тренерами.  Да что ты можешь понимать. Не смей искать ответ на свой вопрос. Записывайся и жди консультации с 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, а не экономить. Мы не сможем оптимизировать сроки и расходы по проекту: будем строить три года вместо шести месяцев и заплатим за две крыши вместо одной.

Источник: https://vc.ru/p/agile-for-aged

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

   1 голос
Средняя оценка: 5 из 5

Как объяснить бабушке, что такое 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 Product Ownership in a nutshell

видео на английском

видео на русском

Agile вне ИТ или как построить машину, пользуясь Agile-принципами

Один из самых популярных вопросов, который мне задают на тренингах — как применять Agile-методы в не IT-проектах.  Разработка нового или развитие существующего программного обеспечения всегда была областью высокой неопределенности. Тут сложно рассчитывать на то, что даже типовой проект пойдет точь-в-точь как предыдущие. Вопрос не в том, будут ли изменения в первоначальных требованиях, а скорее в том, как быстро они появятся.  В тоже время, многие другие проекты условно сводятся к “производству”: изготавливаются почти одинаковые продукты по типовому процессу.  Эти проекты условно-линейные и полностью поддаются планированию.

И все же люди из обычного мира бизнеса часто сравнивают разработку ПО и автомобильный конвейер. Иногда на моем тренинге или после доклада слегка наивный слушатель заявляет: “Мы же не можем собирать машину по частям: сначала колеса, потом двигатель, потом капот”. Подобное заблуждение возникло из-за подмены понятия конвейера, где идет сборка однообразных моделей тех же машин, и работы дизайнерского бюро. Разработка ПО — проблема из области дизайна, а не производства.

Чтобы окончательно развеять заблуждение относительно автомобилей, давайте посмотрим на проект разработки автомобиля с использованием Agile-принципов. Я имею ввиду проект WIKISPEED. Он участвовал в конкурсе суперэкономичных автомобилей, как автомобиль пригодный для езды по официальным дорогам, который потребляет два литра на 100 километров.  До этого попытки собрать подобный автомобиль велись на протяжении уже десятка лет. Это должен быть не просто некий космический болид, где пилот лежа проедет по идеально ровной пустыне. Речь идет о машине, в которой мы с вами можем ездить по городу и автотрассам. Машине, у которой расход на 100 км чуть больше 2-х литров.

В своем интервью автор проекта  Джо Джастис (Joe Justice) рассказывает, что с самого первого места работы он работал менеджером в Agile-командах. Для него это был, по сути, образ мысли и стиль жизни. Джастису довелось работать над разработкой ПО в маленьких и больших распределенных командах. Опять же, перед ним НЕ стояла задача сделать “Agile-машину” или “Lean-машину”. У него была цель создать ультра-эффективный автомобиль с помощью команды волонтеров, распределенной по всему миру. И уже как лидер и менеджер Джо Джастис выбирал методологию, которая помогла группе работать результативно.

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

Итак, команда взялась собрать машину. Участники знали общие требования: обычная комплектация машины, комфортная для каждого. Также они знали дополнительные требования — необходимое для “быть пригодным к езде по официальным дорогам”.

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

Это то, что я называю «Agile продукта». Для меня этот термин обобщает все методы и принципы принятия решений. Все, что надо делать дальше, чтобы приносить определенную пользу. Она может выражаться как в результате, потребляемом пользователями, так и в знании или прояснении рискованных областей. Если интересно, погуглите на темы “Lean Design Thinking” и “Agile Product Design”. Та же, популярная нынче, концепция Lean Startup большей частью адресует эту область.   

Одной из проблем проекта WIKISPEED было то, что команда распределена. Десятилетия назад говорил о том, что Agile методы лучше работают для команд, сидящих рядом. За последнее время появилось много инструментов, которые могут обеспечить команде общую среду общения: YouTube для записи демонстрации, Google Docs, онлайн доски задач, сервис конференц-звонков и, немаловажное, общая email рассылка на команду. Эти инструменты позволили распределенной команде волонтеров чувствовать себя так же, как Scrum команды, сидящие в одной комнате.

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

Это то, что я называю “Agile людей”. Принципы самоорганизации, совместная работа группы над одной целью итерации, общая ответственность за результат — просто неотъемлемые части Agile-методов и самой философии “гибкости” и сотрудничества. Многие современные книги о менеджменте, мотивации, лидерстве и командообразовании говорят о том как использовать эти принципы для достижения максимума в работе “креативных команд”. Если покопаться, то термин “Intelectual workers” ввел еще дедушка Питер Друкер. В современном мире большинство работ относится к этому типу, а не только разработка ПО.

Ну и понятно, что учитывая опыт главного менеджера-организатора, все команды WIKISPEED работали по Scrum, адаптированному для их ситуации. У них были спринты-итерации и небольшие команды, которые фокусировались на улучшении тех или иных параметров автомобиля. В течение итерации команды ежедневно синхронизировались и  активно общались. Как правило в режиме “информация для всех”. А в конце итерации собиралась новая версия автомобиля. Члены команды вместе смотрели на полученный результат и обсуждали, что можно улучшить как в продукте, так и в их способе работы над ним.

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

Если оглянуться и присмотреться, то сегодня многие компании, далекие от разработки ПО, применяют принципы и философию Agile. И дело не только в примере об автомобиле. Кроме разработки автомобиля, я знаю много других случаев: написание  сценария телесериала, ведение юридической практики, оказание контент-услуг. Agile вне ИТ активно применяется компаниями. Особенно когда речь идет о людях, решениях и процессах. Все это позволяет командам быть более гибкими и лучше достигать целей.

Понравилось это:

Нравится Загрузка…

Похожие записи

Как рассказать что такое Agile на заводе? Agile методология.

18 Oct 2017

Если заглянуть в реальную российскую компанию старше 30 лет и больше чем с тысячью сотрудников и произнести слово Agile, то реакция будет как минимум настороженная. Люди там уже слышали истории похожие на «Как рассказать бабушке» или «Как рассказать дедушке» и посмотрели все выступления Грефа, получили с десяток предложений внедрить гибкость за неделю, кто-то из сотрудников даже поработал год со Scrum, но остается один вопрос:

«Что с этим нам делать то, у нас из программирования только сайт?»

В итоге примерно для 100% компаний Agile смахивает на шарлатанство.

Но вот парадокс — в мире 77% компаний*, использующих Agile в проектах, занимаются совсем не разработкой программного обеспечения.

*Из большого ежегодного опроса компаний от VersionOne

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

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

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

Команда в игре «Что? Где? Когда?» существует по принципам Agile. Взаимодействиям отдана ключевая роль. Капитан выполняет роль заказчика продукта (верного ответа), 2-3 эрудита перебирают массивы информации, кто-то следит за временем, есть человек, который анализирует, задает вопросы и побуждает общение, любой может высказаться и привести к результату или все провалить, за пределами игры есть разбор полетов (ретроспектива).

Противовес Agile — это конвейерный (каскадный) метод с жесткой иерархией и точными задачами поставленными как можно ближе к SMART. По этим принципам в «Что? Где? Когда?» капитан должен был бы раздавать точные задачи — кому в каком направлении думать и пытаться собрать это в ответ. Каждый участник должен был бы соблюдать приличия и высказываться когда дойдет очередь. В случае провала нужно было бы кому-нибудь понизить мотивацию или уволить и принимать это решение будет капитан.

Главной причиной появления и развития Agile является то, что все больше проектов не имеют 100% понимания, что должно быть в конце. Расписать точные задачи попросту невозможно. И решили, что свободные взаимодействия важнее инструкций, а готовность к изменениям важнее планов.

Гибкие методологии — это ответ на неопределенность; до конца неизвестно, что нужно сделать и что должно получиться в результате. Казалось бы, а что непонятного в разработке, например, сайта или в строительстве дома или в приготовлении гамбургера в Макдональдсе? Эти проекты поставлены на поток, где неопределенность?

Но. Даже если вы веб-студия и для вас это тысячный сайт, для клиента это первый раз. И его желания останутся неопределенностью до самого конца. Многие студии делают 3-4 варианта главной страницы и закладывают неделю на непредвиденные доработки. У всех, кого я знаю, работа разбита на итерации, после каждого есть демонстрация и обсуждение. Общение с заказчиком важнее подписанного контракта.

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

Хорошо, в изготовлении гамбургера в Макдональдсе нет никакой неопределенности. Процесс отработан за 70 лет и воспроизведен в 125 странах. Да, это конвейер, куда лучше не влезать с гибкостью. Agile не применим в хорошо отлаженных годами процессах. Правда, открытие нового ресторана по очень точной франшизе — это всегда уникальный проект. Где к месту будет итеративный подход, сокращение итераций, распределение ролей, открытое взаимодействие, визуализация проекта на Agile-доске, ретроспектива, ежедневные планерки.

Итого ключевые ценности Agile (манифест):

• свободное взаимодействие в команде
• результативность проекта (классный продукт)
• партнерское общение с клиентом
• готовность к изменениям

Что такое команды с ролями?

В привычной команде есть две роли: Начальник и Подчиненный, один умный другой дурак. В Agile принципиально важны три: Заказчик продукта, Методист, Участник команды.

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

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

Со стороны гибкая команда от привычной отличается именно наличием или отсутствием так называемого повествовательного диалога (narrative collaboration). Если идет обсуждение вопроса «Как реализовать продукт?» на всех уровнях, значит команда гибкая. Если ищут кто виноват, что не выполнен список конкретных задач, значит все как обычно.

Главный вопрос: «Как управлять ресурсами когда все так гибко?»

Все эти рассказы про ответственные команды и истории появления метода воспринимаются как полная фигня, если нет ответа на вопросы:
«А как точнее управлять ресурсами?», «Как раньше понять, что в проекте ресурсов стало не хватать для окончания?», «Мы всегда ставили и распределяли задачи по исполнителям и могли прогнозировать результат, а что теперь?». Что бы рассказать про Agile, можно раскрыть только этот вопрос.

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

Есть несколько важных принципов и методов, явно направленных именно на прогнозирование ресурсов:

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

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

3. Короткие итерации (спринты). Этот подход, как никакой другой позволяет компаниям пробовать что-то из Agile. Руководство согласно на промежуточный результат через пару недель без того, чтобы влезать и всем проставлять задачи. Согласиться на такой режим работы на полгода было бы невозможно.
Спринт (итерация) — это отрезок времени в несколько недель. У нас чаще всего это 2 недели. Самое важное в спринте — это определение того, какой промежуточный результат должен быть получен. Этим результатом хорошо называть итерацию, например, «Выпуск досок с правами» или «Выпустить сайт на тест». Если работа идет по отрезкам времени, но каждый отрезок не приводит к какому-то конкретному результату, то это уже не итерационный подход.

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

Мы используем третий, но оценки бывают только 1h, 2h, 4h, 8h.

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

5. Burndown chart (график сгорания)
Очень простая вещь — это график с двумя линиями; первая — сколько времени сгорело и это всегда прямая, на второй — сколько задач в пересчете на ресурсы закрыто и тут возможны колебания. Фактически это графический ответ на вопрос идет ли команда по плану или отстает.

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

• самая частая ошибка — попытка попадать в оценки очень точно, команда перестает работать на результат
• самый успешный подход — заложить запас по времени, планировать на 80% ресурсов

Инсайд из самой большой, старой и известной seo-студии в России — они закладывают запас в ресурсах два раза, первый при обсуждении с клиентом, второй при внутреннем планировании.

Топ 5 самых популярных Agile-практик понятных всем

Еще раз подчеркну, Agile на базовом уровне применения — это просто. Нет никаких сверхсложных приемов, которые надо долго изучать. Ниже для примера приведено 5 самых популярных практик (по данным все того же опроса от VersionOne)

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

1. Итерационное планирование — спринты (90% команд используют)
Работать небольшими забегами с промежуточным результатом — хорошая практика. Спринт — это несколько недель. Слишком короткие или слишком длинные отрезки — плохо. Одинаковый интервал на все случаи жизни тоже не годится. У спринта должна быть максимально точная цель, исходя из этого и определяется длительность.
Самый частый ошибкой является то, что команды привыкают просто расписывать задачи раз в две недели, теряются процессы постановки промежуточных целей и подведение итогов в конце. Работа сваливается в обычный поток задач с обновлением раз в спринт. Проблему должен решать методист.

2. Ежедневные планерки (88% команд используют)
Задача — чтобы каждый день команда подтверждала единое направление движение всех участников. По классическому описанию каждый в команде раскрывает три вопроса:

• Что сделано к этому моменту из спринта?
• Что планируется на сегодня?
• Какие проблемы возникли или что мешает?

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

3. Ретроспективы (83% команд используют)
Совещание в конце итерации. Обсуждение, что получилось, а что не очень. Самая важная цель — сделать выводы о том, как меняться.
Заказчику продукта — о том как лучше показывать ожидания пользователей, методисту — о том, как побуждать диалог и выполнять договоренности выбранных подходов, команде — о том, как при оценках учитывать новые открывающиеся факторы. Как правило ретроспективы проходят весело — итерация-то закончилась, можно выдохнуть и обсудить итоги. Хорошая практика что-нибудь пить или есть в перерывах этого процесса.

4. Итерационные показы (81% команд используют)
Это демонстрация от команды раз в несколько итераций результатов проекта, как правило в виде выступления. Главный смысл в том, чтобы была «сессия» и ничего страшного, если это станет похоже на отчетность перед руководством. Главная трудность в том, чтобы собрался кто-то кроме команды, да еще и понимал смысл происходящего. По нашей практике приживается только при очень крутом руководстве.

5. Короткие итерации (71% команд используют)
Смысл в том, что нужно постоянно стараться сокращать цикл получения маленьких промежуточных результатов. Если этого не делать, циклы будут естественным образом расти или будет постоянными, независимо от промежуточных целей. Чем короче цикл, тем меньше ошибок при итерационном планировании. Это задача методиста, стоит вспоминать про это хотя бы раз в полгода.

Как понять ведется ли проект по Agile-методологии или еще нет?

Диаграмма того, сколько компаний меняют Agile под себя выглядит так:

Гибкость подхода распространяется и на сам подход. Это первое, что стоит узнать команде, если им предстоит стать гибче. Нельзя быть на 100% Agile, выполняя все предписания. Никто строго не соблюдает правила в чистом виде, на практике у каждой компании есть свои модификации.

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

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

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

Книги, статьи, блоги и видео по Agile – SkillsCup by DBlinov.com

Ниже представлен перечень материалов по Agile и связанным темам.

Материалы об Agile в целом

История и объяснение Agile

Нужен ли вам Agile?

1. Статья Что такое Agile-подход и зачем он нужен бизнесу? от ScrumTrek.
2. Статья Нужен ли тебе Agile: 5 моделей для проверки.
3. Статья Agile или нет: подходят ли вам гибкие методы управления и работы в HBR.

Материалы по Scrum

Роли Скрама

• Владелец продукта
• Скрам-мастер
• Сравнение ролей

События/встречи Скрама

Артефакты Скрама и DoD

• Определение готовности / Definition of Done
• Бэклог продукта
• Бэклог спринта
• Инкремент

Книги по Agile и Скраму

Титул	На русском	In English
	Скрам-гайд — полное исчерпывающее руководство по Скраму версии 2017	Scrum Guide
	Скрам. Гибкое управление продуктом и бизнесом, 2019, Кен Швабер	Agile Project Management with Scrum (Developer Best Practices), 2004
	Книга Scrum. Революционный метод управления проектами от Джефф Сазерленд	Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland
	Scrum. Гибкая разработка ПО от Майка Кона	Succeeding with Agile: Software Development Using Scrum by Mike Cohn
	Основы Scrum. Практическое руководство по гибкой разработке ПО от Кеннет С. Рубин	Essential Scrum: A Practical Guide to the Most Popular Agile Process by Kenneth S. Rubin
	Постигая Agile. Ценности, принципы, методологии от Эндрю Стеллман и Дженнифер Грин	Learning Agile. Understanding Scrum, XP, Lean, and Kanban by Andrew Stellman, Jennifer Greene
	Софт за 30 дней. Как Scrum делает невозможное возможным от Кен Швабер и Джефф Сазерленд	Software in 30 Days. How Agile Managers Beat the Odds, Delight Their Customers, And Leave Competitors In The Dust by Ken Schwaber, Jeff Sutherland
	Эпоха Agile. Как умные компании меняются и достигают результатов от Стивен Деннинг	The Age of Agile. How Smart Companies Are Transforming the Way Work Gets Done
	Чистый Agile. Основы гибкости от Роберт «Дядя Боб» Мартин	Clean Agile: Back to Basics by Robert C. Martin

Книги по Скрам

Скрам-мастерам и Agile-коучам

Более детальная информация для углубленного изучения.

	На русском	In English
	Путь скрам-мастера #ScrumMasterWay от Зузана Шохова	Great ScrumMaster, The: #ScrumMasterWay by Zuzana Sochova
	Agile. Оценка и планирование проектов, 2018, Майк Кон	Agile estimating and planning by Mike Cohn, 2006
	Agile-менеджмент. Лидерство и управление командами, Юрген Аппело	Management 3.0: Leading Agile Developers, Developing Agile Leaders by Jurgen Appelo
	Agile ретроспектива. Как превратить хорошую команду в великую, 2017, Диана Ларсен, Эстер Дерби	Agile Retrospectives. Making Good Teams Great by Esther Derby, Diana Larsen, 2006
	Ретроспектива в Agile. Проверенные методы и инновационные подходы от Марк Лоффлер	Improving Agile Retrospectives. Helping Teams Become More Efficient by Marc Loeffler
	Коучинг Agile-команд от Лисса Адкинс	Coaching Agile Teams. A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition by Lyssa Adkins
	Agile-тестирование. Обучающий курс для всей команды от Джанет Грегори и Лайза Криспин	More Agile Testing: Learning Journeys for the Whole Team by Janet Gregory Gregory
		Agile Testing. A Practical Guide for Testers and Agile Teams by Lisa Crispin
	Scrum на практике.Высокая продуктивность и результаты — прямо сейчас от Джей Джей Сазерленд	The Scrum Fieldbook: A Master Class on Accelerating Performance, Getting Results, and Defining the Future by J.J. Sutherland
	Scrum без ошибок. Инструменты, техники и советы для тех, кто работает по Agile от Илан Голдштейн	Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips by Ilan Goldstein
		Scrum Mastery: From Good To Great Servant-Leadership by Geoff Watts

Скрам-мастерам и Agile-коучам

Владельцу продукта

Книги для владельца продукта

Посмотрите еще и список книг для стартаперов.

Канбан-метод

Канбан-метод

Другие темы

Фасилитация

Трудности фасилитации – разбор проблемных кейсов YouTube-видео 0ч:50м Светлана Мухина

Новые модели управления

---

Считаете, что нужно добавить ещё какой-то полезный ресурс? Оставьте комментарий ниже, пожалуйста.

Другие подборки книг

Слёрм — Agile и семья. Как выдержать друг друга в…

Agile и семья. Как выдержать друг друга в самоизоляции

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

Как это делается?

Шаг 1. Правила. В командах Аджайл, как в бизнесе, так и в семье, всё начинается с правил. Поэтому собираются все жители квартиры — бабушки, дедушки, собаки, кошки, мышки, репки, детки, даже если им год или два — и создают правила. Как их создают? Даётся пять-семь минут — и каждый на листочке пишет правила, которые он бы предложил для семьи. Дальше каждый озвучивает то, что написал — и в итоге создаются на «флипчарте» или на большом листе бумаги правила взаимодействия в семье. Мы собрали мнение каждого, мы определили основные правила и подписали в воздухе, что согласны.

Шаг 2. Ценности. Аджайл — это про ценности внутри команды, внутри компании. И внутри семьи. Мы создаём ценности семьи и обсуждаем их. Каждый пишет свои ценности на листочке, как на первом шаге. В итоге появляются ценности семьи. Если ценности совпадают, хорошо — это объединяет. Если ценности разные, друг другу объясняем, почему каждому эти ценности важны, чтобы каждый принимал другого таким, какой он есть.

Шаг 3. Визуализация и прозрачность процесса. Создаётся доска «to do» или «что делать — в работе — сделано». Подготавливаются бумажные стикеры, если участвуют бабушки и дедушки. Если семья молодая, создаётся проект на asana.com или trello.com. Так у семьи визуализируется планирование. В начале недели или в воскресенье семья планирует, что делать на следующую неделю. Например, «убраться», «купить продукты», «позвонить родственникам», «выбрать путешествие», «посмотреть кино». Все участвуют в планировании. Всё это записывается на стикерах — электронных или обычных. Задачи распределяются среди всех членов семьи. Например, четырёхлетний Яша тянет руку и говорит: «Я буду пылесосить». И родители ему говорят: «Молодец. Вот твой стикер. Когда пропылесосишь, убери стикер в «сделано»». Лучше всего, если стикеры разноцветные, чтобы сразу было видно, у кого сколько дел, кто перегружен, кому нужна помощь.

Шаг 4. Daily. Каждое утро, на завтраке все вместе отвечают на три вопроса.

1. Как прошёл вчерашний день?
2. Что он сегодня планирует делать?
3. Нужна ли ему какая-то помощь?

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

Шаг 5. Demo. Вся семья подходит к доске или смотрит в asana или trello, все ли запланированные дела они сделали, что у кого получилось. И обязательно как-то празднуют — или пиццу заказывают, или вместе смотрят кино. Обязательно нужен какой-то объединяющий процесс. Потому что мы все тонем в бытовухе. Особенно, если мы видим друг друга с утра до вечера.

Шаг 6. Ретроспектива. За ужином мы обсуждаем, что нам улучшить. У ретроспективы есть чёткая формула «плюс-минус-равно». Вначале все делятся успехами. Затем каждый рассказывает, что ему не понравилось. Маленький Яша говорит: «Мне не понравилось, что папа не пускал меня в свой кабинет». А папа объясняет: «Яша, чтобы у тебя было много игрушек, и чтобы мы все вместе поехали летом на море, папе нужно работать, папа за это деньги получает. Помнишь, у нас в правилах записано, чтобы в мою комнату не входили, когда на двери висит табличка? Мы с тобой Яша её рисовали красным фломастером. Если красная табличка висит, ты не заходишь».

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

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

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

_______________________
Марина Алекс, международный эксперт по Agile в бизнесе, консультирует компании в 12 странах, запустила более 170 Agile-команд. Преподаватель открытого и бесплатного курса «Вечерней школы Аджайл», который начинается во вторник 28 апреля в 20:00: http://to.slurm.io/eq65Kg

Как объяснить дедушке Agile и Scrum за 5 минут. И чтобы лучше понять самих себя | Наталья Бабаева | Startup

Вы увидите, что Agile интуитивно понятен.

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

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

«Наташа, стоп! Не думай.

Вы только что прочитали 3 книги по этой теме, посетили пару двухдневных семинаров, посетили лагерь по agile, посмотрели несколько видеороликов и провели несколько сессий по стратегии с тренерами по agile. Ну, а еще несколько лет провел в скрам-процессе.

Совершенно очевидно, Наташа, что ты ха-ха! — что вы могли понять. Не смейте самостоятельно искать ответ на свою проблему. Запишите его и дождитесь консультации со своим Agile-тренером ».

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

Кстати о подозрительном

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

Я решил, что у меня хватит смелости написать пост о том, насколько agile и scrum на самом деле интуитивно понятны, и что важно включить их в нужный момент. И выключите их в нужный момент.Еще раз:

И выключить их в нужный момент.

Итак, позвоните дедушке и давайте начнем.

Объясняя agile дедушке

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

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

— А потом?

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

— Отличная работа, дедушка.А теперь запомните:

Мы назовем дом «продукт » . Ага, не смейтесь.

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

Дом с пристройкой и дом с крыльцом приращений .

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

Ваша жена — участник , ее мнение имеет значение, потому что ей придется жить в доме.

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

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

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

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

— Идеально. А теперь запишите:

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

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

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

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

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

— Хорошо, дедушка, итак:

Ваше обсуждение в начале каждой недели — это спринт планирование .

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

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

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

— Я привозил ее каждые две недели.На всякий случай что-то пойдет не так.

— Посмотрите, что у нас есть:

Каждые две недели до визита жены — это продолжительность вашего спринта .

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

Ваше новоселье — продукт запуск .

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

Историческая справка

Во время колонизации Америки поселенцы отправились на Запад, подальше от цивилизации. У них были ограниченные ресурсы и время, и им пришлось построить жилище до зимы. В первый год они построят небольшие домики из дерна с печью из камня и земли. Это был их самый лучший игрок. В следующем году они построят хижину из необработанного дерева (это версия 2.0 их продукта). Только с 3-го года обучения они обычно начинают строить настоящий прочный дом.

Как простыми словами объяснить Agile бабушкам и дедушкам

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

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

Мы не собираемся открывать континенты (поскольку уже написаны десятки фундаментальных статей об Agile), мы просто рады поделиться краткими выдержками из одного удивительного поста Хенрика Книберга, который опубликовал его в блоге Crisp. Вот самые интересные моменты в нашей интерпретации:

* все фото взяты из видео, опубликованного в оригинальной статье

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

Гибкие роли

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

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

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

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

Это разработчики. Они построят систему.

Вместимость

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

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

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

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

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

Перелив

Переполнение — это то, что происходит, если мы делаем все, о чем нас просят.

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

В этом случае методологии Scrum и XP (Extreme Programming) используют подход «вчерашняя погода». Команда заявляет: «За последние несколько недель мы реализовали 4–6 функций в неделю, поэтому какие 4–6 функций мы будем создавать на этой неделе?» Владелец продукта обязан правильно выбрать, какие пользовательские истории будут реализованы на этой неделе.

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

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

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

Сказать «НЕТ»

Сказать «НЕТ» — это единственный способ остановить выход очереди из-под контроля. «Нет» — это самое важное слово для Владельца продукта. Пэт должен тренировать его каждый день перед зеркалом.

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

Чтобы правильно расставить приоритеты, Питомец должен понимать ценность каждой истории.

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

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

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

Как Pet определяет ценность и размер истории? Она этого совсем не делает, потому что это всего лишь игра в угадывание.

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

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

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

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

Владелец продукта ИТ должен постоянно общаться со всеми. Успешные владельцы продуктов различают 2 составляющих успеха: страсть и общение.

Риски

Риски бывают разных видов:

• Бизнес-риск: «Правильно ли мы поступаем?»
• Социальный риск: «Можем ли мы делать то, что нам нужно?»
• Технический риск: «Будет ли проект работать на этой платформе?»
• Риски со стоимостью и сроками реализации: «Будет ли у нас время и хватит ли денег?»

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

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

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

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

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

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

Компромисс между «делать правильные вещи», «строить правильные вещи» и «делать их быстро»

В идеале — делать все три одновременно, но на самом деле нужно выбирать.

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

или

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

или

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

В Scrum существует здоровое противостояние ролей

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

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

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

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

Таким образом, понятие «Backlog» относится не к продукту, а к команде. Бэклог — это список того, что владелец продукта хочет от команды. И набор историй для разных товаров. Заказчик должен постоянно выбирать актуальные для реализации.

Уничтожение историй

Время от времени заинтересованные стороны будут спрашивать Владельца продукта: «Когда они выпустят мою функцию?» Или «Сколько функций будет выпущено к Рождеству?». Pet должен уметь управлять ожиданиями пользователей.И управлять ими реалистично.

Есть две тенденции: оптимистическая и пессимистическая. Расстояние между трендами показывает, насколько нестабильна скорость команды. Со временем эти тенденции стабилизируются, а конус неопределенности уменьшится.

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

Пэт использует две линии тренда для ответа. Ответ — в апреле или мае.

Заинтересованная сторона спрашивает Пэт: «Сколько будет сделано к Рождеству?»

Это вопрос с фиксированным временем и переменным объемом.Линии тренда говорят нам: «Скорее всего, мы закончим все это, некоторые из них, и ничего из этого».

Затем заинтересованная сторона спрашивает: «Можем ли мы сделать эти функции к Рождеству?» Это вопрос с фиксированным временем и фиксированным объемом.

Пэт говорит: «Нет, этого не произойдет» и продолжает: «Вот сколько еще нам нужно времени».

Лучше сократить объем, чем продлить время. Пэт упрощает выбор, говоря: «Мы можем доставить кое-что здесь, а остальное — позже. Или мы ничего не могли бы доставить сюда, а остальное позже.Что ты предпочитаешь?

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

Хорошо, но что, если у нас есть более крупный проект с несколькими командами? Модель будет та же — управление мощностью, общение с заинтересованными сторонами, принятие решений об отклонении пользовательских историй. Скорость равна сумме скоростей всех команд.

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

Хорошо, готово!

Что вы думаете о таком кратком объяснении владения продуктом Agile? Было ли это полезно для вас?

Чтобы консолидировать эту информацию, вы можете еще раз получить ее из этого видео :

менеджеров проектов объясняют Agile детям

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

1

Если вы понимаете agile в чистом виде, как я всегда объясняю это своим детям, agile — это способность двигаться быстро и легко. — Белкис Васкес-МакКолл, США

2

Вы помните, когда мы были в зоопарке? Организация похожа на большой зоопарк, но только человеческий. Есть много разных людей, которые едят разную — по интересам.Agile — это то, что объединяет их лучше, позволяет им есть вместе и делиться едой друг с другом. Только тогда организация может измениться так же быстро, как леопард, и адаптироваться, как хамелеон. Если они этого не сделают, лев придет и съест их. А мы этого не хотим, так что лучше научиться Agile. — Алеш Штемпихар, Словения

3

Agile Project Management — это когда у вас есть скучное и сложное школьное задание, которое вы вместе с друзьями превращаете в увлекательную игру.Все вы вносите свой вклад в игру, используя свои навыки и интересы, и задача выполняется. — Юлия Черная, Дания

4

Подобно сборке чего-либо из LEGO и тому, что вы решите сделать в любое время, у вас всегда будут все необходимые детали и всегда будут правильные инструкции. — Барри Карри, Ирландия

Пока вы здесь, не хотели бы вы ознакомиться с результатами нашего книжного обзора руководителей проектов за 2018 год?

5

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

6

Сын, когда дедушка и бабушка поженились, времена были тяжелые, и у них не было много денег, чтобы построить большой дом (как у тети Роуз). Это был октябрь, приближалась зима, поэтому сначала им пришлось построить что-то очень быстрое — вот, посмотрите на эту картинку. Да, это был очень маленький дом, только с основными удобствами, но дедушка позаботился о том, чтобы фундамент и крыша были достаточно прочными, чтобы пережить зиму. Затем пришло лето, и дедушка начал надстраивать его — сначала гостиную, потом он расширил кухню, потому что бабушке нужно было больше места, чтобы готовить.В течение следующих двух лет он постепенно улучшал их дом: вот еще одна фотография, когда он добавил крыльцо и сад сзади. Дедушка все делал сам (иногда с помощью дяди Тома), а бабушка была очень довольна тем, что они построили. И в этом, сынок, и есть Agile! — Мариса Сильва, Великобритания

7

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

8

Когда вы пытаетесь построить прототип Эйфелевой башни, просто используя детали LEGO, это называется AGILE Version of Building a REAL. — Афшин Монтазами, Иран

Все дороги ведут к Agile, но некоторые менеджеры проектов даже пытаются объяснить детям, как расставить приоритеты в бэклоге.

9

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

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

10

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

11

Agile — это то, что вы делаете, когда магазин мороженого, в который вы пошли, оказался закрыт. Если вы не подвижны, вы идете домой, потому что ваш план был сорван. Если вы подвижны, вы придумаете что-нибудь не менее увлекательное. — Аллен Голуб, США

12

Знаешь, когда мама говорит НЕТ, а ты спрашиваешь папу? Это Agile. — Перри Уоткинс, США

13

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

14

Я бы назвал отставание корзиной для стирки. Они складывают одежду, и когда приходит время, вы вынимаете одежду из корзины, которая вместе отправляется на стирку (спринт). — Керри Бернс, Соединенное Королевство

15

Что ж, мы можем ошибиться, поэтому мы работаем маленькими шагами и на каждом шаге спрашиваем: «Это правильно?».Таким образом, если мы сделаем что-то не так или нам придется что-то изменить, это не катастрофа. — Гай Маслен, Новая Зеландия

16

Я бы использовал примеры из повседневной жизни, чтобы объяснить эти термины. Я думаю, что дети (даже взрослые!) Узнают больше на конкретных примерах, которые они могут извлечь из книг. Например, установите на холодильнике доску Канбан для работы по дому и поработайте над ней несколько недель. Дети начнут с того, что помогут своим родителям создать бэклог продукта, а затем на следующей неделе будут добровольно выполнять определенные работы (перечисленные в бэклоге). — Кирк Брайд, Канада

17

Я бы сказал (очень иронично), что у хорошего родителя есть ребенок, который говорит министерству обороны раньше, чем папа. Раньше я скучал по распорядку купания моего малыша. Доска и все такое. Но мне пришлось остановиться, когда я столкнулся с проблемой, что DOR — моя работа — иметь пенную ванну уже в воде. — Гарин Рейнеке, Южная Африка

18

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

19

В зависимости от возраста я бы, наверное, поговорил о планировании выходных, чтобы получить от них максимум удовольствия. Список того, чем они хотят заниматься. Список того, что им следует делать, даже если они не хотят. Расставьте приоритеты и приблизьте график. В выходные я спрашивал их, что будет, если позвонит друг с хорошей идеей.Переставить по размеру? Что будет, если друг / погода отменит что-то запланированное? Переставить. Я бы посоветовал им оглянуться в воскресенье вечером. Был ли уик-энд лучше, чем обычно? Что мы хотим сохранить? Хотите, мы хотим стать лучше? — Пол Олдфилд, Соединенное Королевство

20

Agile — это когда группы людей считают, что мы можем последовательно разбивать работу на более мелкие и простые куски и создавать что-то ценное для других людей. Продолжая делать это, мы всегда ищем способы добиться большего и сделать вещи более ценными.Представьте, что вы и четверо друзей начали собирать набор LEGO Voltron. Мы бы разбили его, попросив каждого из вас поработать над одним из 5 львов. По мере того, как каждый из вас выполнял каждый шаг, вы проверяли свою работу или просили кого-нибудь проверить ее, чтобы убедиться, что она правильная. После того, как вы выполните все маленькие шаги, каждый из вас построил бы по одному льву, что уже очень ценно. Однако, когда вы все соберетесь вместе и объедините львов, вы образовали Вольтрона, гигантского робота, защищающего вселенную от зла! Если бы вы начали с создания одного льва, затем следующего и так далее, пока не будут построены все 5, вам потребовалось бы гораздо больше времени, чтобы сформировать Вольтрон, и вселенная не была бы защищена. — Марк Морелл, США

21

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

22

Это похоже на групповое задание по проекту в области науки / социальных исследований в школе, где вы проводите мозговой штурм, планируете, назначаете или беретесь за работу, решая, кто что будет делать, строить, тестировать, если это научный проект, наконец, представить свою работу с презентациями .И так же, как ваши оценки, совокупность данных / фактов, демонстрация, презентация и то, насколько счастливы все, глядя на ваш проект, и т. Д., Все это делается с помощью командной работы. Или играйте в Candy Crush с друзьями, которым нужно закончить уровень хотя бы с одной звездой (что ужасно), прежде чем перейти на следующий уровень. — Анита Гупта, США

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

Иллюстрация: Copyright © Женя Олийнык

Почему обучение важно (или почему вы должны посещать Scan-Agile ’08). История дедушки Тони и дедушки Фрэнсиса

В последнее время я понял, что сегодняшняя способность учиться подобна умению читать в прошлые века. Смущенный?

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

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

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

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

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

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

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

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

В Agile Finland мы пытаемся бороться с этим недостатком обучения, создавая возможности для обучения. В этом году мы организуем конференцию Scandinavian-Agile ’08.На этой конференции у вас будет возможность не только поучиться у первоклассных докладчиков, но и пообщаться с единомышленниками, а также поучиться на их опыте.

Я бы сказал, что это возможность, которую нельзя упускать!

Посетите наш веб-сайт и зарегистрируйтесь как можно скорее. Ожидаем аншлаг и места уже разлетаются!

Приходите и учитесь!

Дедушка Джетсон намного круче, чем дедушка Симпсон | История

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

11-я серия Джетсонов начинается с того, что полицейский останавливает Монтегю Джетсона — дедушку Джорджа и человека, чья энергия и жизненный энтузиазм доминируют в эпизоде. Полицейский замечает, что дедушке Джетсону «110… но он все еще ведет себя как мужчина 75 лет». Из этого мы узнаем, что обещания ХХ века были верны: люди будущего не только будут жить дольше, но и станут намного счастливее и здоровее.Эпизод под названием «Визит дедушки», впервые вышедший в эфир 2 декабря 1962 года, рассматривал все: от будущей моды (когда Джуди и Джейн возвращаются домой с набором новых шляп) до спорта будущего (когда дедушка Джетсон играет с и превосходит всех членов семьи Джетсонов в их любимом виде спорта).

Джейн Джетсонс демонстрирует свою новую шляпу, которую она называет «Венера с лица» (1962). (Джетсоны)

Мода

В «Джетсонах» все, естественно, имеет поворот космической эры — даже мода.Когда Джуди и Джейн возвращаются домой после покупок, они моделируют для Джорджа свои новые шляпы с такими названиями, как «Лунный пейзаж», «Космонавтрис» и «Ядерный взгляд». Все эти образы апеллируют к гуги-тастической вспышке, которую мы стали ассоциировать с футуризмом середины века и, чаще всего, с тем, что люди 21 века называют «взглядом Джетсона». Но корни этих далеких стилей уходят далеко за пределы Всемирной выставки в Нью-Йорке 1939 года. Платье справа было показано в выпуске журнала Vogue от 1 февраля 1939 года и было разработано Генри Дрейфусом для женщины 2000 года.

Дизайн платья для женщины 2000 года от Генри Дрейфуса в выпуске Vogue от 1 февраля 1939 года. (Vogue)

Розничные торговцы 1930-х годов иногда устраивали футуристические показы мод, но эта тенденция действительно взлетела в 1950-е и 1960-е годы, когда дизайнеры были вдохновлены техно-утопическими идеями той эпохи. В 1957 году в магазине Marshall Field’s в Чикаго состоялась двухнедельная выставка, посвященная жизни американцев в 2000 году. В магазине были представлены футуристические работы 17 дизайнеров одежды и аксессуаров, что позволило покупателям взглянуть на предполагаемую футуристическую моду в будущем.От 15 мая 1957 г., номер Chicago Daily Tribune :

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

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

Футуристический халат от Dorian, например, оснащен 40 карманами с пищевыми таблетками, электрическими розетками для мгновенных перманентов и системами связи с роботизированным управлением, чтобы домохозяйка была на связи с прачечной, детской и кухней.

А как насчет свадьбы космической эры? Мы рассмотрели предсказания медового месяца на Луне в конце 1950-х годов. По словам модельера Загри, сама свадьба состоится на Венере:

.

По словам чикагского дизайнера Загри, шикарным местом для свадеб будущего станет планета Венера.Ее дизайн для свадебного костюма — трансформируемый ансамбль из роскошных золотых пластинок. Из объемной юбки и шлейфа открывается комбинезон, подходящий для медового месяца космического корабля. Огромный пластиковый пузырь с радаром — головной убор невесты.

Долговечность

Кресло-качалка — символ более медленной жизни — естественного желания расслабиться по мере того, как человек становится старше и менее подвижным. Футуристическое кресло-качалка дедушки (или, по крайней мере, то, над которым для него работают Джордж и Элрой) — еще один пример технологии Jetsons, которая работает не так, как предполагалось.Глупые шутки вроде Джорджа, раскачивающегося на неконтролируемом кресле-качалке, безусловно, являются нормой во время любого мультфильма, но в семье Джетсонов они также говорят о некотором консерватизме, который пронизывает весь сериал. Используя приколы, в шоу часто утверждают, что нарушение символов традиции (например, кресло-качалка) приведет к неприятным последствиям. И если оставить в стороне традиции, дедушке Джетсону кресло-качалка совершенно не нужно, поскольку в будущем даже 110-летний мужчина будет таким же счастливым и здоровым, как и человек вдвое моложе его.

Предсказания увеличения продолжительности жизни стали чрезвычайно популярными в середине века, но появились они гораздо раньше. В газете Charleston Gazette от 2 января 1926 года была опубликована короткая статья о предсказаниях на будущее, когда люди доживут до 200 лет:

У серьезного ученого есть радостные новости для всех, кто хочет остаться в этом мире, несмотря на его беды и заботы. По его словам, в 2000 году средняя продолжительность жизни составит 100 лет, а многие доживут до 200 лет.

Это заинтересует защитников контроля над рождаемостью, поскольку в 2000 году н.э. может потребоваться что-то вроде контроля над рождаемостью.

Мужчина и женщина 200 лет могут легко иметь тысячи потомков. Однако провидение не позволяет деревьям вырасти до небес.

Четверть века спустя Ассошиэйтед Пресс рассмотрит ожидаемую продолжительность жизни и здоровье в 2000 году в коротком сообщении медицинского редактора AP в 1950 году:

В медицине к 2000 году ожидаемая продолжительность жизни женщин увеличится почти до 80 лет, а мужчин — до 75 лет.

Рекорд будет лучше, если будет обнаружена причина и способ лечения рака. Рак — это форма роста. Это часть обмена веществ. Что касается роста, то сейчас ничего не известно. Метаболизм — это не такая уж полная загадка, но он сложен. Большинство хронических заболеваний, за исключением инфекций, вызываемых микробами и вирусами, основаны на нарушении обмена веществ.

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

«Надежда» очень хороша для ограничения приступов рака еще до 50 лет, но не для их искоренения. Потому что теперь выясняется, что рак — это не одно заболевание, а принимает множество форм.

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

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

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

Джордж и его дед Монтегю играют в боулинг (1962) (Джетсоны)

Спорт

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

Джетсоны, как мы уже видели, чаще всего хотят представить зрителям что-то похожее на аудиторию середины века. Имея это в виду, мы понимаем, почему все члены нашей семьи 2062 года занимаются видами спорта, которые знакомы людям 1962 года, а не полностью создают новый вид спорта.Просто добавьте ко всему «космическое», «небо» или «ядерное» — и вуаля: это будущее. Или, что более уместно с точки зрения 21 века: это был Jetsoned.

7 отличных настольных игр для пожилых людей — Bananagrams

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

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

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

Big Letter Bananagrams — это динамичная гонка слов, посвященная построению таблиц слов быстрее, чем ваши оппоненты. Вы начинаете с кучи плиток с буквами, и вам нужно превратить их в соединяющие слова, как в кроссворде. Сложность в том, что как только кто-то заканчивает свою сетку слов, каждый должен вставить новую букву в свою сетку!

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

18 долларов на Amazon. Купи сейчас.

Ticket To Ride — для пожилых людей, которые любят гулять на свежем воздухе

Ticket to Ride — фантастическая настольная игра для пожилых людей. Все дело в великих американских железных дорогах и соединении городов быстрее, чем ваши оппоненты. Каждый игрок начинает с карт вагонов и карт назначения, и игроки должны тайно соединить свои города.Более длинные маршруты получают дополнительные бонусные баллы.

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

40 долларов на Amazon. Купи сейчас.

Scattergories — для пожилых людей, любящих быстрые игры

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

Звучит просто, но на данный момент обычно довольно сложно заполнить категории (особенно если вы получили букву типа «q»!). Доска не нужна, и вы можете играть в быстрые раунды, где бы вы ни находились, так что это отличная настольная игра для пожилых людей, которые постоянно путешествуют по миру.

10 долларов на Amazon. Купи сейчас.

Hive — для пожилых людей, любящих шахматы

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

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

24 доллара на Amazon. Купи сейчас.

Череп — для пожилых людей, которые любят глупости

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

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

11 долларов на Amazon. Купи сейчас.

Катан — для пожилых людей, которые любят здоровые развлечения

Catan — классическая немецкая настольная игра.Он слегка стратегический, в нем есть здоровая тема (строительство поселений) и он великолепно сбалансирован. Игроки должны собирать ресурсы, такие как дерево и зерно, чтобы строить соединяющиеся города. Они могут обмениваться с другими игроками для дальнейшего расширения, и победителем становится тот, кто первым наберет 10 очков.

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

42 доллара на Amazon. Купи сейчас.

Диксит — для пожилых людей, любящих искусство

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

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

30 долларов на Amazon. Купи сейчас.

новых выпусков видеоигр — Metacritic

	NieR Replicant вер.1,22474487139 … Платформа: Xbox One 23 апреля 2021 г. Приготовьтесь познакомиться с тем, с чего начиналась серия NieR — NieR Replicant ver.1.22474487139 … NieR Replicant ver.1.22474487139, действие которого происходит в постапокалиптическом мире, ставит вас в роли титулованного Нира, молодого человека, который пытается вылечить свою сестру Йону от смертельной болезни. То, что они обнаруживают, заставит их усомниться во всем, что они думали, что знали. У оригинального релиза NieR интересная история. В Японии было две версии игры: NieR Replicant и NieR Gestalt. NieR Replicant сосредоточился на брате Ниере и его сестре Йоне. В NieR Gestalt главным героем был отец Ниер, а его дочь Йона.На Западе выпущен только NieR Gestalt (под названием NIER) — так увлекательно, что это будет первый раз, когда многие люди сыграют в версию игры Replicant.
	Металлургический завод Платформа: Xbox One 22 апреля 2021 г. Вы — Ева, только что вышедшая из Эдема и вооруженная живыми доспехами.Исследуйте новый опасный мир, сражайтесь с его причудливыми обитателями и расширяйте свою империю в отчаянном путешествии, чтобы найти Адама. Smelter — это комбо-стратегия, экшн-платформер, вдохновленная классикой 16-битной эпохи. Управляйте плавильным заводом и его верными войсками Зирма, расширяя территорию плавильного завода по Грубым землям на уровнях стратегии сверху вниз, а затем погрузитесь в захватывающие боевые этапы с боковой прокруткой после аннексии ключевых локаций. Стройте, атакуйте и продвигайте свою армию — открывайте, улучшайте и применяйте навыки элементарных действий против злых врагов, опасной среды и опасных боссов.Освободи мощь плавильного завода! Сюжет: После безвременного разрушения Сада Ева оказывается в незнакомом мире, а ее любимый Адам нигде не может быть найден. В поисках Адама она встречает Смелтера, необычайно самоуверенного крылатого существа, обладающего мощной способностью трансформироваться и сливаться с другими, наделяя их невероятными способностями. Предлагая свою очевидно «неоценимую» помощь, Смелтер трансформируется и сливается с Евой. Они отправляются в путешествие по коварным Шершавым землям.Там они расширяют территорию Медеплавильного завода, позволяя им проникать дальше в различные области, чтобы узнать, что случилось с ее Адамом, надеясь найти его целым и невредимым и найти путь домой к своей мирной жизни …
	Дождь на вашем параде Платформа: Xbox One 15 апреля 2021 г. Путешествуйте по миру милым картонным облаком и испортите всем день! Открывайте новые методы озорства на 50 уровнях, каждый с уникальным окружением и целями.Заводите новых друзей и помогайте им тоже — это очаровательная игра на злорадство. Путешествуйте по миру, изобретая новые способы вызвать хаос и хаос. Превратите идеально сухой и солнечный свадебный день в дождливый, обрушьте на города гром и молнии, принесите столпотворение покупателям в супермаркетах, уничтожьте фермерские посевы, крадитесь по военным базам и обрушьте на динозавров метеориты! Да, даже динозавры не в безопасности! По мере прохождения игры вы будете открывать новые и более комичные методы причинения бедлама.Используйте гром и молнию, чтобы напугать людей и поджечь их, торнадо, чтобы поглотить все, что попадется на их пути, дождь из взрывчатого материала, который вы можете взорвать, и даже целые метеоры и многое другое.
	Потерянные слова: За гранью Платформа: Xbox One 6 апреля 2021 г. Взаимодействуйте со словами, записанными на страницах дневника молодой девушки, чтобы решать сложные головоломки, решать уникальные платформенные сегменты и открывать для себя эмоциональную историю, происходящую в ярком мире Эстории в Lost Words: Beyond the Page.
	Breathedge Платформа: Xbox One 6 апреля 2021 г. Breathedge — это ироничная приключенческая игра на выживание в открытом космосе.Возьмите на себя роль простого парня по имени Человек, который просто несет прах своего дедушки на галактические похороны и внезапно оказывается в эпицентре всемирного заговора. Огромный космический катафалк потерпел крушение в глубоком космосе, оставив всю территорию заполненной мусором, гробами, мертвыми пассажирами и вами. Выживите на этой межзвездной свалке, раскройте глобальный заговор, спасите принцессу и не ломайте пальцы, нажимая на клавиатуру, путешествуя по миру (рекомендуется держать дисплей включенным для полного погружения).Нашим предкам потребовалось много времени, чтобы развиться, потому что у них не было изоленты. Он у вас есть, и вы знаете, как его использовать. С помощью этого волшебного артефакта вы можете создавать множество бесполезных предметов и выбрасывать их из шлюза! Также нужно создать много полезных предметов, но будьте осторожны, так как это может привести к завершению игры. Когда все ваши соседи просто парит в вакууме, ничего не делая, кроме как прикидываться мертвыми, различные инструменты и механизмы помогут вам стать самым шумным соседом на свете.Создайте уникальную космическую станцию, обеспечьте ее кислородом и электричеством, установите всевозможное оборудование от солнечных батарей до фермы для хомяков и превратите ее в настоящую холостяцкую площадку, набив ее мебелью, смешанной со всяким хламом. Да, вы не ослышались, это ваш личный автомобильный гудок! Кроме того, вы можете собрать небольшую ракету, покататься на мертвых или построить большой космический корабль. Транспорт помогает вам двигаться быстрее, избегать препятствий и видеть экран смерти после лобового столкновения. Выживать в космосе — это весело, а выжить с помощью истории — еще веселее, потому что вы можете просто пропустить все это, чтобы рассердить сценаристов! Breathedge предлагает вам интригующий сюжет с множеством мрачных шуток, циничных диалогов, бессмертного цыпленка, безумного врага, а также плохо анимированные ролики и другие особенности, которые делают отличную игру отличной игрой. No related posts. alexxlab Автор записи Добавить комментарий Отменить ответ Ваш адрес email не будет опубликован. Обязательные поля помечены * Комментарий * Имя * Email * Сайт