#Ускорение4X. Генеральные цели

Все, вступления закончились, начинаем изучать практические приемы, из которых состоит #Ускорение4X.

Если вы — тот человек, который берется за внедрение #Ускорения4X в команде, то первый шаг придется сделать вам.

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

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

Как сторимэп помогает не завязнуть в разработке нового продукта на годы

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


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


Чтобы разобраться, мы использовали сторимэп. Этот инструмент помог спланировать работу и запустить «Свою пиццу» за 2,5 месяца. В статье рассказываем, как применяем сторимэп.

Читать дальше →

Почему Agile не работает и что с этим делать

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

Читать дальше →

Redmine, который вы захотите попробовать

Лет 8 тому назад я, начинающий менеджер проектов, начал работать в Redmine. Перед друзьями я хвалился, что все мои проекты хранятся в интернете! И это было круто!

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

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

image

Читать дальше →

Ланнистеры всегда платят свои долги! (и технические тоже)

Практики управления техническим долгом в отдельно взятой команде

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

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

Что удалось получить в результате:

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

Давайте расскажу, как мы этого добились.

Читать дальше →...Далее...

Проведение ретроспективы по методу шести шляп

В следующие несколько абзацев хочу поделиться не так давно случившимся у меня опытом проведения ретроспективы по методу шести шляп. Метод шести шляп (англ. Six Thinking Hats) — метод организации мышления, помогает взглянуть на проблему с разных сторон, а также одна из разновидностей мозгового штурма при работе в команде.
Интересно будет тем, кто ищет новые способы проведения ретроспектив, кто интересуется командной работой, подходами к принятию решений и генерации идей.
Цель текста — рассказать, что такой метод есть, на основе простого примера показать, как его можно использовать для организации ретроспективы; вызвать интерес у читателя для дальнейшего самостоятельного изучения этого метода.

Читать дальше →

[Перевод] Методология VR-разработки

Данная статья является последней в цикле про качественную разработку VR-проектов. Ранее мы уже изучили принципы подбора контента для наших проектов в статье «VR Design: содержимое сцен». Ссылки на другие материалы можно найти в обзорной статье. Разработка проектов с виртуальной реальностью — непростая задача не только из-за того, что VR является очень молодым средством коммуникации. Возможности и ограничения технологии делают разработку достаточно сложной. Как соответствовать таким требованиям, чтобы разрабатывать хорошие VR-проекты, мы узнаем в этой статье. После того, как мы пробежались по основным особенностям VR-разработки в этой серии статей, рассмотрим последнее, самое важное для тебя, как для разработчика, средство: итеративный процесс разработки. Также мы разберем, почему ты не всегда можешь доверять себе и что означает понятие «VR legs».
You have to be super experimental and be willing to accept that a lot of the old ways of doing things just do not work at all anymore. Joel Green из Cloudhead Games, Группа разработки The Gallery

Итеративный процесс разработки

image ...Далее...


Последние посты