Lean №5 - Синхронизация

Синхронизация важна для подхода когда нет четкого разделения зоны ответственности членов команды на отдельные области. То есть когда команда совместно делает какую-либо feature. Можно называть это Feature Driven Development, но по сути это общая практика для всего Agile мышления.

Идеи:

1. Для эффективной синхронной работы становится важным общее владение кодом. Потому мы используем git с дешевыми коммитами и merge. Потому мне так нравится GitHub и я готов его оплачивать. За месяц работы в GitHub код систем неожиданно стал публичным - его смотрят, его ревьюят, за него становится стыдно при fails. Хотя раньше был GitLab но в нем это было не интересно. Нужно продолжать вкладываться в коллективное владение кодом - это и качество продукта, и эффективность/скорость разработки.
2. Работа с git сейчас не достаточна эффективна. Возможно стоит найти публичные проекты на GitHub и посмотреть политику коммитов там для примера. Мы наверное сейчас на уровне SHU и нужно не строить свои регламенты, а начать с копирования хороших продуктов. 
3. Один из дешевых способов синхронизации команды - это CI. Красный билд - отличный показатель ошибки синхронизации усилий в части кода. 
4. Получается чем меньше коммит, тем меньше размер chunk, тем чаще синхронизация, тем меньше потерь на решение проблем синхронизации.
5. Чем чаще идет синхронизация веток в git, тем так же меньше потерь на решение проблем. Какой у нас регламент поднятия изменений из develop в feature-ветки? Почему Андрей фиксит тесты в develop, у Славы эти же тесты падают в своей ветки, он так же сам их фиксит, а потом нужно решать конфликты здесь? Почему feature-ветки такие огромные и включают в себя любые изменения которые разработчик решил сделать за время работы над feature, что в результате ни о какой синхронизации не может идти речи? И остается лишь один вариант - впихнуть потом это все в develop, полдня поднимать красные тесты и выдохнуть.   
6. Для синхронизации с внешними системами нужна тестовая система, которая эмулирует работу внешней и позволяет протестироваться интеграцию. Да, SoapUI решает можно проблем, но для эмуляции работы ведомства по межведу нужно было написать простую Web-форму чтобы визуализировать процесс. Это позволило бы протестировать не только протоколы и интеграцию, но и удобство работы с нашей системой по этим протоколам. ЭТО ВАЖНО! Почему мы сами не увидели проблему в межведе с тем что тип ответа должен быть известен заранее чтобы можно было сформировать ответ, подписать его человеком, и хранить для отправки по запросу. А вопрос удобства - это то самое Agile тестирование и Agile-тестировщик.
7. Вопрос интеграции и взаимодействия должен решаться первым чтобы как можно раньше выявить проблемы и риски, синхронизироваться и выполнять внутреннюю разработку компонент или систем независимо.