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

Держи пари

Отличная семейная игра-викторина для веселого времяпрепровождения. В ней 700 вопросов — но выигрывает тот, у кого лучше развита интуиция, а не эрудиция. Каждый раунд ведущий зачитывает вопрос, а другие игроки пишут ответы. Анонимные карточки с ответами выкладывают на игровое поле, и все пытаются угадать, какой из них верный. Для этого игроки делают ставки на свой или чужой ответ. Если есть абсолютная уверенность, можно дополнить ставку фишкой — 1, 5 или 25 очков. Выигрывает тот, кто наберет больше очков за все семь раундов.

Сложность — простая.

Возраст — от 10 лет.

Количество игроков — от 4 до 20 человек.

Навыки — интуиция, внимательность, скорость переработки информации.

Варианты — нет.

Эврика

«Эврика» — игра, в которой важно быстро вспоминать слова по теме. Игроки раскладывают карты рубашкой вверх на две равные стопки, а затем каждый кладет по одной перевернутой карте себе. Как только у игроков совпадут символы на картах, необходимо быстро выкрикнуть слово по теме, которая написана на карте оппонента: это может быть «Дерево», «Слово из трех букв» или «Знаменитая собака». Нужно назвать имя, предмет или понятие. Если сказали слово раньше соперника, забираете его карту себе. Выигрывает тот, кто соберет больше всех карт.

Сложность — простая.

Возраст — от 6 лет.

Количество игроков — от 3 до 6 человек.

Навыки — быстрое мышление, скорость реакции.

Варианты — «Универсум», «Терра», «Игнис», «Венус».

Шакал

Для тех, кого манит пиратская романтика, создана игра «Шакал». Ей уже около 40 лет, но интерес к ней не ослабевает. Это связано с продуманной механикой и многочисленными вариантами игрового поля. Цель — найти сокровища и перенести их на свой корабль. Для этого игрок управляет тремя пиратами: они рыщут по острову, разыскивая сокровища, отбирают их у других пиратов, могут познакомиться с прекрасной туземкой или полететь на воздушном шаре.

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

Сложность — средняя.

Возраст — от 6 лет.

Количество игроков — от 2 до 4 человек.

Навыки — внимательность, пространственное мышление, логика.

Варианты — «Карточная игра», «Архипелаг», «Остров сокровищ», «Подземелье», Lux.

Поднять перископ

Сюжет игры заинтересует любителей альтернативной истории. Действие происходит в 1918 году, во время Первой мировой войны. Сражение идет на море — игроки управляют старинными подводными лодками. Игра состоит из двух частей: комплектации субмарин и поединка. В начале игрок выбирает 10 карточек-отсеков для моделирования и составляет из них корабль. Каждый отсек обладает четырьмя характеристиками: тип, действие, запас прочности и запасы кислорода — каждую надо продумать и учесть при строительстве. Если только начинаете играть — используйте готовые наборы подводных лодок.

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

Сложность — средняя.

Возраст — от 13 лет.

Количество игроков — 2 человека.

Навыки — стратегическое мышление, логика.

Варианты — нет.

LibertEx

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

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

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

Сложность — средняя.

Возраст — от 12 лет.

Количество игроков — от 3 до 6 человек.

Навыки — финансовая грамотность.

Варианты — другие издания LibertEx.

Проект Манхэттен

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

Сложность — сложная.

Возраст — от 12 лет.

Количество игроков — от 2 до 5 человек.

Навыки — стратегическое мышление.

Варианты — нет.

Космические дальнобойщики

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

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

Сложность — высокая.

Возраст — от 13 лет.

Количество игроков — от 2 до 4 человек.

Навыки — стратегическое мышление.

Варианты — нет.

Космическая тревога

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

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

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

Сложность — высокая.

Возраст — от 12 лет.

Количество игроков — от 1 до 5 человек.

Навыки — стратегическое мышление.

Варианты — нет.

Надеюсь, подборка вам пригодится. Меня больше всего заинтересовали «Эврика» и LibertEx, а вас?

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

Андрей Черабаев, разработчик ИТ-компании MediaSoft:

Свой язык. В основном мы разговариваем матом и обычными английскими словами: фича (feature), релейшен (relation), миддлварь (middleware). По смыслу там ничего сложного. А моя сестра почему-то называет этот язык «эльфийским». Хотя иногда понять программиста действительно сложно. Как можно адекватно воспринимать человека, если он ходит злой потому, что на работе у него «в API булево поле имеет три значения»?

