Comments 11
Меня тоже удивляет то, что Scrum не уделяет внимания управлению требованиями. А также не предусматривает роль бизнес-аналитика (и некоторые другие). Ведь это его забота — «требования, не высказанные клиентом, но необходимые для попадания в цель». А вовсе не команды разработчиков, IMHO.
Если человек приходит к врачу с головной болью и просит отрезать ему ногу, то в случае согласия и проведения операции справедливо обвинит в ошибке врача.
Так в подавляющем большинстве случаев и происходит, особенно при разработке сайтов
Полностью согласен с тем, что осмысленный подход к требованиям обязателен и никакими инструментами это не решить. Хочу лишь спросить, раз вы занимались «внедрением scrum в потоковой web-разработке», насколько scrum как инструмент оказался оправдан?
Скрам дал то, что я от него ожидал:
— Ритмику и темп работы над большим количеством небольших разношерстных проектов в сфере web продакшена и дизайна
— Легкость прогнозирования результатов
— Возможность просто контролировать затраты ресурса и считать плановую и фактическую рентабельность на проектах
— Ритмику и темп работы над большим количеством небольших разношерстных проектов в сфере web продакшена и дизайна
— Легкость прогнозирования результатов
— Возможность просто контролировать затраты ресурса и считать плановую и фактическую рентабельность на проектах
А не порекомендуете, как правильно подготовить исполнительного менеджера проектов c 2 летним опытом работы на Microsoft Project к работе со Скрам — рекомендуемые книги, курсы, видео, wiki — или чтения руководства пользователя достаточно?
Начните отсюда — там в конце много ссылок.
Теория scrum очень проста, проблемы могут начаться на внедрении. Под каждую компанию и сферу деятельности scrum требует адаптации, например, в моей области препятствия вызвала невозможность формирования кроссфункциональных команд, сложность передачи роли product owner'a на сторону клиента, большое количество быстрых (1-3 месяца) проектов на команду, ситуация с несколькими product owner'ами на одну команду. Поэтому я рекомендовал бы искать примеры практического применения в русско- и англоязычных блогах и ресурсах, после чего прикидывать их на свой конкретный случай. «Scrum and XP from the Trenches» Книберга — хорошее собрание практических советов, прочитав которые уже можно что-то делать. На русский перевели ребята из Украины, за что им отдельное спасибо.
Интересную тему подняли… Я был в роли ProductOwner в одном большом веб-проекте (интернет-магазин и рефакторинг), число UserStories было порядка 500. Так вот, чтобы удержать это все дерево в актуальном и согласованном состоянии, мне потребовалось привлечь двух системных аналитиков + самостоятельно прорабатывал требования по несколько часов в день.
Чтобы не сойти с ума и удержать ситуацию под контролем, использовали все доступные инструменты UML: логические модели данных, диаграммы состояний, диаграммы активностей.
Параллельно вели прототип интерфейсов в Axure.
Что могу сказать — ситуация не выходила из под контроля. Но это хорошо, когда у вас с команде профессиональные аналитики. А иначе уверен — начнется коллапс требований и без Requirements Matrix уже не обойтись.
Какой я сделал вывод… Если проект сложный, используется много формальных алгоритмов, биллинг — Scrum может привести к катастрофе, если вовремя не привлечь аналитиков и не ввести в подготовке требований водопадный/итерационный подход.
Чтобы не сойти с ума и удержать ситуацию под контролем, использовали все доступные инструменты UML: логические модели данных, диаграммы состояний, диаграммы активностей.
Параллельно вели прототип интерфейсов в Axure.
Что могу сказать — ситуация не выходила из под контроля. Но это хорошо, когда у вас с команде профессиональные аналитики. А иначе уверен — начнется коллапс требований и без Requirements Matrix уже не обойтись.
Какой я сделал вывод… Если проект сложный, используется много формальных алгоритмов, биллинг — Scrum может привести к катастрофе, если вовремя не привлечь аналитиков и не ввести в подготовке требований водопадный/итерационный подход.
Ценное замечание, полностью согласен. В больших проектах этапу разработки должен предшествовать сбор требований и проектирование, только после этого гибкая разработка. Иначе как минимум потерять концептуальную целостность, то есть сделать плохой продукт, очень легко. Как максимум — завалить проект. В блоге Юрия Ветрова достаточно подробно об это написано.
Sign up to leave a comment.
Scrum и управление требованиями в web-разработке