Как стать автором
Обновить

Почему технический долг — это хорошо

Время прочтения 4 мин
Просмотры 28K
Блог компании Voximplant Разработка веб-сайтов *Программирование *Разработка мобильных приложений *
Перевод
Исключая тех, кому повезло быть богатыми, большинство людей занимают деньги, когда начинают свой первый бизнес. И они надеются, что эти инвестиции себя оправдают. Это пример того, как долг может быть хорошей штукой.

То же самое относится к техническому долгу. Бесчисленное множество статей в интернете рассказывают, как от него избавиться или хотя бы уменьшить. Все эти статьи показывают технический долг каким-то монстром, которого надо избегать. А если не получилось – то бороться изо всех сил.
Читать дальше →
Всего голосов 35: ↑28 и ↓7 +21
Комментарии 21

Что делать с чужими долгами?

Время прочтения 16 мин
Просмотры 34K
Управление разработкой *Управление проектами *Управление продуктом *
Один из аспектов профессии разработчика — посвящение профанов в особенности процесса разработки ПО.
С. Макконнелл, Совершенный код

Цель этой публикации — поделиться опытом работы над проектом со сложной историей и тяжёлым наследием. После ухода из очередного т.н. «стартапа», я решил что хочу попробовать новых ощущений: enterprise, legacy, etc. Для этого взялся за работу над корпоративным приложением для транснационального концерна. Разработка на тот момент шла уже третий год, приложение пережило несколько поколений разработчиков, но стабильного релиза так и не было.

Полагаю публикация будет полезной:

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

Затрагиваемые в статье вопросы:

  • Низкая компетенция разработчиков, и что с этим можно поделать?
  • Какие аргументы убедительны в глазах заказчика для нефункциональных изменений в проекте?
  • Почему работа аналитиков и QA очень важна с точки зрения разработки в частности и для проекта в целом?

Читать дальше →
Всего голосов 88: ↑85 и ↓3 +82
Комментарии 76

Как стать кросс-функциональной командой

Время прочтения 17 мин
Просмотры 9.1K
Блог компании Конференции Олега Бунина (Онтико) Управление разработкой *Управление продуктом *Конференции DevOps *
DevOps обычно рассматривается в двух ипостасях:

  1. Инструментарий — техника, tooling, технические процессы, CI/CD и прочие штуки — авто-всё, всё как код и т.д.
  2. Культура — это как отдельным разработчикам прийти всем вместе к «мир, дружба, жвачка».

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

У таких команд, помимо «мы так не умеем, потому что так раньше не делали», есть и другие вызовы. Михаил Бижан рассказал на конференции DevOps Conf 2019 о тех, с которыми встретилась его команда в Райффайзенбанке, и как они это решали. Михаил отвечает за автоматизацию в банке, вместе с командой внедряя инженерные практики и поддерживая инструменты автоматизации.

Раньше Михаил уже внедрял культуру DevOps в Сбербанке. Но до этого, работая на стороне интегратора (в основном на «госов») наловил кучу анти-паттернов. Потому что чем характерны госзаказчики? Годовалыми проектами, невообразимыми бюджетами и полным отсутствием намека на Agile и DevOps. Там все строго. Сначала ты пишешь ТЗ, чтобы стопка бумаги была метр от пола. Если меньше, это не ТЗ (и даже не проект) — это несерьёзно. Потом ты разрабатываешь, а если что-то не получается — виноват ты и денег не получаешь (хотя госзаказчик, скорее всего, все равно счастлив, потому что бюджет освоен и что-то формальное достигнуто).

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


Читать дальше →
Всего голосов 23: ↑20 и ↓3 +17
Комментарии 0

Technical debt leading to a company crisis

Время прочтения 16 мин
Просмотры 5K
Блог компании Dodo Engineering Управление проектами *Agile *Управление продуктом *IT-компании
Accumulating technical debt may lead your company to a crisis. But it may also become a powerful driver of massive process changes and help with engineering practices adoptions. I'll tell you about it on my own example.


Read more →
Всего голосов 23: ↑22 и ↓1 +21
Комментарии 0

Sprint Review: Днище — Огнище

Время прочтения 5 мин
Просмотры 11K
Блог компании Dodo Engineering Управление проектами *Agile *Управление продуктом *IT-компании