Все воспринимается как задача. А иногда ты начинаешь решать задачу, которой нет. Знаете шутку про «они только познакомились, а она уже решила, как будут звать их внуков»? Я так случайно начал составлять список гостей, когда моя девушка пошутила про свадьбу. У нее минут десять ушло, чтобы объяснить, что это шутка.

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

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

Виктор Ефимов, инженер по архитектуре, команда архитектуры REG.RU:

Особое отношение к быту. Вот впечатления моей второй половинки:

• Любое мероприятие сложнее выноса мусора снабжается планом или чек-листом.
• Для сложного мероприятия также формируется архив информации в виде записок, фотографий и фотографий записок.
• Просьба поадминить нештатное для меня существо — типа кошки — выполняется только при наличии ТЗ или инструкции.
• При непонятном событии, форс-мажоре (кто-то заболел, случился потоп, отключили свет) сразу заводится журнал, где по минутам записывается происходящее — чтобы потом, когда понадобится, можно было восстановить картину.
• В бытовой обиход вошли слова «админить», «ТЗ».

Список составлен с помощью чек-листа c последующим письменным согласованием со второй половинкой.

Антон Боев, технический директор digital-компании DD Planet:

Умение сосредотачиваться. Профессия развивает способность к концентрации — работаем с большим количеством информации.

Тютюнников Антон, программист, команда внутренних сервисов в REG.RU:

Постоянные отсылки к программированию в быту. Делали для детей квест дома, и там было задание: нарисовать клеем ПВА на файле для бумаг снежинки, чтобы, когда подсохнут, их можно было снять и украсить что-то. Жена спросила, можно ли заменить клей гелем с блестками. Я сказал, что надо попробовать — наверное, можно. Когда дети выполнили задание, результат оказался немного не тем: снежинки из геля получились не очень объемными, хотя блестящими и красивыми. А жене я сказал: «Ты что, без тестирования сразу в прод запустила?»

Елисей Самретов, разработчик программных продуктов FL.ru:

Все воспринимается слишком логично. Как в шутке, где жена попросила: «Купи молоко, и если будут апельсины, то пять», — а айтишник принес пять пакетов молока. Так что лучше точно объяснять, сколько чего надо. Иначе придется всю неделю есть простоквашу.
Любовь «докапываться». К решению любых вопросов, даже в обычной жизни, разработчики применяют аналитический подход. Будут выяснять, какие плюсы и минусы у каждого из решений, поэтому время на ответ может растянуться. За просьбой купить хлеб последует уточнение: «А какой?». И это не финальный вопрос, поверьте.

Привычка общаться на «ты». Еще в IT-сфере все на «ты» даже с топ-руководством. Поэтому в разговоре с управляющим партнером проскальзывают реплики вроде: «Толя, а ты посмотрел мой road map по API?» — а в ответ: «Ок, к вечеру заапрувлю после спринта». И все отлично понимают друг друга.

Булат Сальманов, Technical Head of Social Media Marketing Department в SEMrush:

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

Гиперконцентрация. Во время разговора с женой могу выпадать, обдумывая часть диалога. Самое забавное, что в этот момент я все слышу и запоминаю, но не понимаю. Жена спрашивает: «Ты вообще слушаешь меня?» Я слово в слово повторяю ее речь, но понимаю смысл только после того, как выхожу из состояния концентрации.

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

А как проявляется ваша «профдеформация»?

Разговариваем о том, как выглядит стажировка в GB и что она дает. Попутно обсуждаем путь в профессию, выбор между JS/PHP и fullstack JS, создание портфолио. Мой собеседник — Владислав Мищенко — освоил веб-разработку в GeekBrains и стал наставником.

— Владислав, чем занимаетесь сейчас?

— Прохожу стажировку по итогам курса веб-разработки: обычно она длится полтора месяца, но мы взялись за масштабный проект — форум. Его за такое время удалось написать лишь на 35–40 %. Чтобы получить минимально жизнеспособный продукт, пришлось идти «на второй круг». Пишем уже третий месяц. Сейчас делаем личный кабинет и авторизацию через соцсети.

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

— Чем стажировка в GeekBrains отличается от финального проекта по профессии?

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

