Как не называй, это абстракция. Ни один из известных мне фреймворков и методов SDLC, а я их, поверьте, немало знаю, хотя бы поверхностно, не реализует водопадную модель.
Я думаю, ровно по тому, что у вас "Agile не тот". Нет понимания что это такое, как работает, почему работает. Можно начать с того, что agile это вообще не процесс, не фреймворк и даже не метод. Это очень высокоуровневые принципы и образ мышления. А дальше идут всякие методы и фреймворки, которые, основываясь на принципах, описывают, как эффективно решать те или эти задачи.
Например, Scrum за своей простотой скрывает очень много. Если не осознать что именно, не прочитать хотя бы пару книг, не пообщаться с теми, кто прошёл уже этот путь, набив шишек, получится "механический скрам" и результат будет разочаровывающий.
Чтобы этот путь пройти, нужно время. По пути будет больно, меняться всегда больно, организации меняться не хотят. Не все доходят. Облегчить путь можно с помощью тренингов, консультантов, менторов. Ну или упорно через боль продираться самим.
Ну а иначе так и получается, "нам скрам не зашёл, мы теперь по канбану работаем, без спринтов". Эта популярная фраза вызывает facepalm как у тех, кто знает Scrum иак и у опытных Канбанологов.
Nexus содержит Nexus Integration Team, но я не понимаю, почему она "подразумевает наличие технических проблем в продукте, которые будет к проблемам с интеграцией между командами, либо неверно сформированным приоритетам".
Эта команда - развитие концепции Scrum of Scrum, они не занимаются сами интеграциями, интегрировать свою работу должны сами Scrum команды. NIT обеспечивает идентификацию зависимостей, координацию, best practices и т.п. Прочитайте внимательно, в Nexus Guide роль NIT описана достаточно чётко.
Второй абзац поддерживаю, "не управляйте зависимостями, устраняйте их". Мне, кстати, Less больше по душе. Но на практике я ни один из них пока не применял, так что из личного опыта ничего не посоветую. Смотрите сами, спрашивайте экспертов, пробуйте.
При почасовой оплате время учитывать, несомненно, надо. Но и тут много подводных камней - точность и честность учёта, нет мотивации повышать эффективность (ну или надо придумывать сложные KPI). Не знаю вашей области, поэтому воздержусь от оценок и советов.
При отсутствии повременной оплаты, учёт времени - чистый демотиватор для персонала. Хотя для менеджмента некоторые задачи упрощаются, тех же целей можно достичь и без таймтрекинга.
И тут то система А должна, по идее задуматься, что же ей, несчастной, делать с этой незаписанной порцией. Ну и писать прикладной обмен данными на голом TCP тот ещё мазохизм сам по себе.
Не изобретайте велосипедов, писать обработку всяких исключений замучаетесь и всё равно случится ещё что-то. А ещё монторинг и кучка других нюансов.
Пока автоматически обратно мерджить обратно не будем. А вот мердж из develop и сборку всех бранчей по коммиту попробуем настроить и посмотрим как пойдёт.
Ну, делать периодически push в origin как раз не сложно. И hudson умеет мониторить и собирать все ветки, с предварительным мерджем с указанной. Не умел бы, я бы и не заморачивался, наверное.
Такой подход имеет право на существование. Но он откладывает все проверки качества до момента возврата ветки в develop. Ну или полагается на то, что разработчик будет периодически подкачивать к себе изменения вручную (ха три раза).
При этом у нас есть железяка, которая всё равно делает ту же работу. Почему не переложить на неё обязанность проверять здоровье ветки как самой по себе, так и при интеграции? И не получить раннее обнаружение потенциальных проблем?
