Пользователь
0,0
рейтинг
22 июля 2012 в 15:24

Управление → Agile: танцы с бубном или наука

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



Понять последних можно, ведь большинство статей и agile-евангелистов говорят, примерно следующее: «Делайте так, как говорит методология, и ваш проект попадёт в рай. Если нарушите хотя бы одну из практик, то Agile покарает вас»

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

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

А как нас учили смешивать краски? Преподаватель рисования сказал: «Смешайте синюю краску и жёлтую, получится зелёный цвет». Как?! Почему?! Это не нужно знать, это нужно просто запомнить. А потом, в общем, то у кого-то получалось рисовать, а у кого-то не очень.

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

НО! Не всё так плохо. Есть уже немало специалистов, и даже в России, которые пытаются научно подойти к Agile. Находят обоснования практикам, используя имеющиеся научные теории, ставя эксперименты, делая замеры, строя графики и даже рассчитывая показатели по формулам :) Сегодня приведу ссылки на тех, кого я знаю.

Максим Дорофеев


Макс во всю изучает и пропагандирует использование теории управления качеством, теории управления производством и мат. статистики в Agile.

Борис Вольфсон


Борис досконально изучает все практики и всегда зрит в корень проблем, лишь потом предлагает решения в отличие от некоторых Agile-фанатиков, которые «выкрикивают» первое попавшееся agile лекарство хоть немного подходящее к контексту проблемы. Он также как Максим любит мат. статистику и теории менеджмента.

Тимофей Евграшин


Тим – больше практик, чем теоретик. Т.е. он к науке подходит эмпирическим путём: пробует практики, находит подводные камни, адаптирует и улучшает, а потом документирует. Эксперимент для науки не менее ценен, чем теория, потому дам слайдкаст для затрави и ссылку на блог.

Что ещё есть полезного




PS: Вообще ещё есть куча ссылок на интересные и полезные статьи, касты и людей. Но раз уж сказал, чисто за науку, значит за науку :)

PPS: Буду рад если накидаете ссылок ещё на подобные источники с научным подходом к Agile (можно на английском)
Денис Тучин @Kaitaku
карма
24,6
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Управление

