Так совпало, что в нескольких чатиках прозвучали вопросы о том, как правильно принимать/передавать дела по проекту другой команде. Вариант этого вопроса это “как правильно законсервировать проект?”.

В моей жизни было свыше десятка случаев приема продуктов от другой команды и продолжения дел. Несколько случаев передачи проектов внутри одной компании можно считать очень простыми, но в большинстве случаев это были не очень дружественные поглощения, где исходная команда вскоре распускалась, а под поддержку и развитие продукта формировалась новая. Типовым случаем можно считать доступность исходных специалистов для передачи дел в течении примерно 3х месяцев. После чего - крутись как хочешь, но чтобы все работало.

Для понимая особенностей: размер кодовой базы порядка 1 млн строк, число пользователей (b2b) от нескольких тысяч до нескольких десятков тысяч. Нюанс в нашей области - все продукты коробочные, то есть развертываются на серверах клиентов. Нельзя обойтись нежным “работает - не трогай” на своих машинах - каждый раз надо распространить исправление, его развернут на тысячах самых разных машин чужие люди, и если чего пойдет не так, то будет большой вой.

В силу политических причин, все продукты пришлось передавать два раза. От исходной чужой команды - первой своей, а потом от нее другой своей же.

Массовость породила некое подобие процесса:
1) инвентаризация всех существующих ресурсов для последующего копирования. Понятно, что сюда входит репозиторий кода. Но также и багтракер, и хранилище всех документов, и форум, и чат, и история тикетов , вообще все, что можно найти и что отдадут, дистрибутивы и бинарники. Об этом еще немного позже - но это предельно важный этап. Скажу только, что однажды мы обнаружили, что кусок исходников не был на передан (по недосмотру он вообще никогда не помещался в репозиторий) и нужный компонент нашли в бинарном мусоре перебором разных файлов методом черного ящика. Один из них правильно работал по шифрованному протоколу. Фуууух, пронесло…
2) знакомство; требуем общее описание продукта, его архитектуры и принципов. Из чего вы исходили, когда что-то делали, как оно все должно работать вместе. Детали модулей можно почти всегда выяснить по коду, а вот общие принципы выявить тяжело; На хороший документ в большинстве случаев рассчитывать не приходится - вызываем главного специалиста(ов) на место и он под запись рассказывает
3) инструкция по быстрому старту. как это собрать, запустить и убедиться, что работает. До “as a code” подхода оставалось еще очень много лет, да и сейчас он еще не повсеместен. Без такой инструкции я первый принятый продукт бесплодно устанавливал три дня подряд. Про сборку даже говорить не приходится - даже про родной продукт я часто шутил, что можно безопасно допустить утечку исходников - никто не скопирует продукт, потому что собрать его по исходникам просто нереально, нужна цистерна секретного соуса. Разумеется, инструкцию надо немедленно практически проверить. На слово в этом бизнесе верить не стоит.
4) инструкция по расширению - грубо говоря, как добавить новую фичу или модуль. Берем типовую задачу и примеряем ее на код. Интересно, что если с этапа рассказа про архитектуру разработчики выходили со словами “вау! Нам бы так!”, то с прохода по коду все обычно много плевались и говорили нехорошие слова о предшественниках.
5) распросить наиболее проблемные области по текущему опыту. “что бы бы вы советовали сделать самим себе, если бы не прервались.” Инженер не может удержаться и не поговорить о проблемах, а знать слабые места критически важно
6) после воспроизведения сборки, запуска и простых изменений (1-4 недели) с большей частью исходной команды прощаются и ВСЕ управление передается новой команде. 1-3 эксперта из исходной команды остаются консультантами на почасовой оплате на срок 2-4 месяца. Новая команда раскатывает обновление и если клиенты его пережили, то крещением боем пройдено.

Теперь вернемся к инвентаризации -