Мы за скрам!

28

На ИТ-рынке существуют серьезные архитектурные и методологические проблемы (Предыдущие статьи: Кризис доверия и миграция шаблонов поведения, Архитектурный тупик и выходы их него). Они долго накапливались, но теперь достигли такого уровня, когда решать их необходимо. Архитектура информационных систем, которая развивалась в последние годы, привела к тому, что клиенты получили очень сложные ИС, не дающие возможности гибко их изменять. ERP-системы цементируют сложившиеся и описанные бизнес-процессы. Любое изменение – сложный, долгий и дорогой процесс.

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

Этот слой BPMS интегрирован с основной информационной системой, а сама ИС в такой архитектуре внедряется максимально стандартно. Описанный подход дает радикальное ускорение внесения изменений. Один из поставщиков такого продукта компания Pega, но она далеко не единственная. Важно, что такой подход позволяет решить сложившуюся фундаментальную проблему. Пример проекта 

Вторая проблема - традиционная методология разработки ПО «водопад» перестала соответствовать требованиям заказчиков. Они меняются настолько динамично, что то видение, которое было в начале проекта, кардинально меняется к его концу, а «водопад» при таком положении дел дает плохие результаты, вызывает неудачи и/или неисполнения по бюджетам и срокам.

Поэтому стали активно применятся более динамичные методологии. SCRUM («скрам») стал элементом крупных проектов. Сама модель организации проекта должна теперь быть очень динамичной. Вовлечение заказчика в проект, управление изменениями, достижение не раз навсегда поставленных целей, а удовлетворение заказчика играют здесь принципиальную роль. Все это приводит к тому, что гибкие методологии разработки все шире применяются при создании корпоративных информационных систем. Даже у SAP появились методологические изменения, которые отражают их видение таких подходов.

По некоторым данным число неудач в скрам-проектах втрое меньше, чем при традиционном подходе, а число успешно законченных проектов вдвое больше. Связано это в том числе и с тем, как быстро меняются бизнес-процессы в компаниях.

Однако у нас «водопад» попал во все стандарты и в законы, что ставит системные препятствия на пути распространения альтернативных подходов: очевидно, методология скрам может быть востребована только в коммерческом секторе. Те отрасли, где бизнес построен на ИТ-фундаменте: финансы, ритейл, энергетика, в первую очередь проявляют к ней интерес.

Решение методологической проблемы критично и для поставщика, и для покупателя. Так как в наших контрактах традиционно фиксированная цена, фиксированное время, но не фиксированные требования, методология «водопад» приводит к тому, что подрядчик становится заложником своего клиента. При гибких методологиях для клиента выше шанс получить именно то, что нужно, даже если результат не соответствует первичному пониманию.

Мы считаем, что используя скрам и предлагая BPMS-решения, нашли одно из возможных решений фундаментальных архитектурных и методологических проблем, и пытаемся с ним работать. Все равно еще затраты остаются большими, но они намного меньше, чем при традиционных подходах. Плюс большая точность, большая эффективность проекта.

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

Ведь внутри компании тоже этот переход мгновенно не происходит. У нас есть пока одно подразделение, которое работает по модели скрам, и есть отдельные очаги в других подразделениях. Большая часть сотрудников выросла на «водопаде», для них эти новые методологии не просты в освоении. Основная проблема связана с изменением в головах людей, а это быстро не дается.

Мы эту методологию продекларировали год назад. По-настоящему внедрять у себя ее начали в январе 2014 года. Пока мы используем примерно 50%. Столько мы сумели освоить за прошедшие месяцы. И это вовсе не потому, что мы особо упрямые или глупые, а потому, что требуются изменения в головах большого числа людей. У нас по этой методологии работают несколько десятков человек. Самое главное – переход к командной ответственности.

Основное изменение последнего времени – методология скрам стала эффективно применяться в больших корпоративных проектах, длительностью год и более. Появился опыт и понимание, как ее реализовывать. Да, она выросла из небольших динамичных проектов разработки, но сейчас уже есть опыт адаптации и применения именно в крупных проектах. Более того, в крупных проектах эффективность скрама выше, чем в мелких: небольшие проекты при любом подходе и планировать легче, и цена ошибки ниже.