Если за отведенное время проект завершить не удалось, стажировку можно продлить, повторить, как это и получилось у нас. Не могли же мы просто махнуть рукой и сказать: «Ладно, будем считать, что закончили». Для меня это точно не вариант. Преподаватель Сергей Кручинин спросил, кто хочет продолжать. Я записался, ведь без завершенного проекта терялся смысл стажировки.

— Берут всех или есть отбор? И кто предлагает идею?

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

Главная страница форума

— Ваш участок работы в команде?

— Я в первую очередь менеджер: координирую работу над бэкендом и с тимлидами других команд, проверяю код участников. Если нахожу ошибки — объясняю, что исправить. Если у кого-то из коллег возникают трудности — подключаюсь к проблемной задаче и вместе мы ее решаем. То есть на мне организаторские задачи и code review.

— Опыт проджект-менеджера для резюме?

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

— На чем пишете и сколько вас в бэкенде?

— Используем PHP, фреймворк Laravel. На стажировке по веб-разработке нас четверо, включая меня.

— Сколько времени уделяете проекту ежедневно?

— Стараюсь заниматься форумом не менее 2–3 часов в день, по возможности — 4–5 часов. Бывает, до двух дней не прикасаюсь к проекту, потому что выполняю заказы на фрилансе.

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

Базовое оформление дизайнеры нарисовали еще в «первый заход» стажировки. Теперь они изредка что-то дорабатывают или объясняют нам назначение неподписанных элементов интерфейса.

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

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

Второй момент — мы изучаем новые фреймворки. В основном курсе мы работали с Yii 2, а для проекта понадобилось учить Laravel. Это приблизило нас к реальной ситуации, когда на работе требуется быстро вникнуть в незнакомую технологию.

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

Так выглядит страница темы на форуме

— Какое образование получали до GeekBrains?

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

— В интересах у вас многое перечислено: JS, PHP, Python, Java, — то есть вы искали свое направление, свой стек технологий. А в итоге решили на вебе сосредоточиться. Почему?

— Так исторически сложилось. Я начинал как автоматизатор тестирования: для тестов использовал Java, затем переключился на полноценную Java-разработку. Позже возглавлял отдел разработки на оборонном предприятии. Мы писали Windows-приложения на C# для внутреннего использования в организации.

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

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

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

Сначала я купил обучение профессии «Веб-разработчик», а затем еще прошел бесплатный курс Ruby, который выиграл по конкурсу. Занимался практически параллельно: веб-разработку начал с марта, Ruby — с июня. Так что я проходил 2–3 курса в месяц.

— Ruby пока не пригодился?

— В Нижнем Новгороде найти вакансию разработчика Ruby не так просто: требуют большой опыт. Но я не жалею, что изучил основы языка и фреймворк Ruby on Rails. Финальным проектом по этому курсу наша команда сделала сервис Linker, который позволяет создавать коллекции ссылок и обмениваться ими онлайн. Нас было шестеро, я отвечал за менеджмент. Сейчас этот проект в моем портфолио. Интересный опыт.

Фрагмент главной страницы проекта

— Веб-разработчику со знанием PHP проще в Нижнем Новгороде найти работу?

— Вакансии есть, но такой, которая бы меня зацепила, пока не нашел. Хочу профессионально развиваться, а не сидеть на одном PHP-фреймворке или на одной CMS типа Wordpress или Bitrix. Мне нужна компания, которая предложит разноплановые проекты и перспективы карьерного роста.

— Дистанционные варианты рассматриваете?

— Сейчас я как раз фрилансер: сотрудничаю с заказчиками из других городов. Но параллельно ищу постоянное место.

— Предпочитаете офис?

— Да. Когда смотришь, как работают другие, проще настроиться на дело. Дома я более расслаблен.

— Пока вы учились на веб-разработчика, было деление на тех, кто хочет в fullstack, и тех, кому нужен только бэкенд?

— Некоторые предметы мы изучали вместе. Для большей ясности приведу пример. Курс «JS. Уровень 1» — он и для веб-разработчиков полного цикла, и для фронтендеров, и для тех, кто купил отдельный курс вне профессии. Со мной учились люди не только с курсов GeekBrains, но и из GeekUniversity. Были новички в программировании, были и опытные люди, которые пришли освоить новую для себя технологию.

— Кстати, почему вы не захотели стать fullstack-разработчиком JS?

