Related Posts
Оценка и планирование проекта
Мысли о видах информационных систем…
Конфигурация "Выдача пропусков и учет рабочего времени"
Управление ИТ-проектами. Модуль 3: продвинутый курс по гибкому управлению проектами. Agile. Первый поток. Вебинары проходят с 11 сентября по 27 ноября 2026 г.
Загрузка/Выгрузка Excel для справочника "Графики работы сотрудников"
Онлайн-курсы по управлению ИТ-проектами от Марии Темчиной
…
Для Scrum – как контролировать общий прогресс по проекту в целом и как при итерационном внедрении учесть те требования, которые пока еще не вошли в бэклог (например, как заложить в спринтах по производству аналитику, которая понадобится позже – в спринтах по бюджетированию).
Scrum содержит в себе бэклог продукта и бэклоги спринтов.
По ссылке хорошо расписано различие между ними.
По логике, в бэклоге продукта выделяем требования по аналитике, затем будут бэклоги спринтов по производству, затем бэклоги спринтов по бюджетированию. После спринтов по бюджетированию в бэклоге продукта станет актуальной упомянутая задача по аналитикам. Возможно это приведет к изменению задачи в самом бэклоге продукции, а затем дело дойдет до спринтов по реализации несоответствия.
Благодаря ведению бэклога продукта мы в состоянии не упускать из виду подобные архитектурные риски.
И немножко по самой статье.
В ней хорошо расписан гибридный метод, базирующийся на водопаде, с элементами гибкости.
Вероятно возможно решение, (переворачиваем), когда в основе метода будет Scrum с элементами водопада, при таком подъходе бэклог продукта включит в себя в качестве задач как упомянутые выше архитектурные риски, так и чуть ли не привычную структуру водопада, получив тем самым возможность контролировать общий прогресс по проекту в целом.
(1) В прошлой статье на эту тему я написал, что у бэклога есть одна проблема — мы не знаем, все ли задачи внесены в бэклог. То есть сам по себе бэклог (и Scrum в целом) не гарантирует каких-либо абсолютных преимуществ перед водопадом, а с точки зрения стратегии проигрывает водопаду — потому что в конкретной точке отдельного спринта мы не имеем инструментов чтобы понять насколько завершен весь проект. В водопаде я хоть плюс/минус понимаю что закончив этот этап у меня впереди этап такой-то и такой-то — и вот мой весь бюджет проекта, а вот сколько я уже съел и вот сколько у меня еще осталось и как это соотносится с реальностью.
Например, на этапе проектирования я понимаю что выскочил за бюджет проектирования или мои функциональные разрывы уже превышают бюджет этапа доработки. И здесь я могу еще выйти из проекта или пересмотреть стратегию автоматизации — до того как большие деньги будут потрачены (проектирование — это где 20% от бюджета). А спринты таких инструментов не дают — мы кушаем бюджеты,они где-то кончаются — и сколько еще нужно доплатить?
Также спринты не гарантируют срок выполнения проекта — нет понятных показателей сколько сделано, сколько еще осталось сделать.
Также есть вопросы по целостности архитектуры — поэтому как появляется потребность в регулярном рефакторинге архитектуры, чтобы новые решения очередного спринта выстраивались в единую архитектуру с прошлыми.
Если мы с нуля проектируем/разрабатываем уникальный продукт, метод водопада будет иметь подавляющее преимущество перед Scrum.
В практике 1С мы часто встречаем задачи другого рода — у нас на руках типовая, о разработке с нуля и речи не идет, нам нужно ее внедрить, услышать специфику Заказчика, решить ее средствами типовой или доп. разработок.
А когда на руках типовая, можно вести разговор о подходе с серией кратких частых побед (инкрементов) с регулярностью неделя/две/месяц.
Вносим остатки, запускаем силами нескольких консультантов параллельно все чувствительные к регулярности внесения первички процессы (закупки, продажи, банк, склад и т.п.). Дальше больше. Где-то на горизонте себестоимость, затем еще дальше планирование, бюджетирование и т.п.
Одной из методик включающей в себя инкременты и этапность является Scrum.
Сработают и бэклоги и спринты и ролевое распределение участников и филосифия Agile.
Мы действительно не внедрим отсутствующие в бюджетировании аналитики по итогам первых спринтов. Мы и узнаем-то о них только на спринтах в которых будут выполняться задачи постановки требований по бюджетированию. И возможно тогда уже запущена первичка по производству и в ней не будут заноситься эти аналитики.
Но настанет день, когда мы узнаем и про аналитики бюджетирования, запланируем задачи по доработке 1С под них и в конечном итоге появится спринт по внедрению этих аналитик в рабочую систему.
Разумеется какой-то учетный период (несколько месяцев и более) окажется неохваченным доп. аналитиками и возможно прошлый период мы не сможем обработать … но чем эта потеря отличается от той, когда при водопаде мы аналогичный период времени не имеем тех же аналитик, т.к. внедрение системы будет потом и после?
Зато начиная с такой-то даты все у нас будет ок.
PS. При использовании таким образом Scrum в глазах заказчика весь проект будет серией ощутимых и видимых результатов. Вспоминаем, что только реально работая в системе Заказчик расскажет, что он хочет не теоретически, а конкретно от этой системы (перед нами естественная среда выявления реальных и понятных потребностей и требований, что зачастую выглядит дырявым в классическом водопаде).
PPS. Почти так (разве что без употребления слова Scrum и без ряда его деталей) выглядит «второе внедрение» на месте первого неудачного, но научившего Заказчика быть реалистичнее в своих требованиях и ожиданиях (возможно силами другой команды, которой повезло не стать первой для такого проекта).
Друзья, мы сейчас готовимся к ERP Форуму
После него обязательно ответим на вопросы/комментарии
(5) Добрый день!
Решил напомнить об этом вопросе, поскольку тоже интересен ответ.
(6)
сейчас отвечу
(8) Спасибо за ответ, некоторые вещи у меня в голове прояснились.
Собственно
это и есть ответ на то что я имел ввиду в