Скруммное (часть 2).

Эдак с месяца 3-4 уже сижу на Скруме. Маленькие записки по поводу него я уже писал, но постепенно набрались новые мысли и ощущения.

Из новых ощущений
— Очень понравилось то, что не пытаешься планировать в какие-то бесконечные дали, а решаешь текущие проблемы, оставляя будущие проблемы на будущее (причем это относится как к product managment’у, так и к программированию).
— Понравились burnchart’ы — гораздо более объективная и простая методика видеть, как движется проект (по сравнению с нереально тяжким и неточным MS Project).

А вот теперь то, что НЕ понравилось

— Узаконенное не планирование архитектуры.

Молодые/плохие разработчики с удовольствием работают в пределах user story. Приемочные критерии пройдены, а остальное их не сильно волнует. Проблема возникает в том, что они могут писать код, который является полным говном. И когда, даже внутри того же спринта сталкиваешься с другой user story в которой нужно использовать их код, приходится — разобраться в нем, отрефакторить, проверить, что старая US не поломана и что новая сделана. И это в результате выходит дольше, чем сделать хорошо сраз.

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

Впрочем проблема тут не только в Скруме, но просто в Скруме она узаконена.

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

17 комментариев to “Скруммное (часть 2).”

  1. ZaQ:

    Помоему вопрос качества архитектуры лежит полностью на тимлиде, на том, как он мониторит код который пишут остальные, к скраму это не относится.
    Вполне можно то же проектирование вынести в отдельный таск, пусть он и будет выбиваться из «общего» подхода.
    Да и как-то не узрел я требования в скраме НЕпроектировать, это больше к XP относится, а применять практики XP по отдельности, да еще не особо граммотными разработчиками, только проекту вредить (если не убивать).
    Подчеркну, это имхо.

    • Victor Ronin:

      >Помоему вопрос качества архитектуры лежит полностью на тимлиде,

      Абсолютно согласен. Вопрос только, что в Scrum даже не введено такое понятие как team lead. Наоборот есть попытка унифицировать всех членов команды.

      >Да и как-то не узрел я требования в скраме НЕпроектировать, это больше к XP относится

      Прямого требования к НЕпроектированию нету. Но и требования к проектированию тоже нету.

      • ZaQ:

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

        • Victor Ronin:

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

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

          • ZaQ:

            Возможно я неправильно выразился. Имел ввиду, что даже если в команде отказываются от такой роли, как тимлид/архитектор, ее в обязательном порядке возьмет на себя один из разрабочиков, не афишируя и всячески отрицая. А если этого не происходит, то либо команде наплевать на продукт, который они создают, либо им настолько «внушили» основные постулаты скрама, что они по своему сделать боятся. В любом случае все проблемы лезут из менеджмента(скрам-мастера) и к скраму отношения не имеют.
            Конкретно по приведенной ситуации, думаю здесь проблема не в том что «скрам/не скрам», а в том, что суть работы ПМа остается абсолютно одинаковой, меняется только форма и название. И скрам всего лишь не описывает этот момент, вероятно полагаясь на то, что разработка архитектуры может быть выделена в отдельный спринт, раздроблена на несколько частей, как части различных спринтов, либо размазана по всем спринтам равномерным слоем, на усмотрение скрам-команды. Каждый из этих вариатов требует различный уровень и набор квалификаций, чем незаметней этап проектирования, тем выше требования к команде.

            • Victor Ronin:

              Согласен со всем кроме одного пункта — «обязательном порядке возьмет на себя один из разрабочиков». Самоорганизация в командах не всегда происходит.
              Для этого в команде должен оказаться толковый, опытный и энергичный человек.

  2. ZaQ:

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

    • Victor Ronin:

      Есть такое дело 🙂

      Вообще приятней сидеть и пить кофе, чем возится с противными разработчиками 🙂

  3. Denis:

    абсолютно согласен. по обоим негативным и позитивным фактам. сейчас работаю в МС и первый негативный пункт широко распространен в коммандах, которые используют скрам (скрум это как-то по-ирландски 🙂 ). убедить, что нужно сделать архитектуру очень сложно. вообще чуть что сразу следует «мы же аджайл», бесит реально. имхо что waterfall, что scrum требуют просто адекватных людей. и про волшебную палочку согласен, про scrum слышал, про waterfall никогда.

    • Victor Ronin:

      А что такое MC?

      >вообще чуть что сразу следует “мы же аджайл”

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

      • Denis:

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

        • Victor Ronin:

          Насчет много или мало я исходил из того, что в Scrum — средняя продолжительная Sprint — 3-4 недели. И дизайн равный неделе в Scrum считался бы достаточно большим, а месяц — вообще неприемлемым.

  4. Спасибо за предоставленный опыт. Пригодится.

  5. Denis M:

    Кажется open-id не работает, комментарии просто пропадают

    • Victor Ronin:

      Та я никак не разберусь с этой проблемой. Если пытаться написать комментарий еще не залогиневшись по openid — то там, что-то не работает.

  6. AndrewM:

    Привет, Витя. Не знал, что ты уже давно ведёшь свой блог, да ещё такой интересный! Подписался — буду читать 🙂
    По статье — интересная, сам недавно начал практиковать скрам. С плюсами согласен. С минусами вобщем-то тоже. По непланированию архитектуры: имхо конечно же её надо планировать, и чем раньше тем лучше, но, как говориться, без фанатизма. Я бы сказал, важно выбрать правильный курс, подходы, способы организации, и дальше развивать их по ходу проекта.

    • Victor Ronin:

      Привет 🙂

      > да ещё такой интересный!

      Спасибо 🙂

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

      Именно-именно. Я как раз за это ратую. То есть планировать слегка вперед, не забегая совсем уж далеко, но и не оставляя ее на тот момент, когда уже поздно.

      Кстати, если вдруг захочешь почитать, что я писал раньше, то погляди Most Popular Articles. Единственной — что тяжелее слон или кит и где же ты искусственный интеллект, можно спокойно пропустить. Они хотя вверху, но попали туда случайно.