«Мы легли на дно, мы зажгли огни, во Вселенной только мы одни». Кажется, эту строчку из песни группы Сплин смело можно признать саундреком внедрения практики Sprint Review у нас в Dodo Pizza.


Читать дальше →
Всего голосов 32: ↑32 и ↓0 +32
Комментарии 3

Будь как Мунк, или пару слов о техническом долге

Время прочтения 12 мин
Просмотры 12K
Блог компании Dodo Engineering Управление проектами *Agile *Управление продуктом *IT-компании
Ощущения смерти, одиночества, в то же время безумная жажда к жизни… Вы могли бы подумать, что мы решили устроить лекцию по экспрессионизму и погрузить вас в творчество Мунка. Но нет. Все эти этапы ты переживаешь в момент, когда видишь, что твой технический долг скоро столкнёт твою компанию в бездну кризиса.

image
Читать дальше →
Всего голосов 39: ↑36 и ↓3 +33
Комментарии 21

Техдолг. Все говорят: «невозможно», а я говорю, что буду

Время прочтения 18 мин
Просмотры 12K
Блог компании Конференции Олега Бунина (Онтико) Управление разработкой *Управление продуктом *Конференции DevOps *
Очень часто драматически и патетически утверждают, что техдолг лучше не плодить — потом не устранишь. Да, без него, конечно, лучше. Но последствия устранить все-таки можно, и глава Программного комитета Артем Каличкин на конференции DevOpsConf 2020 поделился своим опытом в этой области.

Можно спросить, а причем здесь техдолг, если конференция DevOps? Холиварить об этом можно, например, в рамках DevOps-фуршета, но настолько ли это широкое понятие? Мы узнали, что Артем относит к техдолгу все изменения и доработки, инфраструктурные модификации и изменения процессов, изменения структур команд, направленные на устранение гэпов — которые были допущены (осознанно или нет) в рамках запуска продуктов и фич, и которые со временем сильно мешать жить.

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


Читать дальше →
Всего голосов 50: ↑50 и ↓0 +50
Комментарии 8

Простые причины неизбежности технического долга

Время прочтения 5 мин
Просмотры 9K
Совершенный код *Проектирование и рефакторинг *Управление разработкой *Управление проектами *Управление продуктом *
Перевод

image


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

Читать дальше →
Всего голосов 12: ↑11 и ↓1 +10
Комментарии 24

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

Время прочтения 7 мин
Просмотры 12K
Совершенный код *Проектирование и рефакторинг *Управление разработкой *Управление проектами *Управление продуктом *
Перевод


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


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

Читать дальше →
Всего голосов 30: ↑30 и ↓0 +30
Комментарии 20

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

Время прочтения 5 мин
Просмотры 9.3K
Совершенный код *Проектирование и рефакторинг *Управление разработкой *Управление проектами *Управление продуктом *
Перевод


Вы знаете, каково это. Впихнуть всё необходимое в спринт и так весьма непросто, а ведь ещё нужно где-то найти дополнительные 10–20% времени разработчиков на возврат технического долга. Если вы когда-либо отстаивали необходимость выкраивания времени на это, то вы знаете, что это походит на крестовый поход эпических масштабов.


Но сделать это можно, и в этом руководстве мы выясним, как именно.

Читать дальше →
Всего голосов 18: ↑16 и ↓2 +14
Комментарии 5

История о птице Додо из рода Фениксов. Великое падение Dodo IS

Время прочтения 16 мин
Просмотры 13K
Блог компании Dodo Engineering Программирование *
Каждый год 21 апреля мы вспоминаем историю Великого падения Dodo IS в 2018 году. Прошлое – жестокий, но справедливый учитель. Стоит помнить о нём, повторять уроки, передавать новым поколениям накопленные знания и с благодарностью относиться к тому, кем мы стали. Под катом мы хотим рассказать вам историю о том, как это было и поделиться выводами. Такую ситуацию не пожелаешь даже врагу.


Читать дальше →
Всего голосов 33: ↑24 и ↓9 +15
Комментарии 54

Базовое руководство по созданию сбалансированных команд разработчиков