— Я покупал профессию, когда работал в веб-студии, где мы использовали системы управления контентом: Wordpress, Open Cart и Bitrix. Все эти CMS написаны на PHP. Мне нужен был этот язык, плюс понимание бэкенда, фронтенда и верстки. Поэтому профессия «Веб-разработчик» подходила идеально.

Но от перспектив fullstack-разработки я не отказываюсь: с конца февраля начну проходить курс Node.js, который получил в подарок от GeekBrains. Node.js — это фреймворк, который позволяет писать серверную часть сайта или веб-приложения на JavaScript. Когда освою его, до JS-разработчика полного цикла мне останется изучить Vue и/или React.

— Кроме форума и сервиса Linker, какие сделанные в GeekBrains проекты возьмете в портфолио?

— Я вставил в резюме ссылку на GitHub, где храню проекты, которыми горжусь и за которые меня хвалили преподаватели. Один из них — интернет-магазин на чистом PHP, который я делал на курсе «PHP. Уровень 2». Да, это учебная работа: в базе магазина всего несколько товаров. Зато я глубже вник, как реализовать функции: корзину, разбивку по категориям, подбор товара и другие.

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

— Сколько времени заняло написание интернет-магазина?

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

— Вы не только ученик, но и наставник в GeekBrains. Сколько времени это отнимает и насколько трудно?

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

Мне нравится, что через наставничество я сам учусь. Студенты подчас задают очень интересные вопросы с подвохом. С ходу не ответишь — идешь в Google, вникаешь и дальше объясняешь, как сам понял. Это помогает разобраться в темах, которые ускользнули из твоего поля зрения во время учебы.

— Как собираетесь дальше развиваться в карьерном плане?

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

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

Осторожно: в текст могли просочиться спойлеры.

Сезон 1. Эпизод 2. 15 миллионов заслуг

Что в серии

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

Единственный способ вырваться из этого беличьего колеса — участвовать в шоу талантов. Главный герой Бингем Мэдсен услышал, как поет Эби, и предложил ей выступить перед жюри. Чтобы купить для нее это право, он отдает все свои «заслуги».

Что на самом деле

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

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

Сезон 1. Эпизод 3. История всей твоей жизни

Что в серии

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

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

Что на самом деле

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

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

Первый прототип таких линз представлен в 2011 году. В 2016 презентовали вариант, который взаимодействует со смартфоном.

Сезон 2. Эпизод 1. Скоро вернусь

Что в серии

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

Что на самом деле

В Южной Корее запустили приложение With me. Если человек при жизни позволит отсканировать себя в 3D-принтере, цифровой клон сможет жить бесконечно. С помощью приложения, например, можно сделать селфи с умершим.

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

Сезон 2. Эпизод 6. Момент Уолдо

Что в серии

Анимированный медведь Уолдо — персонаж местного телешоу. Он жестко шутит, задает гостям провокационные вопросы. Медвежонок настолько популярен, что включается в гонку за президентское кресло. Вот только Джейми Солтеру, который оживляет персонаж, все это не нравится.

Что на самом деле

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

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

Сезон 3. Эпизод 1. Нырок

Что в серии

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

Что на самом деле

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

Сезон 3. Эпизод 3. Заткнись и танцуй

Что в серии

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

Что на самом деле

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

Безопасность веб-камер тоже под вопросом. Если уж основатель Facebook Марк Цукерберг заклеивает камеру, то и остальным не стоит от него отставать.

Сезон 3. Эпизод 5. Люди против огня

Что в серии

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

Что на самом деле

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

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

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

Сезон 3. Эпизод 6. Враг народа

Что в серии

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

Что на самом деле

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

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

Сезон 4. Эпизод 2. Аркангел

Что в серии

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

Что на самом деле

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

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

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

Сезон 4. Эпизод 3. Крокодил

Что в серии

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

Что на самом деле

В начале 2018 года произошло сразу две автокатастрофы с участием беспилотников. Машина Uber насмерть сбила женщину, которая переходила дорогу. Спустя неделю внедорожник компании Tesla въехал в бетонное ограждение и загорелся — водитель погиб. При этом эксперты считают, что дорожные происшествия с участием беспилотников вовсе не свидетельствуют, что они опаснее обычных машин.

Что касается доставки пиццы, Pizza Hut намерена запустить свои беспилотные автомобили в 2020 году.

Сезон 4. Эпизод 4. Повесь диджея

