День 2279. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 50. Сегодняшний проект, требующий немедленной реализации, завтра может превратиться в кошмар для службы сопровождения
После релиза системы начинается этап её поддержки. Основные категории поддержки ПО:
- адаптация — модификация в целях работы в операционной среде;
- корректировка — диагностика и устранение дефектов;
- совершенствование — добавление новых функций, повышение производительности и т.п.;
- профилактика — оптимизация и рефакторинг для повышения эффективности, простоты, удобства сопровождения и надёжности.
Добавляемые улучшения могут по-прежнему требовать корректирующей поддержки в целях устранения дефектов. Помимо недостатков требований и кода, недостатки проектирования будут продолжать поглощать ресурсы и при поддержке.
Технический долг и профилактическая поддержка
Команды разработчиков иногда допускают снижение качества, что приводит к образованию технического долга. Быстро написанный код может быть недостаточно продуманным, работать только в данный момент, выполняться неэффективно или быть малопонятным сопровождающих. Быстрые исправления кода могут давать неожиданные побочные эффекты.
Как и любой другой, техдолг рано или поздно должен быть погашен, причём с процентами. Выплата техдолга в ПО включает рефакторинг, реструктуризацию или переписывание кода. Чем дольше долг сохраняется в системе, тем больше процентов начисляется по нему. Каждая минута, потраченная на не совсем правильный код, считается процентом по этому долгу. Значительная доля профилактической поддержки связана с устранением техдолга. Ваша цель - оставить код в лучшем состоянии, чем когда он попал к вам.
Осознанный технический долг
Иногда разумно накопить некий объём техдолга, если команда осознаёт, что переделка несовершенного проекта в будущем обойдется дороже. Если ожидается, что код будет жить недолго, то, возможно, не стоит тратить время на его детальную проработку. Но часто это ожидание не оправдывается. Прототип слишком часто попадает в релиз и в дальнейшем сбивает с толку тех, кто занимается его сопровождением.
Если вы осознаёте техдолг и предусматриваете время в будущих итерациях на устранение недостатков, а не просто надеетесь, что они не вызовут проблем, то, возможно, имеет смысл отложить тщательную проработку проекта. Однако в итоге всё равно придётся улучшать проект, поэтому убедитесь в том, что понимаете это. Таким образом имеются осознанный и случайный техдолг.
Неспособность исправить недостатки проектного решения и кода усложняет работу с системой в последующих итерациях или во время эксплуатации. Эти накопленные проблемы замедляют дальнейшую разработку сейчас и потребуют чрезмерных усилий по поддержке позже.
Погашение техдолга добавляет в проект свои риски. Вы просто улучшаете то, что уже работает, но эти улучшения тоже требуют проверки и утверждения, как и любой другой код в проекте. Регрессионное тестирование и другие методы контроля качества требуют больше времени, чем написание самого кода. Чем масштабнее код и чем глубже перерабатывается проект, тем выше риск непреднамеренно нарушить нормальную работу чего-то ещё.
Всегда есть что-то более срочное, чем рефакторинг существующего кода. Порой трудно выделить ресурсы на погашение техдолга, когда клиенты требуют незамедлительно расширить возможности ПО. Основная проблема при работе с унаследованным кодом — на внесение изменений необходимо много времени. Поэтому если вы хотите, чтобы код был долговечным, то убедитесь, что будущим разработчикам будет приятно вносить в него изменения.
Сделайте профилактическую поддержку частью повседневной деятельности по разработке, улучшайте проекты и код всякий раз, когда взаимодействуете с ними. Не закрывайте глаза на встречающиеся недостатки качества — минимизируйте их.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 6.
Уроки 50 Лет Разработки ПО
Урок 50. Сегодняшний проект, требующий немедленной реализации, завтра может превратиться в кошмар для службы сопровождения
После релиза системы начинается этап её поддержки. Основные категории поддержки ПО:
- адаптация — модификация в целях работы в операционной среде;
- корректировка — диагностика и устранение дефектов;
- совершенствование — добавление новых функций, повышение производительности и т.п.;
- профилактика — оптимизация и рефакторинг для повышения эффективности, простоты, удобства сопровождения и надёжности.
Добавляемые улучшения могут по-прежнему требовать корректирующей поддержки в целях устранения дефектов. Помимо недостатков требований и кода, недостатки проектирования будут продолжать поглощать ресурсы и при поддержке.
Технический долг и профилактическая поддержка
Команды разработчиков иногда допускают снижение качества, что приводит к образованию технического долга. Быстро написанный код может быть недостаточно продуманным, работать только в данный момент, выполняться неэффективно или быть малопонятным сопровождающих. Быстрые исправления кода могут давать неожиданные побочные эффекты.
Как и любой другой, техдолг рано или поздно должен быть погашен, причём с процентами. Выплата техдолга в ПО включает рефакторинг, реструктуризацию или переписывание кода. Чем дольше долг сохраняется в системе, тем больше процентов начисляется по нему. Каждая минута, потраченная на не совсем правильный код, считается процентом по этому долгу. Значительная доля профилактической поддержки связана с устранением техдолга. Ваша цель - оставить код в лучшем состоянии, чем когда он попал к вам.
Осознанный технический долг
Иногда разумно накопить некий объём техдолга, если команда осознаёт, что переделка несовершенного проекта в будущем обойдется дороже. Если ожидается, что код будет жить недолго, то, возможно, не стоит тратить время на его детальную проработку. Но часто это ожидание не оправдывается. Прототип слишком часто попадает в релиз и в дальнейшем сбивает с толку тех, кто занимается его сопровождением.
Если вы осознаёте техдолг и предусматриваете время в будущих итерациях на устранение недостатков, а не просто надеетесь, что они не вызовут проблем, то, возможно, имеет смысл отложить тщательную проработку проекта. Однако в итоге всё равно придётся улучшать проект, поэтому убедитесь в том, что понимаете это. Таким образом имеются осознанный и случайный техдолг.
Неспособность исправить недостатки проектного решения и кода усложняет работу с системой в последующих итерациях или во время эксплуатации. Эти накопленные проблемы замедляют дальнейшую разработку сейчас и потребуют чрезмерных усилий по поддержке позже.
Погашение техдолга добавляет в проект свои риски. Вы просто улучшаете то, что уже работает, но эти улучшения тоже требуют проверки и утверждения, как и любой другой код в проекте. Регрессионное тестирование и другие методы контроля качества требуют больше времени, чем написание самого кода. Чем масштабнее код и чем глубже перерабатывается проект, тем выше риск непреднамеренно нарушить нормальную работу чего-то ещё.
Всегда есть что-то более срочное, чем рефакторинг существующего кода. Порой трудно выделить ресурсы на погашение техдолга, когда клиенты требуют незамедлительно расширить возможности ПО. Основная проблема при работе с унаследованным кодом — на внесение изменений необходимо много времени. Поэтому если вы хотите, чтобы код был долговечным, то убедитесь, что будущим разработчикам будет приятно вносить в него изменения.
Сделайте профилактическую поддержку частью повседневной деятельности по разработке, улучшайте проекты и код всякий раз, когда взаимодействуете с ними. Не закрывайте глаза на встречающиеся недостатки качества — минимизируйте их.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 6.
👍8
День 2283. #УрокиРазработки
10 Уроков Качества Разработки ПО. Начало
1. Поймите разницу между внутренним и внешним качеством
Одна из самых сложных частей нашей работы как разработчиков и архитекторов — помочь менеджерам и нетехническим владельцам продукта понять, что мы подразумеваем под плохим качеством ПО. Ключ — различать внутреннее и внешнее качество.
Внешнее качество — это то, что волнует менеджеров и владельцев продукта. Они заметят, когда отзывчивость или удобство использования будут плохими, или когда ошибки, особенно повторяющиеся, будут накапливаться. Но внутреннее качество? Это наша область. Это та часть, которую они не видят, пока технический долг не снизит скорость доставки новых функций до минимума.
Вот некоторые внутренние признаки качества:
- Читаемость
Что делает код и как он работает?
- Тестируемость
Делает ли он то, что должен?
- Изоляция
Могу ли я изменить это, не сломав что-то еще?
- Обнаруживаемость
Где в системе определено нужное поведение?
- Прослеживаемость
Почему было принято это решение (в коде, архитектуре или дизайне)?
2. Делайте код автоматически тестируемым
Знакомо ли вам то чувство, когда вы изменяете код в кодовой базе, с которой вы не на 100% знакомы, но вы полностью уверены, что автоматизированные тесты вас поддержат? Классные ощущения, правда? Теперь представьте себе похожую кодовую базу, но без такого тестового покрытия. Звучит пугающе.
А что, если вы знаете кодовую базу вдоль и поперёк? Достаточно ли вы уверены, чтобы вносить изменения, не рискуя получить катастрофическую ошибку?
Для тех, кто не чувствует себя уверенно, пришло время инвестировать в автоматизированное тестирование. Начните с создания временной страховочной сетки, используя стратегию тестирования характеристик. Затем начните проектировать код для поддержки подхода «сначала тест». Относитесь к своим тестам как к первоклассному коду. Кодовая база, где 40–50% кода является тестами – это здорово.
3. Не терпите нестабильности в автоматизированном тестировании
Каждый разработчик, который пытался создать набор автоматизированных end-to-end тестов, сталкивался с кошмаром их нестабильности. Да, вы можете гордиться тем, что у вас есть солидное количество тестов. Но если вы не можете положиться на эти тесты из-за их нестабильности, это может стать серьёзной головной болью. Определить, провалился ли тест из-за реальной проблемы в коде базе или просто из-за нестабильности, сложно, особенно когда сбой не связан с конкретным изменением кода.
Чаще всего люди просто повторно запускают тест и надеются на лучшее. Назначить кого-то для расследования этих сбоев сложно, и неопределённость может подорвать производительность. Это может показаться очевидным, но не относитесь к нестабильности как к техническому долгу, который нужно устранить позже. Относитесь к ней как к производственному сбою, требующему немедленного внимания.
Если вам повезло использовать инструмент сборки, такой как TeamCity, вы можете отслеживать нестабильность тестов с течением времени, отмечать тесты как нестабильные и отключать их из конвейера сборки. А ещё лучше — назначить нестабильный тест кому-то для анализа и исправить его, позволяя сборке успешно завершиться. Это позволит нескольким разработчикам не тратить время, пытаясь выяснить, нужно ли им что-то делать с нестабильным тестом. Если у вас нет этих инструментов, договоритесь всей командой о том, чтобы отдать приоритет исправлению нестабильных тестов, чтобы снова сделать сборку зелёной.
Продолжение следует…
Источник: https://www.dennisdoomen.com/2025/03/10-quality-lessons.html
10 Уроков Качества Разработки ПО. Начало
1. Поймите разницу между внутренним и внешним качеством
Одна из самых сложных частей нашей работы как разработчиков и архитекторов — помочь менеджерам и нетехническим владельцам продукта понять, что мы подразумеваем под плохим качеством ПО. Ключ — различать внутреннее и внешнее качество.
Внешнее качество — это то, что волнует менеджеров и владельцев продукта. Они заметят, когда отзывчивость или удобство использования будут плохими, или когда ошибки, особенно повторяющиеся, будут накапливаться. Но внутреннее качество? Это наша область. Это та часть, которую они не видят, пока технический долг не снизит скорость доставки новых функций до минимума.
Вот некоторые внутренние признаки качества:
- Читаемость
Что делает код и как он работает?
- Тестируемость
Делает ли он то, что должен?
- Изоляция
Могу ли я изменить это, не сломав что-то еще?
- Обнаруживаемость
Где в системе определено нужное поведение?
- Прослеживаемость
Почему было принято это решение (в коде, архитектуре или дизайне)?
2. Делайте код автоматически тестируемым
Знакомо ли вам то чувство, когда вы изменяете код в кодовой базе, с которой вы не на 100% знакомы, но вы полностью уверены, что автоматизированные тесты вас поддержат? Классные ощущения, правда? Теперь представьте себе похожую кодовую базу, но без такого тестового покрытия. Звучит пугающе.
А что, если вы знаете кодовую базу вдоль и поперёк? Достаточно ли вы уверены, чтобы вносить изменения, не рискуя получить катастрофическую ошибку?
Для тех, кто не чувствует себя уверенно, пришло время инвестировать в автоматизированное тестирование. Начните с создания временной страховочной сетки, используя стратегию тестирования характеристик. Затем начните проектировать код для поддержки подхода «сначала тест». Относитесь к своим тестам как к первоклассному коду. Кодовая база, где 40–50% кода является тестами – это здорово.
3. Не терпите нестабильности в автоматизированном тестировании
Каждый разработчик, который пытался создать набор автоматизированных end-to-end тестов, сталкивался с кошмаром их нестабильности. Да, вы можете гордиться тем, что у вас есть солидное количество тестов. Но если вы не можете положиться на эти тесты из-за их нестабильности, это может стать серьёзной головной болью. Определить, провалился ли тест из-за реальной проблемы в коде базе или просто из-за нестабильности, сложно, особенно когда сбой не связан с конкретным изменением кода.
Чаще всего люди просто повторно запускают тест и надеются на лучшее. Назначить кого-то для расследования этих сбоев сложно, и неопределённость может подорвать производительность. Это может показаться очевидным, но не относитесь к нестабильности как к техническому долгу, который нужно устранить позже. Относитесь к ней как к производственному сбою, требующему немедленного внимания.
Если вам повезло использовать инструмент сборки, такой как TeamCity, вы можете отслеживать нестабильность тестов с течением времени, отмечать тесты как нестабильные и отключать их из конвейера сборки. А ещё лучше — назначить нестабильный тест кому-то для анализа и исправить его, позволяя сборке успешно завершиться. Это позволит нескольким разработчикам не тратить время, пытаясь выяснить, нужно ли им что-то делать с нестабильным тестом. Если у вас нет этих инструментов, договоритесь всей командой о том, чтобы отдать приоритет исправлению нестабильных тестов, чтобы снова сделать сборку зелёной.
Продолжение следует…
Источник: https://www.dennisdoomen.com/2025/03/10-quality-lessons.html
👍10
День 2284. #УрокиРазработки
10 Уроков Качества Разработки ПО. Продолжение
Начало
4. Пишите код, который вы можете уверенно изменять
Самый важный аспект поддерживаемого кода — это возможность изменять его уверенно: уверенность в том, что вы его поняли, внесли правильные изменения и ничего больше не сломали.
Вот несколько рекомендаций:
- Код должен читаться как книга — методы упорядочены по порядку выполнения, а не по порядку видимости.
- Весь код в методе или функции должен находиться на одном уровне абстракции.
- Методы должны стараться не выходить за рамки 15 строк кода.
- Имена методов должны быть функциональными и объяснять их назначение, а не реализацию.
- Документация кода должна описывать, почему существует метод, а не как он работает.
- Встроенные комментарии допустимы, если они предоставляют дополнительный контекст.
- return либо в самом начале, либо в самом конце, но не в середине.
- Избегайте булевых параметров, используйте перечисления.
- Не вводите абстракции только ради внедрения зависимостей.
- Группируйте код по функциональности, а не по технической структуре для большей ясности.
- Обеспечьте достаточное покрытие тестами: 80% — хорошо, 90% — отлично, 95% — слишком много.
- Не тестируйте слишком подробно; тестируйте внешний интерфейс, но не детали реализации.
5. Это никогда не происходит только один раз
Вы когда-нибудь писали наспех код, а затем обнаруживали, что его используют снова и снова? Или вас просили создать прототип, который каким-то образом попадал в релиз? А как насчёт странной ошибки, которая волшебным образом разрешалась сама собой во время тестирования — только чтобы позже снова появиться в производстве?
Если вы не создаёте MVP (минимально жизнеспособный продукт), не используйте эти практики. Выделите время, чтобы заменить это одноразовое решение надлежащим долгосрочным кодом. Не соглашайтесь на ситуативные решения — будь то очистка куков, повторный запуск нестабильного теста, проблемы с разрешениями или тайм-аутами. Всегда решайте проблемы в корне. Будущий вы скажет вам спасибо.
6. Избегайте любых ручных шагов во время развёртывания
Способность команды развёртывать должным образом протестированную и версионированную программную систему на своей внутренней или облачной инфраструктуре является хорошим показателем зрелости команды. Любой ручной шаг в этом процессе (за исключением ручного запуска конвейера развёртывания) является потенциальной ответственностью и должен быть автоматизирован. Люди совершают ошибки, независимо от того, насколько они скрупулёзны.
С другой стороны, хорошо спроектированный конвейер развёртывания заботится о компиляции исходного кода, вызове любых инструментов анализа кода, запуске автоматизированных тестов, версионировании артефактов развёртывания, предоставлении инфраструктуры, обновлении схемы базы данных, развёртывании в промежуточном слоте, а затем, после подтверждения работоспособности, заменяет его на производственный слот. Всё это без необходимости сообщать разработчикам пароли производственной среды и без того, чтобы кто-либо подключался к производственной среде и вручную запускал скрипты. И если ваш руководитель не видит в этом ценности, аудит, связанный с многочисленными стандартами безопасности, которые у нас есть в настоящее время (ISO 27001, NIS и т.д.), поможет его убедить.
Окончание следует…
Источник: https://www.dennisdoomen.com/2025/03/10-quality-lessons.html
10 Уроков Качества Разработки ПО. Продолжение
Начало
4. Пишите код, который вы можете уверенно изменять
Самый важный аспект поддерживаемого кода — это возможность изменять его уверенно: уверенность в том, что вы его поняли, внесли правильные изменения и ничего больше не сломали.
Вот несколько рекомендаций:
- Код должен читаться как книга — методы упорядочены по порядку выполнения, а не по порядку видимости.
- Весь код в методе или функции должен находиться на одном уровне абстракции.
- Методы должны стараться не выходить за рамки 15 строк кода.
- Имена методов должны быть функциональными и объяснять их назначение, а не реализацию.
- Документация кода должна описывать, почему существует метод, а не как он работает.
- Встроенные комментарии допустимы, если они предоставляют дополнительный контекст.
- return либо в самом начале, либо в самом конце, но не в середине.
- Избегайте булевых параметров, используйте перечисления.
- Не вводите абстракции только ради внедрения зависимостей.
- Группируйте код по функциональности, а не по технической структуре для большей ясности.
- Обеспечьте достаточное покрытие тестами: 80% — хорошо, 90% — отлично, 95% — слишком много.
- Не тестируйте слишком подробно; тестируйте внешний интерфейс, но не детали реализации.
5. Это никогда не происходит только один раз
Вы когда-нибудь писали наспех код, а затем обнаруживали, что его используют снова и снова? Или вас просили создать прототип, который каким-то образом попадал в релиз? А как насчёт странной ошибки, которая волшебным образом разрешалась сама собой во время тестирования — только чтобы позже снова появиться в производстве?
Если вы не создаёте MVP (минимально жизнеспособный продукт), не используйте эти практики. Выделите время, чтобы заменить это одноразовое решение надлежащим долгосрочным кодом. Не соглашайтесь на ситуативные решения — будь то очистка куков, повторный запуск нестабильного теста, проблемы с разрешениями или тайм-аутами. Всегда решайте проблемы в корне. Будущий вы скажет вам спасибо.
6. Избегайте любых ручных шагов во время развёртывания
Способность команды развёртывать должным образом протестированную и версионированную программную систему на своей внутренней или облачной инфраструктуре является хорошим показателем зрелости команды. Любой ручной шаг в этом процессе (за исключением ручного запуска конвейера развёртывания) является потенциальной ответственностью и должен быть автоматизирован. Люди совершают ошибки, независимо от того, насколько они скрупулёзны.
С другой стороны, хорошо спроектированный конвейер развёртывания заботится о компиляции исходного кода, вызове любых инструментов анализа кода, запуске автоматизированных тестов, версионировании артефактов развёртывания, предоставлении инфраструктуры, обновлении схемы базы данных, развёртывании в промежуточном слоте, а затем, после подтверждения работоспособности, заменяет его на производственный слот. Всё это без необходимости сообщать разработчикам пароли производственной среды и без того, чтобы кто-либо подключался к производственной среде и вручную запускал скрипты. И если ваш руководитель не видит в этом ценности, аудит, связанный с многочисленными стандартами безопасности, которые у нас есть в настоящее время (ISO 27001, NIS и т.д.), поможет его убедить.
Окончание следует…
Источник: https://www.dennisdoomen.com/2025/03/10-quality-lessons.html
👍14👎1
День 2285. #УрокиРазработки
10 Уроков Качества Разработки ПО. Окончание
Начало
Продолжение
7. Относитесь к конвейеру сборки и развёртывания так же, как к коду
Особенно болезненный опыт обычно связан с ненадежностью конвейера развёртывания. Поскольку он основан на YAML и встроенных задачах, единственным способом устранения неполадок часто является внесение изменений, постановка конвейера в очередь и ожидание результатов. Просто нет способа проверить это по-другому.
Помимо этого, конвейер — это больше, чем просто ряд задач. Он развивается вместе с кодовой базой, может стать довольно сложным и, следовательно, должен быть простым для понимания и рефакторинга при необходимости. Слишком много компаний пытаются придерживаться конвейеров YAML, обходя ограничения, втискивая скрипты PowerShell или Bash вместе с файлами YAML — хотя есть гораздо лучшие альтернативы. Уже не говоря о необходимости перехода с одного движка сборки на другой, например, с Azure DevOps Pipeline на GitHub Actions. Можно использовать Nuke и C# Это обеспечивает доступ к возможностям навигации, рефакторинга и отладки и позволяет тестировать весь конвейер из локальной среды разработки.
8. После выпуска версии 1.0 будьте ответственны
Ваши пользователи или разработчики зависят от стабильности. Сначала выберите стратегию выпуска — будете ли вы принимать регулярные выпуски или будете выпускать новые версии только при необходимости? Чёткий план помогает согласовывать команды и устанавливать ожидания. Всегда применяйте семантическое управление версиями. Это простая система: увеличивайте основную версию при критических изменениях, второстепенную - для новых функций и версию патча для исправлений ошибок. Избегайте критических изменений, когда это возможно. Внесение серьёзных изменений может разочаровать пользователей, поэтому предоставьте чёткие исключения и альтернативы. Наконец, не забывайте о документации. Чётко документируйте свой код как для команды, так и для пользователей. Хорошо документированный код экономит время, предотвращает ошибки и способствует совместной работе.
9. Берегите историю версий
Представьте, что вы пытаетесь понять, почему кто-то увеличил таймаут для выполнения SQL-запроса до 60 секунд. Нет ничего более разочаровывающего, чем найти PR или описание коммита, в котором указано что-то вроде «Увеличен таймаут SQL». Такое описание сообщает, что было сделано, но не объясняет проблему, которую решал разработчик. Аналогично PR, содержащий один коммит, в котором смешан рефакторинг со значимыми изменениями, скорее всего, вызовет столько же разочарования.
В долго существующей кодовой базе понять, почему код ведёт себя определённым образом или написан в определённом стиле, зачастую можно только по истории изменений файла. Убедитесь, что у каждого коммита одна цель, с заголовком, объясняющим эту цель, и описанием, которое содержит обоснование изменения. Такой подход сохраняет историю изменений полезной и облегчает коллегам выполнение проверок. Просматривая коммит за коммитом, коллега может быстро понять, что все изменения в конкретном PR связаны с определённой задачей, что значительно экономит время. Просто убедитесь, что вы не сжимаете коммиты при слиянии.
10. Не бойтесь отклонять PR, если его слишком сложно просмотреть
Вас когда-нибудь просили просмотреть PR с более чем 100 файлами? Вы прокручиваете код, чувствуете себя подавленным и оставляете комментарий типа «вроде норм». Не бойтесь отклонять огромные PR. Качественный обзор кода становится невозможным при таком количестве изменений.
Попросите разработчика разделить изменения на отдельные, целенаправленные коммиты. Ещё лучше — разбить на несколько PR. Это особенно важно для масштабных изменений, таких как рефакторинг.
Помните, что меньше PR = лучше обзор = более качественный код.
См. также «Мастерство Пулл-Реквестов»
Источник: https://www.dennisdoomen.com/2025/03/10-quality-lessons.html
10 Уроков Качества Разработки ПО. Окончание
Начало
Продолжение
7. Относитесь к конвейеру сборки и развёртывания так же, как к коду
Особенно болезненный опыт обычно связан с ненадежностью конвейера развёртывания. Поскольку он основан на YAML и встроенных задачах, единственным способом устранения неполадок часто является внесение изменений, постановка конвейера в очередь и ожидание результатов. Просто нет способа проверить это по-другому.
Помимо этого, конвейер — это больше, чем просто ряд задач. Он развивается вместе с кодовой базой, может стать довольно сложным и, следовательно, должен быть простым для понимания и рефакторинга при необходимости. Слишком много компаний пытаются придерживаться конвейеров YAML, обходя ограничения, втискивая скрипты PowerShell или Bash вместе с файлами YAML — хотя есть гораздо лучшие альтернативы. Уже не говоря о необходимости перехода с одного движка сборки на другой, например, с Azure DevOps Pipeline на GitHub Actions. Можно использовать Nuke и C# Это обеспечивает доступ к возможностям навигации, рефакторинга и отладки и позволяет тестировать весь конвейер из локальной среды разработки.
8. После выпуска версии 1.0 будьте ответственны
Ваши пользователи или разработчики зависят от стабильности. Сначала выберите стратегию выпуска — будете ли вы принимать регулярные выпуски или будете выпускать новые версии только при необходимости? Чёткий план помогает согласовывать команды и устанавливать ожидания. Всегда применяйте семантическое управление версиями. Это простая система: увеличивайте основную версию при критических изменениях, второстепенную - для новых функций и версию патча для исправлений ошибок. Избегайте критических изменений, когда это возможно. Внесение серьёзных изменений может разочаровать пользователей, поэтому предоставьте чёткие исключения и альтернативы. Наконец, не забывайте о документации. Чётко документируйте свой код как для команды, так и для пользователей. Хорошо документированный код экономит время, предотвращает ошибки и способствует совместной работе.
9. Берегите историю версий
Представьте, что вы пытаетесь понять, почему кто-то увеличил таймаут для выполнения SQL-запроса до 60 секунд. Нет ничего более разочаровывающего, чем найти PR или описание коммита, в котором указано что-то вроде «Увеличен таймаут SQL». Такое описание сообщает, что было сделано, но не объясняет проблему, которую решал разработчик. Аналогично PR, содержащий один коммит, в котором смешан рефакторинг со значимыми изменениями, скорее всего, вызовет столько же разочарования.
В долго существующей кодовой базе понять, почему код ведёт себя определённым образом или написан в определённом стиле, зачастую можно только по истории изменений файла. Убедитесь, что у каждого коммита одна цель, с заголовком, объясняющим эту цель, и описанием, которое содержит обоснование изменения. Такой подход сохраняет историю изменений полезной и облегчает коллегам выполнение проверок. Просматривая коммит за коммитом, коллега может быстро понять, что все изменения в конкретном PR связаны с определённой задачей, что значительно экономит время. Просто убедитесь, что вы не сжимаете коммиты при слиянии.
10. Не бойтесь отклонять PR, если его слишком сложно просмотреть
Вас когда-нибудь просили просмотреть PR с более чем 100 файлами? Вы прокручиваете код, чувствуете себя подавленным и оставляете комментарий типа «вроде норм». Не бойтесь отклонять огромные PR. Качественный обзор кода становится невозможным при таком количестве изменений.
Попросите разработчика разделить изменения на отдельные, целенаправленные коммиты. Ещё лучше — разбить на несколько PR. Это особенно важно для масштабных изменений, таких как рефакторинг.
Помните, что меньше PR = лучше обзор = более качественный код.
См. также «Мастерство Пулл-Реквестов»
Источник: https://www.dennisdoomen.com/2025/03/10-quality-lessons.html
👍14
День 2293. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Совершенствование процессов
Цель совершенствования процесса разработки (Software Process Improvement, SPI) — снизить стоимость разработки и сопровождения ПО. Это средство достижения превосходных бизнес-результатов, что бы ни подразумевалось под ними: ускорение доставки продуктов, уменьшение количества переделок, лучшее удовлетворение потребностей клиентов, снижение затрат на поддержку и т.п. Что-то должно измениться в работе команды, чтобы данная цель стала достижимой. Это изменение и есть SPI. Каждый ретроспективный обзор, чтобы извлечь уроки и улучшить работу в следующий раз, закладывает основу для совершенствования процессов. Каждая новая техника, делающая проект более эффективным и действенным, совершенствует процесс.
Не бойтесь процессов
Для некоторых слово «процесс» имеет негативный оттенок. Иногда люди не осознают, что у них уже есть процесс разработки ПО, даже если он плохо определён или не задокументирован. Некоторые опасаются, что необходимость следовать процедурам будет ограничивать их, подавлять творческий потенциал или замедлит проект. Конечно, можно упорно применять неподходящие процессы, не добавляя ценности и не допуская изменений в проектах и людях. Но это не обязательно! Когда всё работает правильно, организации добиваются успеха благодаря процессам, а не вопреки им. Разумные и подходящие процессы помогают добиваться успеха постоянно. Процесс и творчество совместимы.
Несмотря на концептуальную простоту, SPI — сложная задача. Нелегко заставить людей признать наличие недостатков в их нынешних методах работы. Любая проектная работа сложна, и как же уговорить команды тратить время на выявление и устранение недостатков? Изменить культуру организации непросто, однако SPI предполагает изменение культуры наряду с изменениями в технических и управленческих методах.
Как возвести SPI в привычку
Многие программы SPI не дают эффективных и устойчивых результатов. Новые модные инициативы по изменениям вводятся с помпой, но потом тихо исчезают без объявления и анализа причин. Организация отказывается от приложенных усилий и позже пробует что-то другое. Обычно вы можете совершить только две неудачные попытки стратегического совершенствования, прежде чем люди решат, что организация несерьёзно относится к изменениям. После двух неудач мало кто всерьёз отнесётся к следующей инициативе по изменению.
Чтобы достичь успеха в совершенствовании процессов, нужно время. Организации должны достаточно долго прикладывать усилия, чтобы получить первые плоды. Если вы остановитесь на полпути после вложения средств в оценку и обучение, но до того, как изменения окупятся, то потеряете свои вложения. Крупномасштабные изменения процессов происходят небыстро, поэтому учитесь получать удовольствие от маленьких побед. Постарайтесь определить улучшения, которые можно быстро внедрить, чтобы решить известные проблемы, а также долгосрочные системные изменения.
Если в организации нет настоятельной необходимости соблюдать определённый стандарт, например в целях сертификации, то приемлема любая система разработки, будь то устоявшаяся модель, вроде Agile или какая-то своя. Но если рассматривать SPI просто как очередную причуду руководства, то большинство работников постараются просто пережить её, пытаясь выполнять свою настоящую работу, несмотря на отвлекающие факторы. Это не способствует успеху изменений.
Первые шаги
1. Каких бизнес-результатов вы ещё не достигли, для чего могло бы потребоваться SPI?
2. Увенчались ли успехом прошлые инициативы SPI? Какие действия окупились: устоявшаяся модель совершенствования или доморощенные подходы?
3. Определите любые недостатки или проблемы в работе организации, устранив которые можно улучшить процессы.
4. Как каждая проблема влияет на способность успешно выявлять, разрабатывать и внедрять SPI?
5. Попробуйте определить основные причины, провоцирующие или усугубляющие каждую проблему.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 6.
Уроки 50 Лет Разработки ПО
Совершенствование процессов
Цель совершенствования процесса разработки (Software Process Improvement, SPI) — снизить стоимость разработки и сопровождения ПО. Это средство достижения превосходных бизнес-результатов, что бы ни подразумевалось под ними: ускорение доставки продуктов, уменьшение количества переделок, лучшее удовлетворение потребностей клиентов, снижение затрат на поддержку и т.п. Что-то должно измениться в работе команды, чтобы данная цель стала достижимой. Это изменение и есть SPI. Каждый ретроспективный обзор, чтобы извлечь уроки и улучшить работу в следующий раз, закладывает основу для совершенствования процессов. Каждая новая техника, делающая проект более эффективным и действенным, совершенствует процесс.
Не бойтесь процессов
Для некоторых слово «процесс» имеет негативный оттенок. Иногда люди не осознают, что у них уже есть процесс разработки ПО, даже если он плохо определён или не задокументирован. Некоторые опасаются, что необходимость следовать процедурам будет ограничивать их, подавлять творческий потенциал или замедлит проект. Конечно, можно упорно применять неподходящие процессы, не добавляя ценности и не допуская изменений в проектах и людях. Но это не обязательно! Когда всё работает правильно, организации добиваются успеха благодаря процессам, а не вопреки им. Разумные и подходящие процессы помогают добиваться успеха постоянно. Процесс и творчество совместимы.
Несмотря на концептуальную простоту, SPI — сложная задача. Нелегко заставить людей признать наличие недостатков в их нынешних методах работы. Любая проектная работа сложна, и как же уговорить команды тратить время на выявление и устранение недостатков? Изменить культуру организации непросто, однако SPI предполагает изменение культуры наряду с изменениями в технических и управленческих методах.
Как возвести SPI в привычку
Многие программы SPI не дают эффективных и устойчивых результатов. Новые модные инициативы по изменениям вводятся с помпой, но потом тихо исчезают без объявления и анализа причин. Организация отказывается от приложенных усилий и позже пробует что-то другое. Обычно вы можете совершить только две неудачные попытки стратегического совершенствования, прежде чем люди решат, что организация несерьёзно относится к изменениям. После двух неудач мало кто всерьёз отнесётся к следующей инициативе по изменению.
Чтобы достичь успеха в совершенствовании процессов, нужно время. Организации должны достаточно долго прикладывать усилия, чтобы получить первые плоды. Если вы остановитесь на полпути после вложения средств в оценку и обучение, но до того, как изменения окупятся, то потеряете свои вложения. Крупномасштабные изменения процессов происходят небыстро, поэтому учитесь получать удовольствие от маленьких побед. Постарайтесь определить улучшения, которые можно быстро внедрить, чтобы решить известные проблемы, а также долгосрочные системные изменения.
Если в организации нет настоятельной необходимости соблюдать определённый стандарт, например в целях сертификации, то приемлема любая система разработки, будь то устоявшаяся модель, вроде Agile или какая-то своя. Но если рассматривать SPI просто как очередную причуду руководства, то большинство работников постараются просто пережить её, пытаясь выполнять свою настоящую работу, несмотря на отвлекающие факторы. Это не способствует успеху изменений.
Первые шаги
1. Каких бизнес-результатов вы ещё не достигли, для чего могло бы потребоваться SPI?
2. Увенчались ли успехом прошлые инициативы SPI? Какие действия окупились: устоявшаяся модель совершенствования или доморощенные подходы?
3. Определите любые недостатки или проблемы в работе организации, устранив которые можно улучшить процессы.
4. Как каждая проблема влияет на способность успешно выявлять, разрабатывать и внедрять SPI?
5. Попробуйте определить основные причины, провоцирующие или усугубляющие каждую проблему.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 6.
👍4👎3
День 2300. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 51. Остерегайтесь «менеджмента по Businessweek». Начало
Разочарование неутешительными результатами — мощная мотивация попробовать другой подход. Однако при этом важно иметь уверенность, что любая новая стратегия, которую вы примете, имеет хорошие шансы на успех в решении вашей проблемы. Организации иногда выбирают модные решения и горячие новинки в области разработки ПО, считая их волшебным эликсиром, способным решить их задачи.
Руководитель может прочитать о многообещающей, но, возможно, чересчур разрекламированной методологии и настаивать на немедленном принятии её в организации. Этот феномен называют «менеджмент по Businessweek». Либо разработчик, посетив конференцию, узнаёт о новом способе решения своих задач и торопится попробовать его. Стремление к совершенствованию похвально, но вы должны направить эту энергию в правильное русло и оценить, насколько хорошо потенциальное решение соответствует вашей культуре, прежде чем принять его.
За прошедшие годы люди изобрели бесчисленное множество парадигм, методологий и систем управления разработкой ПО:
- анализ и проектирование структурированных систем;
- объектно-ориентированное программирование;
- информационная инженерия;
- быстрая разработка приложений;
- спиральная модель;
- разработка через тестирование;
- рациональный унифицированный процесс;
- DevOps.
Методология Agile-разработки во многих её вариациях (экстремальное программирование, адаптивная разработка, разработка на основе функциональности, Scrum, Lean, Kanban, Scaled Agile Framework и др.) ещё один пример стремления к идеальным решениям.
Увы, как учит дядюшка Брукс, «серебряной пули не существует». Все вышеперечисленные подходы имеют свои достоинства и недостатки и должны применяться к соответствующим задачам правильно подготовленными командами и руководителями. В качестве примера далее рассмотрим некий новый подход к разработке ПО под названием «Метод Х».
Сначала проблема, потом решение
В статьях и книгах, написанных изобретателями и первыми последователями «Метода Х», восхвалялись его преимущества. Некоторые компании выбрали «Метод Х», желая создавать продукты, которые лучше удовлетворяют потребности клиентов. Хотите быстрее доставлять полезное ПО? (А кто не хочет?) «Метод Х» поможет в этом. Хотите уменьшить количество дефектов, раздражающих клиентов и отнимающих у команды время на доработку? (Опять же, кто не хочет?) «Метод Х» придёт на помощь! В этом суть совершенствования процессов: постановка целей, выявление препятствий и выбор методов, которые, по вашему мнению, могут помочь их устранить.
Однако прежде, чем выбрать какой-либо новый подход к разработке, спросите себя: «Что мешает нам добиться таких же результатов, которые он обещает, уже сегодня?» Если вы хотите быстрее доставлять продукты, что вам мешает? Если цель — уменьшить количество дефектов, то почему сегодня их много? И т.п. Т.е., если «Метод Х» является решением проблем, в чём их причина?
Не все организации тщательно анализируют первопричины, прежде чем хвататься за решения, выглядящие многообещающими. Постановка целей совершенствования — отличное начало, но, помимо этого, важно понимать, какие препятствия стоят на пути к этим целям. Лечить нужно причины, а не симптомы. Если вы не понимаете причины проблем, то выбор любого нового подхода — выстрел в пустоту.
Предположим, вы хотите поставлять программные продукты, хорошо удовлетворяющие потребности клиентов. Вы прочитали, что в командах, применяющих «Метод Х», есть роль под названием «гуру», который отвечает за то, чтобы продукт достиг желаемого результата. «Отлично! — думаете вы. — Гуру позаботится о том, чтобы мы создали правильный продукт. Клиенты будут счастливы». Проблема решена? Может быть, но, прежде чем изменять процессы, ваша команда должна понять, почему ваши продукты не вызывают восторга у клиентов уже сейчас.
Окончание следует…
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
Уроки 50 Лет Разработки ПО
Урок 51. Остерегайтесь «менеджмента по Businessweek». Начало
Разочарование неутешительными результатами — мощная мотивация попробовать другой подход. Однако при этом важно иметь уверенность, что любая новая стратегия, которую вы примете, имеет хорошие шансы на успех в решении вашей проблемы. Организации иногда выбирают модные решения и горячие новинки в области разработки ПО, считая их волшебным эликсиром, способным решить их задачи.
Руководитель может прочитать о многообещающей, но, возможно, чересчур разрекламированной методологии и настаивать на немедленном принятии её в организации. Этот феномен называют «менеджмент по Businessweek». Либо разработчик, посетив конференцию, узнаёт о новом способе решения своих задач и торопится попробовать его. Стремление к совершенствованию похвально, но вы должны направить эту энергию в правильное русло и оценить, насколько хорошо потенциальное решение соответствует вашей культуре, прежде чем принять его.
За прошедшие годы люди изобрели бесчисленное множество парадигм, методологий и систем управления разработкой ПО:
- анализ и проектирование структурированных систем;
- объектно-ориентированное программирование;
- информационная инженерия;
- быстрая разработка приложений;
- спиральная модель;
- разработка через тестирование;
- рациональный унифицированный процесс;
- DevOps.
Методология Agile-разработки во многих её вариациях (экстремальное программирование, адаптивная разработка, разработка на основе функциональности, Scrum, Lean, Kanban, Scaled Agile Framework и др.) ещё один пример стремления к идеальным решениям.
Увы, как учит дядюшка Брукс, «серебряной пули не существует». Все вышеперечисленные подходы имеют свои достоинства и недостатки и должны применяться к соответствующим задачам правильно подготовленными командами и руководителями. В качестве примера далее рассмотрим некий новый подход к разработке ПО под названием «Метод Х».
Сначала проблема, потом решение
В статьях и книгах, написанных изобретателями и первыми последователями «Метода Х», восхвалялись его преимущества. Некоторые компании выбрали «Метод Х», желая создавать продукты, которые лучше удовлетворяют потребности клиентов. Хотите быстрее доставлять полезное ПО? (А кто не хочет?) «Метод Х» поможет в этом. Хотите уменьшить количество дефектов, раздражающих клиентов и отнимающих у команды время на доработку? (Опять же, кто не хочет?) «Метод Х» придёт на помощь! В этом суть совершенствования процессов: постановка целей, выявление препятствий и выбор методов, которые, по вашему мнению, могут помочь их устранить.
Однако прежде, чем выбрать какой-либо новый подход к разработке, спросите себя: «Что мешает нам добиться таких же результатов, которые он обещает, уже сегодня?» Если вы хотите быстрее доставлять продукты, что вам мешает? Если цель — уменьшить количество дефектов, то почему сегодня их много? И т.п. Т.е., если «Метод Х» является решением проблем, в чём их причина?
Не все организации тщательно анализируют первопричины, прежде чем хвататься за решения, выглядящие многообещающими. Постановка целей совершенствования — отличное начало, но, помимо этого, важно понимать, какие препятствия стоят на пути к этим целям. Лечить нужно причины, а не симптомы. Если вы не понимаете причины проблем, то выбор любого нового подхода — выстрел в пустоту.
Предположим, вы хотите поставлять программные продукты, хорошо удовлетворяющие потребности клиентов. Вы прочитали, что в командах, применяющих «Метод Х», есть роль под названием «гуру», который отвечает за то, чтобы продукт достиг желаемого результата. «Отлично! — думаете вы. — Гуру позаботится о том, чтобы мы создали правильный продукт. Клиенты будут счастливы». Проблема решена? Может быть, но, прежде чем изменять процессы, ваша команда должна понять, почему ваши продукты не вызывают восторга у клиентов уже сейчас.
Окончание следует…
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
👍9
День 2301. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 51. Остерегайтесь «менеджмента по Businessweek». Окончание
Начало
Анализ первопричин — это процесс размышлений, когда несколько раз задаётся вопрос «почему?», пока вы не доберётесь до проблем, на которые можно воздействовать с помощью тщательно подобранных действий по улучшению. Первая найденная причина может не оказывать прямого влияния и не быть первопричиной. Следовательно, её устранение не решит проблему. Вам нужно спросить «почему?» еще раз или два, чтобы убедиться, что вы добрались до основания дерева анализа.
На рисунке выше показан фрагмент диаграммы «Рыбий скелет» (диаграмма Исикавы) — удобного способа анализа первопричин. Ваша цель — выпускать продукты, лучше удовлетворяющие потребности клиентов. Напишите эту цель вдоль длинной горизонтальной линии. Это представляет вашу основную проблему. Затем спросите команду: «Почему мы не удовлетворяем потребности наших клиентов?» Один из возможных ответов: команда не получает адекватной информации о требованиях от конечных пользователей — обычная ситуация. Запишите эту причину вдоль диагональной линии, отходящей от формулировки цели. Хорошо, но решение проблемы требует более глубокого понимания. Поэтому далее вы спрашиваете: «Почему мы не получаем такой информации?» Один из членов группы говорит: «Мы пытались поговорить с реальными пользователями, но их руководители говорят, что они слишком заняты, чтобы работать с командой разработчиков». Кто-то ещё жалуется, что представители клиента, работающие с командой, не имеют полного представления о реальных потребностях конечных пользователей. Напишите эти причины второго уровня вдоль горизонтальных линий, отходящих от диагональной линии родительской проблемы.
Кто-то отмечает, что разработчики задают представителям клиента неправильные вопросы: «Почему задаются неправильные вопросы?» Причин может быть несколько, в том числе отсутствие образования или интереса у разработчиков к работе с требованиями. Возможно, бизнес-анализ не является основным навыком команды или в команде нет подготовленного бизнес-аналитика. Каждая причина записывается вдоль новой диагональной линии, соединяющейся с родительской.
Так вы приближаетесь к фактическим препятствиям, стоящим на пути к желаемой цели. Продолжайте анализ до тех пор, пока участники не придут к полному пониманию, почему не достигаются желаемые результаты. Такая диаграмма может стать неразборчивой, поэтому попробуйте записать причины на стикерах, чтобы их можно было перетасовывать по мере исследования.
Постановка диагноза ведёт к излечению
Дальше стоит перейти к поиску практических решений для устранения этих первопричин. Возможно, вы решите, что добавление бизнес-аналитика в команду более ценно, чем принятие «Метода Х» с его «гуру». Или вам нужна комбинация этих двух методов. Вы не узнаете этого, пока не продумаете всё до конца.
Вот несколько хороших вопросов, которые следует задать себе:
- Потребуется ли команде обучение, инструменты или консультации, чтобы начать работу и двигаться вперед?
- Принесёт ли решение выгоду по сравнению с вложениями?
- Какое культурное влияние окажет переход к новым методам на вашу команду, клиентов и их организации?
- Насколько крутой может быть кривая обучения?
Результаты анализа первопричин могут помочь выявить более эффективные методы решения каждой обнаруженной проблемы. Это разумное вложение средств в концентрацию усилий по совершенствованию процессов. Прежде, чем назначать лечение, нужно поставить диагноз.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
Уроки 50 Лет Разработки ПО
Урок 51. Остерегайтесь «менеджмента по Businessweek». Окончание
Начало
Анализ первопричин — это процесс размышлений, когда несколько раз задаётся вопрос «почему?», пока вы не доберётесь до проблем, на которые можно воздействовать с помощью тщательно подобранных действий по улучшению. Первая найденная причина может не оказывать прямого влияния и не быть первопричиной. Следовательно, её устранение не решит проблему. Вам нужно спросить «почему?» еще раз или два, чтобы убедиться, что вы добрались до основания дерева анализа.
На рисунке выше показан фрагмент диаграммы «Рыбий скелет» (диаграмма Исикавы) — удобного способа анализа первопричин. Ваша цель — выпускать продукты, лучше удовлетворяющие потребности клиентов. Напишите эту цель вдоль длинной горизонтальной линии. Это представляет вашу основную проблему. Затем спросите команду: «Почему мы не удовлетворяем потребности наших клиентов?» Один из возможных ответов: команда не получает адекватной информации о требованиях от конечных пользователей — обычная ситуация. Запишите эту причину вдоль диагональной линии, отходящей от формулировки цели. Хорошо, но решение проблемы требует более глубокого понимания. Поэтому далее вы спрашиваете: «Почему мы не получаем такой информации?» Один из членов группы говорит: «Мы пытались поговорить с реальными пользователями, но их руководители говорят, что они слишком заняты, чтобы работать с командой разработчиков». Кто-то ещё жалуется, что представители клиента, работающие с командой, не имеют полного представления о реальных потребностях конечных пользователей. Напишите эти причины второго уровня вдоль горизонтальных линий, отходящих от диагональной линии родительской проблемы.
Кто-то отмечает, что разработчики задают представителям клиента неправильные вопросы: «Почему задаются неправильные вопросы?» Причин может быть несколько, в том числе отсутствие образования или интереса у разработчиков к работе с требованиями. Возможно, бизнес-анализ не является основным навыком команды или в команде нет подготовленного бизнес-аналитика. Каждая причина записывается вдоль новой диагональной линии, соединяющейся с родительской.
Так вы приближаетесь к фактическим препятствиям, стоящим на пути к желаемой цели. Продолжайте анализ до тех пор, пока участники не придут к полному пониманию, почему не достигаются желаемые результаты. Такая диаграмма может стать неразборчивой, поэтому попробуйте записать причины на стикерах, чтобы их можно было перетасовывать по мере исследования.
Постановка диагноза ведёт к излечению
Дальше стоит перейти к поиску практических решений для устранения этих первопричин. Возможно, вы решите, что добавление бизнес-аналитика в команду более ценно, чем принятие «Метода Х» с его «гуру». Или вам нужна комбинация этих двух методов. Вы не узнаете этого, пока не продумаете всё до конца.
Вот несколько хороших вопросов, которые следует задать себе:
- Потребуется ли команде обучение, инструменты или консультации, чтобы начать работу и двигаться вперед?
- Принесёт ли решение выгоду по сравнению с вложениями?
- Какое культурное влияние окажет переход к новым методам на вашу команду, клиентов и их организации?
- Насколько крутой может быть кривая обучения?
Результаты анализа первопричин могут помочь выявить более эффективные методы решения каждой обнаруженной проблемы. Это разумное вложение средств в концентрацию усилий по совершенствованию процессов. Прежде, чем назначать лечение, нужно поставить диагноз.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
👍10
День 2307. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 52. Не спрашивайте: «Что это даст мне?» Спрашивайте: «Что это даст нам?»
Когда людям предлагают использовать новый подход к разработке, следовать другой процедуре или взяться за неожиданное задание, они инстинктивно задаются вопросом: «Что это даст мне?» Это естественная реакция, но не совсем правильный вопрос. Правильный вопрос: «Что это даст нам?»
«Нам» тут может относиться к остальным членам команды, IT-отделу, компании или даже индустрии, только не к отдельному человеку. Инициативы по внедрению изменений должны учитывать коллективные результаты работы, а не только влияние на продуктивность, эффективность или уровень комфорта каждого человека.
Может показаться, что просьба к занятому коллеге, например проверить вашу работу, не принесёт ему выгоды. Однако все вместе такие усилия позволят команде сэкономить больше времени, и тем самым внести чистый положительный вклад в проект. Ревью кода может занять два-три часа времени каждого участника. Эти часы рецензенты не смогут потратить на выполнение своих обязанностей. Но проверка выявит дефекты, а чем раньше они обнаруживаются, тем дешевле их исправление.
Выгода для команды
Предположим, Ари (бизнес-аналитик) написала несколько страниц требований и попросила троих коллег просмотреть их. Каждый из четверых потратил по часу на изучение материала перед встречей команды, которая тоже длилась час:
затраты на подготовку = 1 час/рецензент × 4 рецензента = 4 часа;
затраты на встречу = 1 час/рецензент × 4 рецензента = 4 часа;
общие затраты на рецензирование = 4 часа + 4 часа = 8 часов
Предположим, в процессе рецензирования обнаружены 24 дефекта разной степени серьёзности и на исправление каждого у Ари ушло в среднем 5 минут:
фактические затраты на доработку = 24 дефекта × 0,0833 часа/дефект = 2 часа
Теперь представьте, что Ари не запросила рецензирование. Дефекты останутся в наборе требований и будут обнаружены позже, при разработке. Ари всё так же придётся исправить их, а другим членам команды — переделывать проектное решение, код, тесты и документацию после исправления дефектов. На все эти работы легко может понадобиться в десять раз больше времени. Стоимость переделки может возрасти ещё, если дефекты попадут в конечный продукт:
потенциальные затраты на доработку = 24 дефекта × 0,833 часа/дефект = 20 часов
То есть это гипотетическое рецензирование требований предотвратило потенциальные затраты 18 часов на доработку на последних этапах реализации проекта. Поэтому минимальная окупаемость затрат на рецензирование составляет 225% (18 часов сэкономленного времени ÷ 8 часов на рецензирование). Многие крупные компании оценивают рентабельность вложений в раннее рецензирование как десятикратную. У вас могут получиться другие цифры, но лишь немногие методы разработки ПО могут десятикратно окупить вложения.
Вносите свой вклад в общее дело
В следующий раз, когда коллега или руководитель попросит вас сделать в проекте что-то, что не принесёт вам личной выгоды, думайте не только о своих интересах. Сотрудники несут ответственность за соблюдение установленных правил и приёмов разработки. Справедливо спросить: «Что нам это даст, если я это сделаю?» На просителе лежит бремя объяснения того, какую пользу всей команде принесет ваш вклад. А вы старайтесь внести свой вклад в общий успех команды.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
Уроки 50 Лет Разработки ПО
Урок 52. Не спрашивайте: «Что это даст мне?» Спрашивайте: «Что это даст нам?»
Когда людям предлагают использовать новый подход к разработке, следовать другой процедуре или взяться за неожиданное задание, они инстинктивно задаются вопросом: «Что это даст мне?» Это естественная реакция, но не совсем правильный вопрос. Правильный вопрос: «Что это даст нам?»
«Нам» тут может относиться к остальным членам команды, IT-отделу, компании или даже индустрии, только не к отдельному человеку. Инициативы по внедрению изменений должны учитывать коллективные результаты работы, а не только влияние на продуктивность, эффективность или уровень комфорта каждого человека.
Может показаться, что просьба к занятому коллеге, например проверить вашу работу, не принесёт ему выгоды. Однако все вместе такие усилия позволят команде сэкономить больше времени, и тем самым внести чистый положительный вклад в проект. Ревью кода может занять два-три часа времени каждого участника. Эти часы рецензенты не смогут потратить на выполнение своих обязанностей. Но проверка выявит дефекты, а чем раньше они обнаруживаются, тем дешевле их исправление.
Выгода для команды
Предположим, Ари (бизнес-аналитик) написала несколько страниц требований и попросила троих коллег просмотреть их. Каждый из четверых потратил по часу на изучение материала перед встречей команды, которая тоже длилась час:
затраты на подготовку = 1 час/рецензент × 4 рецензента = 4 часа;
затраты на встречу = 1 час/рецензент × 4 рецензента = 4 часа;
общие затраты на рецензирование = 4 часа + 4 часа = 8 часов
Предположим, в процессе рецензирования обнаружены 24 дефекта разной степени серьёзности и на исправление каждого у Ари ушло в среднем 5 минут:
фактические затраты на доработку = 24 дефекта × 0,0833 часа/дефект = 2 часа
Теперь представьте, что Ари не запросила рецензирование. Дефекты останутся в наборе требований и будут обнаружены позже, при разработке. Ари всё так же придётся исправить их, а другим членам команды — переделывать проектное решение, код, тесты и документацию после исправления дефектов. На все эти работы легко может понадобиться в десять раз больше времени. Стоимость переделки может возрасти ещё, если дефекты попадут в конечный продукт:
потенциальные затраты на доработку = 24 дефекта × 0,833 часа/дефект = 20 часов
То есть это гипотетическое рецензирование требований предотвратило потенциальные затраты 18 часов на доработку на последних этапах реализации проекта. Поэтому минимальная окупаемость затрат на рецензирование составляет 225% (18 часов сэкономленного времени ÷ 8 часов на рецензирование). Многие крупные компании оценивают рентабельность вложений в раннее рецензирование как десятикратную. У вас могут получиться другие цифры, но лишь немногие методы разработки ПО могут десятикратно окупить вложения.
Вносите свой вклад в общее дело
В следующий раз, когда коллега или руководитель попросит вас сделать в проекте что-то, что не принесёт вам личной выгоды, думайте не только о своих интересах. Сотрудники несут ответственность за соблюдение установленных правил и приёмов разработки. Справедливо спросить: «Что нам это даст, если я это сделаю?» На просителе лежит бремя объяснения того, какую пользу всей команде принесет ваш вклад. А вы старайтесь внести свой вклад в общий успех команды.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
👍5
День 2314. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 53. Боль — лучшая мотивация для изменения методов работы
Для команд и организаций, как и для отдельных людей, боль является мощным мотиватором, подталкивающим к изменениям. Мы говорим не о боли, искусственно вызванной извне, когда руководители или клиенты требуют невозможного, а о боли, которую команда испытывает от используемых методов работы.
Мероприятия по совершенствованию процессов не особенно приятны. Они отвлекают от «настоящей работы», которая более интересна членам команды и приносит пользу бизнесу. Усилия по изменению могут казаться сизифовым трудом, поскольку много факторов препятствуют проведению устойчивых организационных изменений. Чтобы мотивировать людей участвовать в изменении, обещанное уменьшение боли должно перевешивать дискомфорт, вызываемый самой процедурой совершенствования. И в какой-то момент участники должны почувствовать, что боль уменьшилась, иначе откажутся участвовать в подобной работе в следующий раз.
Боль причиняет неудобства!
Как бы вы определили «боль» в вашей организации? Какие хронические проблемы возникают в ваших проектах? Определив их, вы сможете сконцентрировать усилия по совершенствованию там, где они принесут наибольшую пользу. Вот несколько типичных примеров «болей» в проектах:
- несоблюдение запланированных сроков поставки;
- выпуск продуктов с чрезмерным количеством дефектов или функциональными недостатками;
- неспособность поспевать за запросами на изменение;
- создание систем, которые трудно расширять без значительных доработок;
- поставка продуктов, не отвечающих в должной мере потребностям клиентов;
- частые сбои системы, вынуждающие дежурного специалиста по поддержке работать по ночам;
- взаимодействие с руководителями, недостаточно хорошо разбирающимися в текущих технологических проблемах и подходах к разработке ПО;
- сложности из-за рисков, которые не были выявлены или уменьшены.
Цель любой деятельности по оценке процесса (группового обсуждения, ретроспективного обзора проекта или оценки сторонним консультантом) — выявить эти проблемные области. После этого появляется возможность определить основные причины проблем и предпринять шаги по их устранению.
Незаметная боль
Проблемы, затрагивающие одних участников проекта, могут быть незаметны другим. Вы можете работать с командой над созданием какой-то функциональности, фонтанировать идеями о постоянном её улучшении. Но с точки зрения команды это будет кошмаром, потому что вы никак не можете определиться с требованиями или выбрать один метод работы. Это подчёркивает необходимость чёткого информирования всех заинтересованных сторон об ожиданиях и проблемах.
Кроме того, трудно продать мышеловку тому, кто не знает, что у него есть мыши. Если вы не замечаете негативных последствий использования текущего подхода, то, скорее всего, не будете восприимчивы к предложениям об изменениях. Любое предлагаемое изменение должно выглядеть как решение проблемы. Поэтому важным аспектом совершенствования процессов выступает выявление причин и затрат, обусловленных проблемами, которые порождает процесс, и последующее информирование тех, кого это касается. Такая осведомлённость может побудить всех участников начать поступать иным образом.
Иногда вы можете стимулировать это осознание. Часто даже групповое обсуждение проблем, с которыми сталкиваются разные члены команды: бизнес-аналитики, руководители проекта, разработчики, заказчики, тестировщики, маркетологи и т.д., - помогает людям понять трудности других и служит хорошей отправной точкой для совершенствования подходов к работе, приносящего пользу всем.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
Уроки 50 Лет Разработки ПО
Урок 53. Боль — лучшая мотивация для изменения методов работы
Для команд и организаций, как и для отдельных людей, боль является мощным мотиватором, подталкивающим к изменениям. Мы говорим не о боли, искусственно вызванной извне, когда руководители или клиенты требуют невозможного, а о боли, которую команда испытывает от используемых методов работы.
Мероприятия по совершенствованию процессов не особенно приятны. Они отвлекают от «настоящей работы», которая более интересна членам команды и приносит пользу бизнесу. Усилия по изменению могут казаться сизифовым трудом, поскольку много факторов препятствуют проведению устойчивых организационных изменений. Чтобы мотивировать людей участвовать в изменении, обещанное уменьшение боли должно перевешивать дискомфорт, вызываемый самой процедурой совершенствования. И в какой-то момент участники должны почувствовать, что боль уменьшилась, иначе откажутся участвовать в подобной работе в следующий раз.
Боль причиняет неудобства!
Как бы вы определили «боль» в вашей организации? Какие хронические проблемы возникают в ваших проектах? Определив их, вы сможете сконцентрировать усилия по совершенствованию там, где они принесут наибольшую пользу. Вот несколько типичных примеров «болей» в проектах:
- несоблюдение запланированных сроков поставки;
- выпуск продуктов с чрезмерным количеством дефектов или функциональными недостатками;
- неспособность поспевать за запросами на изменение;
- создание систем, которые трудно расширять без значительных доработок;
- поставка продуктов, не отвечающих в должной мере потребностям клиентов;
- частые сбои системы, вынуждающие дежурного специалиста по поддержке работать по ночам;
- взаимодействие с руководителями, недостаточно хорошо разбирающимися в текущих технологических проблемах и подходах к разработке ПО;
- сложности из-за рисков, которые не были выявлены или уменьшены.
Цель любой деятельности по оценке процесса (группового обсуждения, ретроспективного обзора проекта или оценки сторонним консультантом) — выявить эти проблемные области. После этого появляется возможность определить основные причины проблем и предпринять шаги по их устранению.
Незаметная боль
Проблемы, затрагивающие одних участников проекта, могут быть незаметны другим. Вы можете работать с командой над созданием какой-то функциональности, фонтанировать идеями о постоянном её улучшении. Но с точки зрения команды это будет кошмаром, потому что вы никак не можете определиться с требованиями или выбрать один метод работы. Это подчёркивает необходимость чёткого информирования всех заинтересованных сторон об ожиданиях и проблемах.
Кроме того, трудно продать мышеловку тому, кто не знает, что у него есть мыши. Если вы не замечаете негативных последствий использования текущего подхода, то, скорее всего, не будете восприимчивы к предложениям об изменениях. Любое предлагаемое изменение должно выглядеть как решение проблемы. Поэтому важным аспектом совершенствования процессов выступает выявление причин и затрат, обусловленных проблемами, которые порождает процесс, и последующее информирование тех, кого это касается. Такая осведомлённость может побудить всех участников начать поступать иным образом.
Иногда вы можете стимулировать это осознание. Часто даже групповое обсуждение проблем, с которыми сталкиваются разные члены команды: бизнес-аналитики, руководители проекта, разработчики, заказчики, тестировщики, маркетологи и т.д., - помогает людям понять трудности других и служит хорошей отправной точкой для совершенствования подходов к работе, приносящего пользу всем.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
👍4
День 2321. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 54. Внедряя новые методы работы, делайте это мягко, но непрерывно
Никто не может по-настоящему изменить что-то, что, по мнению других, работает и даёт положительный результат. В конечном счёте каждый сам решает, готов ли он в будущем действовать иначе.
Руководство
Для того чтобы новые способы работы в организации, занимающейся разработкой ПО, внедрялись эффективно, руководители должны оказывать постоянное мягкое давление в нужном направлении. Чтобы задать желаемое направление, нужно чётко определить цели инициативы и довести их до сведения всех участников. Кроме того, они должны нести пользу бизнесу. Радикальные изменения всем даются с трудом. Постепенные изменения менее разрушительны, и к ним легче адаптироваться. Людям нужно время, чтобы усвоить новые практики и новый образ мышления.
Все участники должны понимать, какой вклад они могут внести в успех проекта. Ищите первых последователей, более восприимчивых к нововведениям, которые могут выступать в качестве пропагандистов изменений среди коллег.
Вот несколько советов, как мягко оказывать давление для достижения цели:
- Определите цели, мотивацию и основные желаемые результаты. Расплывчатые цели, такие как «до¬стичь мирового уровня» или «стать лидерами по продуктивности», бесполезны.
- Выберите метрики (ключевые показатели эффективности), которые будут показывать прогресс в достижении целей и влияние этих из¬менений на ускорение разработки, но имейте в виду, что последние показатели являются запаздывающими. Деятельность по изменению инициируется, поскольку мы уверены, что новые подходы помогут добиться лучших результатов. Однако для того, чтобы эти новые подходы повлияли на проекты, нужно время.
- Ставьте реалистичные и осмысленные цели и ожидания.
- Относитесь к изменениям как к проекту с конкретными действиями, результатами и обязанностями. Не забывайте о ресурсах. Предусмотрите дополнительное время, чтобы люди могли привыкать к новым подходам параллельно с выполнением своих обязанностей по разработке проекта.
- Регулярно информируйте о продвижении инициативы изменений.
- Призывайте людей ответственно относиться к их обязательствам по выполнению определённых мероприятий в рамках изменений.
- Стремитесь добиваться небольших успехов как можно раньше, чтобы показать, что инициатива приносит результаты.
- Обеспечьте обучение новым методам работы. Обучение — это инвестиции в будущие результаты.
Управление вышестоящими руководителями
Ценный навык для любого, кто осуществляет внедрение изменений. Если этим занимаетесь вы, научите своих руководителей говорить публично, какие модели поведения и результаты следует искать, а также какие результаты должны вознаграждаться или корректироваться. Это требует понимания корпоративной политики и умения находить подход к разным людям, представляя ценность изменений каждому руководителю так, чтобы найти у них отклик и получить поддержку.
Независимо от того, стремитесь вы к организации более зрелой модели процессов, такой как CMMI, или внедряете Agile-разработку во всей организации, руководителям важно понимать, как должны измениться их собственные действия и ожидания. Руководители, подающие пример, сами практикуют новые способы работы, публично поощряют их и посылают положительный сигнал всем остальным, что способствует изменению культуры.
Есть такое выражение: «Если вы когда-нибудь окажетесь в толпе людей, пытающихся войти туда же, куда надо и вам, просто перебирайте ногами — и толпа сама внесёт вас». То же самое верно и в отношении совершенствования процессов разработки ПО. Продолжайте двигаться в нужном направлении — и будете постепенно осваивать новые и лучшие способы работы.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
Уроки 50 Лет Разработки ПО
Урок 54. Внедряя новые методы работы, делайте это мягко, но непрерывно
Никто не может по-настоящему изменить что-то, что, по мнению других, работает и даёт положительный результат. В конечном счёте каждый сам решает, готов ли он в будущем действовать иначе.
Руководство
Для того чтобы новые способы работы в организации, занимающейся разработкой ПО, внедрялись эффективно, руководители должны оказывать постоянное мягкое давление в нужном направлении. Чтобы задать желаемое направление, нужно чётко определить цели инициативы и довести их до сведения всех участников. Кроме того, они должны нести пользу бизнесу. Радикальные изменения всем даются с трудом. Постепенные изменения менее разрушительны, и к ним легче адаптироваться. Людям нужно время, чтобы усвоить новые практики и новый образ мышления.
Все участники должны понимать, какой вклад они могут внести в успех проекта. Ищите первых последователей, более восприимчивых к нововведениям, которые могут выступать в качестве пропагандистов изменений среди коллег.
Вот несколько советов, как мягко оказывать давление для достижения цели:
- Определите цели, мотивацию и основные желаемые результаты. Расплывчатые цели, такие как «до¬стичь мирового уровня» или «стать лидерами по продуктивности», бесполезны.
- Выберите метрики (ключевые показатели эффективности), которые будут показывать прогресс в достижении целей и влияние этих из¬менений на ускорение разработки, но имейте в виду, что последние показатели являются запаздывающими. Деятельность по изменению инициируется, поскольку мы уверены, что новые подходы помогут добиться лучших результатов. Однако для того, чтобы эти новые подходы повлияли на проекты, нужно время.
- Ставьте реалистичные и осмысленные цели и ожидания.
- Относитесь к изменениям как к проекту с конкретными действиями, результатами и обязанностями. Не забывайте о ресурсах. Предусмотрите дополнительное время, чтобы люди могли привыкать к новым подходам параллельно с выполнением своих обязанностей по разработке проекта.
- Регулярно информируйте о продвижении инициативы изменений.
- Призывайте людей ответственно относиться к их обязательствам по выполнению определённых мероприятий в рамках изменений.
- Стремитесь добиваться небольших успехов как можно раньше, чтобы показать, что инициатива приносит результаты.
- Обеспечьте обучение новым методам работы. Обучение — это инвестиции в будущие результаты.
Управление вышестоящими руководителями
Ценный навык для любого, кто осуществляет внедрение изменений. Если этим занимаетесь вы, научите своих руководителей говорить публично, какие модели поведения и результаты следует искать, а также какие результаты должны вознаграждаться или корректироваться. Это требует понимания корпоративной политики и умения находить подход к разным людям, представляя ценность изменений каждому руководителю так, чтобы найти у них отклик и получить поддержку.
Независимо от того, стремитесь вы к организации более зрелой модели процессов, такой как CMMI, или внедряете Agile-разработку во всей организации, руководителям важно понимать, как должны измениться их собственные действия и ожидания. Руководители, подающие пример, сами практикуют новые способы работы, публично поощряют их и посылают положительный сигнал всем остальным, что способствует изменению культуры.
Есть такое выражение: «Если вы когда-нибудь окажетесь в толпе людей, пытающихся войти туда же, куда надо и вам, просто перебирайте ногами — и толпа сама внесёт вас». То же самое верно и в отношении совершенствования процессов разработки ПО. Продолжайте двигаться в нужном направлении — и будете постепенно осваивать новые и лучшие способы работы.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
👍3
День 2328. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 55. У вас нет времени, чтобы совершить все ошибки, сделанные до вас
Получать знания от других людей гораздо эффективнее, чем обретать их самостоятельно. Все профессионалы должны тратить часть своего времени на обретение знаний и расширение навыков в постоянно развивающейся области: чтение книг, статей, посещение конференций или прослушивание подкастов, - и думать, как можно применять эти навыки в работе.
Кривая обучения
Кривая обучения описывает, как человек обретает навыки выполнения новой задачи или применения нового приёма в зависимости от своего опыта. В жизни мы постоянно сталкиваемся с бесчисленными кривыми обучения. Всякий раз, пытаясь сделать что-то новое, мы встаём на новую кривую. Не нужно ожидать, что весь потенциал метода раскроется с первой попытки. Когда проектные группы пробуют использовать незнакомые методы, в их планах должно быть предусмотрено время, необходимое на то, чтобы освоиться. Если им не удастся освоить новую практику, то затраченное время будет потеряно навсегда.
Вы, несомненно, заинтересованы в повышении общей продуктивности, которой позволяет добиться ваш набор приёмов. На картинке выше показано, что в самом начале вы имеете определенный уровень продуктивности, который хотите повысить с помощью усовершенствованного процесса, практики, метода или инструмента. Первый шаг — обучение и обретение некоего опыта. Ваша продуктивность немедленно падает, поскольку в периоды обучения вы не выполняете полезную работу. Продуктивность продолжает снижаться, пока вы тратите время на создание новых процессов, пытаетесь понять, как заставить работать новую технику, приобретаете новый инструмент и учитесь использовать его и т. д. По мере осваивания нового способа работы вы начинаете замечать первые успехи, а также некоторые неудачи — пилообразная часть кривой роста продуктивности. Если все пойдет хорошо, то в итоге ваши вложения окупятся и вы почувствуете, что эффективность, результативность и качество возросли. Помните о реальности кривой обучения, внедряя новые практики, и не поддавайтесь искушению сдаться до того, как вложения в обучение начнут окупаться.
Хорошие практики
Забавно, когда кто-то жалуется на другого: «Он всегда думает, что его способ лучше». Конечно, он так думает! Зачем кому-то намеренно делать что-то, выбирая плохие способы? Это было бы глупо. Проблема не в том, что кто-то считает свой способ лучшим, а в том, если он не допускает мысли, что другие могут знать лучшие способы, и не желает учиться у них.
Рецензирование коллегами даёт хорошую возможность наблюдать за способами работы, которые используют другие. В ходе таких встреч можно увидеть, как кто-то использует незнакомые функции, хитрые приёмы программирования или что-то ещё, что зажигает в вашем мозгу лампочку. Это простой способ учиться и совершенствоваться.
Люди часто заводят разговоры о лучших практиках, которые сразу же перерастают в споры о том, чья практика лучше для той или иной цели, в том или ином контексте. Всё это хорошо, но «лучшая практика» — слишком строгий термин.
Совет - собирайте арсенал хороших практик. Чтобы попасть в него, приём просто должен быть лучше, чем тот, который вы используете сейчас. По мере накопления инструментов и методов придерживайтесь тех, которые вы успешно использовали в прошлом. Заменяйте текущую технику новой, только когда новая позволяет получить превосходные результаты во всех случаях. Часто техники могут мирно сосуществовать, и тогда у вас есть возможность выбирать между ними в зависимости от ситуации. Так что овладейте обеими техниками и используйте самую простую из них, позволяющую выполнять работу.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
Уроки 50 Лет Разработки ПО
Урок 55. У вас нет времени, чтобы совершить все ошибки, сделанные до вас
Получать знания от других людей гораздо эффективнее, чем обретать их самостоятельно. Все профессионалы должны тратить часть своего времени на обретение знаний и расширение навыков в постоянно развивающейся области: чтение книг, статей, посещение конференций или прослушивание подкастов, - и думать, как можно применять эти навыки в работе.
Кривая обучения
Кривая обучения описывает, как человек обретает навыки выполнения новой задачи или применения нового приёма в зависимости от своего опыта. В жизни мы постоянно сталкиваемся с бесчисленными кривыми обучения. Всякий раз, пытаясь сделать что-то новое, мы встаём на новую кривую. Не нужно ожидать, что весь потенциал метода раскроется с первой попытки. Когда проектные группы пробуют использовать незнакомые методы, в их планах должно быть предусмотрено время, необходимое на то, чтобы освоиться. Если им не удастся освоить новую практику, то затраченное время будет потеряно навсегда.
Вы, несомненно, заинтересованы в повышении общей продуктивности, которой позволяет добиться ваш набор приёмов. На картинке выше показано, что в самом начале вы имеете определенный уровень продуктивности, который хотите повысить с помощью усовершенствованного процесса, практики, метода или инструмента. Первый шаг — обучение и обретение некоего опыта. Ваша продуктивность немедленно падает, поскольку в периоды обучения вы не выполняете полезную работу. Продуктивность продолжает снижаться, пока вы тратите время на создание новых процессов, пытаетесь понять, как заставить работать новую технику, приобретаете новый инструмент и учитесь использовать его и т. д. По мере осваивания нового способа работы вы начинаете замечать первые успехи, а также некоторые неудачи — пилообразная часть кривой роста продуктивности. Если все пойдет хорошо, то в итоге ваши вложения окупятся и вы почувствуете, что эффективность, результативность и качество возросли. Помните о реальности кривой обучения, внедряя новые практики, и не поддавайтесь искушению сдаться до того, как вложения в обучение начнут окупаться.
Хорошие практики
Забавно, когда кто-то жалуется на другого: «Он всегда думает, что его способ лучше». Конечно, он так думает! Зачем кому-то намеренно делать что-то, выбирая плохие способы? Это было бы глупо. Проблема не в том, что кто-то считает свой способ лучшим, а в том, если он не допускает мысли, что другие могут знать лучшие способы, и не желает учиться у них.
Рецензирование коллегами даёт хорошую возможность наблюдать за способами работы, которые используют другие. В ходе таких встреч можно увидеть, как кто-то использует незнакомые функции, хитрые приёмы программирования или что-то ещё, что зажигает в вашем мозгу лампочку. Это простой способ учиться и совершенствоваться.
Люди часто заводят разговоры о лучших практиках, которые сразу же перерастают в споры о том, чья практика лучше для той или иной цели, в том или ином контексте. Всё это хорошо, но «лучшая практика» — слишком строгий термин.
Совет - собирайте арсенал хороших практик. Чтобы попасть в него, приём просто должен быть лучше, чем тот, который вы используете сейчас. По мере накопления инструментов и методов придерживайтесь тех, которые вы успешно использовали в прошлом. Заменяйте текущую технику новой, только когда новая позволяет получить превосходные результаты во всех случаях. Часто техники могут мирно сосуществовать, и тогда у вас есть возможность выбирать между ними в зависимости от ситуации. Так что овладейте обеими техниками и используйте самую простую из них, позволяющую выполнять работу.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
👍11
День 2342. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 56. Здравый смысл и опыт иногда важнее определённого процесса
Процесс должен работать на вас, а не вы на него. Процессы, адаптированные к ситуации на основе опыта, ведут команды к повторному успеху. В каждой ситуации люди должны осознанно выбирать, масштабировать и адаптировать процессы для получения максимальной выгоды.
Просто наличие процесса не является гарантией его эффективности и уместности. Подвергать сомнению процесс — нормально; ненормально нарушать его. Убедитесь, что понимаете обоснование и цель шага, который вы ставите под сомнение, прежде чем решить отказаться от него. В регулируемых отраслях в процесс добавляются дополнительные этапы, чтобы достичь обязательного соответствия системе управления качеством. Пропуск обязательного этапа может вызвать проблемы при попытке получить сертификат продукта. Не важно, как вы создаёте небольшой сайт или приложение, при условии, что они работают правильно для клиента, но важно, как люди создают медицинские устройства и транспортные системы. Однако часто этапы процесса существуют просто потому, что кто-то согласился с тем, что они будут полезны.
Организации внедряют процессы и методологии, чтобы добиться большей эффективности. Нередко процессы вносят значительный вклад в успех, хотя и не всегда. Процесс мог иметь смысл в момент написания, но теперь не подходит к текущей ситуации. А если процесс непрактичен, то люди будут его игнорировать.
Всякий раз, когда люди не следуют процессу, который, по их утверждениям, они используют, есть три возможных варианта действий:
1. Начать следовать процессу, поскольку это лучший из известных способов выполнения данного конкретного действия.
2. Если процесс не соответствует потребностям, изменить его и сделать более эффективным и практичным, а затем следовать ему.
3. Отказаться от процесса и перестать притворяться, что следуете ему.
Слово «процесс» оставляет у некоторых людей неприятный осадок, но так быть не должно. Процесс просто описывает, как отдельные лица и группы должны выполнять свою работу. Он может быть случайным и хаотичным, хорошо структурированным и дисциплинирующим или находиться где-то посередине. Ситуация с проектом должна диктовать, насколько строгим должен быть процесс. Как вариант, процесс может быть неформальным. Нет задокументированных процедур, но все знают, какие действия должны выполнять, и, взаимодействуя друг с другом, работают без сбоев.
Не будьте категоричны
Процессы не являются догмой. В мире ПО создано множество методологий разработки и управления, которые претендуют на звание панацеи. Но вместо того, чтобы строго следовать какой-либо из них, нужно выбирать их лучшие элементы и применять в зависимости от ситуации.
Методы Agile-разработки получили широкое распространение с конца 1990-х. В «Википедии» определены не менее 14 важных систем и 21 широко используемая практика Agile-разработки ПО. Некоторые пуристы очень обеспокоены соответствием, скажем, методологии Scrum. Потому что «если использовать только отдельные компоненты Scrum, то это будет не Scrum». Так цель соответствовать Scrum или качественно и быстро выполнить работу?
Не важно, если ваши практики противоречат основным принципам Agile. Важно, помогают ли они проекту и организации добиться успеха. Именно это должно быть определяющим фактором. Ни один подход к разработке ПО не является настолько совершенным, чтобы команды не могли настроить его под себя с целью повысить его ценность. Практика должна предлагать лучший способ выполнения работы в конкретной ситуации. Если это не так, то используйте что-нибудь другое.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
Уроки 50 Лет Разработки ПО
Урок 56. Здравый смысл и опыт иногда важнее определённого процесса
Процесс должен работать на вас, а не вы на него. Процессы, адаптированные к ситуации на основе опыта, ведут команды к повторному успеху. В каждой ситуации люди должны осознанно выбирать, масштабировать и адаптировать процессы для получения максимальной выгоды.
Просто наличие процесса не является гарантией его эффективности и уместности. Подвергать сомнению процесс — нормально; ненормально нарушать его. Убедитесь, что понимаете обоснование и цель шага, который вы ставите под сомнение, прежде чем решить отказаться от него. В регулируемых отраслях в процесс добавляются дополнительные этапы, чтобы достичь обязательного соответствия системе управления качеством. Пропуск обязательного этапа может вызвать проблемы при попытке получить сертификат продукта. Не важно, как вы создаёте небольшой сайт или приложение, при условии, что они работают правильно для клиента, но важно, как люди создают медицинские устройства и транспортные системы. Однако часто этапы процесса существуют просто потому, что кто-то согласился с тем, что они будут полезны.
Организации внедряют процессы и методологии, чтобы добиться большей эффективности. Нередко процессы вносят значительный вклад в успех, хотя и не всегда. Процесс мог иметь смысл в момент написания, но теперь не подходит к текущей ситуации. А если процесс непрактичен, то люди будут его игнорировать.
Всякий раз, когда люди не следуют процессу, который, по их утверждениям, они используют, есть три возможных варианта действий:
1. Начать следовать процессу, поскольку это лучший из известных способов выполнения данного конкретного действия.
2. Если процесс не соответствует потребностям, изменить его и сделать более эффективным и практичным, а затем следовать ему.
3. Отказаться от процесса и перестать притворяться, что следуете ему.
Слово «процесс» оставляет у некоторых людей неприятный осадок, но так быть не должно. Процесс просто описывает, как отдельные лица и группы должны выполнять свою работу. Он может быть случайным и хаотичным, хорошо структурированным и дисциплинирующим или находиться где-то посередине. Ситуация с проектом должна диктовать, насколько строгим должен быть процесс. Как вариант, процесс может быть неформальным. Нет задокументированных процедур, но все знают, какие действия должны выполнять, и, взаимодействуя друг с другом, работают без сбоев.
Не будьте категоричны
Процессы не являются догмой. В мире ПО создано множество методологий разработки и управления, которые претендуют на звание панацеи. Но вместо того, чтобы строго следовать какой-либо из них, нужно выбирать их лучшие элементы и применять в зависимости от ситуации.
Методы Agile-разработки получили широкое распространение с конца 1990-х. В «Википедии» определены не менее 14 важных систем и 21 широко используемая практика Agile-разработки ПО. Некоторые пуристы очень обеспокоены соответствием, скажем, методологии Scrum. Потому что «если использовать только отдельные компоненты Scrum, то это будет не Scrum». Так цель соответствовать Scrum или качественно и быстро выполнить работу?
Не важно, если ваши практики противоречат основным принципам Agile. Важно, помогают ли они проекту и организации добиться успеха. Именно это должно быть определяющим фактором. Ни один подход к разработке ПО не является настолько совершенным, чтобы команды не могли настроить его под себя с целью повысить его ценность. Практика должна предлагать лучший способ выполнения работы в конкретной ситуации. Если это не так, то используйте что-нибудь другое.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
👍5
День 2355. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 57. Адаптируйте готовые шаблоны документов. Начало
Простые списки функций, запрашиваемых клиентами – хорошее начало для упорядочивания спецификации. Однако, есть шаблон спецификации требований к ПО (Software Requirements Specification, SRS), описанный в уже устаревшем стандарте IEEE 830. Шаблон содержит множество разделов, которые помогут систематизировать разнообразную информацию о требованиях. Однако, это не догма. Его можно и нужно менять, чтобы он лучше подходил для разрабатываемых вами систем.
Шаблоны документов предлагают несколько преимуществ:
- определяют согласованные способы организации проектной информации, что облегчает людям, работающим с этими документами, поиск нужной информации.
- могут выявить потенциальные пробелы в знаниях автора документа о проекте, напомнить об информации, которую, возможно, следует добавить.
Предположим, вы решили использовать шаблон, приведённый выше, для структурирования информации о требованиях к новой системе. Не заполняйте его сверху вниз. Пишите определённые разделы по мере накопления соответствующей информации. Возможно, через какое-то время вы заметите, что раздел 2.5 «Допущения и зависимости» не заполнен. Это побудит задаться вопросом, есть ли какая-то недостающая информация о предположениях и зависимостях, которую нужно выяснить. Возможно, нужно побеседовать с определёнными заинтересованными сторонами. Может быть, никто ещё не указал на какие-либо вероятные предположения или зависимости и следует их определить. Некоторые допущения или зависимости могли быть записаны где-то еще; тогда, возможно, их следует переместить в этот раздел или добавить ссылки на них. Или, может быть, действительно нет никаких известных предположений или зависимостей. Пустой раздел напоминает, что вам ещё есть над чем поработать.
Кроме того, нужно подумать, что делать, если определённый раздел неактуален для вашего проекта. Один из вариантов — просто удалить его из документа с требованиями по завершении работы. Но отсутствие раздела может вызвать у читателя вопрос: «Я не увидел ничего о допущениях и зависимостях. Есть ли такие? Спрошу-ка я у кого-нибудь». Конечно, можно сохранить заголовок раздела и оставить сам раздел пустым, но это заставит читателя задаться вопросом, завершён ли документ. Лучше оставить заголовок и добавить пояснение: «Для этого проекта не было выявлено никаких допущений или зависимостей». Явное сообщение вызывает меньше путаницы, чем неявное.
Окончание следует…
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
Уроки 50 Лет Разработки ПО
Урок 57. Адаптируйте готовые шаблоны документов. Начало
Простые списки функций, запрашиваемых клиентами – хорошее начало для упорядочивания спецификации. Однако, есть шаблон спецификации требований к ПО (Software Requirements Specification, SRS), описанный в уже устаревшем стандарте IEEE 830. Шаблон содержит множество разделов, которые помогут систематизировать разнообразную информацию о требованиях. Однако, это не догма. Его можно и нужно менять, чтобы он лучше подходил для разрабатываемых вами систем.
РАСШИРЕННЫЙ ШАБЛОН СПЕЦИФИКАЦИИ ТРЕБОВАНИЙ К ПО
1. Введение.
1.1. Цель.
1.2. Условные обозначения.
1.3. Сфера применения проекта.
1.4. Ссылки.
2. Общее описание.
2.1. Перспектива продукта.
2.2. Классы и характеристики пользователей.
2.3. Операционная среда.
2.4. Ограничения и реализация.
2.5. Допущения и зависимости.
3. Системные функции.
3.x. Системная функция X.
3.x.1. Описание.
3.x.2. Функциональные требования.
4. Требования к данным.
4.1. Логическая модель данных.
4.2. Словарь данных.
4.3. Отчеты.
4.4. Целостность, хранение и удаление данных.
5. Требования к внешнему интерфейсу.
5.1. Пользовательские интерфейсы.
5.2. Программные интерфейсы.
5.3. Аппаратные интерфейсы.
5.4. Коммуникационные интерфейсы.
6. Атрибуты качества.
6.1. Удобство использования.
6.2. Производительность.
6.3. Безопасность.
6.4. Защищенность.
6.x. [другие].
7. Требования к интернационализации и локализации.
8. Другие требования.
Приложение A. Глоссарий.
Приложение Б. Модели анализа.
Шаблоны документов предлагают несколько преимуществ:
- определяют согласованные способы организации проектной информации, что облегчает людям, работающим с этими документами, поиск нужной информации.
- могут выявить потенциальные пробелы в знаниях автора документа о проекте, напомнить об информации, которую, возможно, следует добавить.
Предположим, вы решили использовать шаблон, приведённый выше, для структурирования информации о требованиях к новой системе. Не заполняйте его сверху вниз. Пишите определённые разделы по мере накопления соответствующей информации. Возможно, через какое-то время вы заметите, что раздел 2.5 «Допущения и зависимости» не заполнен. Это побудит задаться вопросом, есть ли какая-то недостающая информация о предположениях и зависимостях, которую нужно выяснить. Возможно, нужно побеседовать с определёнными заинтересованными сторонами. Может быть, никто ещё не указал на какие-либо вероятные предположения или зависимости и следует их определить. Некоторые допущения или зависимости могли быть записаны где-то еще; тогда, возможно, их следует переместить в этот раздел или добавить ссылки на них. Или, может быть, действительно нет никаких известных предположений или зависимостей. Пустой раздел напоминает, что вам ещё есть над чем поработать.
Кроме того, нужно подумать, что делать, если определённый раздел неактуален для вашего проекта. Один из вариантов — просто удалить его из документа с требованиями по завершении работы. Но отсутствие раздела может вызвать у читателя вопрос: «Я не увидел ничего о допущениях и зависимостях. Есть ли такие? Спрошу-ка я у кого-нибудь». Конечно, можно сохранить заголовок раздела и оставить сам раздел пустым, но это заставит читателя задаться вопросом, завершён ли документ. Лучше оставить заголовок и добавить пояснение: «Для этого проекта не было выявлено никаких допущений или зависимостей». Явное сообщение вызывает меньше путаницы, чем неявное.
Окончание следует…
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
👍4
День 2356. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 57. Адаптируйте готовые шаблоны документов. Окончание
Начало
Создание подходящего шаблона с чистого листа идёт медленно и бессистемно. Лучше начать с универсального шаблона, а затем адаптировать его к размеру, характеру и потребностям каждого проекта. Многие технические стандарты описывают шаблоны документов. К организациям, выпускающим технические стандарты по разработке ПО, относятся:
- Институт инженеров по электротехнике и электронике (Institute of Electrical and Electronics Engineers, IEEE);
- Международная организация по стандартизации (International Organization for Standardization, ISO);
- Международная электротехническая комиссия (International Electrotechnical Commission, IEC)
Например, международный стандарт ISO/IEC/IEEE 29148 содержит предлагаемые шаблоны для описания ПО, заинтересованных сторон и спецификаций системных требований (ISO/IEC/IEEE 2018). В сети вы найдёте множество шаблонов различных документов.
Поскольку такие общие шаблоны предназначены для широкого круга проектов, они могут вам не подойти. Но они дадут много идей об информации, которую следует добавить, и способах её организации. Концепция использования готовых шаблонов подразумевает возможность адаптировать эти шаблоны к вашей ситуации:
- Удалите разделы, которые вам не нужны.
- Добавьте разделы, которых нет в шаблоне, но которые помогут вашему проекту.
- Упростите или объедините разделы шаблона, если это не вызовет путаницы.
- Измените терминологию в соответствии с вашим проектом или культурой.
- Реорганизуйте содержимое шаблона, чтобы оно лучше соответствовало потребностям вашей аудитории.
- Разделите или объедините шаблоны связанных документов, если это целесообразно.
Если ваша организация работает над проектами нескольких классов или размеров, то создайте наборы шаблонов, подходящие для каждого класса.
Компании добиваются успеха не потому, что пишут отличные спецификации или планы, а потому, что создают высококачественные информационные системы или коммерческие приложения. Хорошо составленные ключевые документы могут способствовать этому успеху. Некоторые люди не используют шаблоны, опасаясь, что они наложат на проект излишние ограничения. Они могут быть обеспокоены тем, что команда сосредоточится на заполнении шаблона, а не на создании продукта. Если у вас нет договорных требований, то вы не обязаны заполнять каждый раздел шаблона. И, конечно же, не обязаны заполнять шаблон до начала разработки. Но, даже если ваша организация не использует документы для хранения информации, при разработке проекта всё равно нужно записывать и сохранять определённые знания в какой-либо форме. Вы можете использовать контрольные списки вместо шаблонов, чтобы не упустить из виду что-то важное. Контрольный список также помогает оценить, насколько полным является набор информации, однако не помогает систематизировать её согласованным образом.
Многие организации хранят требования и другие сведения о проекте в определённом инструменте. Такие инструменты позволяют определять шаблоны для хранимых объектов данных. При необходимости пользователи могут создавать документы в виде отчётов на основе содержимого базы данных инструмента. Всем, кто использует такой инструмент, важно понимать, что он является основным хранилищем текущей информации. Сгенерированный документ — это лишь моментальный снимок содержимого базы данных, который завтра может устареть.
Шаблоны, контрольные списки и формы ценны, т.к. избавляют вас от необходимости заново изобретать способы работы над каждым проектом. Продуманные шаблоны напоминают вам и вашим коллегам о том, как наиболее эффективно внести свой вклад в проект.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
Уроки 50 Лет Разработки ПО
Урок 57. Адаптируйте готовые шаблоны документов. Окончание
Начало
Создание подходящего шаблона с чистого листа идёт медленно и бессистемно. Лучше начать с универсального шаблона, а затем адаптировать его к размеру, характеру и потребностям каждого проекта. Многие технические стандарты описывают шаблоны документов. К организациям, выпускающим технические стандарты по разработке ПО, относятся:
- Институт инженеров по электротехнике и электронике (Institute of Electrical and Electronics Engineers, IEEE);
- Международная организация по стандартизации (International Organization for Standardization, ISO);
- Международная электротехническая комиссия (International Electrotechnical Commission, IEC)
Например, международный стандарт ISO/IEC/IEEE 29148 содержит предлагаемые шаблоны для описания ПО, заинтересованных сторон и спецификаций системных требований (ISO/IEC/IEEE 2018). В сети вы найдёте множество шаблонов различных документов.
Поскольку такие общие шаблоны предназначены для широкого круга проектов, они могут вам не подойти. Но они дадут много идей об информации, которую следует добавить, и способах её организации. Концепция использования готовых шаблонов подразумевает возможность адаптировать эти шаблоны к вашей ситуации:
- Удалите разделы, которые вам не нужны.
- Добавьте разделы, которых нет в шаблоне, но которые помогут вашему проекту.
- Упростите или объедините разделы шаблона, если это не вызовет путаницы.
- Измените терминологию в соответствии с вашим проектом или культурой.
- Реорганизуйте содержимое шаблона, чтобы оно лучше соответствовало потребностям вашей аудитории.
- Разделите или объедините шаблоны связанных документов, если это целесообразно.
Если ваша организация работает над проектами нескольких классов или размеров, то создайте наборы шаблонов, подходящие для каждого класса.
Компании добиваются успеха не потому, что пишут отличные спецификации или планы, а потому, что создают высококачественные информационные системы или коммерческие приложения. Хорошо составленные ключевые документы могут способствовать этому успеху. Некоторые люди не используют шаблоны, опасаясь, что они наложат на проект излишние ограничения. Они могут быть обеспокоены тем, что команда сосредоточится на заполнении шаблона, а не на создании продукта. Если у вас нет договорных требований, то вы не обязаны заполнять каждый раздел шаблона. И, конечно же, не обязаны заполнять шаблон до начала разработки. Но, даже если ваша организация не использует документы для хранения информации, при разработке проекта всё равно нужно записывать и сохранять определённые знания в какой-либо форме. Вы можете использовать контрольные списки вместо шаблонов, чтобы не упустить из виду что-то важное. Контрольный список также помогает оценить, насколько полным является набор информации, однако не помогает систематизировать её согласованным образом.
Многие организации хранят требования и другие сведения о проекте в определённом инструменте. Такие инструменты позволяют определять шаблоны для хранимых объектов данных. При необходимости пользователи могут создавать документы в виде отчётов на основе содержимого базы данных инструмента. Всем, кто использует такой инструмент, важно понимать, что он является основным хранилищем текущей информации. Сгенерированный документ — это лишь моментальный снимок содержимого базы данных, который завтра может устареть.
Шаблоны, контрольные списки и формы ценны, т.к. избавляют вас от необходимости заново изобретать способы работы над каждым проектом. Продуманные шаблоны напоминают вам и вашим коллегам о том, как наиболее эффективно внести свой вклад в проект.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
День 2363. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 58. Если не тратить время на учёбу и совершенствование, то не стоит ждать, что следующий проект будет реализован лучше предыдущего
Процесс размышления о событии, имеющий целью пережить следующее событие, называется ретроспективой («обзором результатов разработки» или «постмортемом» - даже если проект был реализован). Все команды разработчиков ПО должны проводить ретроспективы в конце цикла разработки (выпуска или итерации), по завершении проекта и при возникновении неожиданного или разрушительного события.
Ретроспектива позволяет учиться и совершенствоваться. Команда определяет, что получилось хорошо, а что нет, и благодаря этому получает возможность применить полученный опыт в будущей работе.
Ретроспектива помогает ответить на четыре вопроса:
1. Что получилось хорошо и что мы хотели бы повторить?
2. Что получилось не так хорошо и где в следующий раз следует поступить иначе?
3. Что нас удивило и может быть опасным в будущем?
4. Есть ли что-то, чего мы ещё не понимаем и должны исследовать?
Ретроспектива должна проводиться с привлечением всех участников и не должна использоваться для обвинения кого-то. Важно объективно и беспристрастно исследовать прошлый опыт. Каждый участник ретроспективы должен помнить первый закон Керта: «Какие бы факты ни вскрылись в ходе ретроспективы, мы должны понимать и искренне верить, что каждый старался делать свою работу максимально хорошо, с учётом имеющейся информации, навыков и способностей, доступных ресурсов и ситуации, сложившейся на тот момент.»
Время ретроспективы зависит от объёма проекта, качества выполнения работы и количества нового материала, который еще предстоит узнать. Agile-команде может потребоваться 30-60 минут на обсуждение итогов двухнедельного спринта. В больших проектах можно выделять до нескольких дней. Чем больше потенциальных рычагов для улучшения будущих результатов, тем целесообразнее тратить время на подведение итогов.
Ретроспектива — структурированная и ограниченная по времени последовательность действий: планирование, начало мероприятия, сбор информации, определение приоритетов проблем, анализ проблем и принятие решения о том, что делать с информацией. Члены команды делятся своим опытом работы над проектом: что произошло, когда и чем закончилось. Рекомендуется спрашивать мнение всех участников проекта, поскольку точка зрения каждого уникальна. Важно узнать эмоциональный фон участников во время выполнения проекта. Это позволяет найти идеи, повышающие чувство удовлетворенности работой.
Участники ретроспективы сообщают любые данные, собранные командой, в виде типичных метрик:
- размер — количество и объём требований, пользовательских историй и других элементов;
- трудозатраты — запланированные и фактические;
- время — запланированная и фактическая календарная продолжительность;
- качество — количество дефектов и их виды, производительность системы и другие качественные характеристики.
Результаты ретроспективы обязательно должны учитываться в текущей деятельности по совершенствованию процессов. Люди, проводящие ретроспективы, должны уделить время изучению способов решения прошлых проблем. В это время они не смогут заниматься решением задач проекта, поэтому усилия по совершенствованию должны быть добавлены в графики проекта. Если проектная команда проводит ретроспективу, но руководство не предоставляет ресурсы для решения выявленных проблем, то такая ретроспектива бесполезна.
Поэтому добавляйте в график время для обучения и экспериментов, чтобы люди могли учиться эффективно применять новые практики, инструменты и методы. Проведение ретроспектив без внесения каких-либо изменений в процессы — пустая трата времени, отбивающая у участников охоту участвовать в них. Высший признак успеха ретроспективы — наличие устойчивых изменений. Это говорит о том, что время, потраченное командой на размышления о прошлых событиях, приносит долговременную пользу.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
Уроки 50 Лет Разработки ПО
Урок 58. Если не тратить время на учёбу и совершенствование, то не стоит ждать, что следующий проект будет реализован лучше предыдущего
Процесс размышления о событии, имеющий целью пережить следующее событие, называется ретроспективой («обзором результатов разработки» или «постмортемом» - даже если проект был реализован). Все команды разработчиков ПО должны проводить ретроспективы в конце цикла разработки (выпуска или итерации), по завершении проекта и при возникновении неожиданного или разрушительного события.
Ретроспектива позволяет учиться и совершенствоваться. Команда определяет, что получилось хорошо, а что нет, и благодаря этому получает возможность применить полученный опыт в будущей работе.
Ретроспектива помогает ответить на четыре вопроса:
1. Что получилось хорошо и что мы хотели бы повторить?
2. Что получилось не так хорошо и где в следующий раз следует поступить иначе?
3. Что нас удивило и может быть опасным в будущем?
4. Есть ли что-то, чего мы ещё не понимаем и должны исследовать?
Ретроспектива должна проводиться с привлечением всех участников и не должна использоваться для обвинения кого-то. Важно объективно и беспристрастно исследовать прошлый опыт. Каждый участник ретроспективы должен помнить первый закон Керта: «Какие бы факты ни вскрылись в ходе ретроспективы, мы должны понимать и искренне верить, что каждый старался делать свою работу максимально хорошо, с учётом имеющейся информации, навыков и способностей, доступных ресурсов и ситуации, сложившейся на тот момент.»
Время ретроспективы зависит от объёма проекта, качества выполнения работы и количества нового материала, который еще предстоит узнать. Agile-команде может потребоваться 30-60 минут на обсуждение итогов двухнедельного спринта. В больших проектах можно выделять до нескольких дней. Чем больше потенциальных рычагов для улучшения будущих результатов, тем целесообразнее тратить время на подведение итогов.
Ретроспектива — структурированная и ограниченная по времени последовательность действий: планирование, начало мероприятия, сбор информации, определение приоритетов проблем, анализ проблем и принятие решения о том, что делать с информацией. Члены команды делятся своим опытом работы над проектом: что произошло, когда и чем закончилось. Рекомендуется спрашивать мнение всех участников проекта, поскольку точка зрения каждого уникальна. Важно узнать эмоциональный фон участников во время выполнения проекта. Это позволяет найти идеи, повышающие чувство удовлетворенности работой.
Участники ретроспективы сообщают любые данные, собранные командой, в виде типичных метрик:
- размер — количество и объём требований, пользовательских историй и других элементов;
- трудозатраты — запланированные и фактические;
- время — запланированная и фактическая календарная продолжительность;
- качество — количество дефектов и их виды, производительность системы и другие качественные характеристики.
Результаты ретроспективы обязательно должны учитываться в текущей деятельности по совершенствованию процессов. Люди, проводящие ретроспективы, должны уделить время изучению способов решения прошлых проблем. В это время они не смогут заниматься решением задач проекта, поэтому усилия по совершенствованию должны быть добавлены в графики проекта. Если проектная команда проводит ретроспективу, но руководство не предоставляет ресурсы для решения выявленных проблем, то такая ретроспектива бесполезна.
Поэтому добавляйте в график время для обучения и экспериментов, чтобы люди могли учиться эффективно применять новые практики, инструменты и методы. Проведение ретроспектив без внесения каких-либо изменений в процессы — пустая трата времени, отбивающая у участников охоту участвовать в них. Высший признак успеха ретроспективы — наличие устойчивых изменений. Это говорит о том, что время, потраченное командой на размышления о прошлых событиях, приносит долговременную пользу.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
👍6
День 2370. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 59. Самая удручающая закономерность в индустрии ПО — повторение одних и тех же неэффективных действий снова и снова
У нас имеются бесчисленные коллекции лучших приёмов в области разработки ПО и сборники уроков, извлечённых из практики. Существует огромное количество книг по разным аспектам разработки и управления проектами. И всё же многие проекты продолжают сталкиваться с проблемами, поскольку не практикуют мероприятия, способствующие успеху.
Группа Standish Group публикует отчёты CHAOS (Comprehensive Human Appraisal for Organizing Software - Комплексная оценка персонала при разработке ПО) с 1994 года. Отчеты основаны на данных тысяч проектов и показывают процент проектов полностью успешных, столкнувшихся с трудностями или потерпевших неудачу. Успех определяется как комбинация из трёх показателей:
1. завершение в срок,
2. непревышение бюджета,
3. удовлетворение потребностей клиентов и пользователей.
И доля полностью успешных проектов много лет не превышает 40%. Но главное, что факторы, приводящие к проблемам и неудачам, почти не меняются.
Наблюдение за закономерностями в результатах ведёт к новым парадигмам выполнения работы. Например, аналитический паралич и устаревающие требования в долгосрочных проектах помогли мотивировать стремление к поэтапной разработке. Некоторые данные в отчетах CHAOS показывают, что проекты, практикующие Agile, имеют более высокий процент успеха, чем водопадные проекты.
Разработка ПО отличается от других технических областей тем, что вы можете выполнять полезную работу, имея минимальное формальное образование и опыт, по крайней мере, до определённого момента. Никто не будет просить врача-любителя удалить ему аппендикс, но многие программисты-любители имеют достаточный объём знаний, чтобы писать небольшие приложения. Однако между ними и опытными инженерами-программистами, способными работать над большими и сложными проектами в сотрудничестве с другими, - пропасть.
Сейчас многие молодые специалисты приходят в отрасль через академическую программу в области информатики, разработки ПО или смежных областей. Однако каждый специалист по разработке ПО, имеющий формальное образование или обучавшийся самостоятельно, должен продолжать поглощать постоянно растущий объём знаний и учиться эффективно их применять. В сфере ПО многие аспекты меняются очень быстро. Чтобы идти в ногу с современными технологиями, порой приходится бежать.
Каждая организация, занимающаяся разработкой, накапливает неформальную коллекцию локальных знаний, основанных на опыте. Важно записывать полученные на горьком опыте знания в сборник извлечённых уроков. Предусмотрительные руководители проектов и разработчики с удовольствием обратятся к нему, приступая к новому начинанию.
Совершенствование процесса разработки
1. Пересмотрите посты из серии #УрокиРазработки, и определите, какие советы имеют отношение к вашему опыту совершенствования процессов разработки.
2. Можете ли вы, опираясь на свой опыт, вспомнить какие-либо другие уроки, связанные с совершенствованием процессов, которыми стоит поделиться с коллегами?
3. Вспомните три самые болезненные для вас точки и проанализируйте их первопричины, чтобы выявить факторы, на которые можно направить усилия на первом этапе совершенствования процессов.
4. Пересмотрите методы из блока «Первые шаги» в этом посте. Как каждый метод может повысить эффективность и результативность вашей команды?
5. Как бы вы определили, приносит ли желаемые результаты каждый метод из шага 4? Насколько ценны для вас эти результаты?
6. Определите любые препятствия, которые могут затруднить применение методов, перечисленных на шаге 4. Как бы вы справились с ними? Заручились бы поддержкой коллег, готовых помочь вам в реализации этих методов?
7. Какие тренинги, книги, руководства или другие ресурсы могли бы помочь вашей организации успешнее проводить мероприятия по совер¬шенствованию процессов?
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
Уроки 50 Лет Разработки ПО
Урок 59. Самая удручающая закономерность в индустрии ПО — повторение одних и тех же неэффективных действий снова и снова
У нас имеются бесчисленные коллекции лучших приёмов в области разработки ПО и сборники уроков, извлечённых из практики. Существует огромное количество книг по разным аспектам разработки и управления проектами. И всё же многие проекты продолжают сталкиваться с проблемами, поскольку не практикуют мероприятия, способствующие успеху.
Группа Standish Group публикует отчёты CHAOS (Comprehensive Human Appraisal for Organizing Software - Комплексная оценка персонала при разработке ПО) с 1994 года. Отчеты основаны на данных тысяч проектов и показывают процент проектов полностью успешных, столкнувшихся с трудностями или потерпевших неудачу. Успех определяется как комбинация из трёх показателей:
1. завершение в срок,
2. непревышение бюджета,
3. удовлетворение потребностей клиентов и пользователей.
И доля полностью успешных проектов много лет не превышает 40%. Но главное, что факторы, приводящие к проблемам и неудачам, почти не меняются.
Наблюдение за закономерностями в результатах ведёт к новым парадигмам выполнения работы. Например, аналитический паралич и устаревающие требования в долгосрочных проектах помогли мотивировать стремление к поэтапной разработке. Некоторые данные в отчетах CHAOS показывают, что проекты, практикующие Agile, имеют более высокий процент успеха, чем водопадные проекты.
Разработка ПО отличается от других технических областей тем, что вы можете выполнять полезную работу, имея минимальное формальное образование и опыт, по крайней мере, до определённого момента. Никто не будет просить врача-любителя удалить ему аппендикс, но многие программисты-любители имеют достаточный объём знаний, чтобы писать небольшие приложения. Однако между ними и опытными инженерами-программистами, способными работать над большими и сложными проектами в сотрудничестве с другими, - пропасть.
Сейчас многие молодые специалисты приходят в отрасль через академическую программу в области информатики, разработки ПО или смежных областей. Однако каждый специалист по разработке ПО, имеющий формальное образование или обучавшийся самостоятельно, должен продолжать поглощать постоянно растущий объём знаний и учиться эффективно их применять. В сфере ПО многие аспекты меняются очень быстро. Чтобы идти в ногу с современными технологиями, порой приходится бежать.
Каждая организация, занимающаяся разработкой, накапливает неформальную коллекцию локальных знаний, основанных на опыте. Важно записывать полученные на горьком опыте знания в сборник извлечённых уроков. Предусмотрительные руководители проектов и разработчики с удовольствием обратятся к нему, приступая к новому начинанию.
Совершенствование процесса разработки
1. Пересмотрите посты из серии #УрокиРазработки, и определите, какие советы имеют отношение к вашему опыту совершенствования процессов разработки.
2. Можете ли вы, опираясь на свой опыт, вспомнить какие-либо другие уроки, связанные с совершенствованием процессов, которыми стоит поделиться с коллегами?
3. Вспомните три самые болезненные для вас точки и проанализируйте их первопричины, чтобы выявить факторы, на которые можно направить усилия на первом этапе совершенствования процессов.
4. Пересмотрите методы из блока «Первые шаги» в этом посте. Как каждый метод может повысить эффективность и результативность вашей команды?
5. Как бы вы определили, приносит ли желаемые результаты каждый метод из шага 4? Насколько ценны для вас эти результаты?
6. Определите любые препятствия, которые могут затруднить применение методов, перечисленных на шаге 4. Как бы вы справились с ними? Заручились бы поддержкой коллег, готовых помочь вам в реализации этих методов?
7. Какие тренинги, книги, руководства или другие ресурсы могли бы помочь вашей организации успешнее проводить мероприятия по совер¬шенствованию процессов?
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.
👍1
День 2377. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 60. Невозможно изменить всё сразу
Независимо от того, сколько болевых точек, идей по улучшению или желательных направлений вы определите, скорость восприятия изменений людьми и организациями ограничена. Люди не могут совершенствовать свою работу быстрее, чем позволяют их индивидуальные способности, поэтому инициатива крупномасштабных изменений, навязанная руководством, может ошеломить тех, кого она касается. Попытка изменить слишком многое и сразу может затруднить выполнение работы, поскольку люди будут пытаться понять новые веяния и стараться соответствовать им.
По аналогии с личностным ростом совершенствование процессов разработки ПО — это циклическое, а не прямолинейное движение. Изобразить цикл изменений можно, например, как на рисунке выше.
1. Оценка. Определите, где вы находитесь сегодня: каких результатов достигли ваши проекты в настоящее время и насколько хорошо идут дела. Определите самые проблемные области и самые большие возможности для улучшения.
2. Планирование. Решите, где вы хотели бы быть в будущем: каковы цели по улучшению. Наметьте план, как этого достичь.
3. Выполнение. Самое сложное - начать работать как-то иначе. Придётся познакомиться с практиками и методами, которые могут дать лучшие результаты, опробовать их и скорректировать под условия своей среды. Сохраняйте то, что работает, и изменяйте, заменяйте или отказывайтесь от того, что не работает.
4. Проверка. Позвольте новым методам закрепиться, а затем проверьте, дают ли они ожидаемые результаты. Чтобы изменить направление, требуются время и терпение. Затраты на обучение неизбежны. Улучшение показателей — это долгосрочный, но запаздывающий признак пригодности новых подходов для ваших проектов. Попробуйте определить промежуточные показатели, по которым можно понять, окупается ли то, что вы пытаетесь сделать.
Всегда найдётся над чем поработать. Возвращайтесь к шагу оценки в конце каждого цикла изменений, чтобы изучить новую ситуацию, а затем начинайте новый.
Приоритизация изменений
Вы можете определить больше желаемых изменений, чем могли бы внедрить, поэтому придётся расставить приоритеты, чтобы сосредоточить всю свою энергию на получении максимальной выгоды. Затем вы должны выкроить время для реализации каждого изменения. Если вы намеренно не выделяете время, то никогда не найдёте свободной минутки, не занятой другими хлопотами. Но если вы не сделаете первых шагов к изменениям, то не добьётесь прогресса. Выберите самые актуальные проблемы и начните работать над ними завтра. Да, завтра!
В какой области было бы наиболее желательно увидеть улучшения и уменьшить неприятные последствия? Какие изменения могли бы быть наиболее ценными? Какие изменения кажутся наиболее достижимыми при разумном вложении энергии и денег? Определите основные проблемные области и выберите возможные решения, которые окупятся с высокой вероятностью. Ищите плоды на нижних ветках — быстродостижимые улучшения — и празднуйте эти успехи.
Применяйте системный подход и на личном уровне. Начиная новый проект, определите 2 области, в которых хотелось бы совершенствоваться. Это может быть модульное тестирование, оценка, алгоритмизация, рецензирование, и т.п. Выделите часть времени на чтение литературы или прохождение курсов по выбранным темам и ищите возможности применить то, чему научились, понимая при этом, что потребуются некоторые усилия, чтобы выяснить, как получить наибольший эффект от изменений. Помните, что кривая обучения не является плавным и непрерывным переходом. У вас обязательно будут взлёты и падения. Но, применяя системный подход, вы доберётесь туда, куда хотите попасть.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 8.
Уроки 50 Лет Разработки ПО
Урок 60. Невозможно изменить всё сразу
Независимо от того, сколько болевых точек, идей по улучшению или желательных направлений вы определите, скорость восприятия изменений людьми и организациями ограничена. Люди не могут совершенствовать свою работу быстрее, чем позволяют их индивидуальные способности, поэтому инициатива крупномасштабных изменений, навязанная руководством, может ошеломить тех, кого она касается. Попытка изменить слишком многое и сразу может затруднить выполнение работы, поскольку люди будут пытаться понять новые веяния и стараться соответствовать им.
По аналогии с личностным ростом совершенствование процессов разработки ПО — это циклическое, а не прямолинейное движение. Изобразить цикл изменений можно, например, как на рисунке выше.
1. Оценка. Определите, где вы находитесь сегодня: каких результатов достигли ваши проекты в настоящее время и насколько хорошо идут дела. Определите самые проблемные области и самые большие возможности для улучшения.
2. Планирование. Решите, где вы хотели бы быть в будущем: каковы цели по улучшению. Наметьте план, как этого достичь.
3. Выполнение. Самое сложное - начать работать как-то иначе. Придётся познакомиться с практиками и методами, которые могут дать лучшие результаты, опробовать их и скорректировать под условия своей среды. Сохраняйте то, что работает, и изменяйте, заменяйте или отказывайтесь от того, что не работает.
4. Проверка. Позвольте новым методам закрепиться, а затем проверьте, дают ли они ожидаемые результаты. Чтобы изменить направление, требуются время и терпение. Затраты на обучение неизбежны. Улучшение показателей — это долгосрочный, но запаздывающий признак пригодности новых подходов для ваших проектов. Попробуйте определить промежуточные показатели, по которым можно понять, окупается ли то, что вы пытаетесь сделать.
Всегда найдётся над чем поработать. Возвращайтесь к шагу оценки в конце каждого цикла изменений, чтобы изучить новую ситуацию, а затем начинайте новый.
Приоритизация изменений
Вы можете определить больше желаемых изменений, чем могли бы внедрить, поэтому придётся расставить приоритеты, чтобы сосредоточить всю свою энергию на получении максимальной выгоды. Затем вы должны выкроить время для реализации каждого изменения. Если вы намеренно не выделяете время, то никогда не найдёте свободной минутки, не занятой другими хлопотами. Но если вы не сделаете первых шагов к изменениям, то не добьётесь прогресса. Выберите самые актуальные проблемы и начните работать над ними завтра. Да, завтра!
В какой области было бы наиболее желательно увидеть улучшения и уменьшить неприятные последствия? Какие изменения могли бы быть наиболее ценными? Какие изменения кажутся наиболее достижимыми при разумном вложении энергии и денег? Определите основные проблемные области и выберите возможные решения, которые окупятся с высокой вероятностью. Ищите плоды на нижних ветках — быстродостижимые улучшения — и празднуйте эти успехи.
Применяйте системный подход и на личном уровне. Начиная новый проект, определите 2 области, в которых хотелось бы совершенствоваться. Это может быть модульное тестирование, оценка, алгоритмизация, рецензирование, и т.п. Выделите часть времени на чтение литературы или прохождение курсов по выбранным темам и ищите возможности применить то, чему научились, понимая при этом, что потребуются некоторые усилия, чтобы выяснить, как получить наибольший эффект от изменений. Помните, что кривая обучения не является плавным и непрерывным переходом. У вас обязательно будут взлёты и падения. Но, применяя системный подход, вы доберётесь туда, куда хотите попасть.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 8.
👍8