Время прочтения 13 мин
Просмотры 12K
Управление разработкой *Развитие стартапа Управление продуктом *Карьера в IT-индустрии IT-компании
Перевод
Общался недавно с миддлом из команды разработки, которая состояла из 6-ти сеньоров и одного миддла. По словам миддла, расти в этой команде было очень сложно по ряду причин:

  • отсутствие техлида. Формально техлид был. С очень высоким техническим уровнем. Но как руководитель, который мог заниматься ведением и развитием своей группы, он был полный ноль: не умел декомпозировать задачи, распределять их в соответствии с уровнем каждого члена, не занимался обучением группы, контроль деятельности группы осуществлялся в диктаторском режиме, софт скиллы отсутствовали и т.п.
  • большой разрыв между скиллами миддла и сеньорами. То, что было непонятно миддлу, приходилось изучать на 95% самостоятельно, потому что у сеньоров не было времени и желания помогать миддлу в обучении, отсутствовало парное программирование (при этом код-ревью было отличным с технической точки зрения), в результате скорость работы миддла не удовлетворяла руководство, хотя качество его кода было высоким.
  • отсутствие командного духа. Обстановка в группе была нездоровой, общение не партнерское или менторское, а с унижениями, насмешками, ошибки на этапе разработки были непростительны и т.п.

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

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

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

Переведено @middle_java
Читать дальше →
Всего голосов 20: ↑18 и ↓2 +16
Комментарии 30

Продуктовый разворот: от фигачечной к сознательной работе инженеров

Время прочтения 7 мин
Просмотры 3.4K
Блог компании Конференции Олега Бунина (Онтико) Управление продуктом *Конференции DevOps *IT-компании
Весна 2020 показала, что благодаря DevOps-практикам многие бизнесы смогли быстро перестроить продукты и перейти в онлайн, сохранив работоспособность. Оказалось, что от зрелости практик DevOps зависят не только результаты бизнеса, но и само его выживание.

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

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



Основные измеряемые характеристики DevOps — это стабильность работы приложений и производительность IT-команд, от идеи до выкладки фичи на продакшн. Поэтому мы много говорим о time to market и мониторинге и продолжаем технический трек.

А ещё IT-команды состоят из живых людей, которые не только могут выдавать хорошие KPI, а ещё и делают заведомо полезную работу. Ведь если DevOps-подход завоевал популярность в мире, то, наверное, это кому-то нужно. Для вас мы повстречались с Product Owners и бизнесменами, которые не всегда знают, что такое DevOps (как будто мы знаем :D) и расспросили их о том, что же им важно получить от технарей. В чём эта самая польза.
Читать дальше →
Всего голосов 19: ↑18 и ↓1 +17
Комментарии 0

У Вас проблемы с legacy — значит, Вам повезло! Распил монолита на PHP

Время прочтения 10 мин
Просмотры 9.7K
PHP *Symfony *Управление разработкой *Управление проектами *
✏️ Технотекст 2021

Меня часто просят рассказать о работе с legacy-монолитами. Про микросервисную архитектуру и переход на нее говорят много, но редко упоминают о том, что проекты приходят ней после многих лет роста с монолитным приложением. Учебники по решению проблем не пишут. Чтобы поменять архитектуру живого решения, надо пройти через несколько этапов. Автор работал с разными проектами - и с полноценным multitenancy service-oriented REST architecture, и с огромным монолитом, в репозитории которого были коммиты за десять лет. Эта статья - о темной стороне, о legacy-коде, и практических решениях проблем с монолитным кодом на PHP.

Читать далее
Всего голосов 22: ↑20 и ↓2 +18
Комментарии 69

Technical debt mini-guide. How to pay it off

Время прочтения 7 мин
Просмотры 195
Java *
Туториал

In this article, I want to describe my experience of paying off technical debt on our project in the form of a guide. In this guide, I will highlight some of the most common cases of technical debt and suggest methods for solving them. Since this is a rather extensive topic, I will recommend several books for study, because I do not see it possible to talk about everything within the framework of this article. Everything described applies to the BackEnd part, but it may be suitable for other developers. I would be glad if you share your experience on this topic in the comments.

Read more
Всего голосов 1: ↑1 и ↓0 +1
Комментарии 0