Портал №1 по управлению цифровыми
и информационными технологиями

Agile ITSM

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

Основные причины обратиться к Agile – неудовлетворенность сроками внедрения решений/процессов и соответствия результатов требованиям в динамично меняющейся среде.

Итак, что такое Agile применительно к внедрению и развитию процессов?

Берем Agile manifesto (есть терпимый перевод на Википедии). Выписываем. Меняем слова.

Ценности Agile:

1. Individuals and interactions over processes formal rules and tools.
Личности и их взаимодействие важнее, чем формальные правила и инструменты

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

2. Working software processes over comprehensive process documentation.
Работающий процесс важнее, чем полная документация по нему

3. Customer collaboration over contract negotiation.
Сотрудничество с заказчиком важнее, чем контрактные обязательства

Это не очень четко ложится на процессную тематику, но тоже поддается расшифровке.

4. Responding to change over following a plan
Реакция на изменения важнее, чем следование плану

Аналогично корректируем
Принципы Agile:

  • удовлетворение клиента за счёт ранней и бесперебойной поставки ценного ПО процессов, приносящих пользу;
  • приветствие изменений требований, даже в конце разработки (это может повысить конкурентоспособность работоспособность полученного продукта процесса);
  • частая поставка рабочего ПО обновление процесса (каждые несколько месяцев или недель, желательно – чаще);
  • тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;
  • проектом должны заниматься мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;
  • рекомендуемый метод передачи информации — личный разговор (лицом к лицу);
  • работающее ПО работающий процесс — лучший измеритель прогресса;
  • спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок;
  • постоянное внимание на улучшение технического мастерства и удобный дизайн;
  • простота — искусство НЕ делать лишней работы;
  • лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды
  • команда регулярно должна искать пути стать более эффективной, найдя – начинать вести себя соответственно

Ключевое отличие подходов waterfall и agile:

  • waterfall фиксирует scope (требования), стоимость и сроки являются зависимыми величинами
  • agile фиксирует срок (продолжительность итерации), scope является зависимой величиной

Очевидные плюсы и минусы:

Плюсы:

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

Минусы:

  • существуют риски получения конечного результата (в нашем случае – полноценного всеохватывающего процесса) в более долгие сроки, чем при waterfall подходе
  • более высокие требования к квалификации и дисциплине команды, чем при waterfall
  • Agile практически не совместим с Fixed-price контрактным подходом, подходит только для внутренних процессных команд или внешних подрядчиков, к которым у заказчика есть полное доверие
  • предполагает частые, но небольшие изменения процесса, что каждый требует дополнительной организационной работы (хотя непонятно, почему ИТ не так сильно заботит то, что бизнес каждый раз должен корректировать свои процессы при выходе новой версии ПО)
  • Agile считается ограниченно годным для критичных для организации ПО процессов (хотя к ИТ это может относиться только разве что к Incident Management, и то не везде) и для крупных проектов (хотя я пока не видел ITSM проекта, в котором бы участвовало более 20 проектировщиков).

Минусов вроде как получилось больше, но плюсы таковы, что могут все их перевесить. Могут?

