Scrum и управление требованиями в web-разработке

[ComodoHacker]

Меня тоже удивляет то, что Scrum не уделяет внимания управлению требованиями. А также не предусматривает роль бизнес-аналитика (и некоторые другие). Ведь это его забота — «требования, не высказанные клиентом, но необходимые для попадания в цель». А вовсе не команды разработчиков, IMHO.

[osbornecox]

Да, но ответственность за результат на менеджере, и он решает, привлекать ли аналитика или кого-то еще для получения этого результата.
На не очень больших и не очень дорогих проектах в небольшой команде роль аналитика может выполняться самим менеджером.

[RedSkinS]

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

Так в подавляющем большинстве случаев и происходит, особенно при разработке сайтов

[osbornecox]

По-моему, это не нормально.

[PavelT]

Полностью согласен с тем, что осмысленный подход к требованиям обязателен и никакими инструментами это не решить. Хочу лишь спросить, раз вы занимались «внедрением scrum в потоковой web-разработке», насколько scrum как инструмент оказался оправдан?

[osbornecox]

Скрам дал то, что я от него ожидал:
— Ритмику и темп работы над большим количеством небольших разношерстных проектов в сфере web продакшена и дизайна
— Легкость прогнозирования результатов
— Возможность просто контролировать затраты ресурса и считать плановую и фактическую рентабельность на проектах

[PavelT]

А не порекомендуете, как правильно подготовить исполнительного менеджера проектов c 2 летним опытом работы на Microsoft Project к работе со Скрам — рекомендуемые книги, курсы, видео, wiki — или чтения руководства пользователя достаточно?

[Mezomish]

Начните отсюда — там в конце много ссылок.

[osbornecox]

Теория scrum очень проста, проблемы могут начаться на внедрении. Под каждую компанию и сферу деятельности scrum требует адаптации, например, в моей области препятствия вызвала невозможность формирования кроссфункциональных команд, сложность передачи роли product owner'a на сторону клиента, большое количество быстрых (1-3 месяца) проектов на команду, ситуация с несколькими product owner'ами на одну команду. Поэтому я рекомендовал бы искать примеры практического применения в русско- и англоязычных блогах и ресурсах, после чего прикидывать их на свой конкретный случай. «Scrum and XP from the Trenches» Книберга — хорошее собрание практических советов, прочитав которые уже можно что-то делать. На русский перевели ребята из Украины, за что им отдельное спасибо.

[AlexSerbul]

Интересную тему подняли… Я был в роли ProductOwner в одном большом веб-проекте (интернет-магазин и рефакторинг), число UserStories было порядка 500. Так вот, чтобы удержать это все дерево в актуальном и согласованном состоянии, мне потребовалось привлечь двух системных аналитиков + самостоятельно прорабатывал требования по несколько часов в день.

Чтобы не сойти с ума и удержать ситуацию под контролем, использовали все доступные инструменты UML: логические модели данных, диаграммы состояний, диаграммы активностей.

Параллельно вели прототип интерфейсов в Axure.

Что могу сказать — ситуация не выходила из под контроля. Но это хорошо, когда у вас с команде профессиональные аналитики. А иначе уверен — начнется коллапс требований и без Requirements Matrix уже не обойтись.

Какой я сделал вывод… Если проект сложный, используется много формальных алгоритмов, биллинг — Scrum может привести к катастрофе, если вовремя не привлечь аналитиков и не ввести в подготовке требований водопадный/итерационный подход.

[osbornecox]

Ценное замечание, полностью согласен. В больших проектах этапу разработки должен предшествовать сбор требований и проектирование, только после этого гибкая разработка. Иначе как минимум потерять концептуальную целостность, то есть сделать плохой продукт, очень легко. Как максимум — завалить проект. В блоге Юрия Ветрова достаточно подробно об это написано.