Стратоплан
Компания
49,59
рейтинг
8 мая 2014 в 11:04

Разное → Опрос: какая методология используется в вашем проекте или насколько все у нас через это?

image
Ровно 5 лет назад я решил устроить опрос по поводу того, какая методология используется в отечественных проектах. Особой цели не было — мной двигало чистое любопытство.

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

На 3-м месте оказался Scrum (14%)

2-е место досталось нашей любимой методологии “Как получится” (21%)

А 1-е место с большим отрывом заняла методология… (18+)

1-е место заняла методология «Через %опу» (35%). Я так понимаю, это та же «Как получится», но с эмоциональным окрасом… Причем ход голосования был очень любопытным. Методология «Через %опу» долго шла на 2-м месте, но в какой-то момент совершила прорыв!

После чего аналогичные опросы мы проводили в 2011 и 2012 годах. (В 2010 и 2013 честно забыли их провести). Результаты следующие:

2009 2011 2012
Через %опу 35% 30% 18%
Как получится 21% 18% 15%
Scrum 14% 18% 21%
Agile собственного приготовления 11% 18% 27%
Водопад (Waterfall) --- 5% 8%
RUP-based 5% 5% 5%
XP 3% 1% 1%
MSF 1% 1% 1%
CMM/CMMI 2% 1% ---
Другое 8% 3% 4%
Кол-во ответов 122 913 850


Черт побери, раз уж теперь у нас есть блог на Хабре, то не настала ли пора провести очередной опрос, подумали мы?

На следующей неделе мы думаем опубликовать несколько материалов по управлению проектами, а сегодня перед праздниками возникла идея провести очередной срез нашей отрасли и посмотреть:
  • Какие есть тренды в нашей индустрии?
  • Действительно ли гибкие методологии становятся все популярнее?
  • На самом ли деле, методология лидер-2009 уходит в небытие?


Как вы понимаете, в этом опросе нет глубинного смысла и попытки серьезной аналитики (да и сам опрос не вполне корректен), но все равно будем очень благодарны за ответ!

P.S. Ссылки на результаты опросов 2009, 2011, 2012 на сайте happy-pm.com (осторожно, на сайте противное всплывающее окно): http://www.happy-pm.com/blog/?page_id=675
Какая методология используется в вашем проекте? (Выберите наиболее подходящий вариант)

Проголосовало 2945 человек. Воздержалось 642 человека.

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

