Внедрение scrum для аналитиков

Испробовав scrum, ты начинаешь его применять везде.

Особенности аналитиков
1. Результат их работы часто не представляет самостоятельной ценности, пока это не реализовано разработчиком. Можно считать, что разработка является этапом тестирования для постановки. Поэтому возникает классическая проблема отставания тестирования при классическом подходе к разработке: сначала пишутся постановки, потом они оцениваются, потом они планируются и лишь потом выполняются. Безусловно эти проблемы могут нивелироваться опытом аналитика.
2. Все встреченные мной аналитики - индивидуалисты. Разработчиков объединяет язык программирования, используемые технологии. У аналитиков из инструментов Word и Visio, у них больше свободы и им тяжелее работать вместе. Придуманы нотации, UML, IDEF0, но аналитик их не может полноценно использовать, пока заказчики не начнут использовать эти нотации. А делать правильные описания в правильных нотациях и одновременно иметь классические текстовые постановки не хотят.
3. У разработчиков есть понятие парного программирования, у аналитиков оно отсутствует как класс.
4. Любой может выполнять роль аналитика, плохо или хорошо. Но я не встретил еще аналитика, который может выполнить роль разработчика, пусть даже плохо.
5. Про разработчиков говорят "выделяйте как можно больше непрерывного времени". Аналитики говорят "я должен начать писать одну постановку, не закончить ее переключиться на другую. Затем вернуться к первой, взглянуть на нее свежим взглядом и т.д."

Особенности внедрения scrum для аналитиков
1. Критерий Done.
Надо с ним договориться, что постановка не сделана, если ее не прочитал другой член команды. Без этого невозможно определить, что постановка закончена.И договориться, что вообще-то постановка будет считаться сделанной, если по ней что-то реализовали.
2. Первый месяц заставить жить себя без оценок. Аналитики их давать не любят. Обходиться лишь приоритетами, причем по "мягкой схеме", несколько задач одного приоритета. В дальнейшем все равно начинать требовать оценок.
3. Просить идти аналитиков от меньшего к большему в постановках.
Если аналитик закладывает в постановку много требований, то разработка начинает запаздывать и реализуется не все. Часть переносится на следующую итерацию или вообще "на потом". Постановку тогда надо изменять, чтобы она соответствовала реализации. Лучше, если бы постановка была меньше, потом на изменения написали бы отдельную постановку.
4. Позволять аналитикам делать несколько задач. Но от итерации к итерации изменять это значения и смотреть на его влиянии на фокус-фактор.
5. Попросить начинать постановку с формирования плоского приоритезированного списка User Story. После определения, какие User Story все же реализуем, указывать How to demo. Затем лишь писать собственно постановку и, в идеале, Test cases.