35 вопросов для быстрой оценки качества IT проекта.
Привет, Хабр! Бывают в жизни ситуации, когда надо оценить качество проекта сразу по всем статьям. Можно заказать аудит извне, а можно проверить все самостоятельно, воспользовавшись следующим гайдом.
У меня бакалаврская степень по Прикладной информатике (Корпоративные информационные системы) и 6 лет опыта в веб-разработке, поэтому я составила данный чек-лист (который вы найдете в конце) со 100-балльной системой, который даст примерное представление о качестве проекта. Материал больше подойдет свежим проектам, хотя и для несвежего тоже может быть полезно.
Я разделила статью на подпункты проверки с кратким описанием критериев. Возможно вы найдете в них инсайты и углубитесь в какую-то тему глубже.
1. Требования и обязательства
Прежде всего изучаем требования от заказчика - основные сроки сдачи / выкатки фич. Проверяем обязательства перед организациями, если имеются аккредитации (условия получения/поддержания). Выписываем все контрольные даты.
Тут же проверяем документацию требований - описание процессов системы. В идеале BPMN/Activity/IDEF0. Почему? Графический способ представления информации наиболее быстр в понимании, а популярные нотации понятны всем и однозначны в интерпретации.
2. Методология разработки
Важно проверить наличие методологии разработки: её присутствие указывает на организованность процесса. Отсутствие методологии в больших командах предвещает проблемы, хотя малые проекты могут обходиться тесным общением. Существует множество методологий, подходящую при желании найдёт каждый. Примеры популярных методологий:
Методология | Описание | Что проверить |
Agile | Итеративная и очень гибкая методология. Нацелена на адаптацию к изменениям. | В процессах - возможно спринты, дейли, планирования, ретроспективы |
Scrum | Вариант реализации Agile, самая популярная методология. Те же принципы, чуть более структурировано | В Scrum важны роли (Scrum-мастер, владелец продукта, команда), артефакты (бэклог продукта, бэклог спринта) и события (планирование спринта, дейли скрам, ревью спринта, ретроспектива) |
Lean | Поменьше болтать и побольше работать. | Должен быть фокус на ценность клиента, обратная связь должна как можно быстрее влиять на разработку |
Waterfall | Подходит если есть ОЧЕНЬ четкие конечные требования. В самом начале строится план разработки с дедлайнами. | Должно быть четкое следование плану, должен быть план в целом, четкая документация |
Prototype | Быстро создается прототип продукта и затем дорабатывается, пока не получится приемлемый результат. | Должны быть версии продукта, хорошо тестироваться на пользователях и быстро адаптироваться. |
3. Система управления проектами
Необходима система управления проектами, предпочтительно Jira / Redmine / Trello / Asana / Microsoft Project.
Для Agile нужна доска задач текущего спринта с тестированием, для Waterfall — диаграмма Ганта. Важен беклог с задачами. В Agile/Scrum задачи должны быть структурированы (Epic > Story > Задачи + Test execution).
Важны чёткое описание и заголовок задачи, указание на тестирование и прикрепление коммитов для интеграции с репозиторием.
Тут же сверяемся со сроками из пункта 1. Возможно планы будут в другой системе, это не проблема. Проверьте соответствие планам и риски. Очевидно если есть несоответствие - надо что-то менять.
4. Репозиторий
Смотрим на ветки в проекте, по ним будет понятен git flow. Плохо если веток мало - только master и develop, например. Фичи должны разрабатываться в отдельных ветках, они должны существовать.
Далее идем в Merge requests. Там должно быть:
Нормальное описание
В коммитах должен быть указан номер задачи, без этого код через пару лет превратится в ад, не найдешь концов
Должны быть дискуссии, по крайней мере в больших MR'ах, Approves - иначе произвол
Pipeline - должен быть. В проверках - сборка, линтер, тесты (+ результат развертывания, статический анализ по желанию)
5. Состав команды
Тут много вариантов, но хороший базовый вот такой:
фронтенд
бекенд
дизайнер
продакт
проджект
тестировщик
девопс
Если команда неполная - что-то будет проседать. Если нет отдельно фронтенда и бекенда - возможно будет низкое качество кода. Без дизайнера будет колхозный вид. Без продакта - нет плана разработки (если это не вотерфолл с готовым планом). Без проджекта наступит хаос в разработке. Без тестировщиков - будут находиться баги (не на том этапе когда мы ожидаем), без девопса - система будет нестабильной.
6. Релизы и окружения
Несмотря на стадию проекта - план должен быть. Самый стандарт по окружениям - dev, prod, stage. По релизам должен быть план - Git flow, Continuous Deployment.
Также должен быть план для управления hotfixes и emergency releases, чтобы гарантировать стабильность и непрерывность работы в production среде.
7. Развертывание
Если девопс все-таки есть, стоит для начала посмотреть на диаграммы развертывания. Тут стоит оценить, нужен ли докер или другие инструменты контейнеризации, а также приложения для оркестровки контейнеризованных приложений (k8s и т.п.). Особенно актуально для нескольких окружений, если хочется автоматического развертывания (например, чтобы избежать ошибок при развертывании очередного окружения) и в целом для больших приложений, микросервисных архитектур.
8. Тестирование
Тут мы говорим о тестировании отдельно от разработки. По моему опыту самое важное тут - exploratory testing. Поскольку задачу после выполнения может проверить и сам разработчик при помощи друзей-разработчиков, а вот промежутки между задачами особо никак не проверишь. Некоторые вещи просто стоит порой протыкивать вручную. И это на мой взгляд самое важное. Конечно лучший вариант - когда есть и ручное, и автоматизированное тестирование, но даже когда оно только ручное - это уже хорошо.
Плюсом будет также нагрузочное тестирование.
9. Код
Прежде всего - должны быть выбраны современные технологии. Чтобы никого не обидеть, скажем так: версии фреймворков, библиотек, интерпретаторов/компиляторов не должны быть древними, соответствовать современным тенденциям. Пример (февраль 2024):
PHP 8 - норм, PHP 7 - устаревший.
Node 16 норм, Node 13 - устаревший.
Если есть экспертиза - можно проверить, есть ли архитектура в приложении и современная ли она.
Тесты должны быть.
Проверьте любой файл - насколько он читабелен, есть ли комментарии. Eсли есть экспертиза - можно взглянуть поглубже (SOLID, принципы проектирования).
Есть ли линтеры.
Если фронтенд должен индексироваться - очень желательно SSR.
Документация - как устроено приложение. Я предпочитаю диаграммы классов (вообще все UML диаграммы мне симпатичны), но подойдут и другие популярные способы представления информации.
10. Техническое соответствие
Техническое соответствие: тут убедитесь в соблюдении требований к хранению данных, использовании куки с предупреждением и согласием пользователя, выполнении требований компаний-партнёров (например таких, как обязательное логирование операций).
Безопасность: Проверки на уязвимости и сканирование кода на наличие потенциальных угроз (можно прямо в Gitlab сделать отчет или воспользоваться другими инструментами).
Логирование: очень полезно будет иметь инструмент мониторинга и логирования. Например, Sentry. Это будет очень полезно когда продукт выйдет на пользователей и посыпятся непонятные ошибки.
Производительность: Тесты на скорость загрузки и отклика системы, особенно важны для фронтенда.
Совместимость с браузерами и устройствами: беглая проверка отображения и функционала на разных устройствах и в браузерах.
Доступность (Accessibility) и SEO: Убедиться, что продукт доступен для пользователей с ограниченными возможностями, сделать SEO проверки или проверить отчет
11. Итоговая таблица
Критерий | Балл | Чек |
Есть документация процессов | 2 | |
Есть методология разработки | 4 | |
Методология соответствует описанию | 4 | |
Есть система управления проектами | 5 | |
Система управления проектами соответствует методологии | 5 | |
Фичи структурированы по эпикам и сторям | 4 | |
Описание задач полное и четкое, с скоупом тестирования | 5 | |
Есть интеграция с репозиторием | 4 | |
Планы в СУП соответствуют требованиям | 3 | |
Репозиторий - есть фичи веток | 4 | |
MR - полное описание | 4 | |
MR - в коммитах указан номер задач | 4 | |
MR - есть дискуссии и аппрувы | 4 | |
MR - есть пайплайн | 4 | |
MR - в пайплайне есть сборка, линтер, тесты | 3 | |
Состав команды - полный | 2 | |
Есть релиз план | 2 | |
Есть Continuous Deployment план | 2 | |
Есть план для управления hotfixes и emergency releases | 2 | |
Есть диаграммы развертывания | 1 | |
Развертывание соответствует сложности проекта | 2 | |
Есть ручное тестирование | 3 | |
Есть автотестирование | 2 | |
Есть нагрузочное тестирование | 1 | |
Код - технологии новые | 4 | |
Код - есть архитектура | 2 | |
Код - читабельный, соответствует принципам проектирования | 3 | |
Код - есть линтеры | 2 | |
Код - есть документация | 3 | |
Техническое соответствие - выполнены юридические обязательства (логирование, предупреждения,требования к безопасности) | 2 | |
Есть система логирования ошибок | 2 | |
Безопасность - минимум потенциальных угроз | 2 | |
Производительность - быстрая загрузка и отклик | 2 | |
Работает в нужных браузерах | 1 | |
Accessability и SEO | 1 |
Выводы
Спасибо всем, кто прочитал до конца! Надеюсь данный материал был вам полезен. Делитесь своими критериями проверки проектов!
