Рубрика «управление разработкой» - 84

image

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

Но что, если вы не хотите признавать, что функцию или проект нужно менять или даже отказаться от них полностью?

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

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

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

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

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

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

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

Автор статьи — Патрик "tyil" Спек

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

Перечислим платформы с поддержкой повторяющихся пожертвований. Это самый удобный способ обеспечить стабильный доход.
Читать полностью »

Devops в кровавом энтерпрайзе - 1
Вот к такому можно стремиться

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

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

Или:

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

Читать полностью »

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

Как сделать внутренний продукт внешним. Опыт команды Яндекс.Трекера - 1

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

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

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

Читать полностью »

От 15 и больше: как обеспечить масштабируемость CI - 1

Сейчас публикуется много статей и докладов про конкретные технологии в DevOps: Docker, Kubernetes, Ansible… Я же хочу поговорить про построение процессов и про то, как мы в Wrike за два с половиной года эволюционировали от релизной системы для 15 фронтенд-разработчиков до почти 60-ти, и 2-3 деплоев в день.

Эта статья — про те уроки, которые мы на этом пути решили. Статья основана на моем докладе для DevOps митапа в Wrike Tech Club. Если некогда читать, есть видеозапись презентации. Читатели, добро пожаловать под кат.
Читать полностью »

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

Почему Agile не работает и что с этим делать - 1Читать полностью »

Почему я не веду разработку ПО в Trello? - 1

Я давно являюсь поклонником Trello. Чтобы вы понимали, я пользовался Трелло с 2011 года — именно тогда он вышел на рынок. В этой статье я хочу рассказать о том, чего не хватает в Трелло разработчикам ПО и что с этим можно сделать.
Читать полностью »

image

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

  • Четкая миссия — заявленная причина существования группы.
  • Свободное участие — насколько легко люди могут присоединиться к группе.
  • Прозрачность — насколько открыто и публично принимаются решения.
  • Бесплатные участники — как много можно платить людям за участие.
  • Свобода работы с материалами (ремиксабельность) — насколько свободно участники могут использовать работу друг друга.
  • Четкость протокола — насколько хорошо прописаны правила.
  • Компетентность власти — насколько хорошо следят за соблюдением правил.
  • Нон-трайбализм — насколько далеко распространяются права группы над своими участниками.
  • Самоорганизация — насколько свободно могут участники определять свои задачи.
  • Толерантность — как группа разбирается с конфликтами.
  • Измеримый успех — как хорошо группа может отслеживать свой прогресс.
  • Высокое награждение — как группа вознаграждает своих участников.
  • Децентрализация — насколько широко распределены участники группы.
  • Свободная рабочая среда — насколько легко создавать новые проекты.
  • Стандартная структура — насколько общая структура стабильна и предсказуема.
  • Плавность обучения — насколько легко начать и продолжить учиться.
  • Позитивность — насколько группа движима позитивными целями.
  • Чувство юмора — насколько серьезно группа себя воспринимает.
  • Минимализм — сколько лишней работы делает группа.
  • Разумное финансирование — как группа борется за выживание в экономическом плане.

Спасибо Сергею Даньшину за помощь с переводом.
Читать полностью »

На первых этапах внедрения практик DevOps в программе ЕФС возникали сложности. Например, для выстраивания pipeline некоторых проектов требовалась автоматизация сквозных сценариев с использованием пластиковых карт и электронно-цифровой подписи, тогда как использование аппаратных средств, POS-терминал и Touch Memory — таблетка, накладывает значительные ограничения на автоматизацию проверок. С какими ограничениями столкнулись и как их решали, читайте под катом.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js