О чем молчит SCRUM (часть 1).

Итак, начнем с начала. Почему, собственно я задумался об такой статье? Есть в Scum’е две вещи, которые меня конкретно нервируют.

— Как технарь и программист, я очень не люблю, когда мне говорят «делай только так, потому что так правильно» и при этом не объясняю почему именно так правильно, что будет если сделать не так. А все книги по SCRUM’у так и делают — выдают набор практик, артефактов, ролей и т.п., которые нужно использовать без малейшего объяснения для чего нужна каждая из этих деталей.

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

Собственно эти две вещи и заставили меня копнуться чуть глубже. Ну и плюс, за последние полтора-два года, которые я работал в нескольких модификация SCRUM’а у меня накопилось некоторое количество (отрицательного) опыта.

Сразу замечу, что в этой серии статей я не буду давать обзор SCRUM. Если вы с ним не знакомы, то загляните в описание на wikipedia, а еще лучше найдите и почитайте книжку.

Приступим.

1) Передел территорий

Большинство SCRUM книг начинается с того, что рассказывается о том, какие есть роли в SCRUM’е и как надо начинать работать над проектом (составить backlog, перетасовать его по приоритетам и т.п.). Я не видел еще фактически ни одного источника, которые предлагает как «продать» идею внутри компании. В лучшем случае там пишется: Вася, CTO компании, решил попробоывать SCRUM.
Ну да ладно, умный человек всегда может выбрать с десяток пунктов, по которым SCRUM лучше waterfall и залив их большим количеством меда протолкнуть идею попробовать SCRUM в компании. Хотя и это было бы как-то описать, так как зачастую Вася не CTO в компании, а программист/тим лид/менеджер и соотвественно ему таки приходится пропихивать идею наверх.

Интересное начинается дальше. До тех пор пока SCRUM не стартован или только стартуется, все идет мягко и хорошо. Но вот возникает момент когда обнаруживается что
а) Project manager со всем своим длинным послужным списком PMP сертификатов не нужен, а нужен человек который прочел одну книжку и прошел двухдневный семинар Scrum мастерства. И не дай бог роль Scrum Master’а отдадут не Project Manager.
б) QA manager не нужен, так как внезапно QA становятся Team и теперь являются частью самоорганизающийся команды.
в) Вместо кучи Product manager’ов, маркетологов, sales’ов, которые постоянно совали нос в разработку пытаясь поменять порядок задач, теперь нужен один человек — Product Owner, который имеет право тасовать все задачи как ему вздумается (тут я немного преувеличил, но тем не менее, product managerская работа становится более видимой и их становится нужно меньше).
г) Программисты теперь не имеют право кивать на QA, что те чего-то не сделали. QA не имеел право кивать на программистов, что те чего-то не сделали.
д) Новый Scrum Master должен иметь БОЛЬШИЕ полномочия, для того чтобы расчищать путь для команды и водворять все стороны SCRUM’а. (в целом он конечно может бегать к мендежру каждый раз, когда нужно купить пишущих ручек, но это не так, чтобы слишком эффективно).
е) Лестница технического менеджмента тоже становится вроде как-бы и не слишком нужно, так как по сути они больше ни должны руководить.

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

Нет…Нет… Противостояние не начнется в тот момент, когда будет предложена идея SCRUM’а. Оно не будет открытое. Просто, тот человек, который будет пытаться вводить Scrum (особенно если он не находится на верху иерархии) в какой-то момент обнаружит, что люди не спешат расставаться с их бывшими полномочиями и властью и не сильно спешат все делать по новому.

2) Второе, о чем почему-то редко говориться в Scrum, это о том как переводить проект с классического waterfall (или вообще отсутствия методологии) на Scrum. Опять же в большинстве книг рассказывается о том, что вот мол решили начать новый проект и попробовать Scrum. Извините… секундочку… То есть 80% рынка управления уже существующими проектами — нафиг из описания, а вот лучше мы опишем, как делать для остальных 20%, так как там поменьше зацепочек.

В чем собственно отличие старого проекта от нового проекта? Отличий несколько. Одно отличие — это существующий status quo (по большему счету то, что я описал в пункте 1 насчет власти), второе — это то, что уже есть код, заказчики, баги и т.п. И существует гигантская разница между тем, чтобы красиво и итерративно работать над проектом для которого нету заказчиков, нету багов и код которого новый и хороший.

Коротенький пример по этому поводу. Представим себе, что у вас есть продукт который активно пользуют, и в течении 3 недель (вашего спринта) вам приходит 3-4 бага от заказчиков которые надо пофиксить как можно быстрее. Модель Scrum’а такое не поддерживает. Содержание текущего Sprint’а не может меняться. И в этом смысле, в новом проекте, легко сказать всем вовлеченным — если есть баг, то мы его кладем в Backlog и пофиксим в следующем Sprint’е, в старом проекте где всегда фиксилось в течении 2-3 дней, явно менеджмент и customer support не оценит идею пофикса через 2 недели.

Собственно, это две самые крупные (по моему мнению) проблемы о которых не говорится в книгах. В следующей статье я капну чуть глубже.

