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

Привет! Меня зовут Алёна Исакова, я ведущий тестировщик в Авито, и я хочу рассказать вам про свой опыт введения Agile-тестирования в команду. Когда я читала доступные на русском языке статьи про Agile-тестирование и ATDD, у меня сложилось впечатление, что я «не модная», «не по Agile». Казалось, что это некая сложная структура, которая требует включения разработчиков, и до её применения мне ещё «пахать и пахать».
Какое-то время я жила с этой мыслью, писала в задачи чек-лист проверок при постановке, собирала встречи «feature-team», на которую приглашались PM, QA, Frontend и Backend для обсуждения нюансов задачи до начала реализации.

Как мы внедряли Agile-testing - 1

Те, кто понимают о чем речь, уже заметили подвох, не правда ли?

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

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

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

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

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

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

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

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

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

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

Как проверить идеи, архитектуру и алгоритмы без написания кода? Как сформулировать и проверить их свойства? Что такое model-checkers и model-finders? Требования и спецификации — пережиток прошлого?

Привет. Меня зовут Васил Дядов, сейчас я работаю программистом в Яндексе, до этого работал в Intel, ещё раньше разрабатывал RTL-код (register transfer level) на Verilog/VHDL для ASIC/FPGA. Давно увлекаюсь темой надёжности софта и аппаратуры, математикой, инструментами и методами, применяемыми для разработки ПО и логики с гарантированными, заранее определёнными свойствами.

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

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

Инженерный подход к разработке ПО - 1

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

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

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

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

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

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

Что же делать? Как работать с Игнатом? Добро пожаловать под кат!

«Сгоревшие» сотрудники: есть ли выход? - 1
Читать полностью »

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

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

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

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

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

От монолитов к модульности команд - 1

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

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

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

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

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

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


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