Мы — продуктовая организация среднего размера, в которой работает 700 человек, из которых около 100 — технические специалисты, 75 разработчиков (включая потенциальных клиентов и архитекторов), 15–18 QA-специалистов, 7–8 технических менеджеров по продуктам.
У нас есть около 70 позиций в том, что они называют списком ведер проекта, но если бы я действительно классифицировал их, это было бы 10-15 крупных проектов с несколькими подпроектами в каждом ведре.
У нас есть мобильные приложения, веб-сайты, административные веб-сайты, серверные компоненты и взаимосвязанные платформы B2B и B2C с несколькими подкомпонентами на разных языках от Java, .Net, .Net Core, go, php и т. д., при этом некоторые проекты зависят от внешних третьих сторон, начиная от Банки государственным организациям телекоммуникационным компаниям и т. д.
Проблема, с которой я сталкиваюсь, заключается в том, как заставить этих ребят создавать предсказуемые, эффективные и относительно свободные от ошибок проекты.
Я больше не занимаюсь технологиями, но, учитывая мой давний опыт работы разработчиком и архитектором, мне была поставлена задача справиться с этим и получить текущие хаотические и совершенно непредсказуемые превышения и чрезвычайно раздутые сроки для доставки вещей со скоростью, маневренностью, предсказуемостью и качество.
Мы начали использовать Confluence, где мы пишем наши полные BRD/PRD (пользовательские истории и детали), и Jira, где они далее разбиваются на эпики, пользовательские истории, проблемы, задачи и подзадачи.
Эти ребята почти не следят за процессом, как заставить всех быть на одной волне и как заставить менеджеров по продукту подталкивать разработчиков и QA к качественному результату?
Чтобы дать справку, у нас есть 2-3 основных продукта, но больше менеджеров по продукту, потому что слишком много работы над каждым продуктом, и поэтому нам нужна команда для управления данным продуктом.
Некоторая помощь/руководство/волшебная формула будет принята с благодарностью :)
Я бы также добавил, что для изменения масштаба, который вы рассматриваете, вы должны мыслить с малого, начать с одного продукта и одной команды разработчиков, попытаться запустить их, а затем добавлять дополнительные продукты и команды по мере того, как переезд будет внедряться. .
Также подумайте о том, чтобы нанять тренера по Agile, который поможет вам, так как это немалая задача. Обеспечьте спонсорскую поддержку проекта со стороны руководства, так как команды разработчиков могут сопротивляться изменению своего метода работы, часто они не видят проблем со статус-кво.
Наконец, не сдавайтесь, будет много препятствий для преодоления внедрения гибких методов в существующей организации разработки, но если это превратит хаос в порядок, это принесет много преимуществ.
Удачи!
Масштабируемые фреймворки Scrum должны работать хорошо. Вы можете попробовать Nexus, LeSS или SAFe. Нексус мой фаворит.
В общем, масштабировать плохую agile/scrum-команду — плохая идея. Кроме того, ИМО, вы вряд ли сможете быть эффективными без надлежащего использования конвейеров непрерывной интеграции.
Педро
Тодд А. Джейкобс
Ицньютон