Автор: @eagleson
Стратоплан
рейтинг 49,59
Компания прекратила активность на сайте

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

  • +4
    Для крупных проектов стараемся следовать RUP, для мелких водопад
    • +1
      А какую именно модель из RUP используете?
  • 0
    Я думаю, что вот так под одну гребенку не очень корректно всех загонять.

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

    И если ко внутренним проектам можно хорошо прикрутить scrum/kanban, то в клиентской разработке это сильно, имхо, расшатывает проект и повышает риски. Потому как зачастую бюджеты не резиновые, сроки тоже; клиенту нужен план и понимание когда будет финальный релиз. И ему до одного места, каким образом это будет достигаться. Главное, чтобы была прозрачность и соответствие бюджетам/срокам.
    • +2
      Главное, чтобы была прозрачность и соответствие бюджетам/срокам.


      Знакомо, при этом собственно проект всем до ж*пы. Давайте разделять разработку и занятие х**ней (это когда код пишут, диаграммы всякие рисуют, а результат по факту нахрен никому не нужен — обычно для больших корпораций и госструктур).
      • 0
        Согласен.
    • 0
      В основном мой опыт — аутсорсинг: гибкие подходы порой внедряются самим заказчиком, не говоря уже о том, что все крупные аутсорсеры имеют внутренние отделы внедряющие agile-практики.
      • 0
        Дык аналогично, коллега. Но у нас все индивидуально. Иногда и в вотерфолл скатываемся. Страшного в этом я ничего не вижу.
  • +3
    У нас смесь Scrum и Kanban. Команда разработки одна, проектов несколько.
    • +6
      Это, наверное, в «Agile собственного приготовления» укладывается.
      • 0
        При scrum основная проблема была в шеринге ресурсов между проектами, взяв от Kanban систему контейнеров(процессов в виде дизайн/верстка/программирование итд) проблема ушла сама собой.
        • 0
          О, мы тоже пришли к такому же в итоге :)
      • +7
        У нас смесь Scrum и через жопу. Интересно, это укладывается в «Agile собственного приготовления»? :)
        • +1
          Я думаю, это зависит от того, насколько силен эмоциональный окрас. :)
  • +1
    Скрумбан можно смело добавлять имхо. Я его три конторы подряд пользую.
  • +75
    Просто оставлю это здесь… (18+)

    image
    • +3
      Всегда интересно было кто авторы.
      • +1
        Первый даже есть на хабре.
    • +1
      Это методика концепции «пиши код, блеять!». Странно, что ее нет в голосовалке.
      • 0
        Она там есть — это второй по популярности ответ.
  • +2
    В последних небольших проектах используем канбан (Trello), с навесками для Scrum плагинами.
  • +1
    самодельный Scrumban, стремимся прийти к описанному в playbook.thoughtbot.com/
  • +8
    А я вот часто вижу декларируемый agile / scrum / kanban который на самом деле либо уже через ж@пу либо скоро таковым будет. Это я к тому что между что отвечают в опросе и что происходит на деле есть некоторая разница.
    • +6
      +1.

      Есть на эту темы определение: скрамбат (scrum but), то есть у нас Скрам, но… :)
      • +3
        Я бы сказал Scrum butt
        • +2
          Скрамно
          • +2
            Мертвые скраму не имут.
    • 0
      Agile без вовлеченности обеих сторон (клиент + исполнитель) имхо невозможен в принципе. Как еще agile может быть через ж*пу, я не представляю.
  • +7
    У нас: на словах — Scrum, Kanban; на деле — через %опу.
  • +9
    В конце проектов месяца за 2:
    • +2
      Похоже на схему раздачи «пинков» для ускорения работы сотрудников.
      При этом нужно произносить заклинание «А-А-А-А!».
      • 0
        «Подратирование»
    • +5
      Что подразумевается под «концом» проекта?
      Просто в скольких проектах ни работал, нигде не было конца.
  • +2
    Промежуточные результаты (для тех, кто не зарегистрирован на Хабре, и их не видит):

    image
  • +12
    По моему опыту, «Agile собственного приготовления» это «Как получится» в гриме.

    Так что лидер — он по-прежнему лидер.
  • –1
    Где «литературное программирование»?
    • 0
      Я прошу прощения, а что это такое?
      • 0
        Это калька с «literate programming».
  • +5
    Госструктура.
    Команда по-максимуму пытается использовать Scrum (и довольно неплохо получается), но т.к. руководству (высшему, не прямому) такие слова неизвестны, получается все равно через жопу. Все эти планирования, спринты и прочее летят в трубу, когда руководство внезапно решило подкинуть еще один проект, иногда вообще никак не связанный с разработкой. Увы и ах, чо.
  • +4
    Как по мне — правильнее было бы делать радиобаттон с выбором подхода, типа скрам, вотерфолл, канбан и так далее и отдельным пунком галочку «через жопу». Потому что абсолютно любую идею можно применять именно этим способом, что зачастую и делается. И результаты опросов по годам говорят скорее не о том что лидер в организации работы сменился, а о том что люди лучше овладели терминологией и теперь точно знают что именно у них на проектах применяется через неё, родимую.

    Это, конечно, моё личное мнение. Основанное на том что менеджмент у нас уверен что мы работаем на скраме, а факты говорят иное.
    • 0
      Это, конечно, моё личное мнение. Основанное на том что менеджмент у нас уверен что мы работаем на скраме, а факты говорят иное.


      Такое бывает сплошь и рядом, по-моему. :)

      Строго говоря, «через %опу» — это даже не методология, а отношение к происходящему. :) Но по историческим причинам оставлено как отдельный вариант. :)
  • +1
    А была ещё какая-то картинка с бизнесом в Китае. Там не то что АААА, там — лапша!
  • +1
    для «Agile собственного приготовления» — есть отличный термин ScrumBut

    У меня сложилось впечатление, что даже те, кто вроде как используют Scrum, на самом деле используют ScrumBut ))

    Мы используем Youtrack для организации рабочего процесса, не смотря на конские цены и проблемы с переездом на него, он реально очень удобный.
  • 0
    У нас все, от кого зависит методология, проектирование и принятие решений, из всех слов, перечисленных в опросе, слышали только эти, с символом процента. Так что, здравствуй, %, новый год…
  • +2
    Я подозреваю, что на опрос может оказывать влияние некоторый максимализм присущий разработчикам. Для многих слегка измененный относительно святого писания agile это уже «через жпу».
  • +4
    Вы бы еще объяснили, что значат все эти умные слова…
    • +1
      Тут, надо бы отдельную статью писать, а то и не одну… Но в рамках опроса — если вы этих слов не слышали, скорее всего, этого у вас нет. :)
      • 0
        Ну почему же? Не все же так глубоко в термины лезут.
        Полез в Вики. Допустим вторая методология, которая нашей почте и не снилась или являлась только в мечтах (чаще в мечтах клиентов)
        Канбан — система организации производства и снабжения, позволяющая реализовать принцип «точно в срок».

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

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

        Это примерно как, предложить в обществе интеллигентных и не очень* людей травку Канабис, в то время как 99% (субъективно) присутствующих не знаю что это за трава. А предложи им общеизвестное название — поймут** 99%.

        * то есть. не увлекающихся этим делом
        ** я не говорю о согласие
  • +3
    В прошлой команде у нас была методология «как получится» и мы умудрялись писать и ядро без, которое использовалось в пяти независимых друг от друга приложениях без особых проблем, хотя заказчик был тот еще. Да у нас даже тестировщиков не было. В текущей команде у нас скрам практически по всем правилам, с досками, спринтами и тестированием и мы срываем сроки из-за того что не понимаем как сделать правильно — как всегда архитектура не учитывала неожиданных поворотов событий )

    Мое личное мнение такое, что на самом деле не так важна методология как слаженная команда, хорошая архитектура и понятный код
    • +1
      +1

      Есть отличная статья Алистера Коберна «Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения».

      Оттуда:

      1. Практически любую методологию можно с успехом применять в каком-нибудь проекте.

      2. Любая методология может привести к провалу проекта.

      3. Тяжеловесные методологии тоже могут успешно применяться в работе.

      4. Облегченные методологии чаще приводят к успеху, и, что более важно, разработчики сами говорят, что успех проекта был обеспечен именно методологией.
    • НЛО прилетело и опубликовало эту надпись здесь
  • +2
    А за какой вариант нужно голосовать, если рабочее время тратится непосредственно на работу, а не соответствие методологиям?
    • +3
      В зависимости от получаемого результата — или 'Как получится', или 'Через ж… у'.
      Прям как у нас :)
    • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    Не могу определится, а Через %опу + итерации, это можно назвать «Agile собственного приготовления»?
    • 0
      Итерации были давно :) Так что вопрос очень правильный.
  • +1
    FDD + пиши код, блеать + херак в продакшн. Очень эффективно в сферах, где ошибки не критичны и есть возможность их исправить.

    А Срам — это методика очковтирательства для манагеров, где можно годами рубить бабло закрывая незначительные фичи и баги, отодвигая или размазывая критичные проблемы.
  • +2
    Web-разработка крупных проектов в непосредственном контакте с заказчиком. Kanban + оценка по времени тасков + периодические митинги. Scrum так ни разу не удалось применить из-за его ограничений: фиксированный спринт и полная взаимозамеяемость членов команды друг другом. На практике второе условие не соблюдается почти никогда, да и с первым тоже сложно.
  • 0
    а PMBOK вы не относите к методологии? Мы например у себя используем ее, и у нас все получается.
    Пришлось поставить другое.
    • 0
      Спасибо за комментарий — в следующий раз сделаем, да. А то меня вот и Иван Селиховкин (наш эксперт по управлению проектами) всячески застыдил. :)
    • 0
      PMBoK не методология, это «свод знаний».

      Нельзя просто так взять, и применить PMBoK. :) (разве что под монитор подложить)

      А вот строить управление своими проектами, применяя знания и рекомендации, вырванные из контекста PMBoK, неправильно интерпретированные и не туда приспособленные, можно запросто. Получится «что-то собственного приготовления».
      • 0
        Насчет того, что правильно применять знания PMBOK — это далеко не просто, тут полностью согласен.
        Леонид, вы случайно не работали в 1 из 2 компаний, лидеров на рынке России по предоставлению услуг УП на базе PMBOK? (Не буду называть, какие. Думаю вы меня поймете)
        • 0
          Да, в управлении (особенно — в разработке) теоретические знания применять непросто. Из БоКа или откуда бы там ни было. Банально в силу его, управления, двойственной природы.

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

  • 0
    del

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

Самое читаемое Разное