четверг, 16 июля 2009 г.

Agile Podcast #5. Сезон 1. Требования в Agile

Автор:
Участники: Асхат Уразбаев, Денис Бесков, Денис Миллер, Никита Филиппов
Темы
* Классический аналитик
* Кто создаёт требования и делает сбор, когда
* Управление требованиями
* Управление изменениями требованиями

Денис Бесков - руководитель отдела системного анализа Лаборатории Касперского, евангелист системного анализа разработки ПО в России.

на 0:48
Ярлыки: , , ,

2 коммент.:

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

    В принципе я с вами согласен, сделаю только не большую ремарку.

    1) Аналитик работает Процессе итерации, это фактически Классический Scrum. Длинна итерации месяц, кроссфункциональная команда (то есть все всем помогают в команде), поэтому итерация выглядит как маленький водопад, в начале итерации все работают над требованиями, под руководством Аналитика. В конце итерации все работают под руководством тест-менеджера. Тоже работает отлично если у вас требования от PO приходят в виде фитч и только к началу нового планирования.

    2) Второй вариант, описанный вами, я считаю наиболее рабочим, как с точки зрения планирования, так и с точки зрения качества и скорости работы в итерации.
    ОтветитьУдалить

Подписаться на: Комментарии к сообщению (Atom)