24 комментария to “О чем молчит SCRUM (часть 1).”

  1. Саппорт и разработку основной версии продукта можно разделить (и обычно разделяют). Основную версию вполне можно делать на Scrum.

    • Victor Ronin:

      В следующей статье я об этом напишу (точнее начал писать). Это один из методов. Увы, почему-то не озвученный в официальной литературе.

  2. sergey:

    А меня убивает то что в скраме все считаются одинаково толковыми. Закончил таску? Сходи в беклог и возьми другую. А как какой нибудь junior developer поправит opengl backend, или там добавить api во фрейморку..приходится всовывать разные таски в беклог, для любой квалификации, что в общем то делает беклог нечто другим.

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

    Я бы даже сказал что скорм это сказка для выжимки команды, и в итоге теряется конфликт между менеджером и разработчиком (скорость разработки vs качество архитектуры). И в итоге получается то еще гуано…

    p/s
    Я не против скорм, я его даже немного люблю, но вот терпеть не могу хвалебные статьи про него 🙂

    • а успех вообще всегда «зависит от человеков».

      как говорит один мой знакомый (очень толковый манагер): «для успеха проекта ничего не нужно, кроме толкового манагера и толковой команды».

      • Victor Ronin:

        Безусловно. Собственно, это один из пунктов моей программы на обсуждение.

        Scrum молчит о том, что делать с неидеальными людьми.

    • Victor Ronin:

      Да, я об этом собирался писать.

      Scrum хорошо работает, на идеальных людях. То есть, если все добрые, умные, честные и опытные, то все будет отлично.

      • да не скрам, а всё.

        _всё_ хорошо работает на идеальных людях.
        апологеты скрама говорят, что скрам типа способствует приблежению человека к идеалу, правда не говорят, чем именно 🙂

        • Victor Ronin:

          Та да.

          Насчет приближению к идеалу…. Не знаю… как-то не заметно. 🙂

  4. Коротенький пример по этому поводу. Представим себе, что у вас есть продукт который активно пользуют, и в течении 3 недель (вашего спринта) вам приходит 3-4 бага от заказчиков которые надо пофиксить как можно быстрее. Модель Scrum’а такое не поддерживает. Содержание текущего Sprint’а не может меняться. И в этом смысле, в новом проекте, легко сказать всем вовлеченным – если есть баг, то мы его кладем в Backlog и пофиксим в следующем Sprint’е, в старом проекте где всегда фиксилось в течении 2-3 дней, явно менеджмент и customer support не оценит идею пофикса через 2 недели.

    ну не надо утрировать. там есть прикольная штурка — называется focus factor, типа коэф.сосредоточения. так вот он прекрасно учитывает и 2-3 бага и нервного манагера, который бегает и спрашивает каждые 2 часа «ну как там?».

    опять же никто не мешает в спринт закладывать (по прошлым статистическим данным) таск типа «фиксить баги», 2сторипоинта=8часов.

    ну и главное 🙂 для суппорта уже год-полтора как по все планете шагает канбан. 🙂 чую скоро будут сертификации

    • Victor Ronin:

      Собственно описанная ситуация имеет несколько решений. Я о них собирался писать в следующей статье. Одно из решений таки включать такие задачи в sprint как overhead (мы называли это так), то есть уменьшать focus factor.

      Но в целом focus factor не был озвучен в классическом Scrum (по крайней мере в том, что я читал). Во вторых, у него есть свои недостатки (опять же напишу).

      Да, канбан действительно для support хорош. Но опять, же, если у нас support просто часть разработки. Делить команду на несколько частей и пускать одну по scrum, другую по канбан или делать Scrum-ban?

  5. reflective:

    В статье акцент сделан на том, что есть проекты, команда и желание изменить схему управления, применив абстрактную концепцию по ведению проектов.
    Данный вариант (scrum как конкретная техника) хорош, как когда управление или плохо формализовано или не формализовано вообще (новый проект, стартап итд итп). Если есть четкая постановка краткосрочных задач, мониторинг их выполнения, есть постоянное взаимодействие с заказчиком, рабочий процесс уже организован, то непонятно откуда есть желание перекроить рабочий процесс, изменив роли, регламент работ и рабочий цикл.
    Фактически 2 упомянутых недостатка сводятся к одному, все работает и так, а желание изменить все без ясного понимания , какая выгода, наталкивается на стену недоверия и непонимания.
    Scrum, как и любая техника формализующая процесс, приемлема и полезна, как средство наведения порядка (в случае его отсутствия 🙂 ).

    • Victor Ronin:

      Есть еще третий вариант. Все работает, но работает фигово и как раз в этот вариант попадают гигантское количество компаний.

      И вот именно в такие компании кому-то может захотеть улучшить ситуацию.

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

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

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

      • reflective:

        Мне кажется есть развдвоение целей. Что-то работает не очень хорошо. Если есть видимые проблемы: вариант 1 проект (проблемы постановки целей, приоритетов, критичное изменение функционала, детали реализации итд итп), тогда термин «нравится» вторичен. 2-е команла (кому-то не всем плохо, про баклуши) для этого есть тимлид для контроля за происходящим. Мне просто показалось, что все имеющие проблемы (локального свойства) решаются сразу введением одной техники (глобально). Техника абстрактна, имеющие проблемы в команде конкретны. В этой связи переход на качественно новую технику (перепроектирование существующего цикла) это хирургическое вмешательство там где потенциально можно потенциально обойтись менее радикальными мерами. Даже если и форсировать переход , компромисс издержки всегда имеют место от любой реогранизации (хотя бы на выработку привычки к другому ритму).
        По поводу неожиданностей: что все-таки важнее удерживать неизменный план или решать возникшие критически важные задачи ?
        Успешного решения всех задач и реогранизации бизнес-процессов !

        • Victor Ronin:

          Если честно, то я не уверен, что я полностью понял свой комментарий.

          Единственное, что я могу прокомментировать. Не все кто бьют баклуши — находятся в команде и подчиняются team lead’у. Причем не обязательно именно бить баклуши, человек может просто имеет власть и что-то из этого получает. Люди не любят расставаться с какими-то свойставами работы (власть, возможность работать мало), которые у них есть.

  6. VladStar:

    Подкидываю интересную статейку в 4 частях на тему архитектуры ПО:
    http://habrahabr.ru/blogs/development/90880/