Мы за скрам!

На ИТ-рынке существуют серьезные архитектурные и методологические проблемы (Предыдущие статьи: Кризис доверия и миграция шаблонов поведения, Архитектурный тупик и выходы их него). Они долго накапливались, но теперь достигли такого уровня, когда решать их необходимо. Архитектура информационных систем, которая развивалась в последние годы, привела к тому, что клиенты получили очень сложные ИС, не дающие возможности гибко их изменять. ERP-системы цементируют сложившиеся и описанные бизнес-процессы. Любое изменение – сложный, долгий и дорогой процесс.
Чтобы эти ограничения преодолеть появилось несколько подходов, в том числе создание слоя BPMS, максимально приближающее нас к старой идее описать процесс, а затем быстро его автоматизировать. Как минимум, получив при этом первую версию прототипа нового решения.
Этот слой BPMS интегрирован с основной информационной системой, а сама ИС в такой архитектуре внедряется максимально стандартно. Описанный подход дает радикальное ускорение внесения изменений. Один из поставщиков такого продукта компания Pega, но она далеко не единственная. Важно, что такой подход позволяет решить сложившуюся фундаментальную проблему. Пример проекта
Вторая проблема - традиционная методология разработки ПО «водопад» перестала соответствовать требованиям заказчиков. Они меняются настолько динамично, что то видение, которое было в начале проекта, кардинально меняется к его концу, а «водопад» при таком положении дел дает плохие результаты, вызывает неудачи и/или неисполнения по бюджетам и срокам.
Поэтому стали активно применятся более динамичные методологии. SCRUM («скрам») стал элементом крупных проектов. Сама модель организации проекта должна теперь быть очень динамичной. Вовлечение заказчика в проект, управление изменениями, достижение не раз навсегда поставленных целей, а удовлетворение заказчика играют здесь принципиальную роль. Все это приводит к тому, что гибкие методологии разработки все шире применяются при создании корпоративных информационных систем. Даже у SAP появились методологические изменения, которые отражают их видение таких подходов.
По некоторым данным число неудач в скрам-проектах втрое меньше, чем при традиционном подходе, а число успешно законченных проектов вдвое больше. Связано это в том числе и с тем, как быстро меняются бизнес-процессы в компаниях.
Однако у нас «водопад» попал во все стандарты и в законы, что ставит системные препятствия на пути распространения альтернативных подходов: очевидно, методология скрам может быть востребована только в коммерческом секторе. Те отрасли, где бизнес построен на ИТ-фундаменте: финансы, ритейл, энергетика, в первую очередь проявляют к ней интерес.
Решение методологической проблемы критично и для поставщика, и для покупателя. Так как в наших контрактах традиционно фиксированная цена, фиксированное время, но не фиксированные требования, методология «водопад» приводит к тому, что подрядчик становится заложником своего клиента. При гибких методологиях для клиента выше шанс получить именно то, что нужно, даже если результат не соответствует первичному пониманию.
Мы считаем, что используя скрам и предлагая BPMS-решения, нашли одно из возможных решений фундаментальных архитектурных и методологических проблем, и пытаемся с ним работать. Все равно еще затраты остаются большими, но они намного меньше, чем при традиционных подходах. Плюс большая точность, большая эффективность проекта.
Мы для себя приняли принципиальное решение – там, где возможно, мы везде будем переходить на скрам и гибкие методологии в целом. Причем будем это делать максимально широко. Но путь этот долгий.
Ведь внутри компании тоже этот переход мгновенно не происходит. У нас есть пока одно подразделение, которое работает по модели скрам, и есть отдельные очаги в других подразделениях. Большая часть сотрудников выросла на «водопаде», для них эти новые методологии не просты в освоении. Основная проблема связана с изменением в головах людей, а это быстро не дается.
Мы эту методологию продекларировали год назад. По-настоящему внедрять у себя ее начали в январе 2014 года. Пока мы используем примерно 50%. Столько мы сумели освоить за прошедшие месяцы. И это вовсе не потому, что мы особо упрямые или глупые, а потому, что требуются изменения в головах большого числа людей. У нас по этой методологии работают несколько десятков человек. Самое главное – переход к командной ответственности.
Основное изменение последнего времени – методология скрам стала эффективно применяться в больших корпоративных проектах, длительностью год и более. Появился опыт и понимание, как ее реализовывать. Да, она выросла из небольших динамичных проектов разработки, но сейчас уже есть опыт адаптации и применения именно в крупных проектах. Более того, в крупных проектах эффективность скрама выше, чем в мелких: небольшие проекты при любом подходе и планировать легче, и цена ошибки ниже.
Комментарии (28)
Комментировать могут только авторизованные пользователи.
Предлагаем Вам войти в систему или
зарегистрироваться.
Комментировать могут только авторизованные пользователи.
Предлагаем Вам войти в систему или
зарегистрироваться.
Алешин Евгений Витальевич
Директор службы ИТ
МОНТ
Получается ли в результате приложение, которое можно будет гибко развивать - это скорее вопрос заложенной архитектуры. А с архитектурой в гибкой разработке есть небольшие проблемы.
Шварцблат Марк Рудольфович
ИТ-директор
КТ "Акведук"
Ответ на « А мне кажется, что все эти... »
Алешин Евгений Витальевич
Директор службы ИТ
МОНТ
Ответ на « В моменты углубления кризиса (сам по... »
Правда, теоретически могу допустить, что в результате изменений в налоговом законодательстве компания поменяла схему оптимизации налогов, что привело к изменению поставщиков, логистики и т.д.
Шварцблат Марк Рудольфович
ИТ-директор
КТ "Акведук"
Ответ на « Ну, если изменения в правилах налогообложения... »
Огнивцев Александр Леонидович
Руководитель управления
Альфастрахование
Ответ на « А мне кажется, что все эти... »
Алешин Евгений Витальевич
Директор службы ИТ
МОНТ
Что нам говорили системные интеграторы и вендоры BPMS, когда предлагали попробовать у себя в компании систему управления бизнес-процессами? Что это даст компании гибкость в перестройке процессов и чуть ли не прямое управление процессами бизнес пользователями без участия ИТ.
Что такое Scrum? - методология управления разработкой новых приложений.
Сочетание Scrum + BPMS говорит, что при внедрении будет много новой разработки, зато потом... Боюсь, потом всю разработку, которую вели в приложениях, надо будет вести в BPMS (и немного ещё и в приложениях).
Курочкин Анатолий Михайлович
Старший инженер, аналитик.
Научно-производственное объединение
Обычно "кухня" разработки скрыта и от заказчика, и от пользователя. Кто вынуждает разработчика использовать неэффективную методологию? Или это внутренние, собственные привычки разработчика? Вы приводите пример банковского внедрения - так банк далеко не классика для разработчика.
Алешин Евгений Витальевич
Директор службы ИТ
МОНТ
Ответ на « Я не очень воспринял вот эту... »
Курочкин Анатолий Михайлович
Старший инженер, аналитик.
Научно-производственное объединение
Ответ на « При участии в государственных тендерах надо... »
Давыдов Георгий Игоревич
Архитектор интеграционных решений
R-Style Softlab
Получается, что SCRUM не нужен, если лозунги станут реальностью! Поясню.
Представьте, что вы бизнес заказчик, и «купили» проект с BPMS не просто ради автоматизации процессов и их строго соответствия бумажным регламентам, а с целью получить возможность менять эти процессы в последствии быстро и не принуждённо. Нужен ли вам в этом случае SCRUM? Если цель будет достигнута, то ответ очевиден – не нужен. Пусть к концу проекта есть понимание другой версии процесса, отличной от реализованной. Так ведь это отличный повод на этапе приёмки работ проверить достижение цели, например, перестроив процесс под новые реалии.
Я, как представитель интегратора, прекрасно понимаю, что сближение бизнеса и ИТ, возможность быстро менять процессы – есть. Но с большим количеством ограничений, допущений и нюансов. Именно поэтому, казалось бы невозможное сочетание - BPMS+SCRUM, благодаря которому произошло чудо, имеет место быть.
SCRUM применялся мной на коммерческом проекте лет пять назад, иногда мы скрывали «внутренний» SCRUM от заказчика, сейчас мы используем элементы SCRUM внутри даже на водопадных проектах, и если честно, то я вижу, что преимущества этой методики управления прямо проистекают из ситуаций, когда её выгодно применить:
Мне кажется, что на открытом конкурентном рынке заказчик вряд ли примет решение в пользу SCRUM, потому что основной минус SCRUM: не ясные результаты за непонятный бюджет. Покупатель, очевидно, предпочтёт SCRUMу определённые сроки и цифры с известным результатом. Но если у меня будет возможность с каким-нибудь заказчиком «пойти на SCRUM» я ей непременно воспользуюсь.
Я тоже за скрам!
Тепляков Дмитрий Владимирович
ИТ директор
Футбольный клуб "Шахтер"
Ответ на « Очень интересная тема и обсуждение. BPMS... »
Но совершенно другая ситуация, когда я заказываю крупный проект у аутсорсера. Меня совершенно не устраивает работа по принципу открытого бюджета. Точнее, меня то она может и устроит. Но вот финансовый директор против. В итоге, мне нужно получить хотя-бы рамочное понимание затрат. А это по СКРАМ сделать практически невозможно. Поэтому приходится по стандартной методике - детальное ТЗ, создание прототипа. После этого опять переоценка затрат и сроков, новое утверждение бюджета, и внедрение. Те по сути, классический водопад.
Курочкин Анатолий Михайлович
Старший инженер, аналитик.
Научно-производственное объединение
Ответ на « Очень интересная тема и обсуждение. BPMS... »
Давыдов Георгий Игоревич
Архитектор интеграционных решений
R-Style Softlab
Ответ на « Очень интересная тема и обсуждение. BPMS... »
Попробую. Зачастую исполнитель приходит в проект и выполняет работы, начиная с написания требований к системе, потом эти требования согласуются и начинается разработка.
Не буду рассуждать хорошо это или плохо, когда заказчик не имеет готовых требований к системе, это отдельный большой разговор. Это реальность.
Одновременно с разработкой решения идут уточнения требований, детализация, иногда трансформация. Наступает этап сдачи решения и тут выявляются несоответствия, мол, не так …, нас не устраивает...
Далее стандартный сценарий, исполнитель пытается раскрутить заказчика на доп. бюджет, прикрываясь согласованными требованиями. Тут ситуация развивается по-разному, в зависимости от перспектив длительных партнёрских отношений, манящей перспективы развития, обещаний заказчика по заложенному бюджету, дружеских отношений ТОПов и т.д. и т.п.
Как правило, ситуация решается «баш на баш». Правда, позиция заказчика в этом вопросе всегда сильнее, у исполнителя, по факту есть только один аргумент: «в ТЗ написано …», или даже так: «в ТЗ этого НЕ написано». На что ответ очевиден: «ТЗ писали вы и это ваш промах, что вы не раскрыли эту тему, не дообследовали…».
Т.е. тут в полной мере раскрывается девиз «Клиент всегда прав». С учётом всего этого можно выделить преимущества SCRUMа:
SCRUM поможет влиять на совесть заказчика, мол, мы уже 15 раз переделываем авторизацию пользователя, сколько же можно. Т.е. есть надежда, при определённой харизме, «надавить» на заказчика и «продать» не идеальную для него реализацию.
SCRUM позволит играть важностью требований в надежде, что сложные технически требования можно будет отложить, поскольку они не бизнес критичны. Скажем представитель ИТ может сказать, что подсистема протоколирования его не устраивает, но т.к. требование не мешает бизнесу работать, то до его реализации дело может и не дойти, под предлогом того, что бизнес-требования выполнены
SCRUM даст возможность «закидать» какого-нибудь представителя заказчика сотнями вопросов, уточнений, предложений, которые сместят фокус…
Правда, чтобы в полной мере воспользоваться этими возможностями, нужно быть если не гением SCRUM, то тонко чувствовать ситуацию, так сказать «на кончиках пальцев», обязательно. Я не хочу сказать, что это не честно, это искусство - искусство оставит партнёра довольным, но и самому не остаться в накладе, это рынок, это продажа, которая не закончилась в момент подписания контракта, но которая закончится, только тогда, когда закончится проект.
Я клоню к тому, что иногда исполнителю, даже при фиксированном бюджете и зафиксированных бизнес результатах (а мне сложно представить иного покупателя, проще и эффективнее нанять команду или пойти по пути outstaff), имеет смысл пойти на SCRUM.
Риск, шампанское, драйв!
Курочкин Анатолий Михайлович
Старший инженер, аналитик.
Научно-производственное объединение
Ответ на « Уж очень понравилась мне эта тема,... »
1. Заказчик всегда прав.
2. Взялся за гуж...
3. Заказчик за написание требований, как правило, платит исполнителю деньги.
Не посчитайте меня противником SCRUM, но в данном случае это не есть основной смысл применения методологии. Ведь и исполнитель к написанию требований, как правило, подходит фоормально ("прошлый раз делали, где-то в архиве поищи"). В старые добрые времена, когда деревья были большие, а суммы в миллион рублей считались запредельными, исполнитель, видя неуверенность заказчика в понимании требований, устанавливал чёткие границы разработки, обрезал проект, предлагал опытную эксплуатацию.
В Вашем же примере я вижу способ увеличить бюджет понятным заказчику способом. Что, конечно, тоже интересно.
(Исправлено 24.11.2014 12:18, Курочкин Анатолий Михайлович)
Не буду рассуждать хорошо это или плохо, когда заказчик не имеет...
Лапшин Алексей Евгеньевич
Руководитель проектного сервиса
АйТи
Scrum позволяет лучше и легче контролировать ход проекта и отслеживать проблемы в нем. Быстрее получать обратную связь от заказчика и не делать пустую работу. Waterfall то же позволяет контролировать. отслеживать и получать. Но для этого требуется много больше усилий и много больше времени.
Петров Михаил Викторович
Директор программ и проектов по технологиям
ПО НТИ (РВК)
Огнивцев Александр Леонидович
Руководитель управления
Альфастрахование
Ответ на « Любая методология имеет область адекватного применения.... »
Лапшин Алексей Евгеньевич
Руководитель проектного сервиса
АйТи
Ответ на « Считаю последнюю фразу блестящей характеристикой скрама.... »
Что-то подсказывает мне, что это не так, is it?
Огнивцев Александр Леонидович
Руководитель управления
Альфастрахование
Ответ на « Складывается забавное впечатление, что есть проекты,... »
Петров Михаил Викторович
Директор программ и проектов по технологиям
ПО НТИ (РВК)
Мы для себя приняли...
Крица Александр Юрьевич
Начальник отдела развития ИТ
Судебный департамент при Верховном Суде РФ
Лапшин Алексей Евгеньевич
Руководитель проектного сервиса
АйТи
Ответ на « Можно привести примеры успешных крупных проектов,... »
Если говорить о больших проектах, то есть такие классические как проект Sentinel, реализованный в ФБР. Традиционный подход оказался не в состоянии реализовать столь сложный проект, поэтому был дан шанс гибкому подходу. Естественно, при реализации было огромное количество трудностей, но тем не менее только scrum позволит добиться результата. Ещё есть интересный пример у компании Primavera, которая для реализации очередного релиза своего продукта для классического управления проектами, была вынуждена использовать scrum, т.к. waterfall банально перестал для них работать. Можно почитать и о таком примере в голландских железных дорогах: http://www.infoq.com/articles/dutch-railway-scrum.
Это лишь наиболее цитируемые случаи, кроме них есть и много других. Западный рынок уже более 10 лет активно дрейфует в сторону гибких подходов и классический менеджер проектов без знаний и опыта в гибких подходах становятся динозавром на этом рынке. Мы традиционно отстаем и у нас гибкие подходы используют лишь единицы, поэтому у меня вызывает некоторые затруднение перечислись такие проекты у нас. Пожалуй, могу упомянуть Тинькофф Банк, Люксофт, Peter-Service и Альфа Банк. В проектах Альфа Банка посчастливилось поучаствовать и нам. Все описанное в статье было почерпнуто нами из нашей практики. А в целом цель данной статьи как раз и заключалась в том, чтобы растормошить нашу аудиторию и обсудить почему же в России мы пока так отстаем в его внедрении.
Крица Александр Юрьевич
Начальник отдела развития ИТ
Судебный департамент при Верховном Суде РФ
Ответ на « Если говорить о компаниях, которые используют... »
Еремеев Денис Владимирович
Директор по ИТ
Спецэнерготранс
Ответ на « Если говорить о компаниях, которые используют... »
В Европе уже 10 лет кризис, а у нас, в "Тихой гавани" только началось. Глубина кризиса порождает спрос на RUP и Agile и в частности на SCRUM как "понятный" для Заказчика (не знаем что хотим, но идем примерно туда, деньги если что найдем). Молния ударила, мужик перекрестился, повторил SCRUM и KANBAN и пошел на передовую..
Кашапов Ильгиз Анасович
Руководитель СИТ
ООО НПФ Пакер
Есть большое желание внедрить гибкие методологии разработки. В учебных центрах начали появляться курсы по Agile, Scrum.
Не могли бы подсказать консультантов или компании которые готовы оказать консультационную поддержку при внедрении.
Вяткин Николай Викторович
Эксперт
Ответ на « Всем добрый день!Есть большое желание внедрить... »
Позин Борис
CTO
ЕС-Лизинг
А вот авторы COCOMO и других методик оценки проектов экспериментально выявили (см. работы Бэма, Липаева, Каперса Джонса), что производительность труда сильнее всего зависит от опыта работы программистов в конкретной прикладной области, от опыта работы в технологической среде, от размера или сложности создаваемого ПО. Почему-то эти важные обстоятельства вообще в нашей дискуссии почти не принимаются в расчет? Неужто опять проджект менеджеры считают, что сумеют управлять чем угодно?
Кстати, гибкие подходы и Скрам это не одно и то же, хоть автор и пишет об этом. Почитайте, например, свежую (2014 г.) книжку классика Bertrand Meyer. В ней всё нормально: Скрам - один из методов гибкой разработки. И основные особенности Скрам по сравнению с другими методами гибкой разработки приведены. Давайте отделим рекламу и маркетинг от реального производства и реальной технологии.
Кстати, одно замечание по поводу реплики авторов статьи. Сам "водопад", или "каскад" ничему не препятствует во внедрении гибких методов разработки. Препятствует модель "Fixed Price", которая применяется в госзаказах прежде всего. Не надо бы путать экономику, менеджмент и технику.
Вяткин Николай Викторович
Эксперт
P.S.: Так же надо учитывать, что SCRUM это в большинстве случаев T&M (time and material), а не Fix Price, поэтому это больше подходить для Research проектов.
(Исправлено 26.02.2015 12:47, Вяткин Николай Викторович)