Управление разработкой *

Мы продолжаем цикл публикаций о недостатках Аgile методологии. Сегодня перевод статьи о том, почему инженеры презирают Agile (много новых удивительных наблюдений!)

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

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

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

Если вам приходилось задумываться о построении эффективной экосистемы проекта и определении ролей тимлида и разработчика — статья Артема Прозорова из ZeBrains для вас.

Предлагаю вам задуматься над одним вопросом. Но не спешите с ответом, потому что он не так очевиден, как может показаться:

Какая из команд может реализовать более технически стабильный продукт? 

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

Команда №2: Один сильный разработчик. Ему помогают множество не знакомых между собой людей из разных часовых поясов. У каждого — свой набор компетенций и уровень опыта. Работой над проектом участники занимаются в свободном режиме, по несколько часов в неделю.

* * *

Ответ на этот вопрос получим к концу статьи.

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

Привет, меня зовут Оля, я Head of Processes&Practices, занимаюсь продуктовой трансформацией в inDriver. Сейчас у нас активная продуктовая и инженерная культура, система OKR, масштабное продуктовое планирование и смелые планы на будущее. Но так было не всегда. И в этой статье я расскажу о тех вызовах, с которыми мы столкнулись в процессе трансформации и о том, чего уже удалось достичь.

Всем привет. Меня зовут Даша Викторова, я Project Lead направления Outbound, которое отвечает за автоматизацию доставки в Lamoda. Сегодня поговорим про проектный менеджмент… Но не совсем :) 

Как правило, проект-менеджер (или просто PM) отвечает за реализацию проектов — как ни странно! Однако любой проект состоит не только из задач, которые ведут к достижению конечной цели, но и из процессов, от которых зависит качество и скорость их достижения.

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

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

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

Всем привет! С вами Женя, разработчик Dodo Engineering и один из ведущих подкаста «Читаем вместе». Он посвящен IT-книгам. В каждом сезоне мы планируем читать и разбирать одну книгу. Уже подходит к концу первый сезон, который мы посвятили книге Fundamentals of Software Architecture. Она написана архитекторами для архитекторов, но разработчикам, особенно тем, которые интересуются, как создавать работающие системы, тоже может быть очень интересна и полезна.

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

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

Знакомо? Нам тоже. Но мы смогли победить эти проблемы.

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

Мы в ЛАНИТ – Би Пи Эм уже больше 10 лет используем low-code платформу Pega для автоматизации сложных сквозных бизнес-процессов в российских банках. За это время мы пережили всё, с чем только можно столкнуться на проектах с Pega, и как можно догадаться, раз нас это не убило, то, значит, сделало сильнее. В этой статье поговорим про развитие платформы Pega и о том, как мы пришли к регулярным исследованиям её обновлений.

Всем привет! Сегодня в гостях у нас Олег Мельник — Technical Lead в компании Proxify, а также преподаватель в OTUS.

Поговорили с Олегом про такую роль у разработчиков как техлид.

Машина кружит по заправочной станции на окраине Питера. Подъезжает к колонке, доливает пару литров, отъезжает в парковочный карман, стоит минуту — и всё повторяется снова.

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

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

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

Описание построения процесса календарного и оперативного планирования в связке JIRA<->"локальный MSProject" на примере реализации в одном российском банке.

Привет, Хабр! Меня зовут Роман Блинов, я ведущий технический писатель в «Цифре» — в команде по развитию платформы ZIIoT. Этот пост будет о подходе Docs-as-code для документирования разработки ПО. Пишу с прицелом на тех читателей (то есть писателей), кто этот подход пока не пробовал и по факту имеет набор файлов в Confluence, файлы формата .docx и .pdf, на поддержку, обновление и оформление которых тратится порядка 70 % времени (а хотелось бы меньше), и 101 отговорку разработчиков, чтобы не участвовать в документировании.

Сначала расскажу, с какими проблемами сталкиваются писатели до перехода на Docs-as-code, затем опишу подход в общих чертах и в конце упомяну об основной трудности его внедрения по собственному опыту и опыту коллег.

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

Привет, Хабр. Меня зовут Макс. Я специализируюсь на реконструкции и развитии процессов. Сегодняшняя история про баги. Не баги вообще, а про вполне конкретную их категорию.

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

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

Всем привет! Меня зовут Александр Павленко, PHP-разработчик в NIX и спикер NIXMultiConf. В IT-сфере я наблюдаю такую тенденцию: чем масштабнее проект и чем быстрее растет разработка, тем чаще команде приходится менять, расширять логику приложения и улучшать функционал. В крупных проектах постоянный рефакторинг — неизбежный процесс. Иногда за ним скрываются проблемы, но их не стоит бояться. Подобные моменты — отличный шанс получить новые скиллы, прокачать свою экспертизу и получить доверие клиента.

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

Или как понять, когда остановиться

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

— Скажи, а зачем нам вообще нужны аналитики?

— И действительно, зачем? – подумал тогда я и написал заявление

Вопрос этот, как бы крамольно он ни звучал, очень правильный. Системный анализ, как фаза разработки приложения, присутствует всегда (даже если это системы класса «Hello, world»), а вот системный аналитик, как выделенная роль – нет. Выделение отдельной специальной роли работает точно так же, как и разделение труда в обычном производстве: для маленьких задач не целесообразно, для больших задач – оправданно. При таком разделении  системный аналитик забирает на себя часть задач и функций некоего «универсального» исполнителя задачи. Однако, подобное разделение труда имеет свою цену: это потеря знаний при коммуникации, более сложное управление процессом и др. В этой статье я хочу поделиться своим опытом: описать минусы крайностей и дать рекомендации по распределению обязанностей между системными аналитиками и разработчиками.

Итак, нам нужен системный аналитик, который формирует требования и разработчик, который эти требования реализует в коде.

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

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

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