Agile для CIO как концепция и метод управления

11 января 2014
38

Часть 1. Почему Agile — это не серебряная пуля

Часть 2.

Мы открываем серию дискуссий, посвященных практическому применению Agile к управлению проектами, где постараемся объективно рассказать про особенности аджайл-подходов, подкрепив их разбором практических примеров российских и зарубежных проектов. Начнем с границ применимости...

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

Во первых, Agile не является методологией. Это — прежде всего образ мышления, набор ценностей и принципов (см. Agile Manifest), а потом уже набор фреймворков. Это новая система координат и ценностей (?), которая не может существовать локально в отдельной взятой команде или ИТ-департаменте. Она требует сил и энергии для повсеместной «организационной» трансформации.

Пример. «Оптимум системы не равен сумме локальных оптимумов» Э. Голдратт. Часто многие компании рассказывают об успешности внедрения Scrum или XP на уровне команд разработки. Есть итерации, стенд-апы и пр. Но если посмотреть «сверху», то никаких изменений на уровне всей организации не произошло. Точнее, реализовалась локальная оптимизация в ИТ. Нет ожидаемого эффекта, аджайл стал очередной «игрушкой» для программистов. По прежнему продукты выходят в продакшн раз в полгода, с заказчиками не выстроены прозрачные взаимоотношения, а ошибки копятся из релиза в релиз. В этом случае мы реализовали «механический» Скрам — скопировали процесс, но не изменили ценностную систему координат.

—Во вторых, важно понимать, что влияет на выбор инструмента управления проектом. Ведь Agile, как и «waterfall», PRINCE2 или RUP — лишь один из множества существующих подходов. И перед стартом очередного проекта необходимо учесть много факторов, прежде чем выбрать наилучший. В погоне за явными и неявными ожидаемыми преимуществами Agile (выпускать продукты на рынок быстрее, с лучшим качеством и более высокой удовлетворенности клиентов), мы забываем о дифференциации методов, забываем учитывать, когда один подход может быть лучше, чем другой.

Что могут включают в себя эти факторы:

  • Наличие ограничений (объем, сроки, бюджет)

  • Особенность клиентов

  • Количество рисков

  • Доступные ресурсы

  • Изменчивость требований

Пример. Очень часто аджайл становится некоторым «абсолютным оружием» в компании. Мы торопимся его применять (а скорее всего — пытаемся применять) для всех проектов, объясняя последующие неудачи недостаточным опытом, очередной неработающей в отечественных условиях западной методологией, плохим переводом :) и пр.

Так что же такое аджайл — «серебряная пуля» или очередной БОЛЬШОЙ миф? Где границы применимости? Почему для одних проектов эффект применения есть, а для других приводит к провалу? Возможный вариант ответа будет в нашей следующей дискуссии, в который мы поговорим о Модели Кеневин (Cynefin framework) и теории запутанности.

Но прежде интересно узнать, был ли в вашей практике опыт выбора между подходами к ведению ИТ — проектов? Какие методологии вы обычно используете и с каким результатом? Один из лучших недавно услышанных ответов был таким: «мы стараемся действовать по PMBOK, но получается аджайл...» Это ваш случай?

8050
Поделиться
Коментарии: 38

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

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

    1. Внутреннюю разработку постарались выстроить по принципам Agile, но документирование не запускаемю
    2. Agile - не только разработка ПО.
    3. Часто за проповедью Agile прячут обычный бардак.
    4. Agile требует достаточно высокого самосознания и ответственности участников процесса.
    5. Agile в разработке ПО требует достаточно высокий профессиональный уровень участников.
    6. Пока плохо выстраивается при большом количестве участников и территориальной распределенности проектов.
    7. IMHO, Agile (за пределами разработки ПО) крайняя степень развития "живой" полносвязной организационной структуры предприятия.
    «Классика» vs Agile — Pro и Contra - в этой дискуссии на площадке Михаил Петров попробовал эту тему развить, но большого интереса, к сожалению, она не вызвала.

    • Алексей Пикулев Марк
      Рейтинг: 10
      Unusual Concepts
      Agile Coach
      13.01.2014 15:39

      Добрый день, спасибо за подключение.
      А можно про 7 пункт - как у вас работает Agile за пределами разработки?

      • Марк Шварцблат Алексей
        Рейтинг: 10
        КТ "Акведук"
        ИТ-директор
        13.01.2014 22:41

        1. Частично внедрили принципы для удаленных точек продаж. Это дало увеличение продаж. Т.е. консультантам дали возможность гибко реагировать на запросы клиентов и так же гибко пытаться их удовлетворить. Увели от жесткого следования процедурам писанной технологии и перенацелили на результат.
        2. Так же использовали при открытии новых магазинов, т.к. никакого конвейера не было и каждый проект был чрезмерно уникален, то все прописать было нереально. Гибко и на горизонтальных связях проектных групп решали проблемы.

  • Виктор Федько
    Рейтинг: 217
    АО МПО им.И.Румянцева
    Зам. начальника управления информационных технологий
    13.01.2014 13:25

    Пользуюсь и применяю довольно часто.
    Хорошо там, где :
    1. Надо быстро (быстрее чем вам хотелось бы)
    2. Есть хороший контакт на уровне бизнес-заказчик-разработчик-программист. то есть, когда все друг другу помогают и объединены одной целью - сделать, а не придумать , почему это сделать нельзя. А также, если ставят другу другу задачи, а не подножки)).
    3. Высокий профессиональный уровень участников - ДА, необходимо.
    4. Согласен с тем, что это больше подходит не к глобальному проекту , а больше к "подпроектам" или к "подзадачам". И да, желательно, без территориальных разгулов.
    5. Насчет бардака тоже случается, уж больно удобно ))). но , если бардак хорошо управляем и грамотно выстроен , плюс еще и результат есть - так и ничего страшного. Ничто в этом мире не идеально).

    • Алексей Пикулев Виктор
      Рейтинг: 10
      Unusual Concepts
      Agile Coach
      13.01.2014 15:43

      Добрый день
      По пункту 2 согласен - а не это ли одна из 4 строчек в Agile -манифесте. Ведь залог успеха - взаимодействия сторон :) По глобальным проектам. А как вы проводите границу глобальности? Можно ли спланировать его заранее?

      • Виктор Федько Алексей
        Рейтинг: 217
        АО МПО им.И.Румянцева
        Зам. начальника управления информационных технологий
        13.01.2014 15:56

        Спланировать глобальность проекта? Пожалуй, можно. Но только на некоем интуитивном, эмпирическом уровне.
        Пример: глобальный - это , что я сейчас практически закончил. Примерно 6-7 летняя работа по переводу старой системы на новые ИКТ.(Не я проект начинал). Продолжается развитие и насыщение новым функционалом, которого раньше не было и который бизнес-заказчик требует все сильнее и сильнее. Развитие разбито на те самые "подпроекты" и "подзадачки". И вот довольно приличную их часть мы и ведем именно этим методом. При том, что все бизнес-процессы стандартизованы, описаны, затверждены и обложены регламентами и инструкциями. Иначе у нас нельзя - слишком сложное и высокотехнологичное производство. Есть ТРП КИС, который, конечно, требует еще уточнения и доработки.
        И вот эта методология очень помогает - я вывожу на программиста-разработчика на конкретного пользователя, снимаю первый пласт требований, далее разработка, показ, замечания и т.п. По кругу.Это происходит на 1С и БааН. Частичнов в TCS. Когда придем к консенсусу , опишем, задокументируем.
        Если бы я начинал проект с нуля - по этой методологии не пошел бы. Слишком велики риски утонуть во всех направлениях. Нужно конечную модель видеть и к ней двигаться. А вот по дороге, частично, можно и применять. но с большой осторожностью.

        • Алексей Пикулев Виктор
          Рейтинг: 10
          Unusual Concepts
          Agile Coach
          13.01.2014 16:06

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

          • Виктор Федько Алексей
            Рейтинг: 217
            АО МПО им.И.Румянцева
            Зам. начальника управления информационных технологий
            13.01.2014 16:19

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

          • Марк Шварцблат Алексей
            Рейтинг: 10
            КТ "Акведук"
            ИТ-директор
            13.01.2014 22:51

            План не может поменяться на 100%, если внешняя среда не сильно изменяется. Если это произошло, то планировщика такого уровня надо гнать пасти коров. :)

            • Алексей Пикулев Марк
              Рейтинг: 10
              Unusual Concepts
              Agile Coach
              14.01.2014 08:38

              Тогда думаю, что нужно перейти от термина Глобальный проект - к другим. Поскольку и глобальный проект, и неглобальный могут реализоваться в совершенно разных "средах", окружениях.

    • Михаил Петров Виктор
      Рейтинг: 213
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      21.01.2014 11:36

      по п. 5 - так это и есть инструмент управления бардаком :)

  • Виктор Федько
    Рейтинг: 217
    АО МПО им.И.Румянцева
    Зам. начальника управления информационных технологий
    13.01.2014 15:58

    Вот бы еще добавил - эту методологию применял на предыдущем месте работы в 90-х годах, задолго до появления Манифеста)). Не знал только, что это так красиво впоследствии назовут.))). Думаю, не я один.

    • Алексей Пикулев Виктор
      Рейтинг: 10
      Unusual Concepts
      Agile Coach
      13.01.2014 16:06

      Много там от здравого смысла конечно :)

      • Виктор Федько Алексей
        Рейтинг: 217
        АО МПО им.И.Румянцева
        Зам. начальника управления информационных технологий
        13.01.2014 16:09

        Еще как много. Собственно, с этого , я думаю, почти все начинали. А уж потом назали это методологией)))

        • Алексей Пикулев Виктор
          Рейтинг: 10
          Unusual Concepts
          Agile Coach
          14.01.2014 08:38

          Увы, только вот Agile - это скорее не методология. Я бы лучше применял бы образ мышления :)

          • Виктор Федько Алексей
            Рейтинг: 217
            АО МПО им.И.Румянцева
            Зам. начальника управления информационных технологий
            14.01.2014 08:43

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

            • Михаил Петров Виктор
              Рейтинг: 213
              Счетная палата Российской Федерации
              Директор департамента цифровой трансформации
              21.01.2014 11:38

              ...а затем пиарится под каким-либо лейблом :)

    • Михаил Петров Виктор
      Рейтинг: 213
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      21.01.2014 11:37

      воистину

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

    The J-School Scrum: Bringing Agile Development Into the Classroom

    agile_broussard_sized.jpg

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

    Can Agile Thrive in the Large Enterprise

    Large organizations are usually more complex, with variety of culture or sub-cultural elements, therefore, it is more like to be managed via rigid processes, so can Agile succeed in such a large company environment, or to rephrase it, can Agile values and philosophies succeed in a big company?'

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

    Ideal Agile Scrum Sprint Length

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

    Implementing Agile in Fortune 1000 Companies

    Least Common Denominators of Agile
    Agile is meant to be simple, but like all processes that start simply, it can quickly spiral out of control as layers are added and canonized in an attempt to standardize behavior. As a result, there have been tens of thousands of pages written about agile. But in this article, we are going to try to do the exact opposite and distill agile to its least common denominators. Agile can be broken down into three main process themes: artifacts, ceremonies, and engineering techniques.

    The Old with the New
    When the Agile Manifesto was published in 2001, it ushered in a time period of rapid agile software methodology adoption by IT organizations. Research began to show organizations that adopted agile practices created software with higher quality, better return on investment, and greater stakeholder satisfaction while delivering solutions faster and less expensively than traditional waterfall approaches. However, contrary to those statistics, on large enterprises within Fortune 1000 organizations the authors started to see high-profile project failures associated with agile strategies. Without a more disciplined approach to agile at the enterprise level, the agile movement will risk losing the hard-earned momentum agile pioneers have worked to generate. Sometimes it is better to adopt the least common denominators of a process and create a hybrid of new and old than to throw away the old and adopt a purist framework.

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

    How to Measure KPIs in Agile

    Agile is not about free thinking or doing without structure, Agile is complimentary methodology of Waterfall, add the flexibility on the rigidity; accelerate speed of the hierarchy; create cascade from steep slope, etc. Agile does not take less discipline, but needs more engineering and management discipline, thus, how to measure KPIs in Agile is also critical in Agile project success.

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

    Waterfall to Agile Transformation

    Although Agile has been adopted by mainstream and has been proven with advantage for better improvement and speed, how does a group or a company move from typical waterfall environment to agile methodologies?

    • Алексей Пикулев Марк
      Рейтинг: 10
      Unusual Concepts
      Agile Coach
      14.02.2014 10:18

      Возвращаясь к этой мысли - как перейти от waterfall environment к agile methodologies?

      • Марк Шварцблат Алексей
        Рейтинг: 10
        КТ "Акведук"
        ИТ-директор
        15.02.2014 15:13

        Сложный вопрос. Я не думаю, что для "как" можно составить какой-то четкий вменяемый план перехода от классического процесса к Agile. Тут ведь основная проблема в головах подвижки сделать, а это долго и сложно. У меня сложилось мнение, что Agile можно "привить" в организации только сверху и только с использованием методов самого Agile. Своего рода "метод научного тыка с последовательным приближением к требуемому результату".

        • Виктор Федько Марк
          Рейтинг: 217
          АО МПО им.И.Румянцева
          Зам. начальника управления информационных технологий
          15.02.2014 16:46

          с последовательным приближением к требуемому результату".

          Именно, что только сверху. Если позволяют условия и если есть понимание "верхов" А не все "верхи" к такому готовы, тут действительно нужно "новое мышление".

        • Алексей Пикулев Марк
          Рейтинг: 10
          Unusual Concepts
          Agile Coach
          17.02.2014 10:23

          Полностью согласен. Не может быть "внедрен" Agile - это в первую очередь изменение мышления и много другого на уровне всей организации. Я планировал пообсуждать про трансформацию в отдельной дискуссии.

          • Виктор Федько Алексей
            Рейтинг: 217
            АО МПО им.И.Румянцева
            Зам. начальника управления информационных технологий
            17.02.2014 11:14

            Да чего там в отдельной то. И тут можно, раз пошла такая пьянка))

          • Марк Шварцблат Алексей
            Рейтинг: 10
            КТ "Акведук"
            ИТ-директор
            17.02.2014 15:54

            Coach - барин... :)

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

    Agile Introduction For Dummies - WATERFALL vs. AGILE METHODOLOGY

    There is no IT meeting that does not talk and debate endlessly about Waterfall vs. Agile development methodologies.Feelings run strong on the subject with many considering Agile ‘so of the moment’, just so right, while Waterfall is thought to be passé!But, before deciding which is more appropriate, it is essentially important to provide a little background on both.

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

    Agile Comes to Data Integration

    "Data integration projects take too long," says Todd Goldman, vice president and general manager of Enterprise Data Integration & Data Quality at data integration specialist Informatica. "Part of the reason they take too long is because data integration projects start with a specification from the business, usually in the form of an Excel spreadsheet."

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

    Agile Principles vs. Rules

    Leadership is about "why", to discover the underlining leadership or business fundamental principles. Management is about "what", to define the rules based on the set of principles. More specifically, what are the difference and correlation between principles and rules, at today’s Agile working environment or beyond?

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

    Можно запросить в почту полный отчет. Может быть даже на нашем сайте его выложить.

    8th Annual State of Agile

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

    Is Agile a set of Principles or Practices?

    Agile originally started out as a revolution against rigid, dogmatic practices, but the ironic is that the way some people practice Agile has come full circle back to that rigid adherence to the mechanics of how practices are implemented and have lost sight of the original intent of Agile. So here is an interesting debate: Is agile a set of principles or practices?

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

    Философское отступление...

    Can a Team be Scrum without Retrospectives?

    You can be agile without retrospectives, but it’s a very, very rare team who can. I have run into a few. They’ve usually been doing XP for a while, and are always co-located. Some teams did the retrospective because they were supposed to, but never really came up with anything new. What they were able to do was to inspect and adapt at the drop of a hat. These teams also found that daily standups had become redundant.

Предметная область
Отрасль
Управление