Что в серии

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

Что на самом деле

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

Сезон 4. Эпизод 5. Металлист

Что в серии

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

Что на самом деле

Авторы вдохновились роботами Boston Dynamics. Четвероногий Spot Mini с манипулятором вместо головы умеет выполнять несложные работы по дому, открывать двери, перемещаться по лестницам.

Черное зеркало: Брандашмыг

Это интерактивный фильм, выпущенный в 2018 году. Главный герой — программист: он создает видеоигру на основе фэнтезийного романа. Зрители могли просто посмотреть фильм или повлиять на ход событий. Принять решение в ключевых точках сюжета надо было за 10 секунд.

С технической точки зрения здесь интереснее не что показывают, а как. Примечательно, что геймифицирована серия о создании игры. «Брандашмыг» — не первый и не единственный интерактивный фильм, но исходя из тематики сериала — ожидаемый.

А какие технологии из «Черного зеркала» вам запомнились? Что бы вы хотели видеть в реальности, а чего ни в коем случае нельзя допускать?

Swift существует, чтобы упрощать создание софта для устройств Apple. Тем удивительнее, что до сих пор iOS и другие «яблочные» операционные системы не имели библиотек Swift в своем составе. Стандартные функции языка разработчику приходилось включать в приложение. Пользователь дольше скачивал программу и тратил на нее больше дискового пространства. Написанная на Swift 3 программа не работала с откомпилированными модулями Swift 4. Это называют отсутствием обратной совместимости. Мелочь, а неприятно.

Стандартные библиотеки Swift не были «родными» для ОС — она воспринимала их как файлы пользователя и не спешила подгружать при запуске программ. Это влияло на скорость загрузки софта. Загрузка динамических библиотек Swift занимала 95 % времени от запуска приложения до начала выполнения кода.

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

Swift 5 обеспечивает бинарную совместимость. Это значит, что написанные на нем программы смогут без перекомпиляции работать с будущими версиями языка и в последующих релизах ОС от Apple. Кроме того, больше не нужно включать в программу стандартные функции Swift — они будут храниться в системе.

Сейчас ждут релиза свежие версии систем для мобильных устройств, телевизоров и часов: iOS 12.2, macOS 10.14.4, tvOS 12.2 и watchOS 5.2 — пока они на стадии бета-версий. Когда они выйдут, пользователи откроют App Store и обнаружат, что написанные на Swift 5 приложения весят меньше. А еще программы начнут быстрее запускаться, потому что библиотеки в составе ОС будут кешироваться в памяти, чтобы приложения обращались к ним мгновенно.

Apple обещает, что старые проблемы исчезнут в одночасье — по одному обновлению!

Будут улучшения ощутимы или это реклама?

Чтобы внести ясность, вы можете скачать из App Store интересные вам приложения и посмотреть, сколько весят Swift-библиотеки к ним. Бразильский разработчик Гильерме Рамбо так и сделал. Вот какие результаты он получил:

• Twitter-клиент Chirp для Apple Watch весит 29 Мб, из которых 11,6 Мб — стандартные библиотеки Swift. После обновления до Swift 5 размер приложения уменьшится на 30 %, то есть оно будет весить менее 20 Мб. Результат впечатляющий, но он относится к библиотекам для watchOS. Как дела в iOS? Следующие приложения проходили проверку на iPhone XS Max.
• Инженерный калькулятор PСalc при весе 86,8 Мб включает 7,5 Мб стандартных библиотек. С переходом на Swift 5 размер приложения уменьшится на 9 % — до 80 Мб.
• Apollo for Reddit занимает 35,7 Мб, в том числе 7,5 Мб Swift-библиотек. Значит, в iOS 12.2 вес приложения не превысит 30 Мб, то есть сократится примерно на 20 %.

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

Для разработчиков лучшая часть новости в том, что миграция проектов с Swift 4.2 будет простой.

Код, который компилировался на «четверке», скомпилируется и в Swift 5. А вот исходники на более ранней, третьей версии языка, новому компилятору не скормить. Еще учтите, что уже скомпилированные модули Swift 4 «прикрутить» к новым программам не удастся.

Сколько ждать изменений

Те, кто пользуются бета-версиями «яблочных» операционок и ставят софт через TestFlight, могут оценить разницу в весе приложений на Swift 5 уже сейчас! Остальным придется запастись терпением: дождаться свежей релизной версии своей ОС, а потом — обновления любимых приложений, написанных на Swift 4.

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

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

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

