Темы
* Классический аналитик
* Кто создаёт требования и делает сбор, когда
* Управление требованиями
* Управление изменениями требованиями
Денис Бесков - руководитель отдела системного анализа Лаборатории Касперского, евангелист системного анализа разработки ПО в России.
2 коммент.:
Хотелось бы высказать пару комментов по поводу аналитиков. Как было отмечено, можно работать без аналитика, если проект маленький, не сильно сложный, члены команды держат все архитектуру в голове, заказчик не требует формализации требований. Но если, команда большая (следовательно большая скорость и product owner один просто физически не успеет ответить на все вопросы... к тому же он еще и не всегда доступен), система сложная, разрабатывается уже больше года... в таком случае аналитик просто необходим. Так когда же требования собирать? Раз нужен аналитик - значит система не простая... и быстрых ответов на вопросы разработчиков дать не возможно. В таком случае, если требования будут собираться в процессе итерации, то смотрите что получается... на старте итерации разработчикам делать нечего - предыдущая итерация закончена, продукт зарелизили, дифекты зафиксили... что делать? Т.е. наблюдается простой... ждем пока аналик насобирает требований. А аналитик зависит от заказчика (когда у того будет время ответить на вопросы). В итоге требования формализуются ближе к концу итерации и начинается в спешке реализация фич (и может страдать качество). А вот если собирать требования к итерации, то таких проблем нет: стартуем активную разработку в первый же день итерации, в конце итерации есть время на исправление дифектов и подготовкой к релизу. Кстати, раз система сложная... то и тестируется не за один день, тестерам тоже надо время дать. Асхат поднял вопрос, что в таком случае команда не учавствует в разработке требований. Есть решение и этой проблеме. Что есть спецификация? В ней не только функциональная часть (которую заполняет аналитик), но и техническая часть (дизайн)... и вот эту часть заполняет команда! Т.е. в течение итерации команда имплементит фичи и работает над технической частью требований на следующую итерацию. Является ли BA частью команды? Да... но не учавствует в эстимейтах на имплементацию (т.к. эстимейты дают те, кто реально будет код писать). Но в то же время, BA всегда доступен для ответов на вопросы. Это не прокси-менеджер... это прокси-product owner... и решает проблему доступности product owner для команды (что в большинстве случаев является проблемой в больших проектах). В общем, это работает и работает отлично :-)
Спасибо вам большое за комментарий!
В принципе я с вами согласен, сделаю только не большую ремарку.
1) Аналитик работает Процессе итерации, это фактически Классический Scrum. Длинна итерации месяц, кроссфункциональная команда (то есть все всем помогают в команде), поэтому итерация выглядит как маленький водопад, в начале итерации все работают над требованиями, под руководством Аналитика. В конце итерации все работают под руководством тест-менеджера. Тоже работает отлично если у вас требования от PO приходят в виде фитч и только к началу нового планирования.
2) Второй вариант, описанный вами, я считаю наиболее рабочим, как с точки зрения планирования, так и с точки зрения качества и скорости работы в итерации.
Отправить комментарий