В водопадной модели вся работа аналитиков происходила на стадии сбора, валидации и фиксации требований. На выходе должно было получиться специальное описание будущей системы целиком - спецификация.
Такая организация работ была предельно логична по двум основным причинам. Во-первых, все тогда работали по модели “эффективности по ресурсам”, то есть разные роли рассматривались как станки на заводе, и их нужно было утилизировать по максимуму. При этом единицей работы считался проект целиком. Поэтому логично было загрузить имеющихся аналитиков работой по одному проекту, потом отдать спецификацию разрабам и приступить к работе над следующим проектом. Во-вторых, исправление ошибок на более поздних стадиях работы (а тем более эксплуатации) было очень дорогим, поэтому важно было как можно лучше разобраться с логикой работы системы как можно раньше. В общем, поэтому при водопадной разработке роль аналитика была сконцентрирована в одном месте - так было эффективнее.
Пришел agile и резко сократил размер одной партии работы. Раньше все работали над системой целиком, а стали работать над одним небольшим кусочком системы за раз. И вот тут, как мне кажется, случилась сереьзная ошибка. Из-за того, что объем работы формально уменьшился (формально, потому что в итоге все равно нужно сделать всю систему целиком), стало казаться, что и аналитикам (да и разработчикам тоже, кстати) нужно делать не так много - знай описывай / реализуй очередной инкремент. Так вот ошибка в том, как многие команды относятся к этому инкременту. Я вижу вокруг, что большинство аналитиков просто описывает очередную доработку с минимальным пониманием ее влияния на уже реализованную функциональность (я уж молчу про возможную будущую функциональность). А надо бы модифицировать существующую спецификацию, выбрасывать и переписывать отдельные ее куски, оптимизировать, обобщать, вот это вот все. Ну и разработчики следом тоже просто пилят описанный “дифф”, не особо изменяя то, что было написано раньше, хотя, возможно, стоило бы переписать большой кусок системы.
Это я все к чему - на практике роль аналитика нынче становится какой-то очень уж “тонкой” и много где ее забирают на себя владельцы продукта и/или руководители проекта. Но при этом команды перестают видеть общую картину и тем самым уменьшают свои собственные возможности по реорганизации логики, упрощению системы и облегчению будущих работ. Результат работы аналитика - это модель текущей логики работы системы (в отличие от одного частного ТЗ, в котором описано частное изменение / дополнение). В ходе каждой итерации модель должна перерабатываться целиком с учетом новых вводных. Для более-менее крупных (сложных) систем такая переработка возможна только при наличии выделенных аналитиков, а не аналитиков “по совместительству”.