— Сейчас я — старший разработчик Equation в «Альфа-Банке». Наша команда совершенствует систему расчетов. Если конкретнее говорить о моих задачах, это написание и доработка кода, исправление ошибок ПО.

— Как ты попал в «Альфа-Банк»? И трудно ли было искать вакансии параллельно с учебой?

— Работу я нашел на мероприятии День карьеры в GeekBrains. Такие встречи с работодателями — просто потрясающая идея. Я очень обрадовался, когда узнал о них. Участвовал два раза. И вот во второй мне улыбнулась удача.

— Как это было?

— Первый День дал мне опыт: я растерялся и толком не успел поговорить с работодателями, зато узнал, как преподнести свои знания и пройти собеседование. Особенно полезным было выступление Людмилы Карамышевой. Ее советы помогли мне составить более удачное резюме. Старое просто выкинул.

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

«Альфа» зацепила с первых минут диалога. Компанию представляли приятные и приветливые HR. Они сказали, что ищут специалистов со знанием Java и C++. После беседы обещали перезвонить буквально через пару дней. У меня было чувство нереальности происходящего и огромное желание попасть именно туда.

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

— Чем ты занимался до программирования? И с чего начался интерес к разработке?

— До программирования я учился в Московском авиационном институте (МАИ) и работал на авиационных предприятиях. Когда пришел на предыдущее место работы, понял, что не хватает знаний в области программирования (конкретно C++), и начал искать хорошие курсы.

Сначала я прошел курсы от МФТИ и Яндекса, о которых узнал на сайте Coursera. Было тяжело совмещать дополнительное образование с работой и учебой в вузе, но это принесло плоды.

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

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

— Как получилось, что ты решил сменить сферу деятельности?

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

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

— Почему ты выбрал язык Java?

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

— Легко ли было изучать Java после С++? Были какие-то сложные темы?

— После C++ изучение Java шло более чем прекрасно. Достаточно было провести аналогию между двумя языками, и все становилось на свои места. Сложных тем в Java после C++ не было как таковых. Безусловно, эти языки не полностью идентичны, но похожи.

— Расскажи, пожалуйста, какие именно проекты ты уже сделал и как их оцениваешь?

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

— Какой проект был сложнее, а какой принес больше удовольствия?

— Сложным я бы назвал создание чата. Это был мой первый более-менее крупный проект, и нелегко было воедино связать большие объемы кода. Пришлось попотеть, прежде чем у меня выработалось ясное и четкое понимание, что и как делать. Первое время было тяжело понять клиент-серверное взаимодействие. Но и это прошло. :)

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

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

— Что за игра в итоге получилась?

— Мы разрабатывали своего Bomberman’а. Я сразу понял, сколько всего можно придумать и сделать. Здорово было делиться с преподавателем своими наработками и получать по ним рекомендации. Но главное — это был проект, к которому раз за разом хотелось возвращаться, чтобы дорабатывать.

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

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

— А кто вел курс разработки игр?

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

Кстати, именно в работе над игрой я впервые на практике применил Gradle и Maven. А они очень востребованы на моей нынешней работе!

— Были еще какие-то учебные курсы в GU, которые тебе особенно запомнились и помогли?

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

Также был очень интересен курс HTML/CSS. Очень жаль, что я пока не успел его закончить.

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

— Я поступил в GeekUniversity в декабре 2017 года, а на работу устроился в сентябре 2018. За это время некоторые курсы пришлось перепройти: не все успевал с первого раза, потому что параллельно работал и учился в университете офлайн. Но я все-таки благополучно добрался до конца второй четверти в GU.

— И вот ты на собеседовании в «Альфа-Банке». Трудно было? И долго ли ты к нему готовился?

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

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

— В базовых вопросах знаний хватает, но, безусловно, учиться приходится многому. Во время испытательного срока понадобилось на новом уровне изучить Gradle, git и язык программирования RPG. Уверен, что первые два пункта дались бы мне гораздо легче, если бы я доучился в GU до конца. А вот RPG в любом случае понадобилось бы учить с нуля. Но благодаря знанию Java и C++, я без особых проблем освоил третий язык на минимально необходимом уровне.

Совсем недавно я прошел курс TDD на Java и получил сертификат, подтверждающий мои компетенции.

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

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

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

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

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

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

