Подписаться
Читать в телеграм
Опыт показывает, что обычно наименее подвержены изменениям сроки разработки, а наиболее гибкой частью являются предметная область и требования. Эти обстоятельства и диктуют правила, по которым ведется разработка. В ее ходе мы решаем несколько задач. Первая – это выявление требований заказчика, их структурирование и последующее описание предметной области, зачастую новой для нас. Вторая задача – это собственно разработка, которую можно разделить на проектирование и непосредственно программирование. При этом разрабатываемую систему необходимо интегрировать со смежными системами, разработку нужно вести с учетом языков и фреймворков, принятых у заказчика, придерживаться принятых им методик интеграции. И третья – обеспечение качества и тестирование. Это самая наглядная, наиболее видимая заказчику часть, т.к. именно команда тестирования дает добро на выдачу системы, обеспечивает качественное покрытие тестами, выявляет альтернативные сценарии, возможно, ускользнувшие от разработчиков и аналитиков. Таким образом, исходя из задач проектная команда обычно состоит из аналитиков, разработчиков и тестировщиков. Есть также группа управления, которая включает в себя менеджера проекта и архитектора.
Три кита и одна черепаха
Разработка зиждется на трех китах: управление требованиями, разработкой и тестированием. Все это стоит на большой черепахе – на планировании.
Стоит сказать, что жизненный цикл проекта начинается задолго до старта программирования: еще на этапе пресейла мы выполняем предварительную аналитику, фиксируем основные задачи, которые необходимо решить.
В начале проекта аналитики погружаются в предметную область и описывают задачу с помощью так называемых «постановок» – описаний того, что нужно сделать. Наш основной инструмент на этом этапе – Atlassian Confluence. Это удобное средство для управления большим объемом информации. Говоря по-простому, Confluence позволяет создавать страницы с отформатированным текстом и совместно его редактировать. Для каждого документа ведется история изменений, для обсуждения предусмотрена система комментариев. Страницы можно иерархически организовывать, группируя, например, по функциональным областям проекта, по вехам и т.д.
Чуть позже начала анализа стартует проектирование, архитектор (он же главный конструктор) определяет основные технические решения, выбирает платформу, фреймворки, библиотеки и составляет спецификации. Основными инструментами для него являются все тот же Atlassian Confluence и Visual Paradigm. В Confluence архитектор описывает принятые решения и проставляет прямые и обратные ссылки на «постановки» аналитиков, таким образом, всегда можно понять, как ГК собирается реализовывать то или иное требование и какие требования затрагивает определенное проектное решение. Для проверки своих решений архитектор проводит Design Review: встреча объединяет участников его проектной команды, а также архитекторов и ведущих программистов других проектов, реализуемых у заказчика. Представление решения участникам имеет целью выявить неучтенные факторы, неоптимальные подходы и т.д.
После появления первых проектных решений мы приступаем к самой разработке. Проектные решения детализируются на спецификации, заводятся задачи в Atlassian Jira. Ссылки на задачи по разработке мы проставляем в проектные документы в Atlassian Confluence, благодаря тому что Confluence и Jira интегрированы, при открытии проектного решения мы всегда видим, в каком состоянии находятся задачи. Также стоит сказать, что для управления исходным кодом используется Git, в качестве централизованного сервера репозиториев – GitLab.
Каждую задачу мы разрабатываем в отдельной ветке Git, названной по имени задачи из Jira, что позволяет легко соотносить изменения с требованиями. Комментарии в commit также содержат номер задачи, чтобы коммиты отображались в Jira Worklog. Выполненные задачи переносятся (мержатся) в ветку development, а оттуда – в момент релиза – в ветку master.
Рис. 1. Модель ветвления Git
Немаловажным фактором в достижении качественного результата разработки является тестирование, особенно автоматическое. Автоматические тесты у нас разрабатывают как программисты (unit-тесты), так и тестировщики (с использованием, например, Cucumber), в качестве сервера интеграции и непрерывной сборки мы используем Jenkins.
После сборки и тестирования артефакта он выкладывается в репозиторий Artifactory, откуда его забирает команда тестировщиков для проведения функциональных тестов.
Протестированный релиз, не содержащий критических и важных дефектов, выдается заказчику. Обязательный документ, сопровождающий каждый релиз, – это Release Notes. В нем мы указываем исправленные дефекты, найденные в предыдущих релизах, а также новые возможности системы.
Один из основных критериев успеха проекта – поставка в срок, поэтому мы планируем дату завершения фазы активной разработки на неделю-две (в зависимости от сложности проекта) раньше даты поставки и в это «промежуточное» время проводим стабилизацию — несколько раундов тестирования и исправления выявленных дефектов.
Вопросы коммуникации
Стройный порядок вещей – аналитика, проектирование, разработка, тестирование, поставка – иногда может нарушаться по разным причинам. Самые тяжелые по последствиям случаи – это ошибки в аналитике со стороны как исполнителя, так и заказчика. Они тянут за собой перепроектирование, новую разработку, новые тест-планы, тестирование. Поэтому очень важно как можно более полное погружение аналитиков в предметную область, тщательное ведение реестра требований, отслеживание их изменений и отражение этих изменений в архитектуре приложения. Лет 7 назад на одном из проектов наш аналитик провел очень большую работу, предоставил user stories, описал предполагаемое поведение пользователей при работе с разрабатываемым решением, но при этом неверно проработал внутренние процессы (т.е. процессы, происходящие в системе, скрытые от конечного пользователя). Ошибка была замечена при презентации будущего решения заказчику. Правило представлять алгоритм наших будущих действий и общее видение системы представителям заказчика до начала самой разработки позволило избежать существенных проблем на проекте. Мы заново провели аналитику, изменили архитектуру решения и разработали систему в срок.
Тесная коммуникация внутри проектной команды вообще является одним из важнейших условий создания качественного продукта. Поэтому на каждый проект создается чат в Skype, почтовый список рассылки: мы обсуждаем новые требования заказчика, архитектурные решения и т.д. Кроме того, проводятся ежедневные или еженедельные встречи – статусы, на которых команда определяет, что выполнено, ставит задачи на следующую неделю, корректирует планы. Но и в этих мероприятиях важно соблюдать баланс: например, в одном проекте менеджер устраивал ежедневные статусы по Skype на час-полтора, что в итоге начало тормозить рабочий процесс. По согласованию с заказчиком мы перешли на более эффективные встречи меньшими группами, общий статус собирался раз неделю.
***
Мы используем описанные правила и подходы уже не первый год, и за это время они зарекомендовали себя в целом пуле наших проектов. В других статьях нашего номера мы подробно описываем примеры подобных кейсов.
