О (гибких) методологиях

    Я не отношусь к лагерю сторонников или противников той или иной методологии. Это инструмент, который в умелых руках творит чудеса, а в неумелых чудеса не творит. Ранее я уже немного писал о трендах, возведенных в культ, в списке которых гибкие методологии (в просторечии — эджайл), на мой взгляд, занимают важное место. В этой статье тезисно пройдемся по основным моментам использования методологий, в том числе гибких.

    image

    Плохих и хороших методологий не существует. Существуют подходящие, и не подходящие.

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

    Перед тем, как внедрять методологию нужно составить список причин, почему эта методология не подойдет. В светском мире это называется “оценка рисков”.

    Все споры о том, нужна ли документация или нет, нужен ли PM или нет и т.д. бессмысленны без рассмотрения конкретной команды/заказчика/условий.

    В agile методологий есть один очень существенный недостаток — коллективная ответственность (т.е. её полное отсутствие на практике).

    В случае успеха можно сказать, что всё это стало возможным только благодаря методологии. В случае фейла, в принципе, также можно сказать, что это «просто методология как-то по дебильному была внедрена». Например, скрам-доску ошибочно повесили на западе, а нужно было на востоке.

    «Чистых» внедрений тех или иных методологий в реале практически не существует.

    Agile — это как HTML5 на мобилках. На словах круто, но все педалят нативные приложения.

    Есть мнение, что те, кто не любит agile — просто не умеют его готовить (внедрять). Ок.

    Два самых эпических внедрения скрама моей практике: 1) внедрение в research & development проекте (R&D — это когда любая оценка задачи неточна чуть более чем полностью) в команде из одного человека 2) внедрение скрама в команде, которую еще не набрали. В обеих случаях проекты завершились эпическим фейлом.

    Нужно ли изучать различные методологии? — Да. Нужно ли применять одну методологию? — Нет.

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

    Методологии — ничто, люди — всё.

    Ну и качестве завершения анекдот в тему: — Здравствуйте! Перепишите на меня свою компанию. — Что!? — Ой, извините, не с того начал. Вы используете Agile?

    Спасибо за внимание!
    • +2
    • 19,1k
    • 7
    Поделиться публикацией

    Похожие публикации

    Комментарии 7

      +5
      в команде из одного человека

      в команде, которую еще не набрали

      Да, они не умеют его готовить.
        0
        Уважаемые наши Мартины (Роберт Мартин и Мика Мартин) не смотря на перечисления всех преимуществ Agile'а всё-таки ставят в главенство взаимоотношения людей в команде. Нет людей — нет взаимоотношений — не скрама — скрам плохой.

        На счёт применения разных методологий — ещё один повод потом ругать, что, мол, методология не такая, а просто вязли и замиксовали всё в кучу. Есть даже понятие: scrum-but (на хабре была статейка весной этого года).

        И раз уж Agile — это манифест, то лучшую практику выбирает уже команда, а они есть: scrum, crystal, kanban и т.д.
          +4
          Картинке 40 лет!!! Надоело на нее смотреть :(

          За текст — спасибо. Кратко и по делу…
            0
            Подозрительно напоминает посты о преимуществах\недостатках ООП и ФП и пр.
              0
              ой
                0
                Когда мы вводили «гибкую» методологию, то сразу оговорили, что будем строить свой Scrum, с рулеткой и легкодоступными женщинами. Иначе какая же она гибкая тогда? Мне кажется, глупо следовать каким-то догмам, если применять их в разрезе твоей деятельности просто неэффективно.
                  0
                  Еще нужно добавить определение agile из UrbanDictionary:

                  1. (verb) To work on something when you don't understand the problem space, the market, the actual goal of the product or really any engineering at all.

                  2. Agile is a generalized term for a group of anti-social behaviors used by office workers to avoid doing any work while simultaneously giving the appearance of being insanely busy. Agile methods include visual distraction, subterfuge, camouflage, psycho-babble, buzzwords, deception, disinformation, and ritual humiliation. It has nothing to do with the art and practice of software engineering.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое