Замечательно, лишь бы маятник не пошел в другую сторону: без разбора обвинять все новые технологии как игрушки. Нужно действительно думать о применимости технологии с учетом текущего состояния проекта и компании, планов, текущих бизнес и технических задач. И кто-то должен выполнять роль архитектора.
Статья интересноя, но не описано зачем это нужно. Например, в терминах задач: есть такая-то частая задача, раньше неудобно решалась так, теперь удобно решается через новый инструмент. Так можно еще одну написать :).
Например, включение разработчика в новый проект может заключаться в git clone (с простейшей оберткой, если не хочется писать полный URL), echo 127.0.0.1 my.project.ddk >> /etc/hosts, docker-compose up -d. За запуск всего окружения отвечает docker-compose, поэтому фактически ddk расширяет его (тот же post-install скрипт — это настройка ENV переменных для докера). Я бы, на вскидку, просто копировал docker-compose из проекта в проект. Возможно, написал бы генерилку для него из каких-то параметров. Как раз интересно понять почему отказались от такого пути и перешли на текущую схему, насколько это частное/общее решение.
Насколько понимаю вы не используете Realm mobile platform. Как обстоят дела с синхронизацией БД на сервер? Или у вас только локальная БД? Есть какие-нибудь Open Source проекты на эту тему?
Не соглашусь со статьей в целом. Да, интересно почитать какие задачи были в успешных проектах при росте. Но если их решать сразу в начале, то с огромной вероятностью успешного проекта не получится.
В начале идет большое количество изменений (новый функционал, исправленный старый, эксперименты). Если вместо этого пилить ненужный функционал (закладываться на будущее), то не только стоимость ненужного сейчас функционала и задержка нужного из-за занятости программистов тянут проект к банкротству, но и увеличение стоимости любого функционала из-за ненужного.
Например, локализация, когда достаточно одного языка. Или обрезание логов для двух недель, а потребовалось проанализировать поведение пользователей за больший промежуток времени.
Не, это про «Sustained use discounts»: Automatically up to 30%-off workloads that run for a significant portion of the billing month on Compute Engine and Cloud SQL. Google автоматически применяет «оптовые» (месячные) цены. При этом у Amazon и Azure бывают скидки для крупных компаний.
Понятно, что всё еще сыро, ребята из Docker Inc слишком увлекаются фичами и оставляют много багов по сторонам.
Но принципиально смущает ingress load balacing. По сути он обманывает внешний балансировщик. По идее HAProxy должен знать, что не нужно равномерно распределять трафик на 3 ноды, а нужно на 2 и куда запрос пришел, там и остался. Если запросы «тяжелые» и нагрузка относительно железа небольшая, то потенциально можно себе позволить гонять данные через лишние ноды и сеть, но далеко не для всех сценариев такое подходит. Есть механизм обхода этого? Т.е. выбрасывание портов на конкретной ноде только (ну и информирование о списке нодов через какой-нибудь service discovery можно уже внутри контейнера сделать).
Agile — принципы, они перечислены в статье, реализаций множество, они разные в деталях. В самой популярной реализации принципов — Скраме — за формирование из группы людей команды отвечает отдельный человек — Scrum Master. Он вообще не технический специалист.
Сильная команда из ниоткуда — это несистемный подход. Как не потерять (при естественной смене людей время от времени) силу команды? Как сделать вторую сильную команду? Один из системных ответов на эти вопросы — Scrum. Это исключительно организационный фреймворк для формирования «сильных» команд.
В манифесте нет ничего про раздачу задач, поэтому в Agile можно и так, и так. В Скраме да, предполагается, что люди самостоятельно берут задачи. При этом возможны всякие конфликты, которые должен разруливать скрам-мастер.
Если команда различается по компетенциям, то в начале спринта для улучшения планирования можно задачки разбрасывать на людей, которые все равно будут их делать (чтобы посмотреть, что они не перегружены). Задачи, которые может делать больше одного человека не назначаем.
Функционала меньше, чем в Jenkins (это нормально, нужно учитывать):
— нет постоянных ссылок на скачивание последних артефактов (latest, а не номер билда; удобно для скриптов бутстрапа, например)
— вроде бы в последних версиях ручной запуск появился, но нет параметризированного запуска (может и не нужно, можно тот же список серверов забить в файл отдельными ручными работами, но нужно учитывать при проектировании)
— нет работ не привязанных к ветке/репозитарию (из-за этого придется для некоторых вещей сохранить Jenkins)
— нотификации (типа интеграции со слаком) идут вне файла настройки ci
Текущие минусы:
— долго промучился, но команды сборки докера в докере не заработали (ни docker in docker, который не предназначен для систем CI и постоянно в документации Gitlab CI упоминается; ни пробрасывание сокета докера), использую отдельный shell runner для этого.
— кеширует только после успешного завершения работы (например, пока настраиваешь работу каждый раз качает плагины maven)
— медленно (пофайлово?) сохраняет кеш
— нет способа через UI сбросить кеш и посмотреть какие кеши есть. все-таки кеши время от времени приходится сбрасывать
— по ощущениям собирает медленней Jenkins, относительно долго (секунд 15) запускается любая докер-работа с одной командой echo
— нет готового рецепта для Java/Maven, что-то настроил, но еще не все
В этом случае делаются прототипы, чтобы отработать основные сложные моменты. Длительность прототипов фиксирована, а результат нет. В каких-то случаях можно отработать всё, что нужно для проекта в проверяемой области, в каких-то понять сколько еще делать, в каких-то отказаться от изначально выбранного подхода, и запланировать новый прототип по другому принципу.
Естественно, нужно сознаваться клиенту, что для вас это сложная и нестандартная задача. При этом будет вполне заметное время (и затраты компании) на оценку. Ваша бизнес-модель должна учитывать подобные расходы (либо сразу с клиента брать, либо уровень маржи и проценты конверсии из оценки в проект перекрывают затраты и возможные отказы от заказа).
Очень много всего в кучу собрано, немного прокомментирую.
Rails в 2016 году уже далеко не инновационный фреймворк:
1) всё самое интересное реализовали и другие (и это хорошо)
2) многим проектам на rails уже по многу лет (тому же basecamp),
тут не до экспериментов уже, скорость адаптации новых идей значительно снижается
3) веб за это время поменялся, rails зафейлил поддержку этих изменений:
3.1) веб-сокеты — поддержка заявлена, но лично у меня не взлетело за несколько дней, когда было нужно, пришлось по другому делать
3.2) api-only server side — только сейчас выпускают rails 5 с этим, но оно какое-то ущербное
3.3) микросервисы — вроде бы не мешает, но памяти есть слишком много, если дробить на микросервисы
Если хочется инновационности, то это все же в строну ECMAScript (Meteor.com например) и Golang, PHP тут не при чем.
Что все еще хорошо в rails?
1) ActiveRecord — как раз в противоположность твиту выше. Хорошо, когда можно начинать с простого (всё в одном классе), а при необходимости уже рефакторить и выделять новые классы.
2) Синтаксис руби — всё-таки он один из самых чистых/читабельных. Можно долго рассуждать про IDE, но это помогает скорее в наборе кода, а не читабельности.
3) Определенный уровень матёрости. Сейчас уже выработаны best practicies и куча библиотек, много материалов для обучения. Все руби библиотеки хорошо работают с rails, проблем в подключении нет. Проблем с поиском библиотеки под задачу не встречал.
Есть давно известные проблемы:
1) производительность ruby — они всегда были, с нулевых версий rails, но никогда особо не считалось важным
2) сложность установки — сейчас при наличии ансиблов с шефами и докерами острота снизалась
3) острота ножей — требуются лучше, чем хорошие программисты
4) добавьте свое
Приоритет рейлс — дать лучшим программистам лучший (приятный и острый) инструмент для производительной (с точки зрения фич) серверной разработки. Рейлс не подходит для «промышленной» разработки (когда команда состоит из одного регуляра и кучки юниоров). Исходя из отдельных фраз, с чем-то подобным столкнулся и автор статьи (например, не должно быть большого количества манки патчей, что-то они явно не так делали).
Раньше было практически невозможно найти программиста на php (в смысле, именно программиста), а в rails стекались лучшие из php и java. Сейчас уже не так: и в php научились программировать, и в рейлсах слишком много курсов «программист за неделю».
1) Внедрения обычно делаются партнерами, а не самими топ100. В зависимости от сложности платформы это вполне может быть полноценным программированием.
2) Мелкие компании будут появляться со своими продуктами. Больше или меньше — другой вопрос. Крупным проще посмотреть куда идет рынок и купить компанию/продукт, чем развивать с нуля.
Спрос на фичу репликации/кластеризации как раз большой. Ее делают множество около Postgres-контор. Им тоже на что-то жить надо, но от этого не менее печально.
Статья интересная, но непонятно как это отменяет утилы вроде Chef. Докеры пытаются разворачивать в облаке, с переездом экземпляра приложения при падении одного физического сервера на другой. Тут и взаимосвязи сотен сервисов, инфраструктурные сервисы типа DB/smtp/sms и предоставление аккаунтов к ним, сетевой роутинг, масштабирование серисов и т.п. На этом фоне способ конфигурирования приложения и подключения к БД через попытки не принципиален, все равно нужна мощная внешняя инфраструктура конфигурирования и запуска.
Оба вопроса связаны с платформой JS и тем, что TypeScript достаточно тонкая надстройка.
1) импорты появились в ES6, поэтому достаточно TS 1.7 скомпилировать в ES6, а ES6 в ES5. Насколько такая схема сейчас работает с разными видами IDE, систем сборки и версиями TypeScript не скажу.
2) в JS нет приватных переменных, не стали придумывать усложнение, достаточно ошибки сборки
Пока что непонятно за что деньги брать, бесплатные продукты для работы с БД получше. С полной лицензией можно поставить, попробовать, а отдельно покупать непонятно зачем.
Хочется:
1) Подсказки/инспекции как по запросам (неопределенные значения колонок при group by), так и по структуре (длину поля таблицы можно уменьшить до 12 символов).
2) Диаграммы (далеко не факт, что UML) по группе таблиц (непонятно есть или нет поддержка тегов/групп таблиц). Со связыванием не только по foreign key, но и кастомным (с угадыванием по названию поля user_id, например, и с явным указанием).
3) Сравнение структур двух баз.
4) Документирование базы (общий текст, на группы/теги таблиц, на таблицы и колонки) и генерация html-документации.
Пока что это все приходится делать кучкой скриптов по большей части.
Продукт — не проект. Раньше выделяли 2 типа активностей: процессы (постоянная деятельность, например бухгалтерия или работа точки МакДональдса) и проекты (уникальная деятельность, например, открытие точки МакДональдса). Сейчас появилось мнение, что развитие продукта — это ни то, ни другое (постоянная деятельность стратегически, уникальная деятельность тактически). Ближе к проектам, но не то. В продукте важна перспектива и определение направления развития, а не сдача изначального ТЗ в срок/бюджет/качество. Скрам — организационный фреймворк, который показывает как ПМа в продукте можно разделить на Product Owner и Scrum Master, кто за что отвечает при взаимодействии со stakeholders и командой, как вполне эффективно организовать процессы.
Поставка оборудования — это не продукт, тут Скрам не помошник. Более того, Скрам про разработку ПО, а не общую организацию деятельности. А вот если бы выводили новую линейку оборудования на рынок, то можно было бы как-то попытаться приспособить Скрам к этому, но, опять же, скорее к прошивке для оборудования, чем к самому оборудованию (из-за сложности изменения физического производства).
Скрам для продуктов, а не проектов. Если непонятно что на самом деле нужно сделать (требования постоянно меняются, приоритеты задач постоянно меняются, так что непонятно что будет делаться через 2 недели, при этом фиксируются обязательства на итерацию) — скрам идеален. Он тяжело масштабируется, но масштабируется (например, что-то в районе 60 скрам-команд у аэрбэнби, 600 разработчиков за год съедают больше 10М чего угодно).
Немного типичных заблуждений о скраме:
1) Кроссфункциональность — это на уровне всей команды, а не каждого человека. Тестировщик не должен программировать вместо заболевшего программиста.
2) Скрам мастер должен быть выделенным человеком. Лучше всего «девочка» с гуманитарным образованием. Она отвечает за скрам-процессы и климат в коллективе. При это не принимает решений по сути. Идея в том, что не нужно делать из хорошего программиста плохого менеджера или скрам-мастера, а лучше его оставить программистом и взять отдельного человека в отдельную иерархию.
3) Владелец продукта готовит беклог и отвечает на миллиард вопросов ежедневно. Часто у него бывает своя команда. Там аналитики, дизайнеры и прочие маркетологи. Вопрос в том, что скрам не делался для заказной разработки проектов, а делался для длительной разработки продуктов. При заказной разработке владельца продукта и его команду нужно придумывать как отдельную структуру внутри фирмы-подрядчика.
4) Размер беклога не проблема. Проблема его отсортировать в порядке важности/очередности. Это даже хорошо, что заказчик видит, что еще есть что улучшать. Может, дозакажет сейчас или потом.
5) В самом скраме как именно оценивать не говорится. Предполагается, что как-то в чем-то каждый лично оценивает. Причем скрытно от других членов команды. Потом люди, давшие мин и макс оценки обсуждают почему у них такое расхождение. Это просто разная скорость или учтены разные вещи?
6) Разбор проблем на ретроспективе должен идти не поверхностно (покайся Дениска), а на несколько уровней вглубь (как сделать так, чтобы проблема в принципе не могла повториться; например, автодеплой на сервера).
7) Если планы рассыпаются в прах, то либо сработало слишком много рисков и на них заложили меньше времени, либо изначальные оценки были неверными (не разбиты задачи или оценки выполнения задач для senior, а делали junior). Обе проблемы скрам не решает. Скрам решает проблему с тем, чтобы делали именно то, что нужно заказчику, а не что-то другое.
В общем, обычно пытаются запустить скрам без скрам-мастера (выделенного человека без права принятия решений) и владельца продукта (выделенного человека, который постоянно принимает решения по требованиям к продукту), поэтому получается что-то странное.
Если кратко, то не особо это масштабируется. В классическом Скраме есть ограничение на размер команды, но не описано что делать с кучей команд.
Часто делают и описывают примерно так: проект разбивается на микропроекты (сейчас модно называть микросервисами). Внутри них agile, независимые поставки. Взаимодействие между командами определяется иерархией владельцев продуктов/сервисов (с позиции бизнеса) и иерархией архитекторов (с технической позиции). Сюда же можно добавить еще дизайнеров (если в этих сервисах отдельные UI) и других аналитиков. С точки зрения Scrum архитектор (и др.) внутри команды PO. Как уже архитекторы и PO синхронизируют несколько сотен микросервисов — отдельная история вне Scrum.
> 1) Когда и кем должны быть согласованы интерфейсы их модулей? Поясню: зело сомнительно, что собрав в одной комнате тридцать человек можно заставить их о чём-то договориться.
Интерфейс приходит как часть ТЗ. Делается командой PO (архитекторами в ней).
> 2) Когда проводится интеграционное тестирование?
Идеально всегда, по мере готовности сервисов каждый сервис тестирует интеграцию с другими, которые он использует. Это в теорию микросервисов.
> 3) Кто фиксит глобальные косяки продукта, выявленные на этапе интеграционного тестирования или внедрения? По последнему вопросу: каждая группа будет валить друг на друга, не желая рефакторить или переделывать свою часть кода. Как из этой ситуации выйти?
Самый Главный Архитектор решает где и как исправлять. Исправляет соотв. команда.
Дополнительно можно почитать http://agileatlas.org/articles/item/large-scale-scrum-more-with-less и https://www.scrumalliance.org/community/articles/2013/june/scrum-of-scrums-running-agile-on-large-projects.
Например, включение разработчика в новый проект может заключаться в git clone (с простейшей оберткой, если не хочется писать полный URL), echo 127.0.0.1 my.project.ddk >> /etc/hosts, docker-compose up -d. За запуск всего окружения отвечает docker-compose, поэтому фактически ddk расширяет его (тот же post-install скрипт — это настройка ENV переменных для докера). Я бы, на вскидку, просто копировал docker-compose из проекта в проект. Возможно, написал бы генерилку для него из каких-то параметров. Как раз интересно понять почему отказались от такого пути и перешли на текущую схему, насколько это частное/общее решение.
В начале идет большое количество изменений (новый функционал, исправленный старый, эксперименты). Если вместо этого пилить ненужный функционал (закладываться на будущее), то не только стоимость ненужного сейчас функционала и задержка нужного из-за занятости программистов тянут проект к банкротству, но и увеличение стоимости любого функционала из-за ненужного.
Например, локализация, когда достаточно одного языка. Или обрезание логов для двух недель, а потребовалось проанализировать поведение пользователей за больший промежуток времени.
Но принципиально смущает ingress load balacing. По сути он обманывает внешний балансировщик. По идее HAProxy должен знать, что не нужно равномерно распределять трафик на 3 ноды, а нужно на 2 и куда запрос пришел, там и остался. Если запросы «тяжелые» и нагрузка относительно железа небольшая, то потенциально можно себе позволить гонять данные через лишние ноды и сеть, но далеко не для всех сценариев такое подходит. Есть механизм обхода этого? Т.е. выбрасывание портов на конкретной ноде только (ну и информирование о списке нодов через какой-нибудь service discovery можно уже внутри контейнера сделать).
Сильная команда из ниоткуда — это несистемный подход. Как не потерять (при естественной смене людей время от времени) силу команды? Как сделать вторую сильную команду? Один из системных ответов на эти вопросы — Scrum. Это исключительно организационный фреймворк для формирования «сильных» команд.
Если команда различается по компетенциям, то в начале спринта для улучшения планирования можно задачки разбрасывать на людей, которые все равно будут их делать (чтобы посмотреть, что они не перегружены). Задачи, которые может делать больше одного человека не назначаем.
Bus factor — отдельная история.
— нет постоянных ссылок на скачивание последних артефактов (latest, а не номер билда; удобно для скриптов бутстрапа, например)
— вроде бы в последних версиях ручной запуск появился, но нет параметризированного запуска (может и не нужно, можно тот же список серверов забить в файл отдельными ручными работами, но нужно учитывать при проектировании)
— нет работ не привязанных к ветке/репозитарию (из-за этого придется для некоторых вещей сохранить Jenkins)
— нотификации (типа интеграции со слаком) идут вне файла настройки ci
Текущие минусы:
— долго промучился, но команды сборки докера в докере не заработали (ни docker in docker, который не предназначен для систем CI и постоянно в документации Gitlab CI упоминается; ни пробрасывание сокета докера), использую отдельный shell runner для этого.
— кеширует только после успешного завершения работы (например, пока настраиваешь работу каждый раз качает плагины maven)
— медленно (пофайлово?) сохраняет кеш
— нет способа через UI сбросить кеш и посмотреть какие кеши есть. все-таки кеши время от времени приходится сбрасывать
— по ощущениям собирает медленней Jenkins, относительно долго (секунд 15) запускается любая докер-работа с одной командой echo
— нет готового рецепта для Java/Maven, что-то настроил, но еще не все
В целом, удобно, что интегрировано, но еще сыро.
Естественно, нужно сознаваться клиенту, что для вас это сложная и нестандартная задача. При этом будет вполне заметное время (и затраты компании) на оценку. Ваша бизнес-модель должна учитывать подобные расходы (либо сразу с клиента брать, либо уровень маржи и проценты конверсии из оценки в проект перекрывают затраты и возможные отказы от заказа).
Rails в 2016 году уже далеко не инновационный фреймворк:
1) всё самое интересное реализовали и другие (и это хорошо)
2) многим проектам на rails уже по многу лет (тому же basecamp),
тут не до экспериментов уже, скорость адаптации новых идей значительно снижается
3) веб за это время поменялся, rails зафейлил поддержку этих изменений:
3.1) веб-сокеты — поддержка заявлена, но лично у меня не взлетело за несколько дней, когда было нужно, пришлось по другому делать
3.2) api-only server side — только сейчас выпускают rails 5 с этим, но оно какое-то ущербное
3.3) микросервисы — вроде бы не мешает, но памяти есть слишком много, если дробить на микросервисы
Если хочется инновационности, то это все же в строну ECMAScript (Meteor.com например) и Golang, PHP тут не при чем.
Что все еще хорошо в rails?
1) ActiveRecord — как раз в противоположность твиту выше. Хорошо, когда можно начинать с простого (всё в одном классе), а при необходимости уже рефакторить и выделять новые классы.
2) Синтаксис руби — всё-таки он один из самых чистых/читабельных. Можно долго рассуждать про IDE, но это помогает скорее в наборе кода, а не читабельности.
3) Определенный уровень матёрости. Сейчас уже выработаны best practicies и куча библиотек, много материалов для обучения. Все руби библиотеки хорошо работают с rails, проблем в подключении нет. Проблем с поиском библиотеки под задачу не встречал.
Есть давно известные проблемы:
1) производительность ruby — они всегда были, с нулевых версий rails, но никогда особо не считалось важным
2) сложность установки — сейчас при наличии ансиблов с шефами и докерами острота снизалась
3) острота ножей — требуются лучше, чем хорошие программисты
4) добавьте свое
Приоритет рейлс — дать лучшим программистам лучший (приятный и острый) инструмент для производительной (с точки зрения фич) серверной разработки. Рейлс не подходит для «промышленной» разработки (когда команда состоит из одного регуляра и кучки юниоров). Исходя из отдельных фраз, с чем-то подобным столкнулся и автор статьи (например, не должно быть большого количества манки патчей, что-то они явно не так делали).
Раньше было практически невозможно найти программиста на php (в смысле, именно программиста), а в rails стекались лучшие из php и java. Сейчас уже не так: и в php научились программировать, и в рейлсах слишком много курсов «программист за неделю».
2) Мелкие компании будут появляться со своими продуктами. Больше или меньше — другой вопрос. Крупным проще посмотреть куда идет рынок и купить компанию/продукт, чем развивать с нуля.
1) импорты появились в ES6, поэтому достаточно TS 1.7 скомпилировать в ES6, а ES6 в ES5. Насколько такая схема сейчас работает с разными видами IDE, систем сборки и версиями TypeScript не скажу.
2) в JS нет приватных переменных, не стали придумывать усложнение, достаточно ошибки сборки
Хочется:
1) Подсказки/инспекции как по запросам (неопределенные значения колонок при group by), так и по структуре (длину поля таблицы можно уменьшить до 12 символов).
2) Диаграммы (далеко не факт, что UML) по группе таблиц (непонятно есть или нет поддержка тегов/групп таблиц). Со связыванием не только по foreign key, но и кастомным (с угадыванием по названию поля user_id, например, и с явным указанием).
3) Сравнение структур двух баз.
4) Документирование базы (общий текст, на группы/теги таблиц, на таблицы и колонки) и генерация html-документации.
Пока что это все приходится делать кучкой скриптов по большей части.
Поставка оборудования — это не продукт, тут Скрам не помошник. Более того, Скрам про разработку ПО, а не общую организацию деятельности. А вот если бы выводили новую линейку оборудования на рынок, то можно было бы как-то попытаться приспособить Скрам к этому, но, опять же, скорее к прошивке для оборудования, чем к самому оборудованию (из-за сложности изменения физического производства).
1) Кроссфункциональность — это на уровне всей команды, а не каждого человека. Тестировщик не должен программировать вместо заболевшего программиста.
2) Скрам мастер должен быть выделенным человеком. Лучше всего «девочка» с гуманитарным образованием. Она отвечает за скрам-процессы и климат в коллективе. При это не принимает решений по сути. Идея в том, что не нужно делать из хорошего программиста плохого менеджера или скрам-мастера, а лучше его оставить программистом и взять отдельного человека в отдельную иерархию.
3) Владелец продукта готовит беклог и отвечает на миллиард вопросов ежедневно. Часто у него бывает своя команда. Там аналитики, дизайнеры и прочие маркетологи. Вопрос в том, что скрам не делался для заказной разработки проектов, а делался для длительной разработки продуктов. При заказной разработке владельца продукта и его команду нужно придумывать как отдельную структуру внутри фирмы-подрядчика.
4) Размер беклога не проблема. Проблема его отсортировать в порядке важности/очередности. Это даже хорошо, что заказчик видит, что еще есть что улучшать. Может, дозакажет сейчас или потом.
5) В самом скраме как именно оценивать не говорится. Предполагается, что как-то в чем-то каждый лично оценивает. Причем скрытно от других членов команды. Потом люди, давшие мин и макс оценки обсуждают почему у них такое расхождение. Это просто разная скорость или учтены разные вещи?
6) Разбор проблем на ретроспективе должен идти не поверхностно (покайся Дениска), а на несколько уровней вглубь (как сделать так, чтобы проблема в принципе не могла повториться; например, автодеплой на сервера).
7) Если планы рассыпаются в прах, то либо сработало слишком много рисков и на них заложили меньше времени, либо изначальные оценки были неверными (не разбиты задачи или оценки выполнения задач для senior, а делали junior). Обе проблемы скрам не решает. Скрам решает проблему с тем, чтобы делали именно то, что нужно заказчику, а не что-то другое.
В общем, обычно пытаются запустить скрам без скрам-мастера (выделенного человека без права принятия решений) и владельца продукта (выделенного человека, который постоянно принимает решения по требованиям к продукту), поэтому получается что-то странное.
Часто делают и описывают примерно так: проект разбивается на микропроекты (сейчас модно называть микросервисами). Внутри них agile, независимые поставки. Взаимодействие между командами определяется иерархией владельцев продуктов/сервисов (с позиции бизнеса) и иерархией архитекторов (с технической позиции). Сюда же можно добавить еще дизайнеров (если в этих сервисах отдельные UI) и других аналитиков. С точки зрения Scrum архитектор (и др.) внутри команды PO. Как уже архитекторы и PO синхронизируют несколько сотен микросервисов — отдельная история вне Scrum.
> 1) Когда и кем должны быть согласованы интерфейсы их модулей? Поясню: зело сомнительно, что собрав в одной комнате тридцать человек можно заставить их о чём-то договориться.
Интерфейс приходит как часть ТЗ. Делается командой PO (архитекторами в ней).
> 2) Когда проводится интеграционное тестирование?
Идеально всегда, по мере готовности сервисов каждый сервис тестирует интеграцию с другими, которые он использует. Это в теорию микросервисов.
> 3) Кто фиксит глобальные косяки продукта, выявленные на этапе интеграционного тестирования или внедрения? По последнему вопросу: каждая группа будет валить друг на друга, не желая рефакторить или переделывать свою часть кода. Как из этой ситуации выйти?
Самый Главный Архитектор решает где и как исправлять. Исправляет соотв. команда.
Дополнительно можно почитать http://agileatlas.org/articles/item/large-scale-scrum-more-with-less и https://www.scrumalliance.org/community/articles/2013/june/scrum-of-scrums-running-agile-on-large-projects.