Прочитав статью, зацепился за несколько моментов, которые заставили более чётко сформулировать чеклист о том, как входить в команду уже работающую на проекте.

Этот чеклист (хотя он получился чеклистом с приоритетами, а не линейным чеклистом) и идёт ниже.

Поехали:

1. Познакомиться с людьми и начать строить хорошие рабочие отношения с ними - ибо это самое важное, если слажать здесь, то остальные пункты будут скорее всего для галочки.
2. Получить общее описание проекта - в идеале заиметь vision проекта, чтобы можно было всегда сказать мы делаем то-то и то-то для того-то и того-то и добавление этой фишки будет как 5-е колесо у телеги, а вот здесь без условной кобылы мы не поедем
   
   • если есть чёткие требования по проекту - это тоже "наша прелес-с-сть" - утянуть к себе и выкурить вдумчиво.
3. Получить описание верхнего уровня архитектуры - реальной текущей, а не 3-х годичной давности
   если нет в документах по посидеть со специалистом, разрисовать на доске и понять
   тулзы для восстановления архитектуры из кода могут помочь, но не всегда
   
4. Узнать с какими функциональными группами будет вестись работа: другие группы разарботки, тестировщики, ПМы - кто и за что будет отвечать на уровне групп
5. Чётко понять будут ли конфликты с людьми - т.к. это последний шанс съехать с проекта без проблем
   
   • оценить будет ли комфортно работать с людьми, которые уже работают на проекте
   • с кем возможны конфликты - понять возможные причины конфликтов и постараться предотвратить их (да хоть напиться вместе и набить друг другу морду, если это поможет)
6. Узнать какой процесс используется на проекте
   что делается командой(что не в плане активностей, а в плане результата - не "мы пашем", а "какое поле надо пахать") и какую часть должен будешь делать именно ты ("боронить" :) )
7. Получить разделение обязаностей
   
   • кто ответственен за коммуникацию с "заказчиком":
     
     1. только один человек(TL)
     2. один contact point и остальные разработчики по мере нужды на задачах
     3. все
   • кто раздаёт задачи: ТЛ или самовыбор
   • кто является module owners/experts
   • кто делает проектирование: ТЛ, module owners?
   • кто даёт оценку задачам: заказчик, ПМ, ТЛ, module owners?
   • есть ли development testing? и кто его делает
8. выяснить какие практики на проекте:
   
   • code guidelines
   • защитное программирование
   • есть ли код ревью и какие правила его проведения
   • какие вспомогательные программы активно используются на стандартных задачах
   • есть ли написание прототипов
   • написание юнит тестов
   • постоянные билды
   • все остальные полезные практики, о которых забыл
   Если их нет, то можно(нужно) постараться их на проект протащить - свои нервы потом будут дороже.