The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Несколько лет назад я написал о независимых технических обзорах, которые любой программный проект должен проходить регулярно, чтобы убедиться, что все находится под контролем. Я даже недавно сказал, что нет никаких оправданий для их несоблюдения. Более того, чем больше мы доверяем программистам, тем важнее регулярное обзорное изучение их проектов. Вот краткое изложение того, что должно включать отчет от рецензента.
Я попытался затронуть эту тему в нескольких недавних выступлениях: Заставьте клиентов доверять вам на BDMSummit 2017, Как быть честным и удержать клиента на PMCon Kharkiv 2017 и Как избежать неудачи при аутсорсинге на Kyiv Outsourcing Forum 2017. Также существует несколько блог-постов на ту же тему, включая “Семь смертных грехов программного проекта”, “Как избежать неудачи при аутсорсинге программного обеспечения” и “Руководство по выживанию при аутсорсинге программного обеспечения”. Вот, наконец, более или менее полный список вещей, которые должен включать хороший отчет.
По сути, это список вопросов, на которые должен ответить рецензент. Когда все ответы собраны, отчет готов. Самые важные вопросы находятся в начале.
Релизы происходят часто, по крайней мере раз в неделю?
На сколько большим является технический долг (вещи, которые “в конечном итоге” должны быть исправлены)?
Достаточно ли надежна система доставки для отклонения ошибок?
Насколько чист код? Сколько анти-паттернов здесь присутствует?
Все ошибки и функциональные возможности регистрируются в виде заявок?
Покрыт ли код тестами модульного тестирования и видимо ли покрытие?
Заключаются ли соглашения “Работа по найму” со всеми разработчиками?
Документируются ли ключевые архитектурные технические решения?
Статический анализ применяется и является обязательным для новых изменений?
Внедрена ли непрерывная интеграция (CI) и учитываются ли ее отчеты?
Является ли ветка master только для чтения?
Собираются ли показатели программирования и регулярно их анализируют?
Является ли репозиторий исходного кода собственностью заказчика?
Является ли документация по требованиям краткой и актуальной?
Есть ли в коде документация для ключевых классов, методов и функций?
“Репозиторий исходного кода не содержит мусора?”
Документируются ли пользовательские интерфейсы UI/UX?
Видны ли и регулярно проверяются журналы производства?
Насколько оперативно команда реагирует на заявки?
Имеет ли Git четкую историю документированных изменений?
По сути, это очень краткая компиляция наиболее важных вещей, которые вы можете найти в CMMI. Они требуют всего этого, а также большого списка других вещей сверху. Но небольшому проекту не нужно все то, о чем они просят. Мой список короче и, я уверен, будет достаточным для большинства из вас.
Кстати, вы можете посмотреть отчеты, которые добровольцы создают для участников моей Награды за качество программного обеспечения. Они анализируют проекты с открытым исходным кодом и кратко сообщают о проблемах, которые они находят. Я считаю, что они пытаются ответить на точно такой же набор вопросов.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-05 at 21:49