Комментарии (59)

  • +2
    Если интересуют инженерные практики, я бы посмотрел в сторону Николая Алименкова — xpinjection.com/, лин и канбан — это Асхат Уразбаев (http://zibsun.livejournal.com/), продуктовое управление — Никита Филиппов (http://www.slideshare.net/Nfilippov).

    По поводу затронутой темы очень согласен: просто не надо без оглядки слушаться «тренеров-теоретиков», которые в своей жизни ни сделали ни одного проекта.
    • 0
      Коле, да, зачёт. С инженерными практиками всё проще их используют практически все. Там всё понятно.
      Я бы не сказал, что Асхат и Никита рассказывают что-то больше, чем карго-культ, по край ней мере на конференциях и в статьях.
    • 0
      Ну про Асхата с Никитой я погорячился, конечно. Я имел в виду их теоретические рассказы. Их практический опыт, конечно, без ценен
      • 0
        Денис, а какие продукты сделал Никита, если вы считаете бесценным его опыт?
        • 0
          Я не в курсе его продуктов. Я говорю про опыт консультирования команд, когда он получал фидбэк по тем практикам, которые принимала команда
        • +1
          Дабы снизить троллинговую составляющую дениса

          Денис, в компании Бегун я запустил 6 сервисов (2007-2008) начиная от договоренностей с партнерами, заканчивая «пресс-релизами».

          Самый первый продукт который я запустил, был запуск проекта testbox.com на западный рынок 2006 (к сожалению ныне умерщвленный компанией Агава). Гордиться там было не чем но тем не менее вроде как сервис зарабатывал.

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

          Ну и самым главным продуктом своей жизни на данный момент считаю компанию ScrumTrek, которая тоже вроде бы не на ладан дышит. Чем очень горжусь.
          • 0
            буду рад порадовать тебя выходом нового «продукта» в ближайшие 6 месяцев…
          • 0
            Было бы здорово, чтобы ты написал об этом где-то в профиле, типа этого: scrumtrek.ru/company/team/

            Также интересно где-нить прочитать, почему ты сменил формат деятельности с управления продуктами на консалтинг.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +8
      Ну я так понимаю не используют всякие мелкие конторки типа тех, которые пишут софт для NASA или Boing. Но там сидят всякие старые пердуны которые никак не осознают преимущества Agile и по старинке пишут километровые спецификации и планируют все на годы. Никакой гибкости и релизы раз в пять лет.
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Есть замечательная альтернатива Agile-методикам.
          Серьезные интернет-проекты (скажем топ 500 алексы). Покрытие кода тестами (unit, functional, regression); команда QA, превышающая численность разработчиков; вменяемые PM/PA, планы на месяцы вперед.
          Это, конечно, только мнение — но agile нет места в этом мире. Ну а стартапы… Тут недалеко топик есть :)
          • 0
            кто вам сказал, что они не используют Agile практик?
            Agile на самом деле просто собрал все хорошие практик, которые применялись как раз лучшими в индустрии.
            Кстати, Кент Бек (один из авторов Agile манифеста) работает в Facebook'е
            • +1
              Ну тут, честно говоря, уже спор о терминах (я сам дурак, первым начал).
              Да, эти практики в большинстве своем — просто формализация здравого смысла.
              Нет, «готовые решения» (фиксированные наборы практик, объединенные под одним громким названием) не универсальны.
              Continuous integration — прекрасно, pair programming — прекрасно, TDD — прекрасно. Все три вместе — применимы дай бог в 10% случаев.
              Пока agile-практики не являются самоцелью, они вполне полезны и здравы
              • 0
                Подпишусь под всем выше сказанным)
      • –2
        по вашему километровая спецификация для космической станции это излишество?
        негибкие пердуны значится?

        всякой вещи — свое место. не стоит своей единственной амбразурой оценивать вемь мир.

        • +3
      • 0
        Тут была недавно статья про авионику (поищите если интересно). У них хоть и горы спецификаций, но вполне agile — делают они все небольшими итерациями.
    • +2
      У каждого подхода есть свои плюсы и минусы. Почитайте, для начала, статью Джоэла Спольски — Пять миров. Она старенькая, но полезная. Так вот, Agile это больше «ширпотреб» и «внутреннее ПО» из статьи. А вот если вы будите разрабатывать систему управления ядерным реактором по методологии Agile, то я бы не хотел жить рядом с АЭС, на которую поставят результат вашего первого спринта, для демонстрации его заказчику.
      Но в указанных областях, да, Agile хорош. Я, например, участвую в разработке внутреннего ПО и практикую именно его.
      • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Вообще-то в статье Спольски «ширпотрёбом» и «внутренним ПО» названы не методологии разработки, а типы ПО.

        И кто сказал, что аджайл не подходит для ядерных реакторов? Распространённый миф, но это полная ерунда.
        • 0
          Так как делают ПО для ядерных реакторов? Поделитесь инфой плиз если имеется.

          У меня подозрения, что если там и имееются элементы agile, то никто кроме создателей agile manifesto не распознает их.

        • 0
          Впрочем, если брать суть agile в самом общем понимании, то он будет присутствовать в любой методологии разработки ПО. По той простой причине, что agile — это набор здравых принципов, более или менее присутствующих в любой жизнеспособной методологии.

          Проблема в том, что тут же у каждого комментатора свое понимание agile, вот и доказываем друг другу, у кого шашка длиннее.
          • +1
            Вот-вот, и я об этом. В самом аджайле нет ничего такого, что не подошло бы для разработке ядерных реакторов. Так что глупости всё это.

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

            P.S. Не знаю, о чём вы — я ни о каких шашках ничего никому не доказывал.
  • +4
    Опасность разных методологий в том, что из них делают «культ карго». А потом удивляются, почему не работает.
    • 0
      Британские ученые давно доказали, что карго-культ вреден для здоровья. Вы таки правы. Тупое и слепое следование видимым проявлениям практик прямая дорога в адъ
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      есть множество других способов. Например, большая выборка разных команд и однотипных проектов.
      Но и в рамках одного проекта можно почерпнуть весьма много информации для построения теорий, естественно с учётом опыта предыдущих экспериментов
    • 0
      статистика? не, не слышал.
  • +3
    Хотя бы ради поржать рекомендую посмотреть презентацию про снежинки
    • 0
      Презентация отлична, потому и стоит первой в моём списке :)
  • 0
    Ваше сравнение производных и рисования говорит, в основном, о том, что у вас был бездарный преподаватель последнего. Рисовать стандартные вещи (аналог «брать производные») можно научить любого. А вот пользоваться этими навыками как инструментами — далеко не так просто! Ну и что с того, что вы умеете брать производные? У вас где-то в реальной жизни была абстрактная задача «взять производную»? Так же и рисование — можно научиться рисовать свечку. Но это не гарантирует удачное применение…
    • 0
      Ну преподавателей бездарных у нас полно, но опять же черчение он объяснял намного лучше, ибо это наука :)
      Но в целом я имел в виду именно то что вы написали, можно научить рисовать конкретные предметы, но это не значит, что человек сможет стать художником. А вот если научить брать производные, то любую задачу, где требуется это делать, он решить сможет.
      PS: Я то рисовать хорошо научился ещё до школы, а вот многие мои одноклассники не смогли даже к концу 6 класса.
      • 0
        Если научить человека брать производные, он сможет решать задачи-одноходовки, в которых поставлен вопрос «вдять производную». Больше ничего гарантировать нельзя.

        P.S. при чем тут как вы умеете рисовать.
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Если хотите выйти за рамки троллинга, то посмотрите большую презентацию Хенрика Книберга на эту тему — blog.crisp.se/2010/09/01/henrikkniberg/1283373060000.
      • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      безусловно, это поможет, но результат не гарантирован. Если быть объективным, вообще ни чего не может застраховать от провала, только снизить вероятность)
  • –1
    А препода по матану твоего, часом не Виктором звали? =)
    • –1
      На самом деле, я уже точно не помню кто именно из преподов сказал эту фразу, но вроде это бы Усольцев Лев Павлович
  • +1
    … ведь большинство… agile-евангелистов говорят…: «Делайте так, как говорит методология, и ваш проект попадёт в рай. Если нарушите хотя бы одну из практик, то Agile покарает вас»

    Ни один хороший agile-евангелист или тренер не говорит так. Все подчеркивают, что гибкие методологии на то и названы гибкими: пробуйте, смотрите, что работает, а что нет, меняйте.
    • 0
      Я же говорю про большинство, а не про хороших :) Хороших по пальцам пересчитать. Большую часть из них привёл в статье.
      • 0
        Хотелось бы увидеть примеры этого БОЛЬШИНСТВА. А то как-то в жизни не приходилось встречать таких.
        • 0
          Вот уж чего делать не буду, так это давать ссылки на то, что читать не стоит.
          А вообще вам повезло, либо вы оптимист ;)
      • 0
        Денис, ты забыл про компанию СкрамТрек)
        • 0
          Где их материалы, которые можно почитать/посмотреть, чтобы понять как и почему работают те или иные практики?
          Я нашел только «религиозные» ролики от Асхата и о том как продавать эту религию
          • 0
            agilerussia.ru/ — сайт сообщества
            www.facebook.com/groups/agilerussia/ — группа на ФБ
            кроме того после всех конференций шарятся материалы и легко ищутся по названию конфы и тоже шарятся
            и да, Денис, слишком много сарказма в слове «религия» в контексте agile)
            умерь свой пыл)
            • 0
              Заметь, не я придумал слово «евангелист» ;)
              Про то что я читаю эти сайты ты и так знаешь
              • 0
                =) можно пользоваться советским термином «специалист по просвещению»
                ну а чем тебе не материалы от скрамтрека?
            • 0
              Да, там материалы есть, но не от Скрамтрека. Они, видимо, только на тренингах шарят свои глубокие теоретические познания. И их можно понять
              • 0
                Я, кстати, тоже от скрамтрека) Материалы с тренингов уходят участникам тренинга, а вот все что на agilerussia это мы шарим, процентов 90-95 где-то. Плюс масса открытых вебинаров и мероприятий есть от нас, тот же AgileKitchen или SkillTrek делал вебинары.
  • 0
    Ответил статьей habrahabr.ru/post/148276/
    • 0
      Вот, кстати, и трабл, что есть только избранные шаманы (хорошие agile-гуру), которые могут сказать, что у вас в проекте плохо и что нужно делать. А как простым смертным разобраться в этом? Только наступать на грабли снова и снова. Благо всё ж таки материалы стали появляться, см. выше.
      • 0
        Простым смертным надо исследовать опыт других простых смертных и гуру и применять его для своего контекста. Это ничем не отличается от любой другой области знаний.
  • 0
    В тему: в Питере в следующий вторник мы делаем встречу на тему «Что такое Agile» с одним из лидеров Agile-Питер Таней Васильевой.

    Подробности и регистрация.
  • 0
    А по-моему очень верно сказано )))

    Делайте так, как говорит методология, и ваш проект попадёт в рай

    Ведь если он попал в рай, значит он умер!

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

      Насколько я понимаю, смысла аджайла — это не гибкость во всём, как многие думают. Аджайл — это гибкость в планировании задач. То есть возможность ДЛЯ КЛИЕНТА менять свои планы после каждо итерации. А вот чтобы обеспечить клиенту такую возможность, разработчики должны постараться: clean code, автоматические тесты, непрерывная интеграция и всё такое.
  • –2
    Как автор методологии Lean IT и ИТ стратегии беззатратного развития — не могу обойти вниманием этот пост.
    • 0
      Так в чем ваше внимание заключается?

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