[Управление разработкой, Agile, Развитие стартапа, Управление продуктом] Start Up: Организационные и технические аспекты запуска в крупной IT-компании
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Выбор методологии разработки новых программных продуктов зависит от ряда следующих факторов: новизна и новаторство концепции; понимание клиента, что он хочет; понимание поставщика программных продуктов, что хочет клиент. Парадокс заключается в том, что и тот и другой ошибаются с самого начала на этапе формирования идеи. Для того чтобы идея была подтверждена в виде MVP и в дальнейшем развивалась в виде продукта, необходимо выбрать подход и механизмы, направленные на быстрое получение обратной связи от клиента.
В этой статье мы поделимся опытом запуска стартапа в компании — системном интеграторе ОТР2000 с точки зрения выбора и внедрения гибкого подхода к разработке протестированных и
работоспособных программных продуктов.
Продукты стартапа
Для перехода к деталям и особенностям внедрения методологии, необходимо понять результаты данной трансформации в контексте жизненного цикла стартапа. Существуют два основных этапа [1]:
- Поиск жизнеспособной экономической модели продукта;
- Развитие и масштабирование продукта.
Два наших продукта — «ЧАТ СТП» и «ЕЦУ» — прошли первый этап и в настоящий момент имеют дорожную карту развития вплоть до 2022 года. Поставка MVP третьего продукта «Сервисы ИИ» для подтверждения жизнеспособности концепции ожидается к концу 2020-го, после чего будет принято решение о выделении инвестиций для развития и масштабирования.
Теперь по порядку немного о наших продуктах молодого департамента ЦИИ «Центр искусственного интеллекта» в ОТР2000. Продукт «Чат СТП» (неформальное название «Мессенджер»). Данный продукт предназначен для предоставления технической поддержки клиенту в части сопровождения информационных систем в B2B- и B2G-секторе. Мессенджер является дополнительной альтернативой телефонным обращениям и включает в себя кастомизируемый под свои потребности жизненный цикл обработки обращений.
Продукт «ЕЦУ» — единый центр управления (неформальное название «Супервизор»). Идея ЕЦУ — обеспечить омниканальность различных ИС заказчика в одной системе для эффективного управления и получения всей доступной информации в одном инструменте. ЕЦУ является мощным аналитическим инструментом в части сопровождения проектов и информационных систем.
Продукт «Сервисы Искусственного Интеллекта» готовится к выпуску MVP и представляет собой компоненты по категоризации текста по определенным правилам и поиск решений из базы знаний для ускорения предоставления технической поддержки пользователям и снижения трудозатрат.
Результаты продуктовых команд
Нахождение продукта на втором этапе жизненного цикла является интегральной характеристикой с точки зрения общего результата: клиент выделил инвестиции, и стала понятна бизнес-экономическая модель продукта. Чтобы поддерживать интерес клиента к развитию продуктов и тем самым обеспечивать приток инвестиций, мы для себя выявили две основные метрики:
- Короткие релизные циклы;
- Отношение выпущенных фич к новым в бэклоге;
Короткие релизные циклы позволяют быстрее предоставлять клиенту реализованную гипотезу для получения обратной связи в части доставки ценностей и необходимых изменений. Если через пару выпущенных версий клиент понимает, что нужно убрать или изменить определенный функционал, мы, несомненно, делаем это, так как мы не боимся изменений, даже если они поступают в последний момент [2]. Для эффективного управления данными изменениями для наших продуктов налажен релизный цикл, равный в среднем 2 неделям, по результату которого мы выпускаем протестированную и работоспособную версию программного продукта, готовую для установки в продуктивную среду клиента.
Соотношение выпущенных фич с новыми в бэклоге характеризует:
- Интерес клиента к продукту — красная линия на графике. Данная линия характеризует идеи и гипотезы клиента, которые придают уверенность каждой выпускаемой версии в том, что она будет являться более ценной, чем предыдущая. В случае если линия имеет пологий темп роста, необходимо прилагать больше усилий для вовлечения клиента в процесс разработки продукта.
- Уровень мотивации команд — зеленая линия на графике. Если зеленая линия имеет такой же темп роста, что и красная, это говорит о том, что команда понимает цель и ценность каждой версии и стремится успевать за идеями клиента. Если линия пологая, то необходимо приложить усилия в части формирования и развития команды.
- Уровень декомпозиции — в каждой новой версии мы стремимся выпускать от 5 до 8 новых фич, что позволяет нам иметь релизный цикл, равный двум неделям. Если за релизный цикл выпускается одна большая фича, необходимо задуматься о более детальной декомпозиции.
Становление и развитие продуктовых команд
Культурная среда компании является началом проведения трансформации в части новых практик и подходов. В нашем случае компания ОТР2000 является системообразующей IT-компанией, надежно закрепившейся на B2G-рынке с 2000 г., и насчитывает около 4000 сотрудников, географически распределенных по всей России и за рубежом. На протяжении 20 лет компания экспоненциально росла в части поддержки и развития своих продуктов, что отразилось в выстраивании жесткой матричной структуры департаментов управления. Данный выстроенный механизм имеет водопадную структуру, и перед тем как выпустить очередную версию продукта, необходимо пройти фиксированные этапы через департаменты.
- Департамент бизнес-анализа.
- Департамент проектирования.
- Департамент разработки.
- Департамент тестирования.
- Департамент выпуска версий.
Выпуск работоспособной версии может занимать до полугода, и триггером перехода от одного департамента к другому в основном служит установленная форма отчета с большим количеством подписей. В большинстве случаев сотрудники департамента фокусируют деятельность на подготовке отчетов для приемки результатов своей работы смежным отделом дальше по цепочке. С такой культурной спецификой сложно фокусироваться на потребностях клиента и способах их удовлетворения. Более того, существующие механизмы из-за своей инертности не позволяют быстро апробировать идеи и выпускать MVP для новых продуктов на рынок.
В рамках создания молодого подразделения «Центр Искусственного Интеллекта» в ОТР2000 в начале марта, было принято решение апробировать гибкие методики разработки программных продуктов, которые позволяли бы в кратчайшие сроки выпускать работоспособные версии для инкрементного увеличения ценности продукта.
Внедрение гибкой методологии началось с идеологической трансформации восприятия сотрудниками своей роли и ее влияния на общий результат в рамках организационной сущности продуктовой команды. Идея продуктовой команды заключается в способности выводить новые продукты на рынок от стадии задумки до выпуска протестированной и работоспособной версии продукта при наличии всех необходимых функциональных ролей и ресурсов.
В продуктовую команду должны входить «для фуллхауза» следующие роли (сразу стоит отметить, что данные роли может выполнять один человек):
- Владелец продукта — отвечает за содержание бэклога и видение продукта
- UX/UI — отвечает за дизайн продукта и пользовательский опыт
- Архитектор — отвечает за архитектуру продукта и интеграционные вопросы
- Backend-инженер — отвечает за back продукта
- Frontend-инженер — отвечает за front продукта
- QA-инженер — отвечает за работоспособность продукта
- DevOps — отвечает за выпуск продукта
- Скрам мастер — отвечает за коммуникации и развитие продуктовой команды
Становление и развитие продуктовой команды проходило через много этапов, из которых можно выделить следующие основные:
- Первый этап — «Обнуление». На данном этапе все члены команды должны были забыть старые подходы из того времени, когда они работали в больших департаментах, так как от них теперь не требовались бумаги для перехода из одного этапа на другой. Теперь в команде были все необходимые роли для решения открытых вопросов и развития собственных процессов и подходов.
- Второй этап — «Коммуникации». В одной команде сфокусированы все необходимые роли, скрам-мастер внедрил необходимые ритуалы для поддержки процесса разработки выпуска работоспособных версий продуктов, что упростило коммуникации для решения многих проблем.
- Третий этап — «Роль владельца продукта». Данный этап является самым важным, без него команда не сможет сформироваться и дальше начать развиваться. Понимание и принятие роли владельца продукта должна пройти не только на уровне команды, но также на уровне заказчика и компании в целом.
- Четвертый этап — «Роль скрам-мастера». Скрам-мастер не является руководителем сверху, наоборот, принимая все преимущества модели manager as servant, создает и развивает организационные механизмы разработки продуктов таким образом, чтобы команды ни в чем не нуждались и находились в непрерывном росте и развитии.
Ритуалы в продуктовых командах
Под ритуалом понимается периодическое организационное событие, включающее в себя фиксированный состав участников, направленное на синхронизацию участников в части актуальных и приоритетных задач. Более того, ритуалы играют ключевую системообразующую роль развития продуктовой команды, так как задают правила и форматы взаимодействия членов команды.
Мы успешно апробировали и используем следующие ритуалы в рамках 2-недельного релизного цикла:
- Stand Up — ежедневная 15-минутная встреча, на которой каждый участник команды рассказывает об успехе проделанной работы, блокерах и планах на текущий день. В качестве инструмента используется Kanban-доска.
- Release Planning — двухнедельная 2-часовая встреча, на которой проходит планирование очередной версии продукта, где команда декомпозирует пользовательские истории (user stories) на подзадачи и оценивает сроки реализации в «попугаях». В качестве инструмента используется бэклог продукта.
- Demo — двухнедельная 2-часовая встреча которая проводится после выпуска версии продукта с целью демонстрации нового функционала и получения обратной связи от клиента. В качестве инструмента используется протестированная и работоспособная версия продукта.
- Retrospective — 2-часовая встреча, которая проводится после выпуска 3–4 версий с целью анализа организационных подходов и поиска их улучшений. Результатами данной встречи являются конкретные шаги, направленные на улучшение качества и скорости выпускаемой версии.
Ответственным за фасилитацию обозначенных выше ритуалов является скрам-мастер, и в его обязанности входит не только организовать их ритмичность, но и сформировать цели и решаемые задачи в рамках данных ритуалов. Если ритуалы организованы правильно, то задачи решаются последовательно и всегда есть фокус на приоритетных в данный момент вопросах.
Организация CI/CD релизов
В целях организации короткого инкрементного релизного цикла мы внедрили CI/CD-подход. Данный подход заключаются в следующих технических и организационных возможностях:
- CI (continuous integration) — непрерывная поставка инкремента продукта в виде MR (merge requests) в общий репозиторий программного кода командой продукта.
- CD (continuous deployment) — непрерывная компиляция и сборка продукта из общего репозитория программного кода продукта.
Имея данные возможности, продуктовая команда быстрее определяет проблемы и дефекты при очередном CD, а также устанавливает причинно-следственные связи для их устранения. Для продуктов команд ЦИИ мы в среднем имеем 15 МР и 4 деплоя сборки в день. На картинке проиллюстрирован общий организационной подход в рамках внедрения CI/CD в разрезе управления средой разработки для одной из команд. Отображение данного подходя является базовым, что обеспечивает легкость масштабирования на дополнительные команды и смежные продукты.
Название окружения
Назначение
local
Локальная среда разработки отдельно взятого разработчика. В данном окружении разработчик разрабатывает программный код продукта в части только своих, обозначенных задач. По окончании вливает данные изменения ветки /master или /dev в зависимости от выпускаемой версии продукта.
/dev
На среде развития продукта разрабатываются новые фичи (функционал) и происходит непрерывная интеграция изменений в общий репозиторий с дальнейшим разворачиванием очередной версии билда. На данном стенде проводится интеграция компонентов продуктов, а также функциональные, нагрузочные и регрессионные тесты для согласования выпуска версии в PreProd заказчика.
/master
На среде поддержки продукта осуществляется исправление только критических проблем, возникших при эксплуатации ранее выпущенной версии. Перед выпуском на PreProd проводятся только регрессионное тестирование версии.
Стоит также отметить, что разница версии в ветках /dev и /master отличаются на инкремент ровно одной версии. Данный подход позволяет выносить версию в Prod по окончании релизного цикла и не зарываться в деталях и проблемах, выпущенных, например, 2 месяца назад.
PreProd
На данной среде проводятся интеграция и отладка выпущенных продуктов со смежными информационными системами, а также интеграционное и регрессионное тестирование для согласования выпуска версии в Prod-среду. В дополнение на данном стенде проводят демонстрацию нового функционала заказчику и фокус-пользователям.
Prod
На данной среде происходит эксплуатация пользователями выпущенных в релиз продуктов. На данном стенде не проводится тестирование.
Единственным критерием внедрения эффективного CI/CD-подхода является полное прохождение жизненного цикла сборки от локального MR отдельного разработчика до установки версии в продуктивную среду силами одной команды. Ответственным за процесс и работы CI/CD составе команды отвечает DevOps-инженер.
Инструменты продуктовых команд
Существует много моментов, которые мы хотели бы показать в рамках использования и внедрения инструментов разработки продуктов. Однако в этой статье мы лишь подсветим основные инструменты, которые прижились и доказали эффективность:
Управление содержанием — продукты Atlassian (JIRA, Service Desk, Confluence).
Управление CI/CD — Gitlab.
Управление коммуникациями — Discord, Telegram.
Управление развитием команд — Mural.
Интересные лайфхаки при использовании инструментов:
- Управление каждым продуктом осуществляется с помощью двух проектов JIRA:
a. JIRA управления бизнес-требованиями, к которой имеет доступ клиент, генерируя поток новых идей. С использованием данной JIRA заказчик понимает, что TTM (time to market) равно 1 месяц.
b. Производственная JIRA разработки функционала, к которой клиент не имеет доступа, и он понимает, что уровень декомпозиции новых фич позволяет выпускать версии каждые две недели для приемки в разрезе бизнес-требований.
- Для каждого из продуктов настроен свой репозиторий, который исключает зависимость продуктов друг от друга для релиза.
- Мы замкнули все внутренние и часть внешних коммуникационных каналов в одном инструменте. Таким образом обеспечивается легкость управления данными коммуникациями через каналы, и все команды находятся в одном информационном поле.
- С помощью webhooks можно с легкостью настроить нотификацию в дискорде в части бизнес-логики использования JIRA. Например, появилось новое требование для продукта в JIRA, нотификация автоматически появляется в нужном канале для привлечения внимания.
- Инструмент Mural является универсальным, и там много встроенных шаблонов для фасилитации встреч; он является палочкой-выручалочкой для каждого скрам-мастера.
Заключение
В заключении хотели бы отметить, что целью статьи является возможность поделиться результатами запуска и развития стартапа с точки зрения внедрения фундаментальных процессов и подходов для непрерывной поставки ценности в виде инкрементов продукта. Приведенные результаты, достигнутые за 6 месяцев, могут служить определённой метрикой для сравнения. Мы как стартап не останавливаемся на месте и решаем следующие стратегические вопросы в рамках развития:
- Внедрение модели продуктовой разработки в рамках заказной.
- Внедрение организационного и технического подхода в части разработки ядра продукта и слоя кастомизации.
- Внедрение масштабируемого фреймворка SAFe на смежные продуктовые команды, которые являются поставщиками продуктов в других компаниях.
Ссылки на источники литературы
[1] — Стив Бланк, Боб Дорф — Стартап. Настольная книга основателя.
[2] — https://agilemanifesto.org/iso/ru/manifesto.html
===========
Источник:
habr.com
===========
Похожие новости:
- [Развитие стартапа, Бизнес-модели, Финансы в IT] Календарь IPO 2019-2020: от Lyft и Levi’s до акций Coursera и SpaceХ
- [Тестирование IT-систем, Управление разработкой, Биллинговые системы, Управление проектами, Сотовая связь] Новая функциональность без багов, на примере биллинга для мобильного оператора
- [Управление проектами, Управление сообществом, Управление продуктом, Управление персоналом, Карьера в IT-индустрии] Поговорим «по-красному»?
- [Работа с 3D-графикой, Управление разработкой, Фриланс, Управление персоналом, Дизайн] История о том, как я не нашла инженера
- [Контент-маркетинг, Управление продуктом, Управление медиа, Брендинг, Социальные сети и сообщества] Как работает управление репутацией в интернете
- [Управление проектами, Управление продуктом, Брендинг] Разработка бренда в среде lean startup. Часть 1
- [Управление разработкой, Управление персоналом] Почему без тимлида не обойтись: нюансы формирования комплексной команды разработчиков и работа на удаленке
- [Управление разработкой, Управление проектами, Управление персоналом, Карьера в IT-индустрии] Подключайтесь онлайн к «Академии тимлидов» SimbirSoft
- [Карьера в IT-индустрии, Учебный процесс в IT] Практический видеокурс «CI/CD на примере Gitlab CI»: анонс и предзаказ
- [Анализ и проектирование систем, Программирование, Проектирование и рефакторинг, Управление персоналом, Управление разработкой] Человечная декомпозиция работы
Теги для поиска: #_upravlenie_razrabotkoj (Управление разработкой), #_agile, #_razvitie_startapa (Развитие стартапа), #_upravlenie_produktom (Управление продуктом), #_scrum, #_agile, #_startap (стартап), #_ci/cd, #_komanda (команда), #_produktovaja_razrabotka (продуктовая разработка), #_blog_kompanii_otr (
Блог компании ОТР
), #_upravlenie_razrabotkoj (
Управление разработкой
), #_agile, #_razvitie_startapa (
Развитие стартапа
), #_upravlenie_produktom (
Управление продуктом
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:20
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Выбор методологии разработки новых программных продуктов зависит от ряда следующих факторов: новизна и новаторство концепции; понимание клиента, что он хочет; понимание поставщика программных продуктов, что хочет клиент. Парадокс заключается в том, что и тот и другой ошибаются с самого начала на этапе формирования идеи. Для того чтобы идея была подтверждена в виде MVP и в дальнейшем развивалась в виде продукта, необходимо выбрать подход и механизмы, направленные на быстрое получение обратной связи от клиента.  В этой статье мы поделимся опытом запуска стартапа в компании — системном интеграторе ОТР2000 с точки зрения выбора и внедрения гибкого подхода к разработке протестированных и работоспособных программных продуктов. Продукты стартапа Для перехода к деталям и особенностям внедрения методологии, необходимо понять результаты данной трансформации в контексте жизненного цикла стартапа. Существуют два основных этапа [1]:
Два наших продукта — «ЧАТ СТП» и «ЕЦУ» — прошли первый этап и в настоящий момент имеют дорожную карту развития вплоть до 2022 года. Поставка MVP третьего продукта «Сервисы ИИ» для подтверждения жизнеспособности концепции ожидается к концу 2020-го, после чего будет принято решение о выделении инвестиций для развития и масштабирования.  Теперь по порядку немного о наших продуктах молодого департамента ЦИИ «Центр искусственного интеллекта» в ОТР2000. Продукт «Чат СТП» (неформальное название «Мессенджер»). Данный продукт предназначен для предоставления технической поддержки клиенту в части сопровождения информационных систем в B2B- и B2G-секторе. Мессенджер является дополнительной альтернативой телефонным обращениям и включает в себя кастомизируемый под свои потребности жизненный цикл обработки обращений. Продукт «ЕЦУ» — единый центр управления (неформальное название «Супервизор»). Идея ЕЦУ — обеспечить омниканальность различных ИС заказчика в одной системе для эффективного управления и получения всей доступной информации в одном инструменте. ЕЦУ является мощным аналитическим инструментом в части сопровождения проектов и информационных систем. Продукт «Сервисы Искусственного Интеллекта» готовится к выпуску MVP и представляет собой компоненты по категоризации текста по определенным правилам и поиск решений из базы знаний для ускорения предоставления технической поддержки пользователям и снижения трудозатрат. Результаты продуктовых команд Нахождение продукта на втором этапе жизненного цикла является интегральной характеристикой с точки зрения общего результата: клиент выделил инвестиции, и стала понятна бизнес-экономическая модель продукта. Чтобы поддерживать интерес клиента к развитию продуктов и тем самым обеспечивать приток инвестиций, мы для себя выявили две основные метрики:
 Короткие релизные циклы позволяют быстрее предоставлять клиенту реализованную гипотезу для получения обратной связи в части доставки ценностей и необходимых изменений. Если через пару выпущенных версий клиент понимает, что нужно убрать или изменить определенный функционал, мы, несомненно, делаем это, так как мы не боимся изменений, даже если они поступают в последний момент [2]. Для эффективного управления данными изменениями для наших продуктов налажен релизный цикл, равный в среднем 2 неделям, по результату которого мы выпускаем протестированную и работоспособную версию программного продукта, готовую для установки в продуктивную среду клиента. Соотношение выпущенных фич с новыми в бэклоге характеризует:
Становление и развитие продуктовых команд Культурная среда компании является началом проведения трансформации в части новых практик и подходов. В нашем случае компания ОТР2000 является системообразующей IT-компанией, надежно закрепившейся на B2G-рынке с 2000 г., и насчитывает около 4000 сотрудников, географически распределенных по всей России и за рубежом. На протяжении 20 лет компания экспоненциально росла в части поддержки и развития своих продуктов, что отразилось в выстраивании жесткой матричной структуры департаментов управления. Данный выстроенный механизм имеет водопадную структуру, и перед тем как выпустить очередную версию продукта, необходимо пройти фиксированные этапы через департаменты.
Выпуск работоспособной версии может занимать до полугода, и триггером перехода от одного департамента к другому в основном служит установленная форма отчета с большим количеством подписей. В большинстве случаев сотрудники департамента фокусируют деятельность на подготовке отчетов для приемки результатов своей работы смежным отделом дальше по цепочке. С такой культурной спецификой сложно фокусироваться на потребностях клиента и способах их удовлетворения. Более того, существующие механизмы из-за своей инертности не позволяют быстро апробировать идеи и выпускать MVP для новых продуктов на рынок. В рамках создания молодого подразделения «Центр Искусственного Интеллекта» в ОТР2000 в начале марта, было принято решение апробировать гибкие методики разработки программных продуктов, которые позволяли бы в кратчайшие сроки выпускать работоспособные версии для инкрементного увеличения ценности продукта. Внедрение гибкой методологии началось с идеологической трансформации восприятия сотрудниками своей роли и ее влияния на общий результат в рамках организационной сущности продуктовой команды. Идея продуктовой команды заключается в способности выводить новые продукты на рынок от стадии задумки до выпуска протестированной и работоспособной версии продукта при наличии всех необходимых функциональных ролей и ресурсов.  В продуктовую команду должны входить «для фуллхауза» следующие роли (сразу стоит отметить, что данные роли может выполнять один человек):
Становление и развитие продуктовой команды проходило через много этапов, из которых можно выделить следующие основные:
Ритуалы в продуктовых командах Под ритуалом понимается периодическое организационное событие, включающее в себя фиксированный состав участников, направленное на синхронизацию участников в части актуальных и приоритетных задач. Более того, ритуалы играют ключевую системообразующую роль развития продуктовой команды, так как задают правила и форматы взаимодействия членов команды.  Мы успешно апробировали и используем следующие ритуалы в рамках 2-недельного релизного цикла:
Ответственным за фасилитацию обозначенных выше ритуалов является скрам-мастер, и в его обязанности входит не только организовать их ритмичность, но и сформировать цели и решаемые задачи в рамках данных ритуалов. Если ритуалы организованы правильно, то задачи решаются последовательно и всегда есть фокус на приоритетных в данный момент вопросах. Организация CI/CD релизов В целях организации короткого инкрементного релизного цикла мы внедрили CI/CD-подход. Данный подход заключаются в следующих технических и организационных возможностях:
 Имея данные возможности, продуктовая команда быстрее определяет проблемы и дефекты при очередном CD, а также устанавливает причинно-следственные связи для их устранения. Для продуктов команд ЦИИ мы в среднем имеем 15 МР и 4 деплоя сборки в день. На картинке проиллюстрирован общий организационной подход в рамках внедрения CI/CD в разрезе управления средой разработки для одной из команд. Отображение данного подходя является базовым, что обеспечивает легкость масштабирования на дополнительные команды и смежные продукты. Название окружения Назначение local Локальная среда разработки отдельно взятого разработчика. В данном окружении разработчик разрабатывает программный код продукта в части только своих, обозначенных задач. По окончании вливает данные изменения ветки /master или /dev в зависимости от выпускаемой версии продукта. /dev На среде развития продукта разрабатываются новые фичи (функционал) и происходит непрерывная интеграция изменений в общий репозиторий с дальнейшим разворачиванием очередной версии билда. На данном стенде проводится интеграция компонентов продуктов, а также функциональные, нагрузочные и регрессионные тесты для согласования выпуска версии в PreProd заказчика. /master На среде поддержки продукта осуществляется исправление только критических проблем, возникших при эксплуатации ранее выпущенной версии. Перед выпуском на PreProd проводятся только регрессионное тестирование версии. Стоит также отметить, что разница версии в ветках /dev и /master отличаются на инкремент ровно одной версии. Данный подход позволяет выносить версию в Prod по окончании релизного цикла и не зарываться в деталях и проблемах, выпущенных, например, 2 месяца назад. PreProd На данной среде проводятся интеграция и отладка выпущенных продуктов со смежными информационными системами, а также интеграционное и регрессионное тестирование для согласования выпуска версии в Prod-среду. В дополнение на данном стенде проводят демонстрацию нового функционала заказчику и фокус-пользователям. Prod На данной среде происходит эксплуатация пользователями выпущенных в релиз продуктов. На данном стенде не проводится тестирование. Единственным критерием внедрения эффективного CI/CD-подхода является полное прохождение жизненного цикла сборки от локального MR отдельного разработчика до установки версии в продуктивную среду силами одной команды. Ответственным за процесс и работы CI/CD составе команды отвечает DevOps-инженер. Инструменты продуктовых команд Существует много моментов, которые мы хотели бы показать в рамках использования и внедрения инструментов разработки продуктов. Однако в этой статье мы лишь подсветим основные инструменты, которые прижились и доказали эффективность: Управление содержанием — продукты Atlassian (JIRA, Service Desk, Confluence). Управление CI/CD — Gitlab. Управление коммуникациями — Discord, Telegram. Управление развитием команд — Mural. Интересные лайфхаки при использовании инструментов:
Заключение В заключении хотели бы отметить, что целью статьи является возможность поделиться результатами запуска и развития стартапа с точки зрения внедрения фундаментальных процессов и подходов для непрерывной поставки ценности в виде инкрементов продукта. Приведенные результаты, достигнутые за 6 месяцев, могут служить определённой метрикой для сравнения. Мы как стартап не останавливаемся на месте и решаем следующие стратегические вопросы в рамках развития:
Ссылки на источники литературы [1] — Стив Бланк, Боб Дорф — Стартап. Настольная книга основателя. [2] — https://agilemanifesto.org/iso/ru/manifesto.html =========== Источник: habr.com =========== Похожие новости:
Блог компании ОТР ), #_upravlenie_razrabotkoj ( Управление разработкой ), #_agile, #_razvitie_startapa ( Развитие стартапа ), #_upravlenie_produktom ( Управление продуктом ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:20
Часовой пояс: UTC + 5