Комментариев: 13

  • Vladimir Tarasoff

    Думаю, что могут. Пробую, как раз сейчас на практике.

    Кстати, в случае с ITSM, я бы обратил внимание на Lean и Kanban принципы больше, чем на манифест. 🙂

    И ещё. Если не трудно, поясните вот это утверждение примером:
    Agile практически не совместим с Fixed-price контрактным подходом, подходит только для внутренних процессных команд или внешних подрядчиков, к которым у заказчика есть полное доверие

  • Александр Тараторин

    Владимир, согласен, что можно было бы посмотреть и на Lean, и на Kanban принципы, но мне именно принципы Agile показались ближе к собственной практике.

    Что имелось в виду про fixed-price:
    может быть, я погорячился про несовместимость, но мне трудно представить ситуацию, в которой под каждую ежемесячную (например) итерацию заключается отдельный контракт или доп.соглашение, да еще и без жестко зафиксированного scope. Time&material контракт здесь выглядит более уместным, но много ли найдется заказчиков, которые будут готовы покупать консалтинг на условиях time&material без полного доверия к подрядчику?

    • Согласен, Time&material и Agile идут рядом по своей сути. Однако есть же примеры применения Time&material в крупных проектах, которые совсем не Agile – те же внедрения/доработки ERP.

      Не хочу сказать что там всё гладко, скорее, как правило, наоборот. Но Time&material не является совсем уж стопором.

  • Георгий

    Минус №2 и минус №4 фактически констатирует то, что это применимо в крайне ограниченном кругу компаний/людей
    Минус №1 наверное следует читать как “риски получения конечного результата (в нашем случае — полноценного всеохватывающего процесса) в более долгие сроки существенно выше, чем при waterfall подходе” что тоже не добавляет оптимизма 😉

    Т.е., как ни банально это прозвучит, в подавляющем большинстве компаний минусы перевесят плюсы. в 1-5% компаний плюсы перевесят минусы.

    Идея прекрасна и интересна. Не для всех.

    • “Не для всех” – и с этим согласен! 🙂

      Универсальности никто не обещал, вроде бы.

      • В принципе, возможен вот такой подход. Проводится обследование, в нём фиксируется программа по развитию системы управления ИТ скажем на год (или дольше). Дальше какие-то задачи из этой программы делает сам заказчик, и здесь применение Agile вполне возможно, без отягчающих последствий T&M контрактов. А для решения каких-то (более сложных?) задач привлекается подрядчик. При этом если задачка для подрядчика крупная, но более-менее типовая, она может решаться традиционным подходом. А если задачка помельче или постановка задачи очень нечёткая, то даже независимо от приверженности Agile это может быть T&M (во всяком случае в нашей практике такие примеры есть).
        Таким образом, общая программа развития задаёт вектор движения, а отдельные задачи решаются с применением Agile или без оного, как удобнее в каждом конкретном случае.
        Это по-моему вполне возможно. Хотя тоже не для всех заказчиков:
        1. Во-первых, только для тех, кто сам “питает слабость” к Agile.
        2. Во-вторых, для тех, кто действительно готов самостоятельно вкладываться в развитие внутренней системы управления, даже при отсутствии грандиозных бюджетов на “большой” консалтинг.
        3. В-третьих, для тех, у кого нет хронического неприятия такой формы работы, как обследование (такое бывает).

        • На мой взгляд – вполне рабочий подход. Частично опробован даже.

          • Георгий

            опробован неоднократно – работает.
            Правда раньше не знал что это Agile 🙂 (если бы Остап Бендер узнал что играет такие мудреные партии, он бы удивился, тк играл в шахматы второй раз в жизни)

            И все равно идея – не для всех.

  • Александр Тараторин

    Минус №1 наверное следует читать как «риски получения конечного результата (в нашем случае — полноценного всеохватывающего процесса) в более долгие сроки существенно выше, чем при waterfall подходе» что тоже не добавляет оптимизма
    Если более развернуто:
    – в случае с waterfall у вас есть серьезные риски получить результат, который точно соответствует букве написанного в уставе проекта/контракте, но бесполезен вам как заказчику. В худшем случае – проект вообще может не завершиться.
    – в случае с agile вероятность получить полезные результаты гораздо выше, но общее время пути к цели может быть больше, чем сроки, указанные в том же waterfall-ьном уставе проекта/контракте.

    • Георгий

      Да, все как всегда упирается в стратегию и цели организации в целом и ИТ в частности. Бесспорно Agile подход очень интересен и может позволить получить большие преимущества тем, кто его использует.

      Вообще это конечно будоражит и мотивирует активных, высококлассных специалистов и манифест и такое отношение – это само по себе супер 🙂

  • Тема конечно очень неоднозначна. Как подход к организации проектов с вовлечением внешних консультантов, это конечно будет работать далеко не всегда. Но, во-первых, внутренние активности по оценке, контролю и совершенствованию процессов вполне могут жить по таким законам. А во-вторых, внешний консультант мог бы помочь в такой организации (а для нас это важно, поскольку мне вообще кажется, что контроль, оценка и совершенствование процессов – это абсолютно необходимые активности, не запустив которые едва ли можно надеяться, что процессы “будут жить”).
    То есть мне не кажется, что тема исключительно академична, практика ближе, чем может показаться.

    • Александр Тараторин

      Вброшу еще одну спорную мысль для дискуссии:

      Есть один вариант, при котором Agile ITSM будет работать, а стандартные крупные проекты, скорее всего, вообще не стартуют или провалятся – внедрение при отсутствии поддержки высшего руководства.
      Предположим, что есть крупная организация (сразу оговорюсь – речь не о текущем месте работы 🙂 ), в ней – немаленький ИТ, и высшему руководителю ИТ на ITSM….. Ну не верит оно в волшебную силу процессов, особенно сделанных в соответствии с забугорной методологией. В то же время, в ИТ есть менеджеры, которым это жизненно необходимо. И вот здесь появляется почва для небольших решений, которые могут развиваться, доказывая свое право на жизнь через реальные небольшие успехи, и постепенно расти, завоевывая авторитет и для их участников, и для методологии в целом.
      Стандартный консалтер с “болшим” проектным подходом в такую кашу не полезет – слишком велики риски, а вот Agile в исполнении внутренней команды, подкрепленной внешним опытным мозгом (как вариант), вполне может оказаться успешным. Что приходилось встречать в реальной практике.

      • Я думаю, здесь специфика глубже, чем только форма организации работ.

        Agile – это практика регулярных изменений, выполняемых чётко по графику. В ходе разработки ПО постоянные изменения – это понятное состояние. Но с организационными изменениями всё гораздо сложнее – их обычно стараются пережить, а не поддерживать. Agile в ITSM – это выработка у организации “привычки” (в терминологии Стивена Кови) к постоянным _организационным_ изменениям. Само стремление к этому, мне кажется, может идти только изнутри, консультант не сможет его “навязать”. Поэтому – да, не для всех. И поэтому же дело далеко не только в T&M (и вообще не только в привлечении подрядчиков).


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM