Мое IMHO по данным вопросам:
1. Алексей писал о том, что разработчики должны быть с разносторонним опытом, чтобы каждый мог подхватить кусок работы ушедшего товарища. Но это в идеальном мире. По сути, уход ключевого человека — это риск, и как и другими рисками этим фактором нужно управлять и уменьшать различными способами, кака вариант, добиваясь того, чтобы ничего не было завязано на одного человека с помощью шерингов знаний и т.д. Это в т.ч. задача Скрам Мастера, как по мне.
А что касается заказчика — тут, как мне кажется, выбор не велик. Если уж такая ситуация приключилась — выбраться без потерь у вас не выйдет. Или людей пресовать придется с риском потерять и остальных, либо обуждать с заказчиком дальнейший скоуп и приоритеты. Для этого есть такие инструменты, как матрица приоритетов (Must/Should/Could/Won’t have), согласно которой у вас в любом случае должен в конце релиза быть буфер на работу над Could Have фичами. Ну и в конечном итоге, если отношения с заказчиком нормальные, то он вполне нормально отнесется к такой ситуации, главное не пытаться его обманывать, сваливаясь в No trust/No Transparency сегмент матрицы доверия и разгребая потом последствия.
2. Если готовы к тому, чтобы работать в минус ради репутации — вперед. Т.к. в любом случае вы не успеете, ну либо как в известном меме построите домик из известного материала и палок, и будете стараться чинить быстрее, чем его будут ломать пользователи. Тут как-бы тоже дело такое, есть компании, модель которых построена на культуре овертаймов и порицания тех, кто работает только в пределах рабочего времени. В такой ситуации проект может даже прибыльным оказаться, но нужно быть готовым к тому, что текучка будет неимоверная.

Отличная статья! Стратоплан и Слава Панкратов оценили бы :)

BA — это, в первую очередь, работа с требованиями. А о том, как с ними работать, уже много лет есть книга, которая считается одной из эталонных — Karl Wiegers «Software Requirements». Учите, пробуйте, т.к. опыт и понимание циклов разработки, а также самой отрасли и сферы деятельности заказчиков критичны для этой позиции, ровно как и умение общаться с различными ролями в процессе.