День 1496. #ProjectManagement
Хватит Говорить: «Технический Долг». Начало
Представления людей о «техническом долге» немного отличаются.
- Мы должны были выпустить эту функцию три недели назад.
- Один разработчик застрял в обновлении фреймворка. Другой застрял при реорганизации флагов функций. Третьему нужно было изучить давно заброшенный репозиторий, чтобы внести изменения в базу данных. Команда зарывается. Каждый выпуск новой функции будет выглядеть так, пока нам не дадут несколько недель, чтобы расплатиться с техническим долгом. Мы понятия не имеем, как заставить бизнес задуматься об этом.
Звучит знакомо? Это разочаровывающий разговор.
Но мы часто сами приводим себя в эту ситуацию. Мы пытаемся объединить бизнесменов, дизайнеров, продакт-менеджеров и инженеров, используя фразу «технический долг». Но для каждого эта фраза означает своё. Спросите 10 технических специалистов, что такое технический долг, скорее всего получите 5-7 разных ответов.
Все связывают этот термин с чувством — обычно разочарованием, — но у них нет точного представления о том, откуда это чувство берется. Поэтому они навешивают этот термин на всё, что их беспокоит или пугает. Дизайнеры говорят, что дизайн выглядит не так, как они планировали. Менеджеры скажут, что это задержки в графике релизов функций. Ответы разработчиков будут вариациями на тему «плохого кода».
Когда на собрании звучит термин «технический долг», все расстраиваются, но никто не слушает. Каждый предполагает, что знает, о чём все говорят, но их индивидуальные представления немного отличаются. Для бизнеса это звучит, будто инженеры просят три недели без обязательств по выпуску каких-либо функций. В последний раз, когда им их давали: спустя месяц команда снова отставала, и в их понимании профита от этого ноль.
Мы, инженеры, должны скорректировать терминологию.
Приравнивание технического долга к просто плохому коду имеет несколько проблем.
1. Позволяет думать, что предыдущие разработчики просто халтурили, что нетактично, но нормально, пока мы не поймем, что на самом деле существовало ограничение, о котором мы не знали. Это ограничение объясняет отвратительные характеристики кода, а также мешает нам реализовать наше гениальное решение.
Одна команда бесконечно жаловалась на то, что для получения информации о клиентах требуется запрос из двух разных таблиц. Они думали, что эта структура унаследована и не менялась из-за обратной совместимости. Потратив кучу времени на критику дизайна базы и способы её исправления, команда поняла, что их план… незаконен. Из соображений конфиденциальности в их отрасли хранение этих двух конкретных частей личных данных в одной таблице является незаконным. К счастью, менеджер продукта упомянул о ситуации юристу компании до того, как команда инженеров зашла слишком далеко.
2. Приравнивание технического долга к просто плохому коду создаёт впечатление, что, если мы просто напишем хороший код, у нас не будет технического долга. Поэтому мы не тратим время на обзоры, тесты и комментарии. И через год мы там же, с чего начинали.
3. Позволяет нам путать «этот код не соответствует моим личным предпочтениям» с «этот код является проблемой» — что, опять же, нормально, пока мы не ограничены во времени. Мы тратим «неделю технического долга», занимаясь рефакторингами, вместо того чтобы что-то исправлять. Инженеры любят рефакторить код, чтобы он выглядел лучше. В итоге работать с кодом не становится легче, чем раньше: код просто другой, и никто, кроме автора, больше его не знает. Это одна из основных причин того, что недели «выплаты технического долга» часто мало или совсем ничего не прибавляют к скорости команды после них.
Окончание следует…
Источник: https://stackoverflow.blog/2023/02/27/stop-saying-technical-debt/
Хватит Говорить: «Технический Долг». Начало
Представления людей о «техническом долге» немного отличаются.
- Мы должны были выпустить эту функцию три недели назад.
- Один разработчик застрял в обновлении фреймворка. Другой застрял при реорганизации флагов функций. Третьему нужно было изучить давно заброшенный репозиторий, чтобы внести изменения в базу данных. Команда зарывается. Каждый выпуск новой функции будет выглядеть так, пока нам не дадут несколько недель, чтобы расплатиться с техническим долгом. Мы понятия не имеем, как заставить бизнес задуматься об этом.
Звучит знакомо? Это разочаровывающий разговор.
Но мы часто сами приводим себя в эту ситуацию. Мы пытаемся объединить бизнесменов, дизайнеров, продакт-менеджеров и инженеров, используя фразу «технический долг». Но для каждого эта фраза означает своё. Спросите 10 технических специалистов, что такое технический долг, скорее всего получите 5-7 разных ответов.
Все связывают этот термин с чувством — обычно разочарованием, — но у них нет точного представления о том, откуда это чувство берется. Поэтому они навешивают этот термин на всё, что их беспокоит или пугает. Дизайнеры говорят, что дизайн выглядит не так, как они планировали. Менеджеры скажут, что это задержки в графике релизов функций. Ответы разработчиков будут вариациями на тему «плохого кода».
Когда на собрании звучит термин «технический долг», все расстраиваются, но никто не слушает. Каждый предполагает, что знает, о чём все говорят, но их индивидуальные представления немного отличаются. Для бизнеса это звучит, будто инженеры просят три недели без обязательств по выпуску каких-либо функций. В последний раз, когда им их давали: спустя месяц команда снова отставала, и в их понимании профита от этого ноль.
Мы, инженеры, должны скорректировать терминологию.
Приравнивание технического долга к просто плохому коду имеет несколько проблем.
1. Позволяет думать, что предыдущие разработчики просто халтурили, что нетактично, но нормально, пока мы не поймем, что на самом деле существовало ограничение, о котором мы не знали. Это ограничение объясняет отвратительные характеристики кода, а также мешает нам реализовать наше гениальное решение.
Одна команда бесконечно жаловалась на то, что для получения информации о клиентах требуется запрос из двух разных таблиц. Они думали, что эта структура унаследована и не менялась из-за обратной совместимости. Потратив кучу времени на критику дизайна базы и способы её исправления, команда поняла, что их план… незаконен. Из соображений конфиденциальности в их отрасли хранение этих двух конкретных частей личных данных в одной таблице является незаконным. К счастью, менеджер продукта упомянул о ситуации юристу компании до того, как команда инженеров зашла слишком далеко.
2. Приравнивание технического долга к просто плохому коду создаёт впечатление, что, если мы просто напишем хороший код, у нас не будет технического долга. Поэтому мы не тратим время на обзоры, тесты и комментарии. И через год мы там же, с чего начинали.
3. Позволяет нам путать «этот код не соответствует моим личным предпочтениям» с «этот код является проблемой» — что, опять же, нормально, пока мы не ограничены во времени. Мы тратим «неделю технического долга», занимаясь рефакторингами, вместо того чтобы что-то исправлять. Инженеры любят рефакторить код, чтобы он выглядел лучше. В итоге работать с кодом не становится легче, чем раньше: код просто другой, и никто, кроме автора, больше его не знает. Это одна из основных причин того, что недели «выплаты технического долга» часто мало или совсем ничего не прибавляют к скорости команды после них.
Окончание следует…
Источник: https://stackoverflow.blog/2023/02/27/stop-saying-technical-debt/
👍12
День 1497. #ProjectManagement
Хватит Говорить: «Технический Долг». Окончание
Начало
Чтобы решить эти проблемы, выберите что-то измеримое для оценки качества системы, например: нагрузка по обслуживанию. Сколько времени и усилий разработчики тратят на задачи, не связанные с добавлением или удалением функций? Если у нас 6 разработчиков, но половина работы приходится на обслуживание, то надо планировать выпуск функций, полагаясь только на 3 разработчиков. Мы также можем отслеживать это число и определять, насколько быстро оно растёт с течением времени. Чем быстрее растёт нагрузка по обслуживанию, тем больше разочарований мы можем ожидать. Нулевой рост означает, что мы всегда можем обслуживать систему с той же долей нашей команды инженеров.
Как бороться с ростом нагрузки по обслуживанию? С помощью хороших практик управления кодом: документирование систем, восстановление контекста из кода и проектирование будущих изменений. Мы редко вознаграждаем, признаём или учимся управлению кодом так, как мы делаем это в отношении навыков разработки.
Снижение нагрузки по обслуживанию делает код более удобным для сопровождения с течением времени. Это требует выделения отдельных задач обслуживания, отслеживания их происхождения и устранения этих проблем в источнике. Эти рутинные работы, подкреплённые эмпирическими данными, дают нам что-то конкретное для обсуждения на встречах о техническом долге.
Выполняем ли мы сейчас много рутинных обновлений библиотек или фреймворков? Может быть, нужно регулярно выделять время на них. Чем больше их накапливается, тем сложнее становится отлаживать взаимодействие между выпусками разных библиотек. И чем реже программисты их выполняют, тем меньше у них практики, что делает обновление более сложным и болезненным, когда оно становится обязательным.
Есть ли у нас заброшенные репозитории, и мы каждый раз выясняем, как внести в них изменения? Возможно, нужно приложить усилия для восстановления информации о том, как они работают. Когда кто-то из ключевых членов команды уходит, внезапно оказывается, что они знали много критической информации, которая нигде не была записана или систематизирована. Разработчикам необходимо заранее оценить и устранить ущерб, нанесённый общим знаниям команды, прежде чем перед дедлайном окажется, что нужно изменить незнакомые части кодовой базы.
Мы работаем с устаревшей унаследованной архитектурой, основанной на предположениях о предметной области, которые больше не соответствуют действительности? Может быть, нужно создать план перестройки архитектуры.
Как определять такие задачи и расставлять их приоритеты – отдельная сложная тема, но даже сосредоточение внимания на нагрузке по обслуживанию в единицах конкретных работ, а не на единой горе «технического долга», позволит лучше спланировать решение этой проблемы.
Итого
Чем дольше мы откладываем работы по обслуживанию, тем менее гладкой и легкой будет разработка функций. Вместо того, чтобы заметать все эти задачи под ковёр под названием «технический долг», а затем время от времени прерывать разработку, чтобы разобраться с ним, мы можем отслеживать, какие конкретные элементы системы усложняют разработку функций, измерять их с точки зрения требуемого объёма усилий разработчиков, а затем согласовывать их выполнение как отдельных задач. Мы больше не считаем их непрозрачными и с неопределённой стоимостью. Вместо этого мы представляем их как чётко очерченные инвестиции в нашу способность эффективно создавать функции. Это помогает всем чётко понимать, что такое технический долг, а также увеличивает вероятность того, что:
- инженерам будет назначаться определённая работа по техническому обслуживанию,
- инженеры смогут выделить время для выполнения этой работы,
- работы по техническому обслуживанию, выбранные по итогам обзора реальных причин замедления разработки функций, на самом деле улучшат опыт разработки функций в будущем.
Источник: https://stackoverflow.blog/2023/02/27/stop-saying-technical-debt/
Хватит Говорить: «Технический Долг». Окончание
Начало
Чтобы решить эти проблемы, выберите что-то измеримое для оценки качества системы, например: нагрузка по обслуживанию. Сколько времени и усилий разработчики тратят на задачи, не связанные с добавлением или удалением функций? Если у нас 6 разработчиков, но половина работы приходится на обслуживание, то надо планировать выпуск функций, полагаясь только на 3 разработчиков. Мы также можем отслеживать это число и определять, насколько быстро оно растёт с течением времени. Чем быстрее растёт нагрузка по обслуживанию, тем больше разочарований мы можем ожидать. Нулевой рост означает, что мы всегда можем обслуживать систему с той же долей нашей команды инженеров.
Как бороться с ростом нагрузки по обслуживанию? С помощью хороших практик управления кодом: документирование систем, восстановление контекста из кода и проектирование будущих изменений. Мы редко вознаграждаем, признаём или учимся управлению кодом так, как мы делаем это в отношении навыков разработки.
Снижение нагрузки по обслуживанию делает код более удобным для сопровождения с течением времени. Это требует выделения отдельных задач обслуживания, отслеживания их происхождения и устранения этих проблем в источнике. Эти рутинные работы, подкреплённые эмпирическими данными, дают нам что-то конкретное для обсуждения на встречах о техническом долге.
Выполняем ли мы сейчас много рутинных обновлений библиотек или фреймворков? Может быть, нужно регулярно выделять время на них. Чем больше их накапливается, тем сложнее становится отлаживать взаимодействие между выпусками разных библиотек. И чем реже программисты их выполняют, тем меньше у них практики, что делает обновление более сложным и болезненным, когда оно становится обязательным.
Есть ли у нас заброшенные репозитории, и мы каждый раз выясняем, как внести в них изменения? Возможно, нужно приложить усилия для восстановления информации о том, как они работают. Когда кто-то из ключевых членов команды уходит, внезапно оказывается, что они знали много критической информации, которая нигде не была записана или систематизирована. Разработчикам необходимо заранее оценить и устранить ущерб, нанесённый общим знаниям команды, прежде чем перед дедлайном окажется, что нужно изменить незнакомые части кодовой базы.
Мы работаем с устаревшей унаследованной архитектурой, основанной на предположениях о предметной области, которые больше не соответствуют действительности? Может быть, нужно создать план перестройки архитектуры.
Как определять такие задачи и расставлять их приоритеты – отдельная сложная тема, но даже сосредоточение внимания на нагрузке по обслуживанию в единицах конкретных работ, а не на единой горе «технического долга», позволит лучше спланировать решение этой проблемы.
Итого
Чем дольше мы откладываем работы по обслуживанию, тем менее гладкой и легкой будет разработка функций. Вместо того, чтобы заметать все эти задачи под ковёр под названием «технический долг», а затем время от времени прерывать разработку, чтобы разобраться с ним, мы можем отслеживать, какие конкретные элементы системы усложняют разработку функций, измерять их с точки зрения требуемого объёма усилий разработчиков, а затем согласовывать их выполнение как отдельных задач. Мы больше не считаем их непрозрачными и с неопределённой стоимостью. Вместо этого мы представляем их как чётко очерченные инвестиции в нашу способность эффективно создавать функции. Это помогает всем чётко понимать, что такое технический долг, а также увеличивает вероятность того, что:
- инженерам будет назначаться определённая работа по техническому обслуживанию,
- инженеры смогут выделить время для выполнения этой работы,
- работы по техническому обслуживанию, выбранные по итогам обзора реальных причин замедления разработки функций, на самом деле улучшат опыт разработки функций в будущем.
Источник: https://stackoverflow.blog/2023/02/27/stop-saying-technical-debt/
👍6
День 1574. #DevOps #ProjectManagement
Без Паники! Пособие по Управлению Любым Инцидентом в Продакшене. Начало
Независимо от того, насколько сильна ваша организация, насколько тщательно планирование и развертывание… всё когда-нибудь ломается. Системы выходят из строя, ключевые функции перестают работать, и в какой-то момент карьеры каждого разработчика возникает проблема.
Природа этих проблем меняется с течением времени, но некоторые вещи остаются неизменными в том, как вы смотрите на проблемы и как люди могут работать, чтобы убедиться, что вы надёжно их исправите. И чтобы было ясно, мы не говорим о серийных багах в продакшене, мы говорим о проблемах, которые являются большими и объёмными, но в то же время деликатными. Следующие шаги применимы к людям на всех уровнях и могут дать некоторое представление о том, через что проходят люди на разных ролях в компании.
Шаг 1. Не паникуйте и определите проблему
В один прекрасный день базовая функциональность приложения перестаёт работать. Команда разработчиков собирается в совещательной комнате, чтобы найти решение проблемы. Инстинктивная реакция: «Быстрее, откатывай всё назад!» Это понятное чувство, мы создали проблемы, и, естественно, есть желание от них избавиться. Но с быстрыми действиями приходят и быстрые ошибки, и более опытные разработчики здесь резонно зададут вопрос: «А почему не работает?». Да, вашей реакцией может быть: «Кого это волнует? Наша ошибка видна всему миру!» Но спокойный характер и аналитическая манера поведения успокоят команду и убедят, что то, что происходит в этой комнате, правильно: надо задавать вопросы и исследовать.
Шаг 2. Диагностика и понимание источника проблемы
Это звучит как очевидная вещь, но из-за беспокойства и паники никто может не задаться этим вопросом. Оставьте проблему, чтобы убедиться, что вы знаете, почему это не работает. Перепроверьте журналы исключений, отдельные рабочие процессы или даже не было ли чего-то странного на системном уровне. Воспроизведите ошибку (здесь очень поможет, если ваши среды разработки настроены максимально идентично производственной среде). После того, как вы поймёте, что сделали не так, и наберётесь достаточно уверенности для следующего выпуска, начинайте откат. Это тонкий момент, но учитесь всегда использовать все возможности для поиска природы ошибки, прежде чем откатиться и потерять свой лучший источник информации: реальную проблему в дикой природе.
Также важно найти кого-то, кто займётся техническими вопросами и сможет помочь координировать усилия по исправлению (обычно это более старший разработчик), и кого-то, кто будет отвечать за «пиар для внешней среды» и «прикрытие с воздуха» тех, кто может захотеть потратить время на изучение ошибки (обычно это директор или технический руководитель). Это делается для защиты самого ценного ресурса во время кризиса: времени и внимания тех, кто действительно может реализовать план исправления.
Более технический специалист нужен, чтобы помочь разбить решение на этапы и делегировать или разделить работу, которую необходимо выполнить. А лидер инцидента (как его часто иронически называют) должен помогать, но не диктовать. Лучшие лидеры инцидентов задают два вопроса: «На каком этапе мы находимся?» и «Что вам нужно?», а также могут держать рассерженных пользователей подальше от специалистов, решающих проблему.
Окончание следует…
Источник: https://stackoverflow.blog/2023/05/03/dont-panic-a-playbook-for-managing-any-production-incident/
Без Паники! Пособие по Управлению Любым Инцидентом в Продакшене. Начало
Независимо от того, насколько сильна ваша организация, насколько тщательно планирование и развертывание… всё когда-нибудь ломается. Системы выходят из строя, ключевые функции перестают работать, и в какой-то момент карьеры каждого разработчика возникает проблема.
Природа этих проблем меняется с течением времени, но некоторые вещи остаются неизменными в том, как вы смотрите на проблемы и как люди могут работать, чтобы убедиться, что вы надёжно их исправите. И чтобы было ясно, мы не говорим о серийных багах в продакшене, мы говорим о проблемах, которые являются большими и объёмными, но в то же время деликатными. Следующие шаги применимы к людям на всех уровнях и могут дать некоторое представление о том, через что проходят люди на разных ролях в компании.
Шаг 1. Не паникуйте и определите проблему
В один прекрасный день базовая функциональность приложения перестаёт работать. Команда разработчиков собирается в совещательной комнате, чтобы найти решение проблемы. Инстинктивная реакция: «Быстрее, откатывай всё назад!» Это понятное чувство, мы создали проблемы, и, естественно, есть желание от них избавиться. Но с быстрыми действиями приходят и быстрые ошибки, и более опытные разработчики здесь резонно зададут вопрос: «А почему не работает?». Да, вашей реакцией может быть: «Кого это волнует? Наша ошибка видна всему миру!» Но спокойный характер и аналитическая манера поведения успокоят команду и убедят, что то, что происходит в этой комнате, правильно: надо задавать вопросы и исследовать.
Шаг 2. Диагностика и понимание источника проблемы
Это звучит как очевидная вещь, но из-за беспокойства и паники никто может не задаться этим вопросом. Оставьте проблему, чтобы убедиться, что вы знаете, почему это не работает. Перепроверьте журналы исключений, отдельные рабочие процессы или даже не было ли чего-то странного на системном уровне. Воспроизведите ошибку (здесь очень поможет, если ваши среды разработки настроены максимально идентично производственной среде). После того, как вы поймёте, что сделали не так, и наберётесь достаточно уверенности для следующего выпуска, начинайте откат. Это тонкий момент, но учитесь всегда использовать все возможности для поиска природы ошибки, прежде чем откатиться и потерять свой лучший источник информации: реальную проблему в дикой природе.
Также важно найти кого-то, кто займётся техническими вопросами и сможет помочь координировать усилия по исправлению (обычно это более старший разработчик), и кого-то, кто будет отвечать за «пиар для внешней среды» и «прикрытие с воздуха» тех, кто может захотеть потратить время на изучение ошибки (обычно это директор или технический руководитель). Это делается для защиты самого ценного ресурса во время кризиса: времени и внимания тех, кто действительно может реализовать план исправления.
Более технический специалист нужен, чтобы помочь разбить решение на этапы и делегировать или разделить работу, которую необходимо выполнить. А лидер инцидента (как его часто иронически называют) должен помогать, но не диктовать. Лучшие лидеры инцидентов задают два вопроса: «На каком этапе мы находимся?» и «Что вам нужно?», а также могут держать рассерженных пользователей подальше от специалистов, решающих проблему.
Окончание следует…
Источник: https://stackoverflow.blog/2023/05/03/dont-panic-a-playbook-for-managing-any-production-incident/
👍10
День 1575. #DevOps #ProjectManagement
Без Паники! Пособие по Управлению Любым Инцидентом в Продакшене. Окончание
Начало
Шаг 3. Исправление: начнём работать над проблемой
Мы знаем, что у нас есть проблема, мы знаем источник проблемы, теперь давайте составим план и исправим её. Мы все любим переходить к этому шагу, сразу приступать к исправлению. И иногда у нас есть такая роскошь для простых вопросов, когда проблема настолько очевидна, что подтверждение и понимание источника проблемы — быстрые шаги. Но если проблема зашла далеко или она серьезная, нужно поступать более обдуманно.
Тут координатор поможет расставить приоритеты в работе, выяснить, где находятся самые важные шаги по смягчению последствий, и убедиться, что у всех заинтересованных сторон есть чёткие ожидания относительно того, что надо делать и какой будет результат. Разработчик, работающий над проблемой, обязан привлечь этого человека, убедиться, что он предоставит ему ресурсы, необходимые для решения проблемы. Это может быть время, доступ или другие люди, у которых есть специфические знания. Это важная тема на данном этапе: дать инженерам то, что им нужно, чтобы исправить ситуацию. Возможно, это должно волновать всех инженеров-руководителей не только тогда, когда что-то пошло не так, и жизненно важные рабочие процессы встали.
Больше всего во время кризиса не хватает не информации или помощи других разработчиков, а возможности сфокусироваться. Это может показаться странным, но это чувство знакомо любому, кто был в одной лодке с лидерами, которые паникуют или никогда не понимали заблуждений мифического человеко-месяца. Они с нетерпением ждут новостей о ходе работы, и что может быть лучше, чем собирать всех на митинги четыре раза в день, чтобы узнать, как продвигаются дела. А это постоянные отвлечения, переключения контекста и обновления багтрекеров. Способность сосредоточиться и избавиться от отвлекающих факторов - самый важный фактор для решения проблемы.
Шаг 4. Проверка и обучение
Если все пойдёт хорошо, тесты подтвердятся, и вся ценная информация, полученная на шагах 1 и 2, даст вам уверенность в новых планах тестирования, вы можете развернуть исправление. Как только оно будет опубликовано, дайте время команде на всех уровнях, чтобы изучить его и подтвердить, что всё работает как надо. Если инженерам в начале этих инцидентов даются время и свобода, то они более уверенно и спокойно относятся к последующим релизам и исправлениям.
Однако, публикация исправления и уверенность команды в его правильности – лишь половина дела. Теперь нужно сделать так, чтобы болезненный и возможно дорогостоящий опыт этой проблемы способствовал развитию команды. Люди часто воспринимают крупные кризисы, как проблему, которая никогда больше не повторится, что совершенно неразумно. Часто лучшее обучение — это учиться справляться с проблемами, а не притворяться, будто мы можем их избежать.
В конце концов, чаще всего всё сводится к элементарной человеческой ошибке. Поэтому техническому руководителю нужно быть больше сосредоточенным не на предотвращении ошибок, а на оттачивании способности команды справляться с ними. Да, важна работа по предотвращению будущих подобных ошибок. Но часто есть больше возможностей для улучшения того, как команда реагирует на ошибку. Как дать инженерам больше возможностей для концентрации? Как можно ускорить расследование инцидента? Или даже кто лучше всего справляется с коммуникацией между разными специалистами или командами и какая информация им нужна?
Источник: https://stackoverflow.blog/2023/05/03/dont-panic-a-playbook-for-managing-any-production-incident/
Без Паники! Пособие по Управлению Любым Инцидентом в Продакшене. Окончание
Начало
Шаг 3. Исправление: начнём работать над проблемой
Мы знаем, что у нас есть проблема, мы знаем источник проблемы, теперь давайте составим план и исправим её. Мы все любим переходить к этому шагу, сразу приступать к исправлению. И иногда у нас есть такая роскошь для простых вопросов, когда проблема настолько очевидна, что подтверждение и понимание источника проблемы — быстрые шаги. Но если проблема зашла далеко или она серьезная, нужно поступать более обдуманно.
Тут координатор поможет расставить приоритеты в работе, выяснить, где находятся самые важные шаги по смягчению последствий, и убедиться, что у всех заинтересованных сторон есть чёткие ожидания относительно того, что надо делать и какой будет результат. Разработчик, работающий над проблемой, обязан привлечь этого человека, убедиться, что он предоставит ему ресурсы, необходимые для решения проблемы. Это может быть время, доступ или другие люди, у которых есть специфические знания. Это важная тема на данном этапе: дать инженерам то, что им нужно, чтобы исправить ситуацию. Возможно, это должно волновать всех инженеров-руководителей не только тогда, когда что-то пошло не так, и жизненно важные рабочие процессы встали.
Больше всего во время кризиса не хватает не информации или помощи других разработчиков, а возможности сфокусироваться. Это может показаться странным, но это чувство знакомо любому, кто был в одной лодке с лидерами, которые паникуют или никогда не понимали заблуждений мифического человеко-месяца. Они с нетерпением ждут новостей о ходе работы, и что может быть лучше, чем собирать всех на митинги четыре раза в день, чтобы узнать, как продвигаются дела. А это постоянные отвлечения, переключения контекста и обновления багтрекеров. Способность сосредоточиться и избавиться от отвлекающих факторов - самый важный фактор для решения проблемы.
Шаг 4. Проверка и обучение
Если все пойдёт хорошо, тесты подтвердятся, и вся ценная информация, полученная на шагах 1 и 2, даст вам уверенность в новых планах тестирования, вы можете развернуть исправление. Как только оно будет опубликовано, дайте время команде на всех уровнях, чтобы изучить его и подтвердить, что всё работает как надо. Если инженерам в начале этих инцидентов даются время и свобода, то они более уверенно и спокойно относятся к последующим релизам и исправлениям.
Однако, публикация исправления и уверенность команды в его правильности – лишь половина дела. Теперь нужно сделать так, чтобы болезненный и возможно дорогостоящий опыт этой проблемы способствовал развитию команды. Люди часто воспринимают крупные кризисы, как проблему, которая никогда больше не повторится, что совершенно неразумно. Часто лучшее обучение — это учиться справляться с проблемами, а не притворяться, будто мы можем их избежать.
В конце концов, чаще всего всё сводится к элементарной человеческой ошибке. Поэтому техническому руководителю нужно быть больше сосредоточенным не на предотвращении ошибок, а на оттачивании способности команды справляться с ними. Да, важна работа по предотвращению будущих подобных ошибок. Но часто есть больше возможностей для улучшения того, как команда реагирует на ошибку. Как дать инженерам больше возможностей для концентрации? Как можно ускорить расследование инцидента? Или даже кто лучше всего справляется с коммуникацией между разными специалистами или командами и какая информация им нужна?
Источник: https://stackoverflow.blog/2023/05/03/dont-panic-a-playbook-for-managing-any-production-incident/
👍8
День 1622. #ProjectManagement
Управляем Здоровьем Команды, Техническим Долгом и Предотвращаем Переписывание с Нуля. Начало
Обычно бывает так: опытная команда блестящих инженеров запускает новый продукт, клиентам нравится, фичи релизятся как из автомата. А спустя какое-то время внезапно продуктивность падает, выпускать новые функции всё сложнее, клиенты недовольны, инженеры устают от работы больше, чем когда-либо прежде, и призывают переписать всё с нуля. Время паники. Что случилось?
Первые признаки ухудшения
Команды похожи на огороды. Вначале растения мелкие, сорняков мало. Затем, из-за того, что вы не пропалывали, не поливали и не подкармливали, половина растений погибла, а другая превратилась в джунгли. Три вещи заставляют команды переходить в режим бурлаков:
- Первоначальные архитектурные решения были неверны или основывались на несовершенных предпосылках.
- Команда вынуждена выпускать продукт любой ценой, откладывая работу над техническим долгом.
- У команды нет системного плана решения проблем долга по мере роста системы.
Технический долг — убийца команд. Думайте о функциях и долге как о кредитной карте. Залезать в долги по кредитке каждый месяц — это нормально. Однако высокая процентная ставка разорит вас, если вы не выплатите долг.
Уменьшение объёмов предоставляемых функций при увеличении серьёзности возникающих проблем указывает на то, что команда в опасности. Если команда замедлилась с выпуска пяти средних и крупных функций в квартал до 1 функции с 3-кратным увеличением количества серьёзных ошибок за тот же период без изменений в составе команды, она движется к провалу. Задача для любого хорошего лидера в том, чтобы постоянно поддерживать минимальный уровень технического долга, позволяя команде продолжать выпускать функции.
Хорошая практика №1: постоянные обзоры архитектуры
Обзоры архитектуры распространены в начале проекта. Сначала команда придерживается надёжных архитектурных принципов, система не слишком сложна в обслуживании и т. д. Как только выходит версия 1.0, команда обычно прекращает рассмотрение новых функций с точки зрения влияния на архитектуру в пользу быстрой доставки. Это компромисс. Нет времени пересматривать архитектурные изменения. Но правильно ли это? Понимаем ли мы растущую систему?
Что делать?
Необходим официальный анализ архитектуры каждой новой функции среднего и крупного размера. Назначьте команде фиксированное время для рассмотрения влияния на архитектуру всех новых функций. 3-5 страниц или слайдов обзора с 1-3 диаграммами архитектуры вполне достаточно. Включите требование о проведении архитектурного анализа во все планы проекта. Все участвуют в рассмотрении, и все оценивают.
Зачем?
- Все в команде понимают, что делают все члены команды.
- Команда может взвесить технические компромиссы до того, как код будет написан и помещён в репозиторий — тогда обычно уже слишком поздно.
- Сложность системы и потенциальные проблемы со стабильностью, производительностью и масштабируемостью выявляются заранее.
- Команда создаёт архив диаграмм, чтобы будущим товарищам по команде было проще адаптироваться.
- Младшие инженеры узнают, как легко создавать более сложные системы.
Непрерывные обзоры архитектуры — первая защита от деградации проекта. В конечном счёте 30-минутная встреча в будущем сэкономит месяцы. Поэтому обозревайте архитектуру заранее, регулярно и используйте обзоры как средство раннего предупреждения.
Продолжение следует…
Источник: https://betterprogramming.pub/managing-team-health-tech-debt-and-avoiding-the-dreaded-rewrite-94878da7ca43
Управляем Здоровьем Команды, Техническим Долгом и Предотвращаем Переписывание с Нуля. Начало
Обычно бывает так: опытная команда блестящих инженеров запускает новый продукт, клиентам нравится, фичи релизятся как из автомата. А спустя какое-то время внезапно продуктивность падает, выпускать новые функции всё сложнее, клиенты недовольны, инженеры устают от работы больше, чем когда-либо прежде, и призывают переписать всё с нуля. Время паники. Что случилось?
Первые признаки ухудшения
Команды похожи на огороды. Вначале растения мелкие, сорняков мало. Затем, из-за того, что вы не пропалывали, не поливали и не подкармливали, половина растений погибла, а другая превратилась в джунгли. Три вещи заставляют команды переходить в режим бурлаков:
- Первоначальные архитектурные решения были неверны или основывались на несовершенных предпосылках.
- Команда вынуждена выпускать продукт любой ценой, откладывая работу над техническим долгом.
- У команды нет системного плана решения проблем долга по мере роста системы.
Технический долг — убийца команд. Думайте о функциях и долге как о кредитной карте. Залезать в долги по кредитке каждый месяц — это нормально. Однако высокая процентная ставка разорит вас, если вы не выплатите долг.
Уменьшение объёмов предоставляемых функций при увеличении серьёзности возникающих проблем указывает на то, что команда в опасности. Если команда замедлилась с выпуска пяти средних и крупных функций в квартал до 1 функции с 3-кратным увеличением количества серьёзных ошибок за тот же период без изменений в составе команды, она движется к провалу. Задача для любого хорошего лидера в том, чтобы постоянно поддерживать минимальный уровень технического долга, позволяя команде продолжать выпускать функции.
Хорошая практика №1: постоянные обзоры архитектуры
Обзоры архитектуры распространены в начале проекта. Сначала команда придерживается надёжных архитектурных принципов, система не слишком сложна в обслуживании и т. д. Как только выходит версия 1.0, команда обычно прекращает рассмотрение новых функций с точки зрения влияния на архитектуру в пользу быстрой доставки. Это компромисс. Нет времени пересматривать архитектурные изменения. Но правильно ли это? Понимаем ли мы растущую систему?
Что делать?
Необходим официальный анализ архитектуры каждой новой функции среднего и крупного размера. Назначьте команде фиксированное время для рассмотрения влияния на архитектуру всех новых функций. 3-5 страниц или слайдов обзора с 1-3 диаграммами архитектуры вполне достаточно. Включите требование о проведении архитектурного анализа во все планы проекта. Все участвуют в рассмотрении, и все оценивают.
Зачем?
- Все в команде понимают, что делают все члены команды.
- Команда может взвесить технические компромиссы до того, как код будет написан и помещён в репозиторий — тогда обычно уже слишком поздно.
- Сложность системы и потенциальные проблемы со стабильностью, производительностью и масштабируемостью выявляются заранее.
- Команда создаёт архив диаграмм, чтобы будущим товарищам по команде было проще адаптироваться.
- Младшие инженеры узнают, как легко создавать более сложные системы.
Непрерывные обзоры архитектуры — первая защита от деградации проекта. В конечном счёте 30-минутная встреча в будущем сэкономит месяцы. Поэтому обозревайте архитектуру заранее, регулярно и используйте обзоры как средство раннего предупреждения.
Продолжение следует…
Источник: https://betterprogramming.pub/managing-team-health-tech-debt-and-avoiding-the-dreaded-rewrite-94878da7ca43
👍13👎1
День 1623. #ProjectManagement
Управляем Здоровьем Команды, Техническим Долгом и Предотвращаем Переписывание с Нуля. Продолжение
Начало
Хорошая практика №2: Журнал ошибок и постоянные исправления
Журнал ошибок указывает на проблемы продукта. Разберитесь со списком ошибок. Это требует времени, но сделайте это всё равно.
Обработка ошибок – принудительная функция, как соглашение об уровне обслуживания (SLA), в котором мы объявляем обязательство по исправлению ошибок перед с нашими внутренними клиентами. И не все ошибки равны. Некоторые более сложны или более важны:
1. Система неработоспособна
- Затронуты все пользователи: Критическая ошибка - Исправлять немедленно!
- Некоторые пользователи: Серьёзная – 3-5 часов.
- Мало пользователей: Средняя – 2-3 дня.
2. Система сильно повреждена
- Все: Серьёзная – 3-5 часов.
- Некоторые: Средняя – 2-3 дня.
- Мало: Средняя – 2-3 дня.
3. У пользователей есть альтернативное решение
- Все: Серьёзная – 3-5 часов.
- Некоторые: Незначительная – 1-2 недели.
- Мало: В период исправления ошибок – 1 месяц.
4. Не влияет на систему
- Все: Незначительная – 1-2 недели.
- Некоторые: В период исправления ошибок – 1 месяц.
- Мало: Можно игнорировать
Журнал ошибок должен содержать список ошибок с их уровнем критичности. Кроме того, за состоянием проекта можно следить, отмечая на графике оценку количества ошибок с коэффициентом их критичности:
- Критическая – 2х
- Серьёзная – 1,5х
- Средняя – 1х
- Незначительная – 0,5х
Тогда, если на 1й неделе случилось 5 средних и одна серьёзная ошибка – это 5*1 + 1*1,5 = 6,5. На второй неделе 1 серьёзная и 6 незначительных – 1*1,5 + 6*0,5 = 4,5. Со временем этот график будет показывать состояние продукта.
Что делать?
- Определите SLA ошибки. Каждый продукт и каждая команда отличаются, но мы можем установить внутренние ожидания в отношении времени обработки для серьёзных, но не критических проблем. Мы быстро исправим серьёзные ошибки, а ошибки с более низким приоритетом будут исправлены или подвергнуты рефакторингу позже.
- Каждый спринт члены команды просматривают журнал ошибок и назначают исправления, чтобы обеспечить постоянный цикл исправления и сокращения количества ошибок.
- Сообщайте об исправлениях ошибок в заметках о выпуске, публикации во внутреннем чате или в каком-либо другом средстве. Например, сделайте «день выпуска отчёта об ошибках» и публикуйте этот отчёт.
- Используйте простые формулы для расчёта количества ошибок и удерживайте количество ошибок как можно более равномерным спринт за спринтом. Отслеживайте это желательно на общих дашбордах о состоянии проекта.
Зачем?
- Создаёт «систему раннего предупреждения». Команда привыкает к ритму и осознанию своих невыполненных работ по ошибкам и рабочей нагрузке. В результате разработчики могут определить, когда ошибки накапливаются, и спланировать их исправление.
- Внутренние клиенты имеют чёткие ожидания относительно того, когда появятся исправления ошибок, и у них есть возможность видеть работу команды.
- Команда узнаёт о горячих точках продукта раньше и может использовать эту информацию для следующего раунда планирования спринта. Чем короче время, чтобы избежать проблемы, тем меньше времени тратится впустую.
Примечание: сделайте так, чтобы ваши клиенты могли легко сообщать об ошибках! Не прячьте средство сообщения об ошибках, вы не всегда будете ловить ошибки в журналах.
Окончание следует…
Источник: https://betterprogramming.pub/managing-team-health-tech-debt-and-avoiding-the-dreaded-rewrite-94878da7ca43
Управляем Здоровьем Команды, Техническим Долгом и Предотвращаем Переписывание с Нуля. Продолжение
Начало
Хорошая практика №2: Журнал ошибок и постоянные исправления
Журнал ошибок указывает на проблемы продукта. Разберитесь со списком ошибок. Это требует времени, но сделайте это всё равно.
Обработка ошибок – принудительная функция, как соглашение об уровне обслуживания (SLA), в котором мы объявляем обязательство по исправлению ошибок перед с нашими внутренними клиентами. И не все ошибки равны. Некоторые более сложны или более важны:
1. Система неработоспособна
- Затронуты все пользователи: Критическая ошибка - Исправлять немедленно!
- Некоторые пользователи: Серьёзная – 3-5 часов.
- Мало пользователей: Средняя – 2-3 дня.
2. Система сильно повреждена
- Все: Серьёзная – 3-5 часов.
- Некоторые: Средняя – 2-3 дня.
- Мало: Средняя – 2-3 дня.
3. У пользователей есть альтернативное решение
- Все: Серьёзная – 3-5 часов.
- Некоторые: Незначительная – 1-2 недели.
- Мало: В период исправления ошибок – 1 месяц.
4. Не влияет на систему
- Все: Незначительная – 1-2 недели.
- Некоторые: В период исправления ошибок – 1 месяц.
- Мало: Можно игнорировать
Журнал ошибок должен содержать список ошибок с их уровнем критичности. Кроме того, за состоянием проекта можно следить, отмечая на графике оценку количества ошибок с коэффициентом их критичности:
- Критическая – 2х
- Серьёзная – 1,5х
- Средняя – 1х
- Незначительная – 0,5х
Тогда, если на 1й неделе случилось 5 средних и одна серьёзная ошибка – это 5*1 + 1*1,5 = 6,5. На второй неделе 1 серьёзная и 6 незначительных – 1*1,5 + 6*0,5 = 4,5. Со временем этот график будет показывать состояние продукта.
Что делать?
- Определите SLA ошибки. Каждый продукт и каждая команда отличаются, но мы можем установить внутренние ожидания в отношении времени обработки для серьёзных, но не критических проблем. Мы быстро исправим серьёзные ошибки, а ошибки с более низким приоритетом будут исправлены или подвергнуты рефакторингу позже.
- Каждый спринт члены команды просматривают журнал ошибок и назначают исправления, чтобы обеспечить постоянный цикл исправления и сокращения количества ошибок.
- Сообщайте об исправлениях ошибок в заметках о выпуске, публикации во внутреннем чате или в каком-либо другом средстве. Например, сделайте «день выпуска отчёта об ошибках» и публикуйте этот отчёт.
- Используйте простые формулы для расчёта количества ошибок и удерживайте количество ошибок как можно более равномерным спринт за спринтом. Отслеживайте это желательно на общих дашбордах о состоянии проекта.
Зачем?
- Создаёт «систему раннего предупреждения». Команда привыкает к ритму и осознанию своих невыполненных работ по ошибкам и рабочей нагрузке. В результате разработчики могут определить, когда ошибки накапливаются, и спланировать их исправление.
- Внутренние клиенты имеют чёткие ожидания относительно того, когда появятся исправления ошибок, и у них есть возможность видеть работу команды.
- Команда узнаёт о горячих точках продукта раньше и может использовать эту информацию для следующего раунда планирования спринта. Чем короче время, чтобы избежать проблемы, тем меньше времени тратится впустую.
Примечание: сделайте так, чтобы ваши клиенты могли легко сообщать об ошибках! Не прячьте средство сообщения об ошибках, вы не всегда будете ловить ошибки в журналах.
Окончание следует…
Источник: https://betterprogramming.pub/managing-team-health-tech-debt-and-avoiding-the-dreaded-rewrite-94878da7ca43
👍9
День 1624. #ProjectManagement
Управляем Здоровьем Команды, Техническим Долгом и Предотвращаем Переписывание с Нуля. Окончание
Начало
Продолжение
Хорошая практика №3: дисциплинированное исправление/рефакторинг
Организуйте ротацию дежурных в момент отправки продукта. Несмотря на то, что в продукте мало ошибок, может быть, мало клиентов и нет шансов выхода из строя под нагрузкой, назначение дежурных и их ротация заранее запускает «мышечную память».
Дежурство в команде с небольшим продуктом, пользовательской базой или активностью кажется контрпродуктивным, поскольку дежурные не создают новых функций. Кажется, что нужно задействовать всех на улучшение продукта, и не беспокоиться о поддержке, пока это не понадобится. Но так вы лишаете себя хорошего и простого средства управления техническим долгом и поддержания здоровья команды.
Что делать?
- Установите ротацию в тот момент, когда пользователи продукта смогут получить доступ к продукту. Наличие пользователей – это сообщения об ошибках.
- Установите разумную продолжительность (1 неделя, 1 спринт), чёткие процедуры передачи задач и расписание, чтобы все знали, когда они будут дежурить.
- Дежурство — это устранение инцидентов, исправление ошибок, снижение сложности кода (рефакторинг), а только затем работа над новыми функциями. Если бэклог ошибок заполняет всё дежурство, этот инженер не работает над новыми функциями.
- Не назначайте дежурному инженеру ничего, кроме дежурных задач.
Зачем?
- Команда методично устраняет ошибки, и технический долг стабилизируется.
- Команда выполняет SLA по ошибкам — внутренние и внешние клиенты довольны.
- Более стабильный продукт => меньше пожаров в продакшене и меньше простоев.
- Младшие инженеры получают возможность исправлять ошибки во всех частях системы, быстрее повышая свой уровень.
- Ещё одна система раннего предупреждения о здоровье команды. Если дежурство занято сложными, серьёзными ошибками, мы узнаём о проблемах сразу, а не через несколько месяцев.
Помните о компромиссе: команда предоставит меньше функций за счёт более стабильного продукта. Устанавливайте ожидания относительно ротации дежурных не в команде, а в организации в целом.
Переписывать ли заново?
Вышеупомянутые принципы должны создать систему раннего предупреждения и сосредоточить команду на поиске рефакторинга архитектуры из-за изменения технологии или бизнес-условий задолго до того, как вы достигнете этого состояния.
Инженеры любят работать над чистой кодовой базой и всегда агитируют начать все сначала. Но почти никогда не следует начинать заново, потому что это сопряжено с невероятными рисками.
Но иногда приходится:
- Нужно объединить два или более продукта в один с перекрывающимися возможностями и множеством новых требований. Создать новый продукт чаще намного быстрее.
- Первоначальные архитектурные предположения настолько ошибочны, или проблемы безопасности/конфиденциальности/соответствия настолько серьёзны, что единственным решением является создание нового продукта.
- Компания так далеко отошла от первоначальной основной миссии, что рефакторинг не спасёт кодовую базу.
Это серьёзное событие. Риски сумасшедшие: клиенты могут не захотеть использовать переписанный продукт. Команда может развалиться до или во время переписывания. Компания может рухнуть или у неё закончатся деньги. Переписать на новую архитектуру может не получиться по какой-то технической причине. Рассмотрите все компромиссы и убедитесь, что все согласны с вашим решением.
Итого
Большая часть этого процесса происходит за счёт времени команды на создание функций, но время, потерянное при этом, намного меньше, чем потеря всей команды. Держите технический долг под контролем.
Источник: https://betterprogramming.pub/managing-team-health-tech-debt-and-avoiding-the-dreaded-rewrite-94878da7ca43
Управляем Здоровьем Команды, Техническим Долгом и Предотвращаем Переписывание с Нуля. Окончание
Начало
Продолжение
Хорошая практика №3: дисциплинированное исправление/рефакторинг
Организуйте ротацию дежурных в момент отправки продукта. Несмотря на то, что в продукте мало ошибок, может быть, мало клиентов и нет шансов выхода из строя под нагрузкой, назначение дежурных и их ротация заранее запускает «мышечную память».
Дежурство в команде с небольшим продуктом, пользовательской базой или активностью кажется контрпродуктивным, поскольку дежурные не создают новых функций. Кажется, что нужно задействовать всех на улучшение продукта, и не беспокоиться о поддержке, пока это не понадобится. Но так вы лишаете себя хорошего и простого средства управления техническим долгом и поддержания здоровья команды.
Что делать?
- Установите ротацию в тот момент, когда пользователи продукта смогут получить доступ к продукту. Наличие пользователей – это сообщения об ошибках.
- Установите разумную продолжительность (1 неделя, 1 спринт), чёткие процедуры передачи задач и расписание, чтобы все знали, когда они будут дежурить.
- Дежурство — это устранение инцидентов, исправление ошибок, снижение сложности кода (рефакторинг), а только затем работа над новыми функциями. Если бэклог ошибок заполняет всё дежурство, этот инженер не работает над новыми функциями.
- Не назначайте дежурному инженеру ничего, кроме дежурных задач.
Зачем?
- Команда методично устраняет ошибки, и технический долг стабилизируется.
- Команда выполняет SLA по ошибкам — внутренние и внешние клиенты довольны.
- Более стабильный продукт => меньше пожаров в продакшене и меньше простоев.
- Младшие инженеры получают возможность исправлять ошибки во всех частях системы, быстрее повышая свой уровень.
- Ещё одна система раннего предупреждения о здоровье команды. Если дежурство занято сложными, серьёзными ошибками, мы узнаём о проблемах сразу, а не через несколько месяцев.
Помните о компромиссе: команда предоставит меньше функций за счёт более стабильного продукта. Устанавливайте ожидания относительно ротации дежурных не в команде, а в организации в целом.
Переписывать ли заново?
Вышеупомянутые принципы должны создать систему раннего предупреждения и сосредоточить команду на поиске рефакторинга архитектуры из-за изменения технологии или бизнес-условий задолго до того, как вы достигнете этого состояния.
Инженеры любят работать над чистой кодовой базой и всегда агитируют начать все сначала. Но почти никогда не следует начинать заново, потому что это сопряжено с невероятными рисками.
Но иногда приходится:
- Нужно объединить два или более продукта в один с перекрывающимися возможностями и множеством новых требований. Создать новый продукт чаще намного быстрее.
- Первоначальные архитектурные предположения настолько ошибочны, или проблемы безопасности/конфиденциальности/соответствия настолько серьёзны, что единственным решением является создание нового продукта.
- Компания так далеко отошла от первоначальной основной миссии, что рефакторинг не спасёт кодовую базу.
Это серьёзное событие. Риски сумасшедшие: клиенты могут не захотеть использовать переписанный продукт. Команда может развалиться до или во время переписывания. Компания может рухнуть или у неё закончатся деньги. Переписать на новую архитектуру может не получиться по какой-то технической причине. Рассмотрите все компромиссы и убедитесь, что все согласны с вашим решением.
Итого
Большая часть этого процесса происходит за счёт времени команды на создание функций, но время, потерянное при этом, намного меньше, чем потеря всей команды. Держите технический долг под контролем.
Источник: https://betterprogramming.pub/managing-team-health-tech-debt-and-avoiding-the-dreaded-rewrite-94878da7ca43
👍8
День 1733. #BestPractices #ProjectManagement
Принципы Бережливой Разработки ПО
Бережливая Разработка ПО (Lean Software Development) — это гибкая система управления проектами и разработки продуктов, основанная на принципах бережливого производства. Основное внимание уделяется обеспечению ценности для клиента путём оптимизации ресурсов, рабочих потоков и процессов. Ниже рассмотрим основные принципы бережливой разработки.
1. Устранение потерь
Эта концепция заимствована из мира бережливого производства, где она известна как «муда» (от японского бесполезность, расточительность). В разработке ПО потерями может быть что угодно: от написания ненужного кода до чрезмерных совещаний, которые не приносят никакой пользы. Цель состоит в том, чтобы оптимизировать рабочий процесс, выявляя и удаляя всё, что не помогает конечному продукту или не удовлетворяет потребностям клиента.
2. Усиленное обучение
Обучение является неотъемлемой частью разработки. Принцип усиленного обучения подчёркивает, что команда всегда должна находиться в состоянии непрерывного обучения. Будь то проверка кода, обратная связь или изучение новых материалов, этот принцип предполагает, что более информированная команда производит продукт более высокого качества. Такие практики, как предметно-ориентированное проектирование (DDD), помогают команде сосредоточиться на изучении и правильном моделировании предметной области.
3. Принятие решения как можно позже
Слишком раннее принятие решений может привести к переработке, если эти решения окажутся неправильными. Этот принцип советует отложить принятие решения до последнего ответственного момента. Это позволит команде получить максимальное количество информации и контекста перед принятием решения, тем самым снижая вероятность дорогостоящих ошибок.
4. Максимально быстрая поставка
Скорость и эффективность являются ключевыми факторами в бережливой разработке программного обеспечения. Этот принцип направлен на максимально быструю поставку функционального продукта покупателю. Речь идет не о спешке, а о поиске оптимального потока, который позволит выполнить быструю поставку без ущерба для качества. Важными показателями, которые команды могут отслеживать, чтобы определить скорость поставки готовых продуктов, являются
- время цикла (cycle time) - время, которое нужно команде, чтобы создать продукт,
- время поставки (lead time) – время между выставлением заказа клиентом и исполнением заказа.
5. Расширение возможностей команды
В рамках бережливой разработки ПО мотивированная и самостоятельная команда считается более эффективной и гибкой. Расширение прав и возможностей команды предполагает предоставление им автономии в принятии решений и ответственности за выполнение своих задач. Это создаёт чувство ответственности среди членов команды, повышая их производительность и продуктивность.
6. Обеспечение целостности
Качество не должно быть второстепенным вопросом; оно должно быть интегрировано в продукт с самого начала. Обеспечение целостности означает создание надёжной, удобной в обслуживании и адаптируемой системы с самого начала. Это требует стремления к совершенству от каждого члена команды на каждом этапе процесса разработки.
7. Оптимизация всего
Принципы бережливого производства подчеркивают важность рассмотрения процесса разработки как единого целого. Вместо того, чтобы сосредотачиваться исключительно на отдельных задачах или модулях, важно понять, как каждый элемент вписывается в общую картину. Оптимизируя всю систему, а не её части, вы можете обеспечить максимальную эффективность всего процесса.
Помните: «система, порождающая дефекты, является дефектной системой» - Джеффри Палермо. Обеспечьте качество всего процесса и выявляйте проблемы до того, как они покинут процесс.
Источник: https://ardalis.com/principles-lean-software-development/
Принципы Бережливой Разработки ПО
Бережливая Разработка ПО (Lean Software Development) — это гибкая система управления проектами и разработки продуктов, основанная на принципах бережливого производства. Основное внимание уделяется обеспечению ценности для клиента путём оптимизации ресурсов, рабочих потоков и процессов. Ниже рассмотрим основные принципы бережливой разработки.
1. Устранение потерь
Эта концепция заимствована из мира бережливого производства, где она известна как «муда» (от японского бесполезность, расточительность). В разработке ПО потерями может быть что угодно: от написания ненужного кода до чрезмерных совещаний, которые не приносят никакой пользы. Цель состоит в том, чтобы оптимизировать рабочий процесс, выявляя и удаляя всё, что не помогает конечному продукту или не удовлетворяет потребностям клиента.
2. Усиленное обучение
Обучение является неотъемлемой частью разработки. Принцип усиленного обучения подчёркивает, что команда всегда должна находиться в состоянии непрерывного обучения. Будь то проверка кода, обратная связь или изучение новых материалов, этот принцип предполагает, что более информированная команда производит продукт более высокого качества. Такие практики, как предметно-ориентированное проектирование (DDD), помогают команде сосредоточиться на изучении и правильном моделировании предметной области.
3. Принятие решения как можно позже
Слишком раннее принятие решений может привести к переработке, если эти решения окажутся неправильными. Этот принцип советует отложить принятие решения до последнего ответственного момента. Это позволит команде получить максимальное количество информации и контекста перед принятием решения, тем самым снижая вероятность дорогостоящих ошибок.
4. Максимально быстрая поставка
Скорость и эффективность являются ключевыми факторами в бережливой разработке программного обеспечения. Этот принцип направлен на максимально быструю поставку функционального продукта покупателю. Речь идет не о спешке, а о поиске оптимального потока, который позволит выполнить быструю поставку без ущерба для качества. Важными показателями, которые команды могут отслеживать, чтобы определить скорость поставки готовых продуктов, являются
- время цикла (cycle time) - время, которое нужно команде, чтобы создать продукт,
- время поставки (lead time) – время между выставлением заказа клиентом и исполнением заказа.
5. Расширение возможностей команды
В рамках бережливой разработки ПО мотивированная и самостоятельная команда считается более эффективной и гибкой. Расширение прав и возможностей команды предполагает предоставление им автономии в принятии решений и ответственности за выполнение своих задач. Это создаёт чувство ответственности среди членов команды, повышая их производительность и продуктивность.
6. Обеспечение целостности
Качество не должно быть второстепенным вопросом; оно должно быть интегрировано в продукт с самого начала. Обеспечение целостности означает создание надёжной, удобной в обслуживании и адаптируемой системы с самого начала. Это требует стремления к совершенству от каждого члена команды на каждом этапе процесса разработки.
7. Оптимизация всего
Принципы бережливого производства подчеркивают важность рассмотрения процесса разработки как единого целого. Вместо того, чтобы сосредотачиваться исключительно на отдельных задачах или модулях, важно понять, как каждый элемент вписывается в общую картину. Оптимизируя всю систему, а не её части, вы можете обеспечить максимальную эффективность всего процесса.
Помните: «система, порождающая дефекты, является дефектной системой» - Джеффри Палермо. Обеспечьте качество всего процесса и выявляйте проблемы до того, как они покинут процесс.
Источник: https://ardalis.com/principles-lean-software-development/
👍11
День 1739. #BestPractices #ProjectManagement
Раздувание Процессов: Тихий Убийца Продуктивности Разработчиков
На начальных стадиях проекта разработки команды отличаются гибкостью, быстрым принятием решений и стремлением предоставлять ценные функции. Однако по мере того, как проекты усложняются и масштабируются, многие из них становятся жертвами коварного антипаттерна: раздувания процессов.
Факторов, приводящих к этому, множество:
1. Организационная культура.
Слишком осторожная организация может создать несколько уровней бюрократии, предполагая, что чем больше формализованы процессы тем меньше риск.
2. Недостаток доверия.
Руководство, которому не хватает уверенности в возможностях разработчиков, может навязать несколько уровней утверждения и документацию.
3. Сложность масштаба.
Расширение проектов часто влечёт увеличение числа заинтересованных сторон, каждая из которых добавляет свой уровень сложности и свои процессы.
4. Устаревший багаж.
Иногда ненужные процессы задерживаются просто потому, что «так было всегда».
Последствия
1. Снижение производительности.
Разработчики часто тратят больше времени на административную работу, чем на фактическую разработку.
2. Утечка инноваций.
Бюрократия может подавить творчество и ограничить эксперименты.
3. Задержка вывода продукта на рынок.
Сложные процессы удлиняют циклы разработки.
4. Снижение морального духа.
Потеря гибкости и рутина процессов могут подорвать моральный дух команды.
Примеры раздувания процессов
1. Чрезмерные проверки кода.
Обязательное проведение нескольких уровней проверок даже для тривиальных изменений может серьёзно замедлить цикл разработки.
2. Слишком сложные системы заявок.
Сложные системы тикетов, требующие заполнения множества полей ещё до того, как задача будет одобрена, могут занять столько же времени, сколько и исполнение задачи.
3. Обязательные отчеты.
Требование подробных отчетов с описанием каждой потраченной минуты может отнять время и отвлечь внимание от фактического кодирования.
4. Чрезмерное количество совещаний
Борьба с раздуванием процессов
1. Регулярные аудиты.
Последовательно анализируйте существующие процессы для оценки их актуальности и эффективности. Это следует делать в рамках регулярных командных (и организационных) ретроспектив. Но убедитесь, что такие аудиты полезны, а не усугубляют проблему раздувания процессов!
2. Принципы бережливости и гибкости.
Примите методологии, направленные на получение максимальной отдачи при минимальных затратах на процессы. Многие agile-практики, подчёркивают важность обеспечения быстрого прохождения процесса с минимальными церемониями.
3. Поощряйте доверие и автономию.
Дайте разработчикам полномочия принимать решения без ненужных бюрократических одобрений. Ваша команда не сможет заслужить ваше доверие, если вы как менеджер первый не доверитесь ей.
4. Минимально жизнеспособный процесс.
Внедряйте только те процессы, которые абсолютно необходимы для поддержания качества и контроля. Если сомневаетесь, выбросьте. Если есть возможность сократить процессы и повысить производительность, поэкспериментируйте с этим и посмотрите, сработает ли это для вашей команды и организации.
Итого
Раздувание процессов — это тихий, но смертоносный фактор, подрывающий продуктивность разработки ПО. Распознав его симптомы и приняв упреждающие меры, команды смогут вернуть себе гибкость и дух творчества, а проекты вернуть на путь эффективности и инноваций.
Источник: https://ardalis.com/process-bloat-silent-killer-developer-productivity/
Раздувание Процессов: Тихий Убийца Продуктивности Разработчиков
На начальных стадиях проекта разработки команды отличаются гибкостью, быстрым принятием решений и стремлением предоставлять ценные функции. Однако по мере того, как проекты усложняются и масштабируются, многие из них становятся жертвами коварного антипаттерна: раздувания процессов.
Факторов, приводящих к этому, множество:
1. Организационная культура.
Слишком осторожная организация может создать несколько уровней бюрократии, предполагая, что чем больше формализованы процессы тем меньше риск.
2. Недостаток доверия.
Руководство, которому не хватает уверенности в возможностях разработчиков, может навязать несколько уровней утверждения и документацию.
3. Сложность масштаба.
Расширение проектов часто влечёт увеличение числа заинтересованных сторон, каждая из которых добавляет свой уровень сложности и свои процессы.
4. Устаревший багаж.
Иногда ненужные процессы задерживаются просто потому, что «так было всегда».
Последствия
1. Снижение производительности.
Разработчики часто тратят больше времени на административную работу, чем на фактическую разработку.
2. Утечка инноваций.
Бюрократия может подавить творчество и ограничить эксперименты.
3. Задержка вывода продукта на рынок.
Сложные процессы удлиняют циклы разработки.
4. Снижение морального духа.
Потеря гибкости и рутина процессов могут подорвать моральный дух команды.
Примеры раздувания процессов
1. Чрезмерные проверки кода.
Обязательное проведение нескольких уровней проверок даже для тривиальных изменений может серьёзно замедлить цикл разработки.
2. Слишком сложные системы заявок.
Сложные системы тикетов, требующие заполнения множества полей ещё до того, как задача будет одобрена, могут занять столько же времени, сколько и исполнение задачи.
3. Обязательные отчеты.
Требование подробных отчетов с описанием каждой потраченной минуты может отнять время и отвлечь внимание от фактического кодирования.
4. Чрезмерное количество совещаний
Борьба с раздуванием процессов
1. Регулярные аудиты.
Последовательно анализируйте существующие процессы для оценки их актуальности и эффективности. Это следует делать в рамках регулярных командных (и организационных) ретроспектив. Но убедитесь, что такие аудиты полезны, а не усугубляют проблему раздувания процессов!
2. Принципы бережливости и гибкости.
Примите методологии, направленные на получение максимальной отдачи при минимальных затратах на процессы. Многие agile-практики, подчёркивают важность обеспечения быстрого прохождения процесса с минимальными церемониями.
3. Поощряйте доверие и автономию.
Дайте разработчикам полномочия принимать решения без ненужных бюрократических одобрений. Ваша команда не сможет заслужить ваше доверие, если вы как менеджер первый не доверитесь ей.
4. Минимально жизнеспособный процесс.
Внедряйте только те процессы, которые абсолютно необходимы для поддержания качества и контроля. Если сомневаетесь, выбросьте. Если есть возможность сократить процессы и повысить производительность, поэкспериментируйте с этим и посмотрите, сработает ли это для вашей команды и организации.
Итого
Раздувание процессов — это тихий, но смертоносный фактор, подрывающий продуктивность разработки ПО. Распознав его симптомы и приняв упреждающие меры, команды смогут вернуть себе гибкость и дух творчества, а проекты вернуть на путь эффективности и инноваций.
Источник: https://ardalis.com/process-bloat-silent-killer-developer-productivity/
👍7
День 1745. #Карьера #ProjectManagement
Как Дать Эффективную Обратную Связь Сложному Человеку. Начало
Если слишком долго позволять трудным в общении людям делать всё по-своему, это может нанести непоправимый ущерб. Предоставление им обратной связи будет неэффективным, если она не будет правильной. Рассмотрим стратегии предоставления обратной связи таким трудным людям.
В коллективах бывают умные, талантливые и результативные люди. Они умеют решать сложные проблемы, и на них можно положиться для достижения цели. Но что, если они хороши только при самостоятельном выполнении работы? Что, если команде трудно общаться и сотрудничать с ними, что снижает продуктивность и результативность команды? Что, если они:
- Унижают других, когда их идеи неудачны.
- Занимают оборонительную позицию, когда другие с ними не согласны.
- Устанавливают высокие стандарты и ожидают, что другие будут им соответствовать.
- Выражают недовольство криком и гневом.
- Перебивают других и не позволяя им говорить.
- Ожидают особого к себе отношения.
То, что они хороши в том, что они делают, не дает им права действовать бездумно по отношению к другим. Каждый заслуживает уважения, и ни от кого не следует ожидать толерантности к плохому поведению.
Роберт Саттон в книге «Хороший босс, плохой босс» говорит, что лучшие начальники делают больше, чем просто заряжают людей, набирают и воспитывают работяг. Они устраняют негатив, потому что даже один токсичный человек или несколько деструктивных поступков могут навредить множеству хороших людей и конструктивных действий.
Это не значит, что надо избавиться от них. Это последний выход, когда ничего больше не помогает. Сначала возьмите на себя сложную задачу дать обратную связь этим трудным людям.
Именно здесь большинство менеджеров допускают ошибки. Они либо слишком долго позволяют трудным людям делать всё по-своему, причиняя непоправимый ущерб, либо дают обратную связь в неправильной форме. Тогда трудные люди отказываются её принимать, занимают оборонительную позицию и могут даже ожесточиться, что только больше усложнит работу с ними.
Вот 4 стратегии дать обратную связь сложному человеку, чтобы он не бросил работу или не создал ещё больше проблем.
1. Тщательно выбирайте слова
Для сложного человека определённые слова в обратной связи вызывают сильные негативные чувства, которые заставляют его защищаться:
- Обобщающие, типа «всегда» и «никогда».
- Навязывающие, как «не могу», «не должен», «должен», «подчиняться».
- Бросающие вызов: «плохой», «требовательный», «непрофессиональный», «грубый».
- Осуждающие: «ошибка», «неудача», «неприемлемо».
Селеста Хэдли пишет в книге «Нам надо поговорить»: «Высокообразованные люди склонны придавать большое значение логике и преуменьшать важность эмоций. Конечно, вы не можете выиграть дебаты с помощью эмоциональных аргументов, но разговор — это не дебаты, а люди по своей сути нелогичны. Мы эмоциональные существа. Удалить или попытаться удалить эмоции из вашего разговора — значит извлечь большую часть смысла и важности».
Будьте внимательны, тщательно обдумайте эффект того, что вы говорите, и избегайте эмоционально заряженных слов, которые делают обратную связь неэффективной.
Например:
Вместо: Вы всегда опаздываете на встречи. Ваше поведение испортит и других членов команды.
Скажите: На последних двух встречах я заметил, что вы приходили через 10-15 минут после начала. Вы можете приходить на собрания вовремя и подать хороший пример другим?
Вместо: Вы должны позволить другим высказываться в обсуждениях. Перебивать их – это грубо.
Скажите: Выслушивание различных точек зрения поможет нам принимать более правильные решения. Давайте попробуем стимулировать участие других в обсуждениях.
Продолжение следует…
Источник: https://www.techtello.com/give-feedback-to-a-difficult-person/
Как Дать Эффективную Обратную Связь Сложному Человеку. Начало
Если слишком долго позволять трудным в общении людям делать всё по-своему, это может нанести непоправимый ущерб. Предоставление им обратной связи будет неэффективным, если она не будет правильной. Рассмотрим стратегии предоставления обратной связи таким трудным людям.
В коллективах бывают умные, талантливые и результативные люди. Они умеют решать сложные проблемы, и на них можно положиться для достижения цели. Но что, если они хороши только при самостоятельном выполнении работы? Что, если команде трудно общаться и сотрудничать с ними, что снижает продуктивность и результативность команды? Что, если они:
- Унижают других, когда их идеи неудачны.
- Занимают оборонительную позицию, когда другие с ними не согласны.
- Устанавливают высокие стандарты и ожидают, что другие будут им соответствовать.
- Выражают недовольство криком и гневом.
- Перебивают других и не позволяя им говорить.
- Ожидают особого к себе отношения.
То, что они хороши в том, что они делают, не дает им права действовать бездумно по отношению к другим. Каждый заслуживает уважения, и ни от кого не следует ожидать толерантности к плохому поведению.
Роберт Саттон в книге «Хороший босс, плохой босс» говорит, что лучшие начальники делают больше, чем просто заряжают людей, набирают и воспитывают работяг. Они устраняют негатив, потому что даже один токсичный человек или несколько деструктивных поступков могут навредить множеству хороших людей и конструктивных действий.
Это не значит, что надо избавиться от них. Это последний выход, когда ничего больше не помогает. Сначала возьмите на себя сложную задачу дать обратную связь этим трудным людям.
Именно здесь большинство менеджеров допускают ошибки. Они либо слишком долго позволяют трудным людям делать всё по-своему, причиняя непоправимый ущерб, либо дают обратную связь в неправильной форме. Тогда трудные люди отказываются её принимать, занимают оборонительную позицию и могут даже ожесточиться, что только больше усложнит работу с ними.
Вот 4 стратегии дать обратную связь сложному человеку, чтобы он не бросил работу или не создал ещё больше проблем.
1. Тщательно выбирайте слова
Для сложного человека определённые слова в обратной связи вызывают сильные негативные чувства, которые заставляют его защищаться:
- Обобщающие, типа «всегда» и «никогда».
- Навязывающие, как «не могу», «не должен», «должен», «подчиняться».
- Бросающие вызов: «плохой», «требовательный», «непрофессиональный», «грубый».
- Осуждающие: «ошибка», «неудача», «неприемлемо».
Селеста Хэдли пишет в книге «Нам надо поговорить»: «Высокообразованные люди склонны придавать большое значение логике и преуменьшать важность эмоций. Конечно, вы не можете выиграть дебаты с помощью эмоциональных аргументов, но разговор — это не дебаты, а люди по своей сути нелогичны. Мы эмоциональные существа. Удалить или попытаться удалить эмоции из вашего разговора — значит извлечь большую часть смысла и важности».
Будьте внимательны, тщательно обдумайте эффект того, что вы говорите, и избегайте эмоционально заряженных слов, которые делают обратную связь неэффективной.
Например:
Вместо: Вы всегда опаздываете на встречи. Ваше поведение испортит и других членов команды.
Скажите: На последних двух встречах я заметил, что вы приходили через 10-15 минут после начала. Вы можете приходить на собрания вовремя и подать хороший пример другим?
Вместо: Вы должны позволить другим высказываться в обсуждениях. Перебивать их – это грубо.
Скажите: Выслушивание различных точек зрения поможет нам принимать более правильные решения. Давайте попробуем стимулировать участие других в обсуждениях.
Продолжение следует…
Источник: https://www.techtello.com/give-feedback-to-a-difficult-person/
👍11