День 2265. #УрокиРазработки Уроки 50 Лет Разработки ПО
Урок 47. Стремитесь к тому, чтобы дефект нашли коллеги, а не покупатели
Независимо от того, насколько хороша ваша работа, когда другие просматривают её результаты, они улучшаются. Показать своё творение другим людям и просить их подсказать вам, что с ним не так, — это не инстинктивное, а приобретаемое поведение. Всегда неловко, когда рецензент замечает вашу ошибку, но в голове сразу всплывает «молодец, что заметил!». Но лучше, чтобы ошибки находили друзья или коллеги до выпуска, а не клиенты после.
Код-ревью — проверенный метод повышения качества и продуктивности. Он улучшает качество, позволяя обнаруживать дефекты раньше, чем они могли бы быть выявлены в противном случае. Раннее обнаружение дефектов повышает продуктивность, поскольку члены команды тратят меньше времени на исправление дефектов на более поздних этапах разработки или даже после релиза. Даже обзор незаконченного продукта позволяет потребителям оценить, насколько хорошо этот продукт удовлетворит их потребности. А если вы пригласите рецензентов, не входящих в проектную команду, они смогут узнать о некоторых аспектах вашего продукта, а также увидеть, как работает другая команда. Это взаимное обогащение помогает распространять эффективные практики по всей организации.
Разработчики ПО создают множество других артефактов, помимо кода: планы, требования, несколько видов дизайна, планы тестирования и сценарии, экраны UI, документацию и т.п. Всё, что создает человек, может содержать ошибки, поэтому будет очень полезно, если кто-то ещё просмотрит результаты его труда.
Разновидности ревью ПО 1. Проверка коллегой. Попросите одного из коллег просмотреть ваш код и внести предложения по улучшению или исправлению.
2. Круговое обсуждение. Передайте фрагмент своей работы нескольким коллегам и попросите каждого написать отзыв.
3. Пошаговое обсуждение. Автор начинает обсуждение, объясняет, как работает продукт, просит дать обратную связь. Пошаговые обсуждения часто используются для проверки проектного решения, когда требуется мозговой штурм с коллегами.
4. Командный обзор. Автор заранее передаёт продукт и вспомогательные материалы нескольким рецензентам, чтобы у них было время изучить его и обозначить любые проблемы. Во время встречи рецензенты высказывают замечания.
5. Инспекция. Наиболее формальный тип подразумевает участие нескольких персонажей: автор, ведущий (модератор), секретарь, инспектор и т.п. Лучше всего подходит для рецензирования продуктов с повышенным риском.
Даже если вы не практикуете ни один из перечисленных методов рецензирования, просто попросите коллегу посмотреть на вашу работу и помочь найти ошибку или улучшить дизайн. Любой отзыв лучше, чем его отсутствие. Если члены команды не решаются поделиться результатами своего труда, опасаясь критики, — это тревожный сигнал. Еще одним таким сигналом является критика рецензентами автора за ошибки или просто за то, что он выполнил работу не так, как сделали бы они. Плохо продуманные процедуры рецензирования могут нанести ущерб культуре команды разработчиков.
В здоровой культуре разработки члены команды не только предлагают, но и принимают конструктивную критику. Это пример взаимовыручки: ты помогаешь мне, я помогаю тебе — и все выигрывают.
Рекомендации для отзывов: - сосредоточьтесь на продукте, а не на авторе; - формулируйте комментарии как замечания, а не обвинения; - сосредоточьтесь на содержании недостатков, а не на стиле; - если вы автор, отбросьте своё эго и будьте более восприимчивы к предложениям по улучшению.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 6.
День 2265. #УрокиРазработки Уроки 50 Лет Разработки ПО
Урок 47. Стремитесь к тому, чтобы дефект нашли коллеги, а не покупатели
Независимо от того, насколько хороша ваша работа, когда другие просматривают её результаты, они улучшаются. Показать своё творение другим людям и просить их подсказать вам, что с ним не так, — это не инстинктивное, а приобретаемое поведение. Всегда неловко, когда рецензент замечает вашу ошибку, но в голове сразу всплывает «молодец, что заметил!». Но лучше, чтобы ошибки находили друзья или коллеги до выпуска, а не клиенты после.
Код-ревью — проверенный метод повышения качества и продуктивности. Он улучшает качество, позволяя обнаруживать дефекты раньше, чем они могли бы быть выявлены в противном случае. Раннее обнаружение дефектов повышает продуктивность, поскольку члены команды тратят меньше времени на исправление дефектов на более поздних этапах разработки или даже после релиза. Даже обзор незаконченного продукта позволяет потребителям оценить, насколько хорошо этот продукт удовлетворит их потребности. А если вы пригласите рецензентов, не входящих в проектную команду, они смогут узнать о некоторых аспектах вашего продукта, а также увидеть, как работает другая команда. Это взаимное обогащение помогает распространять эффективные практики по всей организации.
Разработчики ПО создают множество других артефактов, помимо кода: планы, требования, несколько видов дизайна, планы тестирования и сценарии, экраны UI, документацию и т.п. Всё, что создает человек, может содержать ошибки, поэтому будет очень полезно, если кто-то ещё просмотрит результаты его труда.
Разновидности ревью ПО 1. Проверка коллегой. Попросите одного из коллег просмотреть ваш код и внести предложения по улучшению или исправлению.
2. Круговое обсуждение. Передайте фрагмент своей работы нескольким коллегам и попросите каждого написать отзыв.
3. Пошаговое обсуждение. Автор начинает обсуждение, объясняет, как работает продукт, просит дать обратную связь. Пошаговые обсуждения часто используются для проверки проектного решения, когда требуется мозговой штурм с коллегами.
4. Командный обзор. Автор заранее передаёт продукт и вспомогательные материалы нескольким рецензентам, чтобы у них было время изучить его и обозначить любые проблемы. Во время встречи рецензенты высказывают замечания.
5. Инспекция. Наиболее формальный тип подразумевает участие нескольких персонажей: автор, ведущий (модератор), секретарь, инспектор и т.п. Лучше всего подходит для рецензирования продуктов с повышенным риском.
Даже если вы не практикуете ни один из перечисленных методов рецензирования, просто попросите коллегу посмотреть на вашу работу и помочь найти ошибку или улучшить дизайн. Любой отзыв лучше, чем его отсутствие. Если члены команды не решаются поделиться результатами своего труда, опасаясь критики, — это тревожный сигнал. Еще одним таким сигналом является критика рецензентами автора за ошибки или просто за то, что он выполнил работу не так, как сделали бы они. Плохо продуманные процедуры рецензирования могут нанести ущерб культуре команды разработчиков.
В здоровой культуре разработки члены команды не только предлагают, но и принимают конструктивную критику. Это пример взаимовыручки: ты помогаешь мне, я помогаю тебе — и все выигрывают.
Рекомендации для отзывов: - сосредоточьтесь на продукте, а не на авторе; - формулируйте комментарии как замечания, а не обвинения; - сосредоточьтесь на содержании недостатков, а не на стиле; - если вы автор, отбросьте своё эго и будьте более восприимчивы к предложениям по улучшению.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 6.