— Когда планируешь вернуться к обучению в GeekUniversity?

— Собираюсь где-то в начале марта. Очень надеюсь, что к этому времени успею разобраться со всеми делами: окончить вуз и защитить диплом.

— Спасибо тебе за историю. Успеха в любимой работе и, конечно, в дальнейшем обучении!

GeekBrains уже рассказывал о «Водопаде» (Waterfall), на очереди — Agile: познакомимся с этой схемой, по которой организуют работу многие коллективы программистов.

В феврале 2001 года семнадцать человек — крупные IT-специалисты и разработчики — собрались на горном курорте в штате Юта. Отдохнули, пообщались и составили небольшой документ — Agile-манифест.

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

Гибкость во всем

С английского agile переводится как «подвижный, быстрый, проворный». Но в русской IT-лексике за этой группой методологий закрепилось определение «гибкие». Agile-подход динамично организует программирование, постоянно адаптируя проект к новым обстоятельствам и требованиям.

Не углубляясь в детали, вспомним, как устроена разработка по методологии Waterfall:

1. Выдвигаются требования к ПО, разрабатывается техническое задание (ТЗ).
2. Поставленные задачи воплощаются в коде.
3. Выполняется тестирование.
4. Готовое ПО внедряется в работу.

Теоретически в Waterfall возможен возврат на предыдущие ступени — например, если оказывается, что ту или иную задачу невозможно выполнить по техническим причинам. В этом случае ТЗ пересматривают, но это скорее чрезвычайная ситуация. В норме конечный продукт должен идеально соответствовать требованиям, целям и задачам, которые были сформулированы до разработки.

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

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

Чтобы понять, как это работает, представим коллектив разработчиков, создающих аудиоплеер. Уже написан костяк программного кода: интерфейс и базовый функционал. Программа умеет воспроизводить файлы формата MP3, WAV и OGG. Но пользователи предлагают добавить проигрывание CD-дисков и подключить горячие клавиши, чтобы быстро управлять плеером.

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

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

На этом итерация завершается — и начинается новый виток разработки.

Идеи и принципы

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

Четыре центральных идеи Agile Manifesto

• Люди и взаимодействие важнее, чем процессы и инструменты.
• Работающее ПО важнее, чем исчерпывающая документация.
• Сотрудничество с заказчиком важнее, чем согласование условий контракта.
• Готовность к изменениям важнее, чем следование первоначальному плану.

12 принципов Agile

1. Задача высшего приоритета — регулярно и как можно раньше удовлетворять потребности заказчика, предоставляя ему программное обеспечение.
2. Учитывать, что требования могут измениться на любом этапе разработки. Если изменения быстро вносятся в проект, заказчик может получить конкурентные преимущества.
3. Выпускать версии готовой программы как можно чаще — с промежутком от двух недель до двух месяцев.
4. Ежедневно вместе работать над проектом — разработчикам и заказчикам.
5. Поручить работу мотивированным профессионалам. Обеспечить поддержку и условия, довериться им — и работа будет сделана.
6. Общаться напрямую — это самый эффективный способ взаимодействия внутри команды и вне ее.
7. Считать главным показателем прогресса работающий продукт.
8. Поддерживать постоянный ритм работы — касается и разработчиков, и заказчиков.
9. Уделять пристальное внимание техническому совершенству и качеству проектирования — это повышает гибкость проекта.
10. Минимизировать лишнюю работу.
11. Стремиться к самоорганизующейся команде — в ней рождаются наиболее эффективные и качественные решения.
12. Всем участникам команды — постоянно искать способы повышать эффективность работы.

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

Scrum

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

Впервые термин прозвучал в 1986 году. Японские исследователи Икуджиро Нонака и Хиротака Такеучи в статье The new New product development game сформулировали принципы, позволяющие быстрее создавать новый продукт. Среди условий такой разработки назвали самоорганизующуюся команду специалистов, их полную свободу в творчестве и работе — без ограничений со стороны топ-менеджмента. Этот подход авторы описали так:

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

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

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

Методика, предложенная Нонака и Такеучи, нашла применение в IT-сфере, разработке инженерных решений в машиностроении, электронике. В 90-х Scrum оформился как проработанная и цельная методология, оброс конкретными приемами, помогающими с нуля наладить работу команды. Благодаря Кену Шваберу и Джеффу Сазерленду Scrum пришел в IT и приобрел популярность среди разработчиков — некоторые даже считают эту методологию революционной.

