Рубрика «управление проектами» - 62

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

Раньше наш процесс релиза был ручным, медленным и напичканным ошибками.
Мы проваливали спринт за спринтом, потому что не успевали сделать и выложить фичи к следующему Sprint Review. Мы ненавидели наши релизы. Часто они длились по три-четыре дня.

В этой статье мы опишем практику Stop the Line, которая помогла нам сфокусироваться на устранении проблем конвейера выкладки. Всего за три месяца нам удалось увеличить скорость деплоя в 10 раз. Сегодня наш деплой полностью автоматизирован, а релиз монолита занимает всего 4-5 часов.
Stop the line или прокачай свой pipeline, йоу - 1
Читать полностью »

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

В этой статье я объясню, почему тебе не нужно идеальное решение.
Читать полностью »

Docs as Code. Часть 1: автоматизируем обновление - 1

В больших проектах, состоящих из десятков и сотен взаимодействующих сервисов, всё чаще становится обязательным подход к документации как к коду — docs as code.

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

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

Жизнь доклада на TeamLead Conf идет в несколько этапов. Сначала он появляется в виде заявки, потом в программе на сайте конференции, перетекает в рассылку, в анонс на Хабр и на сцену. После — живет в расшифровке на Хабре и YouTube-канале, если попал в список лучших. Чтобы перейти из стадии заявки в стадию «Отличный доклад! Надо запостить об этом в Facebook» требуется много времени — порой месяцы. В это время спикеру помогает Программный комитет: структурирует мысли, убирает лишнее, ищет примеры, смотрит презентациею и выступления. Но эту работу мало кто видит. Как у айсберга 90% массы спрятаны под водой, так и 90% работы над докладом спрятаны от глаз.

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

От заявки до сцены. Жизнь доклада на Saint TeamLead Conf 2019 - 1
Читать полностью »

Основатели стартапов страдают от депрессии и наркомании. Это цена смелости и яркого воображения - 1Для инвесторов и работников компании выход стартапа на IPO — праздник, но основателю компании и её исполнительному директору непросто пережить этот момент. Физически тяжело. В целом, первые годы жизни бизнеса — непростое испытание для предпринимателей, пишет The Wall Street Journal.

Слева на диаграмме показаны результаты исследования 2016 года, проведённого специалистами из Калифорнийского университета в Сан-Франциско, Калифорнийского университета в Беркли и Стэнфордского университета. Это распространённость психических расстройств среди предпринимателей, в сравнении с контрольной группой. Среди них депрессия, ADHD (синдром дефицита внимания и гиперактивности), тревожность, злоупотребление психоактивными веществами и биполярное расстройство. По некоторым показателям предприниматели превосходят контрольную группу в несколько раз.
Читать полностью »

Я постоянно делаю коммиты в проекты open source (Red Hat и др.). И заметил, что больше всего времени отнимают негативные код-ревью, субъективные по сути. Чаще всего такое происходит с коммитами, где мейнтейнеру по какой-то причине не нравится ваше изменение. В лучшем случае такая стратегия код-ревью приводит к потере времени в бессмысленных спорах; в худшем случае он активно препятствует коммиту, создавая враждебную и элитарную среду.

Код-ревью должен быть объективным, кратким и, по возможности, содержать только определённые факты. Это не политический или эмоциональный спор, а технический. Его цель — продвижение вперёд, развитие проекта и всех участников. Любой коммит должен оцениваться только по существу, а не по субъективному мнению.
Читать полностью »

Даже в очень крупных компаниях часто отношение к разработчикам, как к грибам: держат в темноте и кормят навозом. Пишите код, родные, и не высовывайтесь. Этот подход может быть удобен для многих (в том числе иногда — для самих разработчиков в случае не очень адекватного менеджмента), но с точки зрения бизнеса неоптимален. Моя позиция: разработчики должны иметь возможность узнавать всё то, что происходит в компании и на рынке, но без давления. Захотел — копнул и разобрался, не захотел — не надо.

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

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

Здравствуйте. Я уже давно не пишу на php, но то и дело натыкаюсь на интернет-магазины на системе управления сайтами Битрикс. И я вспоминаю о своих исследованиях.

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

И это всё очень интересно.

Джумла вызывает смех.
Вордпресс вызывает удивление.
Битрикс вызывает ненависть. Почему? Я захотел ответить именно на этот вопрос, и этот ответ оказался неожиданным.
Читать полностью »

Дорогой Agile, мне надоело притворяться - 1

«Agile мёртв». Люди всё время так говорят. Но обязательно добавляют: «Мы просто шутим». Они типа имели в виду, что это у тебя такие неправильные и глупые практики, что это для тебя Agile мёртв. Но «настоящий» Agile не мёртв. Просто все его делают неправильно. Так что я понял: настоящий Agile — это, знаете ли, Agile в теории. Даже я его внедрял. И знаете что? Мне надоело.

Недавно я видел в статьях ту же самую старую защиту: «Но-но-но, проблема в водопаде, скраме и неправильной реализации Agile, несоблюдении Манифеста… бла-бла-бла». Тогда Боб Маршалл сказал мне правду. Он сказал: «Заткнись, Чарльз. Манифест Agile — это кувшин, который мы наполняем». Он сделал несколько замечаний, с которыми мне пришлось согласиться. Я задумался. Результатом стала эта статья.
Читать полностью »

Казалось бы, что сложного может быть в планировании своей работы? Берёшь листок бумаги, записываешь на нём задачи, делаешь — всё просто. Но в реальности планирование почему-то не работает «из коробки».

Кругом враги. Как параноику планировать свою работу - 1

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

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


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