Каковы извлеченные уроки проекта?
Извлеченные уроки – это ключевой – как положительный, так и отрицательный – опыт, накопленный на протяжении всего жизненного цикла проекта, а также по его завершению. Размышляя об этих знаниях и понимании, вы можете преобразовать полученные знания в действия, необходимые для улучшения текущих систем и процессов и обеспечения успеха будущих проектов.
Для некоторых организаций уроки, извлеченные из управления проектами, представляют собой неформальный процесс, в ходе которого они обсуждают и документируют опыт проекта на этапе закрытия. Другие организации проводят занятия по извлечению уроков в конце каждого этапа проекта. Менеджеры проектов, члены проектных групп, а также руководители групп могут участвовать в сеансе извлечения уроков, чтобы просматривать отчеты и принимать решения о том, как преобразовать полученное понимание в действия.
Занятия по извлечению уроков могут проводиться на разных этапах проекта в зависимости от его сложности; в конце каждого этапа, при завершении проекта или в режиме реального времени.
Почему извлеченные уроки должны быть неотъемлемой частью управления проектами
В конечном итоге извлеченные уроки могут оказать реальное влияние на процессы компании и работу команд.
Процесс извлечения уроков
Процесс извлечения уроков включает пять этапов. Они направлены на получение важных уроков, извлеченных в ходе проекта от участников встречи, и на определение того, как успешно применить эти знания для достижения лучших результатов в будущих проектах. Шаги:
Процесс извлечения уроков (Нажмите на шаблон, чтобы отредактировать его онлайн)
Определить извлеченные уроки
Начните с пересмотра того, что пошло хорошо, а что не очень хорошо в ходе проекта, который вы только что завершили, и что необходимо улучшить. Это должно быть сделано во время сеанса извлечения уроков, в котором принимают участие ключевые заинтересованные стороны проекта.
Вы можете использовать подобную диаграмму, подобную приведенной ниже, для записи отзывов и ключевых моментов, обсуждавшихся во время сеанса.
Шаблон «Извлеченные уроки» (Нажмите на шаблон, чтобы отредактировать его онлайн)
Задокументируйте извлеченные уроки
Следующим шагом процесса является документирование результатов в подробном отчете. Он должен включать отзывы участников о сильных и слабых сторонах проекта и рекомендации по улучшению.
Проанализируйте извлеченные уроки
На этом этапе процесса проанализируйте и систематизируйте извлеченные уроки, чтобы определить, как их применить. Затем принимаются решения о необходимом обучении сотрудников и усовершенствовании процессов управления проектами.
В качестве дальнейшего шага вы можете создать план действий с указанием необходимых шагов, ответственных сторон/отделов, ресурсов и сроков.
Шаблон плана действий (нажмите на шаблон, чтобы отредактировать его онлайн)
Архивируйте извлеченные уроки
Обратитесь к документам, посвященным извлеченным урокам, для улучшения текущих процессов проекта. Оптимизируйте возможность поиска этих документов, создав папки для каждого типа проектов и правильно упорядочив их по дате или названию проекта. Если инструмент, который вы используете для хранения отчетов, предлагает возможность поиска по ключевым словам, любому будет намного проще их получить.
Построение организационной структуры разработки команды
Одной из известных особенностей микросервисной архитектуры является независимая (по крайней мере до этапов интеграционного тестирования) параллельная разработка различными командами разработки. И это действительно так. Разделив решение по набору сервисов, можно получить результат от команды разработки артефактов в виде сборки, которые должны работать совместно, т.к. они заранее заключили договор о контракте. Но каким образом принять решение, сколько должна быть команда, какие компоненты какая из команды должна создать? Т.е. иными словами по какому принципу построения команды.
Задачу команды можно определить, как задачу создания эффективной организационной структуры. Предлагаю оценить эффективность орг. структура с точками зрения следующим образом:
Предлагаю изменить примеры, какие были случаи, когда орг. структура была сохранена в соответствии с принципами выше:
Допустим, в нашем расширении имеется набор компонентов, которые обеспечивают достаточное количество технологических функций и могут использоваться другими сервисами.
Например, аутентификация, авторизация, ОТР, нотификация, сервис замены и валидации мобильных документов, оркестратор, инструменты для разработки форматно-логических контролей и другие.
По каким-то причинам набор данных сервисов назван командой разработки архитектуры платформенными сервисами. А у менеджера, отвечающего за проект, по каким-то причинам возникает желание создать команду разработки, которая будет называться Платформа.
Допустим, что команда разработки Платформы должна разработать несколько десятков компонент. Чтобы разработать эти компоненты, требуется несколько десятков человек. Т.е. по сути команда Платформы не будет устойчива, т.к. см. критерий №1 выше. Также у команды Платформы будет несколько заказчиков, например, департамент информационной безопасности в части аутентификации и авторизации, операционный департамент в части инструментов разработки форматно-логических контролей и нотификаций. Что вступает в противоречие с критерием №5. Поэтому лучше сделать несколько отдельных команд разработки технологических или платформенных компонент.
Возможно, есть что-то, что объединяет каким-то образом данные команды разработки «платформенных» компонент? Если посмотреть на зависимости, то от команд, включенных в понятие Платформы, зависит работа менее технологических сервисов. Будем называть такие сервисы бизнес сервисами. Напротив, команды разработки платформенных компонент практически не зависят от других команд разработки. Также от стабильности компонент Платформы и от частоты изменения артефактов Платформы зависит скорость реализации проекта. Например, если компонент, отвечающий за аутентификацию нестабилен, и часто не работает аутентификация на среде интеграции, то выполнение интеграционных тестов может быть заблокировано.
На практике это означает, что для разработки данных компонент стоит привлечь наиболее квалифицированных разработчиков. А с точки зрения дорожной карты работ, разработка требований, архитектура, разработка компонент и стабилизация компонент должна идти с некоторым опережением относительно планов разработки бизнес сервисов.
Также можно вспомнить закон Конвея, который говорит о том, что организационная структура может влиять на архитектуру решения. Например, с выделением Платформы в отдельную организационную единицу потребуется при появлении новых фичей и компонент решать вопрос, является ли компонент платформенным, или нет. Кажется, что вопрос искусственный. На самом деле часто достаточно сложно провести четкую границу и разработать критерии “платформенности”. Как следствие, архитектурные границы при выделении отдельной команды Платформы могут проводиться, повторяя организационную структуру. С этой точки зрения лучше работает более плоская орг. структура, когда все команды разработки одинаковы по значимости, нет избыточных слоев иерархии или группировок команд. Таким образом есть возможность избежать решения вопросов, которые при правильной организации не будут возникать.
Представьте решение, в котором обработка запроса проходит несколько слоев системы: сначала запрос обрабатывается слоем адаптеров, далее запрос обрабатывается слоем бизнес логики. Архитекторы специально выделили эти слои, исходя из требований Заказчика.
Для обработки каждого типа документа для разных линий бизнеса разрабатывается сервис-адаптер и сервис, реализующий бизнес логику. Каждый сервис адаптера выполняет меппинг объекта внешнего API на внутреннюю структуру DTO объектов системы при передаче запроса в сервис бизнес логики.
Давайте представим, что мы принимаем решение разделить команды не по бизнес процессам и типам документов, а по технологическим слоям. Точно так, как архитекторы отразили в архитектурном решении. Например, мы обосновываем наше решение следующим образом: в случае организации команд по бизнес направлениям есть риск сделать сильно связанные компоненты – сервис адаптера и сервис бизнес логики.
В данном случае можно сказать, что данная орг. структура неэффективна с т.з. критерия №2. Даже при простом изменении есть большая вероятность, что кол-во коммуникаций между данными командами будет существенным.
Также, с т.з. критерия №3, данные команды по сути решают одну и ту же бизнес проблему, реализуют те же требования, для одного и тоже бизнес Заказчика. В этом смысле данная организация команд не идеальна.
Требования реализовывались бы эффективней, если бы мы разделили команды не по принципу слоев, а по принципу бизнес направлений, бизнес доменов.
Обычно команды, которые разделены по принципу бизнес направлений или бизнес доменов, работают на конкретного заказчика, могут доставить самостоятельно изменения до прода при необходимости решить конкретную задачу домена, мы называем стримами или бизнес стримами.
Данные примеры взяты из реальных проектов. Какие выводы я сделал из данных примеров и из проектного опыта?
Во-первых, желательно, чтобы орг. структура с точки зрения команд разработки оставалась плоской, без лишних иерархий или группировок. Если не очевидно, как лучше поступить с точки зрения команд разработки, то можно начать с выделения отдельной команды на том же уровне иерархии.
Во-вторых, архитектурные границы и границы ответственности команд не обязательно должны совпадать.
В-третьих, метод группировки и команд и компонент по доменам, по направлениям бизнеса, как правило оказывался достаточно эффективным при прочих равных.
В-четвертых, структура управления командой разработки должна быть выровнена с орг. структурой бизнеса. Чтобы упростить, сократить кол-во коммуникаций, сделать их более эффективными. У команды разработки должен быть куратор (Владелец продукта) со стороны бизнеса.
Оценка и планирование проекта
Каким образом выполнить оценку затрат на выполнение работ по разработке и запуску в эксплуатацию решения? Есть ли какие-то работы, или затраты, которые нужно учитывать при планировании и оценке?
Часто Заказчик требует выполнить работающий прототип системы еще на фазе выбора подрядчика, чтобы исключить тех Разработчиков, которые не обладают достаточной экспертизой в технологиях, а также проверить способность Разработчика организовать работы. Этап создания прототипа поможет детально разобраться в требованиях и попытаться выполнить меппинг на будущие компоненты системы, которые либо будут представлены в прототипе, либо в целевой системе.
В любом случае сначала нужно вооружиться подходом Domain Driven Design, определить ключевые бизнес области и сущности. Создать предварительную архитектуру решения, разбить на компоненты, оценить связи между ними. После чего наложить нефункциональные требования на полученную компонентную модель и подумать над отказоустойчивостью, масштабированием, кол-вом зависимостей, развертыванием и сопровождением решения. Далее уже можно приступить к верхнеуровневой оценке трудоемкости разработки, тестирования, интеграционного тестирования, UAT и т.п. Вряд ли можно ожидать от экспертов, что оценка работы будет выполнена с точностью, превышающей 50%, потому что слишком много факторов будут влиять на объем работы, о которых будет сказано ниже.
Исходя из кол-ва микросервисов можно также оценить затраты на инфраструктуру для обеспечения процесса разработки и тестирования. Допустим мы определили, что у нас будет несколько десятков микросервисов. Выбрали модель бранчевания Git-flow с релизными ветками, чтобы обеспечить стабильность компонент. Также определили какие окружения вам нужны для процесса разработки. Допустим у каждой команды разработки будет по 2 нейсмпейса с двумя разными ветками. На одном неймспейсе выполняется Дев тестирование, на другом выполняется стабилизация релиза командой разработки. Можно сделать грубое допущение, что каждый контейнер при развертывании и запуске в опершифте потребует 500Мб оперативной памяти. Плюс потребуются ресурсы для нод самого опеншифта. Б Д и Кафку логично развернуть отдельно, за рамками опеншифта с целью экономии ресурсов и более стабильной работы данных компонент. Плюс необходимо учесть место под хранение логов, трейсов Zipkin. Это только дев-тест окружение. Еще как правило нужно создать окружения интеграционного тестирования, UAT, stage (тестирование развертывания, тестирования работоспособности релиза непосредственно перед деплоем в прод), среду нагрузочного и стресс тестирования. Не забыть про сервера обеспечения процессов CI/CD, DevOps: сервер сборки, сервер хранения артефактов, сервер статического анализа кода, сервер выполнения Unit и интеграционных тестов. В принципе, среды разработки могут быть развернуты в облаке, например в AWS. Стоимость ресурсов AWS известна, можно примерно посчитать сколько получится.
Оценка затрат на тестирование
Если мы допустим, что будем следовать подходу contract first (а как иначе?), постоянно интегрировать решение, все равно, существенные затраты будут лежать в области валидации сквозных сценариев, разбора ошибок, анализа в каком из сервисов возникла проблема и т.п. Чем больше сервисов, тем больше точек интеграции, тем больше затраты на тестирование. Можно точно сказать, что потребуются бОльшие по сравнению с монолитом затраты на интеграционное тестирование и стабилизацию решения в целом. Не важно, как вы это будете делать: автоматизируете сквозные сценарии и будете поднимать экземпляры сервисов при помощи test-containers, используете подход consumer driven contract (например, используя библиотеку pact), либо создадите команду ручного интеграционного тестирования, т.к. автоматизация пока еще не успевает за ходом разработки контрактов. В любом случае нужно будет тратить ресурсы на интеграцию сервисов, ресурсов нужно больше, чем при разработке монолита. Не только по причине больших затрат на разработку и выполнение интеграционных сценариев, но из-за усилий на анализ проблем и на исправление.
Сбор данных от команды проекта
Аналогично опроснику для заказчика, можно сделать опрос членов проектной команды. Здесь можно задать больше вопросов и попросить более детальную информацию. Эксперты предлагают следующий список вопросов для внутреннего опросника:
Для простоты можно шкалу оценок сделать аналогичной клиентской, от 1 до 10.
Процессы и подходы
В данном разделе хотелось бы поделиться некоторыми наблюдениями, практиками и открытыми вопросами в области построения и внедрения процессов разработки с учетом особенностей, которые накладывает микросервисная архитектура.
Разработка и тестирование
Основной вызов в проектах, в которых мне приходилось участвовать, находился в области валидации корректной работы интеграционных сценариев и постоянной интеграции микросервисов. Можно разработать отдельные микросервисы достаточно быстро и качественно, создав набор Unit-тестов для валидации работы отдельного сервиса. И уже на этапе прекоммита путем запуска CI-процедур валидировать качество кода отдельного сервиса путем запуска unit-тестов.
Но как выстроить процесс постоянной интеграции в проекте с сотней сервисов и нескольким десятков команд разработки? Каким образом не допускать проблем интеграции, ошибок в API или выявлять ошибки на самом раннем этапе? Хотелось бы сразу заметить, что если отпустить каждую команду разработки на время, сказав, что мы встретимся через месяц или 2 на этапе интеграционного тестирования, то скорей всего, этап интеграционного тестирования просто невозможно будет измерить во времени. Лучше спланировать работу таким образом, чтобы как можно чаще компоненты развертывались на среде интеграционного тестирования и регулярно выполнялись интеграционные сценарии. По крайней мере не реже чем раз в спринт.
Хотел бы перечислить ниже те подходы, которые работали хорошо. И это не значит, что нельзя сделать еще лучше.
1. Contract first. Интеграция на уровне контрактов
Разработка начиналась с фиксирования контрактов и тестов работы контрактов. Команды описывали контракт применяя подход OpenAPI, делали коммит в репозиторий с API, включая примеры запросов и ответов. Далее разрабатывали интеграционный сценарий, выполняли совместное ревью контрактов и сценариев. Тем самым снижались риски получения дефектов на среде интеграционного тестирования. Разработка начиналась с разработки API на mock-ах с валидацией работы контракта на общем окружении. Это касается и REST API между бэком и фронтом, и API для межсервисного взаимодействия (например, разработки Feign Client), и передачи сообщений kafka.
Думаю, стоит немного уточнить, что здесь называется контрактом. В данном случае контракт – это не только структура и набор полей в json, описывающий передаваемый DTO, это еще и контракт в части типов полей, примеров заполнения полей и самое главное, описание ожидаемого поведения одного компонента от другого компонента.
Каким образом описать ожидаемое поведение с примерами запросов и ответов?
Во-первых, при разработке контракта со стороны сервиса – поставщика контракта прикладывались примеры запросов и ответов. Сам контракт проходил ревью со стороны сервисов потребителей.
Во-вторых, со стороны сервиса, который использует контракт другого сервиса, разрабатывались сценарии. Идеально с использованием Gherkin. А со стороны сервиса поставщика контракта, выполнялось ревью сценариев.
Причем на самом раннем этапе проекта я бы предложил сложить все контракты в 1 репозиторий (да, это напоминает монолит, предлагаю вспомнить совет Мартина Фаулера, “Monolith first”). В разные папки, конечно. С обязательным привлечением к ревью лидов тех компонент, которые потребляют измененный контракт и с привлечением архитекторов для ревью всех без исключения коммитов в части изменения АПИ. В итоге затраты на ревью, некоторые неудобства монолитности единого репозитория с контрактами окупится в дальнейшем меньшим объемом доработок и дефектов. Открытый вопрос, который здесь возникает, в какой момент времени и каким образом нужно перейти от единого репозитория с АПИ к нескольким независимым артефактам. Предлагаю оставить этот вопрос пока открытым.
2. Выполнение DoD проверяется на стенде интеграционного тестирования
Любые демонстрации новых фичей владельцу продукта проводились только на среде интеграционного тестирования. Самые ранние первые релизы ставились на среду интеграции.
Чем раньше команда разработки узнает, что компонент должен развернуться и работать достаточно стабильно не только на стенде разработки, но и на общем стенде, тем быстрей команда начнет заниматься автоматизацией развертывания и учиться проходить установленные для интеграционного стенда критерии качества.
3. Quality gate для установки на интеграционных стенд
Правила развертывания на интеграционный стенд в большей степени повторяли правила развертывания в прод.
Таким образом, можно было выставить критерии качества к процедурам развертывания, к качеству кода для всех компонент, контролировать исполнение и прохождение критериев отдельными командами. Например, правило установки номера версии в соответствии с https://semver.org/ очень помогало выстраивать коммуникации между командами. Если команда, которая использует сервис-поставщика контракта видит, что поменялся номер патча этого сервиса, то значит версия обратно совместима. И если с повышением номера патча контракт перестает работать так, как ожидалось, то, это баг, незапланированное изменение. Нужно либо вернуть обратную совместимость, либо запланировать доработки совместно с сервисами потребителями, либо исправить дефект.
Не секрет, что чем на более позднем этапе выявлен дефект, тем дороже его исправление, дороже иногда на порядки. Отдельные недоработки, отсутствие функциональности на ранних этапах разработки допустимы. Но наличие дефектов, неработоспособность того, что должно работать не ломая интеграционный тест, лучше сразу делать предметом работы над ошибками с целью исправить подход сейчас, чтобы не терять темп в будущем. Причины могут оказаться совершенно разными, например, часто команды под давлением менеджеров торопились, не закончив внутренние тесты или регрессионные тесты, выдавали артефакт на среду интеграции. Поэтому важно контролировать выполнение критериев качества для поставки на среду интеграции. Еще раз повторю, данные критерии должны быть такими, как будто мы ставим артефакт в прод.
4. Привлечение поддержки к интеграции
К поддержке работоспособности стенда, к разбору ошибок на самом раннем этапе привлекались будущие специалисты сопровождения уровней L2, L3.
Это позволяло специалистом сопровождения узнать о решении гораздо больше, чем они могли бы узнать из последующего обучения.
5. Поддержка обратной совместимости
Начиная с определенного этапа разработки, от команд разработки требовалось планировать работы с учетом поддержки обратной совместимости. На каком этапе требовать от команд поддерживать обратную совместимость? С одной стороны, у нас есть контракт, и интеграционные тесты, которые могут не полностью покрывать все сценарии тестирования и все сценарии использования тем более. С другой стороны, есть план работ, и не все фичи, которые могут повлиять на изменение контракта (включая ожидаемое потребителем поведение) еще могут быть разработаны, чтобы достоверно сказать, что контракт уже не поменяется и достаточно стабилен. Обычно, когда успешно прошел первый интеграционный тест между компонентами, и по всем фичам закончен технический дизайн, выполнено ревью контрактов, можно начинать требовать обратную совместимость от сервисов-поставщиков контракта.
6. Отладка и тестирование с возможностью подключения к интеграционному стенду
Хорошей практикой является интеграция среды разработки при отладке и тестировании сервисов-потребителей контракта с сервисами-поставщиками контакта, развернутыми на более стабильной среде (среде интеграционного тестирования). Это позволит, во-первых, снизить затраты на инфраструктуру (не нужно деплоить в среду разработки отдельной команды дополнительные сервисы другой команды). А, во-вторых, командам разработки снизить работы по развертыванию и поддержке на своих стендах сервисов для тестирования, от которых они зависят. Командам разработки компонент, от которых зависят другие компоненты, данный подход привьет культуру выпуска стабильных версий компонент на среду интеграционного тестирования и поддержке обратной совместимости. Это позволяло на раннем этапе выявить возможные нарушения обратной совместимости сервисами-поставщиками контракта. Параллельно экономить ресурсы RAM кластера OpenShifit в контуре разработки.
7. Использование BDD
Имеет смысл использовать BDD для интеграционного тестирования, в частности описывать сценарии в формализованном виде на самом раннем этапе (идеально еще на этапе анализа). Это также означает, что у вас либо уже есть фреймворк автоматизации для конкретной доменной области, либо вы до начала разработки начали создавать сценарии и автоматизировать ключевые слова сценариев (например, описанных при помощи Gherkin). Тогда на последующих этапах можно сэкономить за счет автоматически повторяемых регрессионных тестов, за счет более раннего выявления дефектов.
Еще одно преимущество BDD состоит в том, что если меняются требования и меняется пользовательский сценарий, мы можем уточнить совместно с бизнес анализом перечень формально описанных сценариев тестирования, которые изменятся. Таким образом, с одной стороны сужая требуемый объем тестирования и с другой стороны уточняя скоуп доработок.
Слабой стороной BDD являются предпосылки, при которых этот подход работает. Иначе получится лишь имитация подхода. Это следующие предпосылки:
8. Автоматизация интеграционных сценариев.
BDD подход прекрасно совмещается с автоматизацией интеграционных сценариев.
Если взять интеграционные сценарии и проранжировать их по стоимости автоматизации и по приоритету (например, выбрать сценарий, которые затрагивает наиболее устойчивые компоненты). То очевидно, что можно определить наиболее критичные и самые дешевые сценарии, чтобы запланировать их к реализации в первую очередь либо силами команды автоматизированного тестирования, либо силами команды разработки.
Например, сценарий двухфакторной аутентификации. Этот сценарий затрагивает сразу несколько критических компонент бэка, таких как api-gateway, сервис аутентификации, OTP, нотификаций по SMS. Во-вторых, с точки зрения автоматизации не является сильно трудозатратным, но является переиспользуемым в других тестах.
Имеет смысл также запланировать ночные сборки с последующем запуском автоматизированных интеграционных тестов.
9. Стабильность и доступность интеграционной среды
Желательно определить, какие из компонент должны быть наиболее стабильными, чтобы не пришлось постоянно чинить среду интеграционного тестирования. Возможно, обновление таких компонентов на интеграционной среде будет построено несколько иначе, с большим вниманием к качеству, к подходу к развертыванию и откату. Например, развертывать их в режиме blue green deployment, чтобы не оказывать влияние на большой проект, не вызвать простой проектной команды.
Что работало не очень хорошо или работало, но могло бы работать лучше?
Скорей всего, не работало, потому что мы просто не научились использовать данные подходы и технологии. Тем не менее.
Идея выглядит красиво. И в принципе есть здравый смысл в том, чтобы использовать при тестировании компонента-поставщика контракта тесты, которые написаны компонентом-потребителем контракта. Например, для тестирования интеграции между фронтом и бэком.
Но внедрение подхода и в частности библиотеки PACT требует существенной доработки CI/CD и как, оказалось, необходимы доработки в самой библиотеке, когда нужно сделать реальный интеграционный тест. Т.е. затраты на тестирование с данным подходом превышают затраты на разработку автотестов с использованием более классических подходов.
Конечно важно контролировать зависимости и планировать инкремент продукта. Но не надо ждать пока все разработки будут закончены. Важно интегрировать контракты на как можно раннем этапе.
Стратегия бранчевания
В проектах использовали стратегию бранчевания GitFlow с релизными ветками с небольшими девиациями.
Ревью кода
Возможно это выглядит банальным, но если в проекте больше сотни репозиториев кода, в разработку вовлечено несколько десятков команд разработки желательно установить правила ревью, общие для всех команд.
Очень желательно начать с установки в качестве владельца репозитория кода компонента лидера команды разработки данного компонента. Таким образом фиксируется владелец и персональная ответственность владельца за качество того кода, который находится в репозитории. Установка процедуры ревью в команде, контроль исполнения процедур ревью – это ответственность лидера разработки.
Поэтому было очень странно узнать в одном из проектов, что владельцем репозиториев являются архитекторы, а не лиды разработки. Что приводило к небольшому недопониманию в процессе выдачи прав на репозитории.
Как инструмент для ревью кода обычно в проектах разработки используем Gerrit.
В качестве подхода используется как минимум двухстадийный процесс ревью, с использованием pull request, когда ревью должны сделать 1 или несколько коллег, а вливать код в ветку develop на основании pull request может либо лидер разработки, либо в его отсутствие тот, кто его замещает.
Технический дизайн
Это процесс и одновременно этап в SDLC продукта или отдельной фичи, который позволяет трансформировать архитектурное решение в набор конкретных задач разработки с указанием конкретных подходов, инструментов языка программирования с учетом существующей кодовой базы.
В общем случае в качестве результата работы архитектора можно получить набор схем и диаграмм, отражающих принципиальные связи между компонентами системы.
Чтобы данные схемы и диаграммы превратились в работающий код, требуется сделать дополнительное более детальное проектирование и планирование. Например, уточнить какие классы должны быть созданы или изменены в каких слоях приложения, с каких компонент лучше начать разработку. В этом заключается суть технического дизайна.
Технический дизайн выполняется совместно, как архитектором так и лидом разработки. Как правило , лид разработки готовит тех дизайн, ревью делает архитектор.
В качестве результатов технического дизайна можно ожидать, что будут определены конкретные компоненты, слои внутри компонент, в которых требуется доработка. Будет описаны детали реализации в виде диаграмм классов или API. Будут созданы задачи в джире, оценена трудоемкость и порядок разработки.
К процессу ревью технического дизайна кроме лида разработки и архитектора также подключаются деливери менеджер, лид тестирования и лиды разработки зависимых компонент.
Этапы поставки и контроль качества
Каждая разработка, фича проходит заранее определенные этапы жизненного цикла. При этом качество результатов, получаемых на выходе одного этапа, влияет на качество результатов, которые будут получены на следующем этапе. Возникает задача определения критериев качества артефактов, получаемых на каждом из этапов.
Например, возьмем набор сторей в джире, которые формируют бэклог продукта. Очень желательно определить критерии качества сторей, которые могут быть взяты в следующий спринт командой разработки. Часто такие критерии называются Definition of Ready сторей разработки. Например, закончен ли технических дизайн, выполнены ли оценки, определен ли сценарий демонстрации фичи, определен ли DoD для стори, выполнялась ли командой разработки с привлечением аналитиков и тестировщиков декомпозиция, анализ стори и т.п.
Очень часто приходилось наблюдать, как команды по каким-то причинам не уделяли достаточного внимания разбиению требований на стори, на участие команды в декомпозиции задач стори, на описание того, что же в итоге должно быть сделано. При этом не нужно описывать трактаты в джире. Важно, чтобы каждый участник процесса разработки понял, что должно быть сделано, и ожидаемые результаты зафиксированы в виде чек листа DoD и задач. В противном случае аналитики, архитекторы, разработчики и тестировщики вместо того, чтобы фокусироваться на решении конкретных задач в рамках ограниченного во времени спринта будут пытаться в течение спринта завершить то, что должно быть сделано в рамках предыдущего спринта – завершить анализ или технических дизайн, декомпозировать задачи, отвлекая друг друга.
Еще раз хотел бы подчеркнуть, что если есть вопросы к качеству результатов определенного этапа разработки, то имеет смысл в первую очередь проверить критерии качества артефактов на входе данный этап.
DevSecOps
По статистике CI/CD сервера на одном из проектов с 20-ю командами разработки, которые разрабатывали около 100 микросервисов, ежемесячно в пиковые месяцы выполнялось до 4 тыс сборок, 6 тыс деплойментов (включая среды разработки), 11 тыс прекоммитных проверок, 2.5 тыс посткоммитных проверок и другие задачи. После вывода в опытную эксплуатацию решения ежедневно на продуктивную среду доставлялось до 10-15 hot-fix версий микросервисов. Проект выполнялся бы гораздо медленней и темпы разработки были бы гораздо ниже, если бы процессы CI/CD не были бы автоматизированы. Думаю, что очень большая доля успеха проекта по разработке решения на микросервисной архитектуре приходится на область автоматизации CI/CD процессов, проверок выполнения обязательных шагов процесса, процессов тестирования, проверок соответствия артефактам критериям качества.
Кол-во вызовов различных типов jenkins jobs в CI-CD пайплайнах одного из проектов по месяцам
Для проекта разработки с несколькими сотнями разработчиков и тестировщиков час простоя кластера сред разработки и тестирования, серверов CI/CD стоят несколько человеко недель или даже человеко-месяцев. Поэтому к инфраструктуре сред разработки и тестирования предъявляются соответствующие требования отказоустойчивости, масштабируемости. Обязательно использование средств мониторинга инфраструктуры сред разработки и тестирования.
Интересный случай, который повторялся дважды на двух разных проектах. На ранних этапах проекта, когда не все скрипты по запуску инфраструктуры были отлажены, были попытки со стороны спонсора проекта экономить на ресурсах сред разработки, останавливая кластера разработки в облаке на ночные часы. Однако последующее восстановление работы, прогрев серверов отнимал время команды и в итоге стоимость простоя команды в первый час рабочего дня была больше, чем стоимость инфраструктуры. Экономить на инфраструктуре становилось возможным только когда автоматизация была отлажена.
В тех проектах, где мне приходилось участвовать, использовался акселератор для автоматизации CI/CD. Это специализированная платформа, опробованная на нескольких проектах. Данная платформа разворачивалась в облаке, например, в AWS и/или на серверах. При установке платформы автоматически развертывается кластер OpenShift, SonarQube, Nexus, Jenkins, ELK, Grafana, Kibana, Gerrit, Git, дэшборды для мониторинга и др. компоненты. Из коробки сразу доступны Jenkins-задания для пре-коммитов, пост-коммитов, сборки кода, сборки сервиса в контейнер, задания включают проверки на соответствия процессам ревью кода, стратегии бранчевания, присвоения версии компонента и др. В зависимости от выбранного на проекте подхода и стека устанавливаются инструменты автоматизированного функционального, нагрузочного тестирования, тестирования безопасности. К платформе прилагается стандартные поддерживаемые процессы CI/CD.
Если бы мы не использовали акселератор, то перед выполнением проекта по разработке, следовало бы выполнить проект по созданию инфраструктуры и процесcов CI/CD. На подобный проект может потребоваться еще несколько месяцев.
Постоянное совершенствование процессов
Производство программного обеспечения очень похоже на дискретное производство и многие практики, которые используются в разработке ПО пришли в ИТ из реального производства.
Во-первых, это практика постоянных непрерывных улучшений (Кайдзен). Даже в самом передовом проекте всегда найдется множество вещей, которые можно улучшить.
Для того, чтобы понять, что можно улучшить, ретроспективы с командами просто необходимы.
Во-вторых, это практика бережливого производства LEAN. Практика помогает определить те процессы, которые увеличивают ценность продукта, и сконцентрироваться на улучшении именно этих процессов. Анализ процессов с точки зрения потерь также бывает полезен.
Использование накопленных знаний
В этой главе на самом деле весь смысл существования процесса закрытия проектов. Данный процесс выполняется как раз для того, чтобы можно было извлечь пользу из набитых в процессе работы шишек и вынесенных уроков. Порой выходы из процесса закрытия могут пригодиться в довольно отдаленных направлениях бизнеса, как например маркетинг.
Ответственность за корректное сохранение и возможность переиспользования накопленной информации лежит на руководителе проекта. Он должен быть заинтересован в первую очередь чтобы решения выявленных проблем могли быть переиспользованы в масштабах всей компании. Руководитель проекта (или его коллеги) сам может в будущих проектах снова встретить те же самые проблемы, если в компании не имплементируются своевременно выученные уроки. А если еще и это случится на другом проекте с тем же самым клиентом, получится совсем интересная ситуация.
Здесь можно отметить, что грамотное внедрение и использование приемуществ процесса закрытия в компании как раз хорошо ложится на один из основых принципов Канбан метода – начните с того что есть сейчас и эволюционно улучшайте процессы.
В завершение финальный чеклист для проверки корректности завершения проекта:
Формализация завершения проекта
Финальный отчет заказчику
Отправляем заказчику финальный отчет, включающий:- цели проекта- достигнутые результаты- критерии успешной приемки и завершения (success / exit criteria)- перечень поставляемых компонент и/или адрес где они находятся
Внутреннее информационное письмо о завершении проекта
Часто бывает ситуация, когда о новых проектах информирование сотрудников успешно налажено, а вот о закрытии проектов сообщают редко. В информационном письме перечисляем членов проектной команды, благодарим всех за хорошую работу, можно приложить благодарственные письма от заказчика если таковые имеются. Этим письмом вы уведомляем о высвобождении ресурсов, используемых в проекте (сотрудники, инфраструктура, другие ресурсы). Данное письмо также подводит некую логическую финальную черту для сотрудников, принимавших участие в проектах. Это достаточно важный аспект с психологической точки зрения, сильно влияющий на дальнейшую мотивацию сотрудников – ощутить логическое завершение проделанной работы, услышать благодарность за потраченные усилия и внутренне собраться для следующего этапа/проекта. Адресаты — в зависимости от размера и структуры компании. В небольших компаниях до 250-300 человек, по моему мнению, есть смылс рассылать такие письма на всех. Если больше, можно ограничиться отделом или департаментом, включив туда отделы продаж, маркетинга, руководство.
Архивация проектной документации
Обычная формальность — помечаем как заархивированные пространства в Confluence, архивируем документы на дисках Google, закрываем каналы или группы в используемых мессенджерах, закрываем проект в Jira и так далее.