Командный дух

В команде, работающей по принципам Scrum, нет внутренней иерархии: ни руководителей, ни подчиненных, ни указаний-приказов. Есть два особых члена группы: product owner — владелец продукта, и scrum master — скрам-мастер.

Product owner лучше всех знает, каким должен быть продукт. Зачастую это заказчик, его представитель или сотрудник, ответственный за взаимодействие с клиентом. Он должен ясно понимать, что именно требуется конечному пользователю программы. Все пожелания и предложения по функциональности и внешнему виду продукта (в Scrum они называются stories — истории) он заносит в специальный список — Product Backlog. Бэклог формируется до старта разработки и по ходу постоянно пополняется. Здесь же указывают приоритеты доработок.

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

Рывок! Еще рывок!

Работа над программой в Scrum, как и в Agile в целом, разделена на итерации. Здесь любят спортивную терминологию: эти отрезки разработки называют забегами или спринтами. Каждый начинается с того, что команда сообща определяет, какие именно истории из списка владельца продукта она сможет реализовать на этом спринте. Выбранные идеи переносятся в отдельный список — sprint backlog. Фиксируется цель: что конкретно команда сможет продемонстрировать пользователю в итоге. Задачи распределяют, и начинается забег.

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

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

Важно помнить, что в итоге скрам-забега пользователь получает готовую версию программы: можно запускать и работать. На ранних этапах проекта программа может быть способна только вывести сообщение «Hello, world!». Но даже самый первый спринт должен дать результат: программа уже есть и она запускается.

XP — программируем экстремально!

Речь не о Windows XP. Под этой аббревиатурой скрывается еще одна методология из класса Agile: eXtreme Programming — экстремальное программирование. Ее придумал разработчик Кент Бек, развивали Уорд Каннингем, Мартин Фаулер и другие. Это набор простых принципов и практик, которые помогают наладить эффективную работу.

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

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

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

Экстремальные практики

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

В начале каждого цикла разработчики устраивают общее собрание — представителя заказчика тоже приглашают. Совместно решают, какую функциональность будут реализовать. За основу берутся пользовательские истории — то есть задачи и требования — с учетом их значимости.

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

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

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

Другая полезная практика — постоянная коллективная работа. XP подразумевает тесное сотрудничество и взаимопомощь. Разработку ведут в группах по десять человек, которые активно обмениваются информацией. Практикуется парное программирование: один разработчик создает модуль, второй наблюдает.

Парное программирование — одна из полезных практик XP

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

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

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

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

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

Переработку XP не поощряет: требует от программистов неукоснительно соблюдать рамки 40-часовой рабочей недели. Никаких «я только допишу эту функцию»! Если не умеете переключаться и отдыхать — скоро не сможете и продуктивно работать.

Экстремально — не значит плохо

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

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

Экстремальное программирование не предписывает, как действовать в конкретной ситуации. Если решение задачи для всех очевидно и написать код не составит труда — нет реальной необходимости в парном программировании. Если на часах 18:00, а вам осталось дописать двадцать строк кода — можно не откладывать на завтра. Методология не заменяет здравый смысл!

Никакого волшебства

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

Agile-методологии предъявляют высокие требования к профессионализму, квалификации и настрою специалистов. Важна сплоченность коллектива, взаимное уважение и обмен опытом. Экстремальные практики не научат плохого программиста гениально кодить, Scrum не поможет конфликтному специалисту влиться в коллектив.

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

Преимущества Agile

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

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

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

Темная сторона силы: недостатки Agile

Не факт, что программа когда-нибудь будет завершена.

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

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

Пользователь требует все и сразу.

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

Работа над проектом требует не только профессионализма разработчика, но и сознательности пользователя. А спросите у программистов, часто ли им встречались адекватные, понимающие пользователи.

«Золотые пользователи»

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

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

Строительство без чертежей

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

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

Постоянная спешка

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

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

До тех пор, пока работает…

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

Кому подойдет Agile

Методологии класса Agile хорошо себя покажут, если:

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

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

Больше методологий богу методологий!

Мы рассмотрели Scrum и XP, но класс Agile включает и другие методологии. Есть любопытные подходы и вне Waterfall и Agile. Продолжим в следующей статье.