7216
Коментарии: 28

Комментировать могут только авторизованные пользователи.
Предлагаем Вам в систему или зарегистрироваться.

  • Евгений Алешин
    Рейтинг: 36
    МОНТ
    Директор службы ИТ
    19.11.2014 10:48

    А мне кажется, что все эти разговоры про быстро меняющиеся процессы - это такой фиговый листочек, который прикрывает слабую осознанность "бизнесом" собственных операционных процессов. Младший персонал, как правило, понимает процессы на уровне нажимания кнопок, а менеджеры знать не хотят ни про эти кнопки, ни про системы в целом - профит энд лосс им подавай. А итеративный подход просто дает возможность постепенного понимания командой разработки предметной области. Тем не менее, реальность такова, какова она есть и гибкие подходы работают, тем более что они в себе содержат элементы самоорганизации команды (ежеутренние собрания) и элементы работы с заказчиком (демонстрация после каждой итерации).
    Получается ли в результате приложение, которое можно будет гибко развивать - это скорее вопрос заложенной архитектуры. А с архитектурой в гибкой разработке есть небольшие проблемы.

    • Марк Шварцблат Евгений
      Рейтинг: 30
      КТ "Акведук"
      ИТ-директор
      19.11.2014 10:57

      В моменты углубления кризиса (сам по себе кризис у нас вечен) процессы действительно приходится менять часто и на лету, пытаясь приспособиться к внезапно изменившимся условиям. Вот кто сейчас может точно сказать - когда и в каком объеме заработают новые поборы в местный бюджет с каждой торговой точки?

      • Евгений Алешин Марк
        Рейтинг: 36
        МОНТ
        Директор службы ИТ
        19.11.2014 11:16

        Ну, если изменения в правилах налогообложения и скачки валютных курсов будут тянуть за собой изменения в процессах, которые требуют итеративной разработки (это команда 5-7 человек), то это "дырки" в архитектуре приложения. Такие изменения обычно отрабатываются в рамках обычной поддержки (так называемый Канбан).
        Правда, теоретически могу допустить, что в результате изменений в налоговом законодательстве компания поменяла схему оптимизации налогов, что привело к изменению поставщиков, логистики и т.д.

        • Марк Шварцблат Евгений
          Рейтинг: 30
          КТ "Акведук"
          ИТ-директор
          19.11.2014 11:22

          Это может повлечь за собой закрытие нескольких десятков небольших торговых точек со всеми связанными изменениями, чтобы не потерять рынок.

    • Александр Огнивцев Евгений
      Рейтинг: 12
      ГК РОСАТОМ АО КИС "ИСТОК"
      Директор по информационным технологиям
      19.11.2014 18:17

      Так и есть. Когда я в 90-ые годы работал разработчиком, что использовал методологию скрам, правда не знал об этом. Прямой контакт с заказчиком, реализация прямо со слов, короткие циклы, постоянные презентации и т.д. Разница в том, что в те годы заказчик как правило точно знал чего он хочет по бизнесу, но не знал что можно реализовать через ИТ. Теперь заказчик точно знает, что через ИТ реализовать можно все, но не знает чего он хочет по бизнесу. Ситуация неопределенности воспроизвелась, теперь на новом витке и в такой ситуации, конечно, гибкие технологии становятся востребованными.

  • Евгений Алешин
    Рейтинг: 36
    МОНТ
    Директор службы ИТ
    19.11.2014 12:14

    Кстати, сочетание Scrum + BPMS, выбранное системным интегратором для практической работы, любопытно.
    Что нам говорили системные интеграторы и вендоры BPMS, когда предлагали попробовать у себя в компании систему управления бизнес-процессами? Что это даст компании гибкость в перестройке процессов и чуть ли не прямое управление процессами бизнес пользователями без участия ИТ.
    Что такое Scrum? - методология управления разработкой новых приложений.
    Сочетание Scrum + BPMS говорит, что при внедрении будет много новой разработки, зато потом... Боюсь, потом всю разработку, которую вели в приложениях, надо будет вести в BPMS (и немного ещё и в приложениях).

  • Анатолий Курочкин
    Рейтинг: 25
    Научно-производственное объединение
    Старший инженер, аналитик.
    19.11.2014 13:05

    Я не очень воспринял вот эту мысль: "Однако у нас «водопад» попал во все стандарты и в законы, что ставит системные препятствия на пути распространения альтернативных подходов: очевидно, методология скрам может быть востребована только в коммерческом секторе. Те отрасли, где бизнес построен на ИТ-фундаменте: финансы, ритейл, энергетика, в первую очередь проявляют к ней интерес."

    Обычно "кухня" разработки скрыта и от заказчика, и от пользователя. Кто вынуждает разработчика использовать неэффективную методологию? Или это внутренние, собственные привычки разработчика? Вы приводите пример банковского внедрения - так банк далеко не классика для разработчика.

    • Евгений Алешин Анатолий
      Рейтинг: 36
      МОНТ
      Директор службы ИТ
      19.11.2014 19:08

      При участии в государственных тендерах надо соблюдать законы государства. :) А государство принимало в разное время законы/стандарты, где прямо или косвенно указывало методологию управления проектом и разработки. Дальше понятно - выиграл тендер и наплевал на указанную в тендере водопадную модель, а в жизни применяешь гибкую разработку. Но документацию-то надо составлять под условия тендера, проверять будут по ней. А ну как система получится неудачной и начнутся разборки с привлечением Счётной палаты и прочих "органов"?

      • Анатолий Курочкин Евгений
        Рейтинг: 25
        Научно-производственное объединение
        Старший инженер, аналитик.
        20.11.2014 13:44

        Ну если только с государственным заказчиком. Хотя бы объяснимо.

  • 19.11.2014 15:03

    Очень интересная тема и обсуждение. BPMS всегда подвигался под лозунгами сближения ИТ и бизнеса, возможностью минимальными затратами перестраивать бизнес-процессы.
    Получается, что SCRUM не нужен, если лозунги станут реальностью! Поясню.
    Представьте, что вы бизнес заказчик, и «купили» проект с BPMS не просто ради автоматизации процессов и их строго соответствия бумажным регламентам, а с целью получить возможность менять эти процессы в последствии быстро и не принуждённо. Нужен ли вам в этом случае SCRUM? Если цель будет достигнута, то ответ очевиден – не нужен. Пусть к концу проекта есть понимание другой версии процесса, отличной от реализованной. Так ведь это отличный повод на этапе приёмки работ проверить достижение цели, например, перестроив процесс под новые реалии.
    Я, как представитель интегратора, прекрасно понимаю, что сближение бизнеса и ИТ, возможность быстро менять процессы – есть. Но с большим количеством ограничений, допущений и нюансов. Именно поэтому, казалось бы невозможное сочетание - BPMS+SCRUM, благодаря которому произошло чудо, имеет место быть.
    SCRUM применялся мной на коммерческом проекте лет пять назад, иногда мы скрывали «внутренний» SCRUM от заказчика, сейчас мы используем элементы SCRUM внутри даже на водопадных проектах, и если честно, то я вижу, что преимущества этой методики управления прямо проистекают из ситуаций, когда её выгодно применить:

    • Заказчик не знает, что необходимо, а-ля «хочу сайт, ну… личный кабинет». Если сказать более обобщённо, то нет ТЗ. Это позволяет вообще выкинуть этот обязательный для «водопада» этап. С одной стороны, экономия есть, с другой стороны, привязка к партнёру становится катастрофичной, да и сам исполнитель «подсаживается» на ключевых сотрудников. Вы думаете полетел бы Гагарин в космос, если бы ракету строили по SCRUM?
    • Исполнитель не знает инструментов/технологий. Такой подход позволит начать проект с минимальным знанием, изучая технику и предметную область на ходу. Опять же – экономия. Правда, цена ошибки на начальном этапе, может вылиться в грандиозные затраты потом.
    • Оценить сроки и бюджет не получается, ввиду причин из первых двух пунктов.
    • Нужны быстрые результаты, но при этом ваш бизнес не «встанет колом» при их отсутствии.
    • Команда проекта не сформирована или не фиксирована, состав постоянно меняется, или это внутренний (читай не коммерческий) проект. Здесь SCRUM поможет всех «загрузить» работой, а объяснять малые темпы не требуется.
    • Ваша команда устала от однообразия, нужно привнести драйва, вы не можете найти других способов для мотивации, а текущая эффективность никого не устраивает.

    Мне кажется, что на открытом конкурентном рынке заказчик вряд ли примет решение в пользу SCRUM, потому что основной минус SCRUM: не ясные результаты за непонятный бюджет. Покупатель, очевидно, предпочтёт SCRUMу определённые сроки и цифры с известным результатом. Но если у меня будет возможность с каким-нибудь заказчиком «пойти на SCRUM» я ей непременно воспользуюсь.
    Я тоже за скрам!

    • 19.11.2014 18:54

      Как человек, имеющий команды разработчиков в штате, и работающий с аутсорсерами, согласен с Георгием. По СКРАМ хорошо работать, когда у меня сидит штатная команда, а запросы от подразделений меняются по два раза на день. Тогда работа спринтами имеет смысл - мы сразу выдаем заказчику небольшой работающий кусок, а он нас корректирует, правильно ли мы двигаемся или нет. И если заказчику это не нравится - потеря времени на переделки небольшая.
      Но совершенно другая ситуация, когда я заказываю крупный проект у аутсорсера. Меня совершенно не устраивает работа по принципу открытого бюджета. Точнее, меня то она может и устроит. Но вот финансовый директор против. В итоге, мне нужно получить хотя-бы рамочное понимание затрат. А это по СКРАМ сделать практически невозможно. Поэтому приходится по стандартной методике - детальное ТЗ, создание прототипа. После этого опять переоценка затрат и сроков, новое утверждение бюджета, и внедрение. Те по сути, классический водопад.

    • Анатолий Курочкин
      Рейтинг: 25
      Научно-производственное объединение
      Старший инженер, аналитик.
      20.11.2014 14:02

      Короткий, но блестящий анализ!

    • 20.11.2014 17:09

      Уж очень понравилась мне эта тема, позволю себе ещё пару строк. Я, возможно, буду в чём-то противоречить себе же, но есть ещё мысль, которую я пропустил в предыдущем высказывании, т.к. коротко сформулировать её довольно сложно.
      Попробую. Зачастую исполнитель приходит в проект и выполняет работы, начиная с написания требований к системе, потом эти требования согласуются и начинается разработка.
      Не буду рассуждать хорошо это или плохо, когда заказчик не имеет готовых требований к системе, это отдельный большой разговор. Это реальность.
      Одновременно с разработкой решения идут уточнения требований, детализация, иногда трансформация. Наступает этап сдачи решения и тут выявляются несоответствия, мол, не так …, нас не устраивает...
      Далее стандартный сценарий, исполнитель пытается раскрутить заказчика на доп. бюджет, прикрываясь согласованными требованиями. Тут ситуация развивается по-разному, в зависимости от перспектив длительных партнёрских отношений, манящей перспективы развития, обещаний заказчика по заложенному бюджету, дружеских отношений ТОПов и т.д. и т.п.
      Как правило, ситуация решается «баш на баш». Правда, позиция заказчика в этом вопросе всегда сильнее, у исполнителя, по факту есть только один аргумент: «в ТЗ написано …», или даже так: «в ТЗ этого НЕ написано». На что ответ очевиден: «ТЗ писали вы и это ваш промах, что вы не раскрыли эту тему, не дообследовали…».
      Т.е. тут в полной мере раскрывается девиз «Клиент всегда прав». С учётом всего этого можно выделить преимущества SCRUMа:
      SCRUM поможет влиять на совесть заказчика, мол, мы уже 15 раз переделываем авторизацию пользователя, сколько же можно. Т.е. есть надежда, при определённой харизме, «надавить» на заказчика и «продать» не идеальную для него реализацию.
      SCRUM позволит играть важностью требований в надежде, что сложные технически требования можно будет отложить, поскольку они не бизнес критичны. Скажем представитель ИТ может сказать, что подсистема протоколирования его не устраивает, но т.к. требование не мешает бизнесу работать, то до его реализации дело может и не дойти, под предлогом того, что бизнес-требования выполнены
      SCRUM даст возможность «закидать» какого-нибудь представителя заказчика сотнями вопросов, уточнений, предложений, которые сместят фокус…
      Правда, чтобы в полной мере воспользоваться этими возможностями, нужно быть если не гением SCRUM, то тонко чувствовать ситуацию, так сказать «на кончиках пальцев», обязательно. Я не хочу сказать, что это не честно, это искусство - искусство оставит партнёра довольным, но и самому не остаться в накладе, это рынок, это продажа, которая не закончилась в момент подписания контракта, но которая закончится, только тогда, когда закончится проект.
      Я клоню к тому, что иногда исполнителю, даже при фиксированном бюджете и зафиксированных бизнес результатах (а мне сложно представить иного покупателя, проще и эффективнее нанять команду или пойти по пути outstaff), имеет смысл пойти на SCRUM.
      Риск, шампанское, драйв!

      • Анатолий Курочкин
        Рейтинг: 25
        Научно-производственное объединение
        Старший инженер, аналитик.
        24.11.2014 12:17

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

        Георгий Игоревич, так ведь в этом соль! Согласен, это именно реальность, где есть ряд постулатов:
        1. Заказчик всегда прав.
        2. Взялся за гуж...
        3. Заказчик за написание требований, как правило, платит исполнителю деньги.
        Не посчитайте меня противником SCRUM, но в данном случае это не есть основной смысл применения методологии. Ведь и исполнитель к написанию требований, как правило, подходит фоормально ("прошлый раз делали, где-то в архиве поищи"). В старые добрые времена, когда деревья были большие, а суммы в миллион рублей считались запредельными, исполнитель, видя неуверенность заказчика в понимании требований, устанавливал чёткие границы разработки, обрезал проект, предлагал опытную эксплуатацию.
        В Вашем же примере я вижу способ увеличить бюджет понятным заказчику способом. Что, конечно, тоже интересно.

  • Алексей Лапшин
    Рейтинг: 10
    АйТи
    Руководитель проектного сервиса
    24.11.2014 17:02

    Вся дискуссия развернулась в противопоставлении фиксированной для реализации задачи (waterfall) и не фиксированной (scrum), что в корне не верно. Ни та ни другая методология не отвечает на вопрос, что будет реализовано, а отвечают на вопрос. как будет реализовано и кто для это нужен. Это как с геометриями Лобачевского и Евклида (последняя является предельным случаем первой, кстати). Если установить продолжительность sprint во время, отведенное на весь проект, то легко перейдем от scrum в waterfall.
    Scrum позволяет лучше и легче контролировать ход проекта и отслеживать проблемы в нем. Быстрее получать обратную связь от заказчика и не делать пустую работу. Waterfall то же позволяет контролировать. отслеживать и получать. Но для этого требуется много больше усилий и много больше времени.

  • Михаил Петров
    Рейтинг: 809
    Счетная палата Российской Федерации
    Директор департамента цифровой трансформации
    26.11.2014 13:44

    Любая методология имеет область адекватного применения. Scrum требует намного большей квалификации исполнителя - как с точки зрения управления объемом и ресурсами, бюджетом, рисками, так и с точки зрения управления ожиданиями заказчика, требует вовлечения заказчика в процесс и создания определенного рода партнерства. "Классически" воспитанный ИТ-менеджер к такому не привык. Но для некоторых проектов (когда делать надо, в четко понятный срок, что - до конца не понятно, но надо) эта методология - единственный выход. Это надо далеко не всегда - где-то классический подход вполне себе. В ситуации меняющейся среды, когда надо быстро бежать чтобы хотя бы оставаться на месте, scrum все более и более будет востребован.

    • Александр Огнивцев Михаил
      Рейтинг: 12
      ГК РОСАТОМ АО КИС "ИСТОК"
      Директор по информационным технологиям
      28.11.2014 11:16

      Считаю последнюю фразу блестящей характеристикой скрама. Если нужна движуха и общее бурление + заказчик готов платить за это деньги, то лучше скрама не придумаешь. Если нужен просто результат, то лучше использовать проектный подход.

      • Алексей Лапшин Александр
        Рейтинг: 10
        АйТи
        Руководитель проектного сервиса
        28.11.2014 17:25

        Складывается забавное впечатление, что есть проекты, которые реализуются ПРИВЫЧНЫМ методом waterfall. Эти проекты ВСЕ и ВСЕГДА выполняются в срок и бюджет с полной удовлетворенностью заказчика. И вдруг этим счастливым заказчикам предлагают променять свое счастье на неизведанные и сомнительные новые подходы, например, scrum.
        Что-то подсказывает мне, что это не так, is it?

        • Александр Огнивцев Алексей
          Рейтинг: 12
          ГК РОСАТОМ АО КИС "ИСТОК"
          Директор по информационным технологиям
          28.11.2014 17:36

          Действительно забавное впечатление! У меня есть еще более забавное впечатление, что заказчику вместо грамотной проектной команды, предлагают "как всегда", только в другой упаковке и почему-то считают что результат работы будет более другим. Судя по всему системные проблемы в образовании дают о себе знать - не учили про "а вы друзья как ни садитесь...". Ну или учили, но не дошло.

  • Михаил Петров
    Рейтинг: 809
    Счетная палата Российской Федерации
    Директор департамента цифровой трансформации
    26.11.2014 13:46

    Вопрос к автору. Уважаемый Тагир, Мы для себя приняли принципиальное решение – там, где возможно, мы везде будем переходить на скрам и гибкие методологии в целом. Причем будем это делать максимально широко... Ведь внутри компании тоже этот переход мгновенно не происходит. У нас есть пока одно подразделение, которое работает по модели скрам, и есть отдельные очаги в других подразделениях. А где Вы для себя считаете что возможно? Какое подразделение уже так работает и в чем это выражается?

  • Александр Крица
    Рейтинг: 20
    Судебный департамент при Верховном Суде РФ
    Начальник отдела перспективного развития ГАС «Правосудие» Управления информатизации
    28.11.2014 13:42

    Можно привести примеры успешных крупных проектов, реализованных по гибкой методологии разработки ПО, в частности SCRUM?

    • Алексей Лапшин Александр
      Рейтинг: 10
      АйТи
      Руководитель проектного сервиса
      28.11.2014 17:16

      Если говорить о компаниях, которые используют в работе scrum, то их можно посмотреть, например, в этом перечне: https://docs.google.com/spreadsheet/ccc?key=0AgfBeuoRfUzNdDlMNG82SlhmUVRhOEk0REtrdmthNWc#gid=5
      Если говорить о больших проектах, то есть такие классические как проект Sentinel, реализованный в ФБР. Традиционный подход оказался не в состоянии реализовать столь сложный проект, поэтому был дан шанс гибкому подходу. Естественно, при реализации было огромное количество трудностей, но тем не менее только scrum позволит добиться результата. Ещё есть интересный пример у компании Primavera, которая для реализации очередного релиза своего продукта для классического управления проектами, была вынуждена использовать scrum, т.к. waterfall банально перестал для них работать. Можно почитать и о таком примере в голландских железных дорогах: http://www.infoq.com/articles/dutch-railway-scrum.
      Это лишь наиболее цитируемые случаи, кроме них есть и много других. Западный рынок уже более 10 лет активно дрейфует в сторону гибких подходов и классический менеджер проектов без знаний и опыта в гибких подходах становятся динозавром на этом рынке. Мы традиционно отстаем и у нас гибкие подходы используют лишь единицы, поэтому у меня вызывает некоторые затруднение перечислись такие проекты у нас. Пожалуй, могу упомянуть Тинькофф Банк, Люксофт, Peter-Service и Альфа Банк. В проектах Альфа Банка посчастливилось поучаствовать и нам. Все описанное в статье было почерпнуто нами из нашей практики. А в целом цель данной статьи как раз и заключалась в том, чтобы растормошить нашу аудиторию и обсудить почему же в России мы пока так отстаем в его внедрении.

      • Александр Крица Алексей
        Рейтинг: 20
        Судебный департамент при Верховном Суде РФ
        Начальник отдела перспективного развития ГАС «Правосудие» Управления информатизации
        01.12.2014 09:56

        Речь идет не о компаниях, а о проектах. Компания может быть крупной, а проект маленький. Проект ФБР Sentinel не является SRUM в чистом виде. В нем использован смешанный подход с использованием Ajile-методологии http://www.osp.ru/os/2011/10/13012229/

      • Денис Еремеев Алексей
        Рейтинг: 181
        Спецэнерготранс
        Директор по ИТ
        20.02.2015 19:56

        Чем менее успешный бизнес Заказчика - тем менее доволен он на входе в проект , тем быстрее и гибче надо быть исполнителю, а значит использовать rup или agile (scrum, kanban) - легче методология, быстрее идет работа, лучше контакт с Заказчиком, а значит в итоге Он будет более доволен. И да же если по результатам проекта в красивых отчетах будет по-привычке написано, что "мы использовали методологию Waterfall" (типа мы все так и планировали), понятно, что "за кадром" останется много чего. Главное, что цель достигнута и Заказчик остался доволен.

        В Европе уже 10 лет кризис, а у нас, в "Тихой гавани" только началось. Глубина кризиса порождает спрос на RUP и Agile и в частности на SCRUM как "понятный" для Заказчика (не знаем что хотим, но идем примерно туда, деньги если что найдем). Молния ударила, мужик перекрестился, повторил SCRUM и KANBAN и пошел на передовую..

  • 05.12.2014 07:35

    Всем добрый день!

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

    • 26.02.2015 12:51

      http://scrumtrek.ru/ - самые опытные. В двух компаниях именно их привлекали для обучения и постановки процесса

  • Борис Позин
    Рейтинг: 10
    ЕС-Лизинг
    CTO
    30.12.2014 22:03

    Легко спорить, если не приводишь доказательств, если не рассматриваешь объекты разработки в измерениях "Сложность" или "масштаб", суммарная трудоемкость и т.п.
    А вот авторы COCOMO и других методик оценки проектов экспериментально выявили (см. работы Бэма, Липаева, Каперса Джонса), что производительность труда сильнее всего зависит от опыта работы программистов в конкретной прикладной области, от опыта работы в технологической среде, от размера или сложности создаваемого ПО. Почему-то эти важные обстоятельства вообще в нашей дискуссии почти не принимаются в расчет? Неужто опять проджект менеджеры считают, что сумеют управлять чем угодно?
    Кстати, гибкие подходы и Скрам это не одно и то же, хоть автор и пишет об этом. Почитайте, например, свежую (2014 г.) книжку классика Bertrand Meyer. В ней всё нормально: Скрам - один из методов гибкой разработки. И основные особенности Скрам по сравнению с другими методами гибкой разработки приведены. Давайте отделим рекламу и маркетинг от реального производства и реальной технологии.
    Кстати, одно замечание по поводу реплики авторов статьи. Сам "водопад", или "каскад" ничему не препятствует во внедрении гибких методов разработки. Препятствует модель "Fixed Price", которая применяется в госзаказах прежде всего. Не надо бы путать экономику, менеджмент и технику.

  • 26.02.2015 12:45

    Хотел бы отметить, что SCRUM имеет очень ограниченную область применения. Мои аргументы строятся на опыте работы по данной методологии как на стороне разработчика (EMC, Zodiac Interactive), так и на стороне заказчика (Лента). У нас в компании параллельно ведется более 20-ти проекто, из них только в нескольких применяется модель гибких методологий управления проектами, в частности SCRUM. Особенность данного метода: быстрая и гибкая РАЗРАБОТКА НОВОГО еще не существующего продукта в условиях постаяного процесса изменения требований и приоритетов. При внедрениях существующих платформ, SCRUM подход не эффективен. К примеру, можно посмотреть на итерационный подход SAP (ASAP, ASAP Focus и т.п.), который уже многие 10-ки лет эффективно работает. Возможно использовать смешанные подходы, но это уже нельзя назвать SCRUM или гибкой методологией: в своей практике встречал смешанный подход SCRUM + CMMI.

    P.S.: Так же надо учитывать, что SCRUM это в большинстве случаев T&M (time and material), а не Fix Price, поэтому это больше подходить для Research проектов.

Предметная область
Отрасль
Управление
Мы используем файлы cookie в аналитических целях и для того, чтобы обеспечить вам наилучшие впечатления от работы с нашим сайтом. Заходя на сайт, вы соглашаетесь с Политикой использования файлов cookie.