А был ли Scrum*? +6




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

Почему я решил написать эту статью


Очень часто в рабочей среде, на просторах интернета и на собеседованиях можно услышать, например, вот такое:
«С этим Скрамом столько встреч! Когда работать то?!»;
«Хорошо, пусть это будет хоть Скрам, хоть Срам, только отвалите и дайте мне писать код!»;
«У нас тоже этот Скрам навязали, вообще непонятно для чего»;
«Каждый день стендапы минут по сорок, нафига мне на них присутствовать? Хотите знать, что я сделал и над чем работаю сейчас — смотрите Jira, Confluence, Git и т.д.»
«Скрам-мастер вообще шут какой-то, ему бы всё хороводы водить, вместо управления проектом!»;
«Да, Скрам мы использовали: главное, что ретроспективы проводили».
Цель данной статьи показать, что тот негатив, который всё ещё большим потоком льётся в сторону Скрама, на самом деле к нему не относится, и проблему нужно искать в другом месте.

Далее я хотел бы рассказать о типичных случаях, откуда берут своё начало эти проблемы.

Сам я являюсь сертифицированным (scrum.org) в области Скрам сотрудником одной большой организации из финансового сектора (не «зелёной», если что). В настоящее время у нас не Скрам, но мы движемся в эту сторону, и лично у меня есть видение зачем и как мы будем это делать и дальше.

На самом деле увлечение гибкими методологиями и Скрамом в частности пришло ко мне не так давно, но на мой взгляд, важно не «как давно», а «насколько качественно и осознанно».

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

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

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

Невидимую для многих мощь Скрама можно в какой-то степени сравнить с мощью Экселя: на вид всё довольно просто, а если покопаться…

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

1. «Навязали»


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

  • Осознавал ли менеджмент, для чего он собирается идти в гибкие методологии и Скрам в частности?
  • Как до сотрудников донесли информацию о необходимости трансформации, и почему в этом помогут гибкие методологии и Скрам в частности?
  • Как осуществили поддержку сотрудников в условиях трансформации, проводилось ли качественное обучение, аттестация и помощь в запуске команд?

Очень частая история, когда компании трансформируются, просто потому что это «модно».
В итоге что-то хорошее вряд ли получается, и возникающий ропот, впоследствии перетекает в волну негатива.

В этом плане мне понравилась одна фраза в тему: «In traditional companies, traditional managers organize traditional transformations.»

Однако, буду с вами честен: когда нам впервые «занесли» Agile/Scrum/Kanban, то именно про Скрам я как раз исходно думал, как о какой-то фигне с бесконечными встречами. Изменения в моём отношении к нему пришли после того, как в одном очень крутом проекте я сам себе задал вопрос: «А что если...?».

2. Гадание на Скрам по фотографии


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

Не исключаю также наличие раскольников, которые спорят о том, стоять на Ежедневном Скраме (Daily Scrum) кругом, квадратом, или какой-либо другой фигурой. Если кругом, то передавать слово по часовой стрелке, против, или как-то ещё.

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

Глядя на огромный поток информации в сети, создаётся впечатление, что многие просто не знают, что является первоисточником и где черпать базовые знания по фреймворку.

Так вот, главным документом по Скрам является «The Scrum Guide», написанный в соавторстве Кеном Швабером и Джеффом Сазерлендом, доступный на многих языках, включая русский.
На мой взгляд, для того, чтобы получить базовые знания по Скрам и, впоследствии не засорять своё сознание всевозможными неверно истолкованными дополнениями к Скрам, требуется всего два основных компонента: желание и вдумчивое прочтение «The Scrum Guide», причём не один раз. Документ этот довольно компактный — менее двадцати страниц, осилить можно.

Что касается тренингов скажу коротко: будьте осторожны! В рамках этой статьи никого рекламировать не буду, но считаю, что «правильными тренингами» по этой теме в нашей стране можно доверять всего одной-двум компаниям.

3.«Толкование» некоторых разделов Scrum Guide и не только


В контексте того, сколько однотипных обсуждений в сети ходит относительно Скрам попробую заострить на них внимание и изложить моё понимание в соответствии со Скрам-гайдом и опытом.

Скрам является…


Выделю две из трёх характеристик: простым для понимания и трудным для совершенного овладения.

Некоторые думают, что здесь есть противоречие.

Спринт


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

  1. В чём на ваш взгляд смысл называть фиксированные во времени интервалы работы Спринтами? Например, может проще каждые две недели просто отправлять отчёт о проделанной работе?
  2. Если вы в процессе перехода на Скрам, то какой длины вы выбрали Спринт? Когда я задавал этот вопрос, то чаще всего встречал удивлённый взгляд и следом ответ: «Стандартный — 2 недели».
  3. Почему вы выбрали Спринт такой длины?
  4. Почему не рекомендуется устанавливать длину Спринта более месяца?

Кто-то может не поверить, но ответы на эти вопросы есть в Скрам-гайде.

4. Daily Scrum (Ежедневный Скрам)


Одна из самых дискуссионных тем — Daily Scrum, он же Daily Standup Meeting, он же Ежедневный Скрам, или просто «Постояшка».

Вы можете мне не поверить, но у этого события есть фиксированное время проведения (time-box) — не более 15 минут, вне зависимости от длины Спринта.

Команда сама определяет формат встречи. А самое важное в этой пятнадцатиминутке — это понять статус продвижения к Цели Спринта.

Теперь вопросы на засыпку: многие ли из вас знают, что такое Цель Спринта? Многие ли из вас умеют её сформулировать? А кто вообще их формулирует?

В подавляющем большинстве случаев негодуют от Скрам именно из-за своего незнания и непонимания, для необходимо именно это событие под названием Daily Scrum.

Это не отчётная встреча! В тех встречах, которые я часто наблюдаю, не хватает разве что сообщений о том, сколько раз человек попил кофе, чай, воду, а также сходил в туалет. А «не более 15 минут» может и на полтора часа растянуться.

Ещё раз: Daily Scrum — это про движение к Цели Спринта!

Осознав только эту часть Скрама, вы, на мой взгляд, сможете совершить значительный прорыв.
И ещё ремарка, которая для многих становится открытием, Daily Scrum — это событие, в котором может принимать участие (заметьте, «принимать участие» и «постоять рядом, послушать» — это разные вещи) только Development Team (Команда Разработки)! Даже Scrum Master (Скрам-мастер) и Product Owner (Владелец Продукта), если они не являются по совместительству членами Development Team, непосредственного участия в этой встрече не принимают!

5. Скрам-мастер — это не Менеджер Проекта и не прислуга


Другая весьма распространённая тема: Скрам-мастер (SM) = Менеджер Проекта (Project Manager, PM).

Вы можете найти кучу статей на тему SM vs. PM.

Выделю основное:
  • Скрам-мастер несёт ответственность за продвижение и поддержку Скрама в соответствии со Скрам-гайдом.
  • Основные заблуждения про Скрам-мастера:
  • Скрам-мастер НЕ управляет проектом;
  • Скрам-мастер НЕ управляет командой (кого взять, кого убрать);
  • Скрам-мастера не выбирают по принципу самого опытного, или долгоработающего сотрудника компании;
  • Скрам-мастер НЕ является секретарём команды, “забивающим встречки”.
  • В обязанности Скрам-мастера НЕ входит доставка пиццы по пятницам (любимая тема на тренингах), стирка носков и глажка шнурков Владельцу Продукта, или членам Команды разработки.

Зоны ответственности Скрам-мастера также изложены в Скрам-гайде.
В завершение этого раздела могу ещё несколько тем вбросить, для самостоятельной проработки, если кому интересно:

  • Scrum, как карго-культ vs. Scrum и сюхари.
  • Product Owner — это менеджер продукта, а не проекта, или команды. Здесь же PO vs. PM.
  • Product Owner и Scrum Master в одном флаконе.
  • Главное в Scrum — Ретроспектива, или встречал почти вот так: Scrum = Ретроспектива (а вот ретроспектива чего — это уже другой вопрос)!
  • ...

Назрело в свете того, что по работе встречается, в комментариях, в том числе и на Хабре.
Скрам — это Кен Швабер, Джеф Сазерленд и их Scrum Guide. Смотрите End Note.
Скрам — это то, что в Скрам-гайде, а не то, что вы привыкли называть у себя в компании.
У нас тоже пока ещё не Скрам, но мы это понимаем, признаём и знаем, как двигаться к нему. Причём мы также понимаем, что двигаться туда точно надо, так как это действительно может принести огромную пользу организации.

Подводим итоги


Если приведёнными выше заметками я хоть кого-то сподвигнул задуматься и переосмыслить, что же всё-таки такое этот Scrum, да гибкие методологии в целом, то буду считать, что цели я достиг!
Вода камень точит и, возможно, в недалёком будущем мы уже не так часто как сейчас будем слышать “Вы очень увлеклись этим Скрамом, а исходя из результатов такой-то команды (использующей по факту СкрамНО) не стоит этого делать”.

Всем спасибо за внимание и буду рад вашим комментариям и замечаниям!

Ссылки


www.scrumguides.org/index.html

Вы можете помочь и перевести немного средств на развитие сайта

Теги:



Комментарии (148):

  1. fcoder
    /#19146991 / +7

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

  2. eugenvz
    /#19147049 / -2

    Прежде всего, спасибо за комментарий!
    Цель как раз и была «вбросить», или просто, чтобы люди призадумались, что всё не просто так и не стоит «верить слухам» ;-), а многое можно почерпнуть из уже имеющихся общедоступных источников.
    Я намеренно не стал растолковывать весь Скрам-гайд, а только дал «для затравочки».
    Вам конкретно отвечу:
    1. Цель спринта (беру из русской версии документа, хотя рекомендую пользоваться английской, как первоисточником): «Цель Спринта – это установленный для Спринта ориентир, который достигается через выполнение части Бэклога Продукта.»
    2. Скрам-мастер: несет ответственность за продвижение и поддержку Скрама в соответствии с Руководством по Скраму. Он достигает этих целей, помогая всем понять теорию, практики, правила и ценности Скрама.
    Скрам-мастер — это лидер-слуга для Скрам-Команды. Людям вне команды он помогает понять, что из их взаимодействий со Скрам-командой полезно, а что нет. Скрам-мастер помогает изменить эти взаимодействия так, чтобы они максимально увеличивали ценность, которую создает Скрам-команда.
    3. Product Owner (Владелец Продукта): Владелец Продукта несет ответственность за достижение максимальной ценности продукта как результата работы, которую выполняет Команда Разработки. Способы достижения максимальной ценности могут различаться и зависят от самих организации?, Скрам-команд и конкретных людей.
    Владелец Продукта – единственный человек, который отвечает за управление Бэклогом Продукта.

    Как я уже написал в статье, одна из целей — это показать, что прежде чем давать какие-либо вольные интерпретации ролям и зонам ответственности, необходимо детально ознакомиться с первоисточником.
    Что такое «ванильное определение», я не знаю но, подозреваю, что это частично то, о чём я писал: секретарь, прислуга, психолог. Вот как раз НЕТ!
    В идеале СМ в части работы с командой стремиться создать из неё самоорганизующуюся команду и, опять же таки в идеале, команда должна научиться обходиться без него (без СМ).
    Могу ещё много писать, но не буду :-), чтобы не написать коммент размером со статью :-)
    Всегда готов пообщаться в оффлайне на эти темы!

    • fcoder
      /#19147429

      «Ванильное» это и есть из первоисточника. Я использовал английскую вики, гугл тоже использует слово «facilitator» для скрам мастера в своём определении.

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

      • eugenvz
        /#19147581 / -1

        «Ванильное» это и есть из первоисточника. Я использовал английскую вики, гугл тоже использует слово «facilitator» для скрам мастера в своём определении.

        В принципе можно посмотреть в гайде, включая обязанности СМ для PO, DevTeam и Организации. В общем там не только фасилитация.
        Скрам-мастер задуман действительно как коуч. Но по-факту в зрелой команде — именно что назначает встречи (те, что в рамках скрам-процесса) и следит за регламентом (чтобы ретро уложилось в отведённое время митинга, чтобы команда не «забыла» показать демо, чтобы не было перекоса по поинтам от спринта к спринту и готовит кучу отчетности по спринту). Поэтому в зрелых командах скрам-мастера и правда частенько выпиливают, а его обязанности взваливают на ПО или на членов команды по-очереди, что как по мне, так весьма неэффективно. Обычно «дежурный» СМ как свои функции не может выполнить нормально, так и скрам-мастера настоящего заменить полноценно не может.

        В целом согласен с вами. Если уже не особо требуется команде, то пора ему подумать дальше, как расти, так как есть куда.

  3. TyVik
    /#19147281

    Как в тему! Как раз читаю Scrum Guide, есть вопрос по понятию «scrum-команда». Я так понял, что она должна быть компактной (замкнутой и ограниченной), чтобы работа над артефактами итерации зависила только от неё. Как в таком случае быть с дизайнерами, которые в большинстве случаев представляют собой другой отдел?
    Несколько раз упомяналось, что в команде есть всего одна роль — разработчик. Как тогда тестировать и деплоить? В общем случае этим могут (или должны) заниматься другие люди.

    • eugenvz
      /#19147421 / -1

      По Скрам-команде: должна быть кросс-функциональной и самоорганизующейся.
      То, что вы, скорее всего, имеете в виду — это про кросс-функциональность (не следует путать со взаимозаменяемостью). То есть когда в команде присутствуют все необходимые компетенции для создания продукта от начала и до конца и, соответственно, она не зависела бы от компетенций извне.
      В вашем случае необходимо договариваться и брать дизайнера в Скрам-команду, что, скорее всего, уже будет вопросом на уровне Организации и трансформации соответственно.
      В Скрам-команде всего три роли: PO, SM и Development Team. Грубо говоря, «разработчик» (developer) в Scrum Team — это тот, кто непосредственно выполняет работу «руками» :-), например, кодит, тестит, организует маркетинговые компании и т.д. Короче не только о программерах идёт речь :-)

      • staticlab
        /#19148831

        Непонятна формулировка из The Scrum Guide:


        Скрам-мастер предоставляет услуги Команде Разработки:
        — коучит Команду Разработки быть самоорганизующейся и кросс-функциональной

        Я могу представить себе коучинг по самоорганизации. Но что вкладывается в понятие коучинга для обеспечения кросс-функциональности команды?


        — Нам нужно разработать интерфейс для нашего приложения, но у нас нет дизайнера!
        — Но вы же кросс-функциональная команда!
        … И пулемёт застрочил вновь.

        • Hokum
          /#19148845

          Значит необходима внешняя косультация или внешний исполнитель, если это необходимо на постоянной основе, то нужно брать дизайнера в команду на постоянной основе. Кросс-функциональность — это не про то, что каждый "и швец, и жнец, и на дуде игрец". Это про то, то в команде есть отдельно "швец", отдельно "жнец" и отдельно "на дуде игрец".

          • staticlab
            /#19148875

            Да, определение кросс-функциональности понятно. Непонятна роль скрам-мастера в решении это проблемы. То есть он «обучает» команду, чтобы та сама просила у своей компании и PO себе дизайнера?

            • Hokum
              /#19149511

              Да, так это предполагается по The Scrum Guide. СМ — это штатный консультант-наблюдатель за процессом. Если команда отклонилась от цели и не проводит daily, он может подойти и сказать, что у вас тут какая-то фигня начинает происходить, вы отклонились от цели спринта, но повлиять ни на что он не может.

    • fcoder
      /#19147453

      Каждая задача перед тем как попасть в спринт должна пройти обсуждение (где уточняются детали, оценивается) и планирование (где определяется готовность для взятия в спринт).

      Если выясняется, что задача не может быть взята до выполнения каких-то внешних для команды (в вашем случае дизайнерских) задач, то создаётся запрос (или задача) на ПО

      • fcoder
        /#19147457

        (мобильная версия не позволяет редактировать)
        … создается задача для другой команды. И на неё ставится ссылка. А дальше ваш ПО и ПО другой команды разбираются с приоритетами

        • eugenvz
          /#19147599 / -1

          Судя по вашим комментариям вы очень даже в теме ;-)
          Есть ещё такая штука как критерии INVEST, DOR (Definition Of Ready). Если вам интересно, то почитайте.
          DOR — это то, что, например, про задачи внешнего вендора, от которых зависит ваша команда. Но фишка в том, чтобы не увлекаться DOR везде и всюду, так как перебор ведёт в неуместный Waterfall (я не против Waterfall, подчёркиваю «неуместный» в случае выбранного Agile-подхода).

  4. dipsy
    /#19147417 / +4

    «Каждый день стендапы минут по сорок, нафига мне на них присутствовать? Хотите знать, что я сделал и над чем работаю сейчас — смотрите Jira, Confluence, Git и т.д.»
    В статье рассказывается нам, глупым, до сих пор не понимающим зачем стендапы, что 40 минут-то это конечно перебор и надо всего 15 (не считая времени на подготовку перед и возврат в работу после).
    А всё равно непонятно, чем встречи в таком формате лучше например общего чата, где в реальном времени можно общаться, а не ждать 15-минутки следующего дня. Ну и прогресс опять же в реалтайме видно по чату и по коммитам с тикетами. Зачем эта ежедневная ритуальная клоунада с "что делал что сделано какие проблемы"? Нет ответа.

    • usego
      /#19147607 / -1

      Хотя бы для того, что бы выдёргивать людей из зоны комфорта и заставлять общаться с командой. Есть определённый тип людей, которые днями могут сидеть над банальной проблемой и никого не спросить как её лучше решать. А на стендапах такое часто всплывает раньше, чем несколько дней.

      • dipsy
        /#19147951 / +2

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

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

        • usego
          /#19148077 / -1

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

        • eugenvz
          /#19148113 / -1

          Вы выдали ключевую фразу, которую я «подрежу» слегка:

          Была бы заинтересованность
          .
          Смена методологии очень часто заставляет выйти наружу реальную заинтересованность (читай производительность, эффективность и т.п.) человека в работе. И скорее именно это уже не нравится человеку, а не «гибкость» той или иной методологии.

    • eugenvz
      /#19147619 / -2

      1. Глупыми я никого здесь не считаю.
      2. Если 15-минутки идут ежедневно и в целом всё ок (все понимают для чего у них Скрам), то ненужно к ним готовиться.
      3. События (обязательные встречи, если в общем) в Скрам не отменяют других встреч и прочего общения членов команды.
      4. Про «клоунаду». Формат Daily Scrum может определить сама команда. Важно получить информацию по статусу движения к цели спринта и есть ли какие проблемы с этим.
      В целом, если команда только начинает свой путь в Agile/Scrum, то лучше просто следовать гайду (видимо это подразумевается под «ритуалами»). Дальше, по мере того, как будет больше опыта и понимания фреймворка, всё должно стать проще. На самом деле в статье я вскользь упомянул про «сюхари» (можно посмотреть Вики) — это, на мой взгляд, как раз на данную тему.

      Очень часто возникает ситуация, когда «все всё знают», сидя рядом друг с другом, а на Daily выясняется, что кто-то один мучается с проблемой, решение которой знает другой. Или же когда происходит «вброс», который приводит к существенному изменению в работе.

      • dipsy
        /#19147979 / +3

        Очень часто возникает ситуация, когда «все всё знают», сидя рядом друг с другом, а на Daily выясняется, что кто-то один мучается с проблемой, решение которой знает другой. Или же когда происходит «вброс», который приводит к существенному изменению в работе.
        Очень часто возникает ситуация, когда просматривая коммит коллеги, который, по моему мнению, делает там что-то не то, предлагаю ему решение, которое сам знаю. Сразу предлагаю, не ожидая следующего дня и ритуальной сходки, понимаете? Более того, даже работа с 9 до 18 с пн по пт, это пережиток прошлого, люди всегда онлайн, всегда доступны, не надо всех собирать в одном месте, чтобы донести информацию или взаимодействовать друг с другом.
        Вот я здесь оставил информацию, с ней в ближайшие часы ознакомится пара десятков человек, мне не надо их ждать, собирать где-то, тратить их время, отвлекать от чего-то важного, когда им будет удобно они зайдут и прочитают (сейчас читаете), возможно даже как-то отреагируют. Вот так это работает в 21 веке.

        • nekt
          /#19149005

          сколько времени надо тратить, чтобы мониторить все коммиты коллег? А если он не хочет «пушить в общий репо, пока не причешу историю коммитов»?

          В общем случае стендапы достаточно показательны для определения зрелости команды. Если все процессы идут как надо, если члены команды проактивны, если цели понятны, то даже 15 минут будет много. Просто шанс оттранслировать в команду происходящие прямо сейчас процессы.
          Простое сообщение вида «Делаю задачу Х, столкнулся с проблемой Y, Z обещал показать как она решалась раньше» занимает 20-30 секунд, а тот, кто хочет побольше узнать о проблеме Y может просто подойти после стендапа и послушать, а что, а как.

        • eignatik
          /#19152623

          Вам ведь никто не запрещает за пределами ежедневного скрама общаться по разным вещам. 15 минутами не ограничивается общение, это подразумевает, что у вас есть 15 минут на команду, чтобы рассказать статусы с точки зрения общей перспективы текущего спринт. То есть можно заострить внимание на какие-то важные проблемы, но самое важное, держать в курсе всех не о том, какой код и комиты вы делаете, а что с точки зрения прогресса по задаче вы сделали, и как это влияет на прогресс в спринте.

          • dipsy
            /#19152671

            Послушайте, у меня в сутках 24 часа, а вы хотите украсть из них 30 минут (стендап + подготовка и время на возврат к работе). Мне жалко, жизнь не вечная.

            а что с точки зрения прогресса по задаче вы сделали, и как это влияет на прогресс в спринте.
            Давайте я когда сделаю, вам сразу сообщу, так не лучше будет? И если проблемы возникнут сообщу, сразу. А если вы ждете пока я что-то сделаю, чтобы свою часть начать, тоже можем договориться. Не обязательно всем собираться в кружок, да ещё каждый день.

            • time2rfc
              /#19153021

              Простите за мой вопрос, не хотел вас обидеть, скорее лучше понять позицию.
              А вы на работе 8 часов от звонка до звонка работаете не покладая рук и не отвлекаясь ?

            • eignatik
              /#19153293

              Я понимаю, что есть люди, которые предпочитают такой режим, и в нем работают вполне успешно. Но на мой взгляд, когда речь идёт о большом проекте, где работает команда из большого количества людей, и кроме такой команды есть ещё другие команды и им надо синхронизироваться и так далее, то это бывает очень полезным и важным. Скрам — это не лекарство от всех бед, есть много методологий и они работают не хуже. Просто если процесс поставлен правильно, то обычно понятно, зачем в данном случае используется такая методология итеративная.
              Одна из важных причин, почему так же используется Скрам — это прогноз и оценка, планирование. Я понимаю, что такие вещи могут не интересовать простого разработчика, но с точки зрения продукта — это важно, потому что это деньги. Чем более точное планирование, тем больше денег сохранит бизнес (в общем случаеъ есть много специфики от области бизнеса). Например, если разработка ведётся итерациями и все это мониторится, собираются метрики, то спустя какое-то время можно сказать, на какой капасити команда может 100% отрабатывать, и вы будете удивлены, на сколько точно такие «предсказания» работают. Но это при условии корректной интерпретации и применения методологии. Если коверкать понимание методологии, то лучше делать без неё. У меня есть опыт работы в компаниях, где использовали скрам, потому что надо бы, и от этого процесс страдал. И наоборот, работал там, где процесс поставлен грамотно, и разница видна очень сильно.
              Я не призываю использовать скрам. Потому что он не всегда подходит, есть много причин его не использовать, в зависимости от многих факторов. Но нередко правильное применение скрама наводит правильный порядок и упрощает разработку продукта.

              • gennayo
                /#19153735

                Вы можете привести хоть какие-нибудь цифры, позволяющие сравнить состояние «до» и «после» внедрения скрам?

      • staticlab
        /#19148533 / +2

        Про «клоунаду»
        видимо это подразумевается под «ритуалами»

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

        • eugenvz
          /#19148561

          Я как раз от крупных компаний и отталкивался ;-) и прекрасно знаю, что в первую очередь СМ это почему-то психолог/психиатр/психоаналитик :-)
          Согласен с вами, что карго-культ, который в итоге получается, ничего кроме негатива не вызывает.
          Об этом в том числе я и писал.
          Я смотрю на комментарии и понимаю, что многие восприняли мою статью, как оду Скраму, как к призыв к тотальному переходу на него. На самом деле это не так, но каждому я не собираюсь это доказывать.
          Эта статья на «задуматься», а не «мы все в Скрам!».

          • staticlab
            /#19148595 / +1

            и прекрасно знаю, что в первую очередь СМ это почему-то психолог/психиатр/психоаналитик

            Я бы не ставил психиатра и психоаналитика в этот ряд. Всё-таки они имеют дело с гораздо более серьёзными проблемами.


            Разработчики не любят упоминание Скрама потому, что его часто просто спускают сверху вместе с СМ, и за этим термином часто скрываются как раз-таки вышеописанные карго-культы.

      • staticlab
        /#19148627

        а на Daily выясняется, что кто-то один мучается с проблемой, решение которой знает другой

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

        • eugenvz
          /#19148643

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

          • staticlab
            /#19150135

            Насчёт их решения не понял, почему теряется день.

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

            • dimm_ddr
              /#19151767

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

              • staticlab
                /#19152023

                С дейли связано тем, что люди вот прямо сейчас все тут, обнаружили проблему, но решать её не имеют права.

      • MacIn
        /#19149019

        Очень часто возникает ситуация, когда «все всё знают», сидя рядом друг с другом, а на Daily выясняется, что кто-то один мучается с проблемой, решение которой знает другой

        Ну, тогда этот кто-то просто по факту обращается к коллегам, в общий чат, например — он же сам понимает, что тупит над решением. После первого-второго такого скрытого случая ему объяснят, что если ты тупишь, то обратиться к коллегам — не зазорно.
        Зачем тут ежедневные летучки?

  5. ioppoi
    /#19147427 / +3

    короче, скрам-мастер не нужен

    • eugenvz
      /#19147431 / -2

      Столь лаконичный тезис сразу рождает вопросы:
      1. Кому не нужен?
      и
      2. Когда не нужен?

      • ioppoi
        /#19148425

        никому и никогда не нужен

  6. reishi
    /#19147437 / +2

    Если команде нужен скрам-мастер, значит пора сменить команду

    • eugenvz
      /#19147443 / -2

      1. Если команда хочет работать по Скрам, значит СМ ей нужен.
      2. Если команда работает не по Скрам, СМ ей не нужен.
      Вроде основные ситуации разобрали.

      • Tyiler
        /#19147465

        развелось вас, болтунов и лоботрясов. менеджеров не хватает чтоли?
        назови как-нидь еще тогда «НЕДОКРАМ», пойдет название? или тебе надо простыню текста еще написать, как правильно жить по «НЕДОКРАМ»у?
        ПС: не просите только уточнять: «каких именно не хватает?, когда они не нужны?»…

        • eugenvz
          /#19147523

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

          • Tyiler
            /#19147547

            называю вещи своими именами.
            есть что ответить по сути? чем отличается СМ от менеджера, кроме того что он прочитал портянку текста об скраме?

            • eugenvz
              /#19147553 / -2

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

              • Tyiler
                /#19147563

                опять слова-слова…
                я думаю все все поняли.

              • boodda
                /#19147801

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

                • eugenvz
                  /#19147841

                  Вы ошибаетесь, мне никто ничего не продавал.
                  Что касается ответственности, то в итоге она на PO, например. Он отвечает перед стейкхолдерами. Так что, как минимум, одного ответственного отыскали.
                  Если вы делите PO и DevTeam, то это уже не команда (то есть не та самая Scrum Team).

                  • boodda
                    /#19147937 / +1

                    По скраму команда самоогранизуемая, и вот когда стекхолдеры спросят с PO за просраный дедлайн, тот в лучших традициях, скажет — «команда сработала не так, а я что?? Я то все по скраму делал, а вот Вася с Петей в скрам не верят вот и все пошло по п… не так».
                    Вот как так получилось? Вроде на русском написал, но как то не очень похоже на русский.

                    • eugenvz
                      /#19148005

                      Это про частые реалии и здесь я спорить не буду. Те, про кого вы написали — это не PO и, соответственно, это не команда. Есть ещё одна схожая ветвь, когда без стейкхолдеров «типа PO» начинает в конце спринта неприятно удивляться результату, выданному DevTeam. И это тоже не PO и не команда.
                      Но не только в книжках, но и в жизни я встречал и работал с командами, которые были единым целым — Scrum Team. Там, в общем-то было без сюрпризов и без «размываний» и прочих «размазываний» ответственности.
                      В одном из своих комментов я уже ссылался на одно интервью, где речь шла о совсем других компетенциях (более высокого уровня), когда идёшь в гибкие методологии.

                      • boodda
                        /#19148103 / +1

                        Скажите честно, это были вполне коммуникабельные профессионалы своего дела? могли они также эффективно работать без скрама? Дал ли скрам стабильный прирост эффективности хотя бы 20% на протяжении года или двух? Было ли это экономически оправдано? То есть, дополнительное время которое уходит на планирование в рамках команды, ретроспективы, митинги, демонстрации помноженное на стоимость человеко-часа, оно приносит экономический эффект для этих продуктов? ну и про реалии тоже не стоит забывать в вашем ответе

                        • eugenvz
                          /#19148203 / +1

                          Я считаю, что даже специалистам высокого класса можно было бы извлечь пользу из гибких методологий.
                          В ваших сообщениях чувствуется «боль потери времени на совещания». Это может быть вызвано тем, что:
                          1. Может Скрам в принципе не подходит для вас (Скрам — не серебряная пуля).
                          2. Может нет реального понимания, как правильно проводить эти совещания. Нет «того СМ», который должен был объяснить, что к чему.
                          Одна из интересных вещей, которую я в своё время открыл в Скрам — это то, что оказывается в нём тоже есть планирование :-) Причём даже посерьёзнее в некоторых моментах, чем в старом добром Waterfall.
                          Ещё раз: я не склоняю всех к сожительству Скраму. Просто то, что часто называют Скрамом, как правило, таковым не является.

                          • boodda
                            /#19148287

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

                            • eugenvz
                              /#19148301

                              1. Были вполне себе профессиональные работники.
                              2. В другой сфере деятельности, скорее всего могли бы. В той, где я это наблюдал, со Скрамом было эффективнее.
                              3. В процессе сбора статистики и пока она в плюсе.
                              4. См. п. 3.
                              5. Планирование по Скрам в наших реалиях позволяет сэкономить очень много времени, а значит и денег.

                    • fcoder
                      /#19148229

                      И тут выходит на первый план отчётность, которая показывает наглядно (на графиках), что и петя и вася в последние скажем 10 спринтов деливерят нормально (не хуже других в команде), а проблема в другом. Например, скоуп гораздо больше продуктивности команды и тренд непопадания проекта в дедлайн был виден ещё 6 спринтов назад.

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

                      Возможность делать оценку производительности, предсказывать готовность фич (с точностью примерно в 2 спринта) — это то, за что так любит скрам руководство.

                      • nekt
                        /#19149017

                        Как показывает практика, когда фокус внимания смещается с «побольше сторипонинтов закрыть» на «сделать нормальный сервис/продукт», начинают возникать вопросы «а так ли нам нужно все то, что мы делаем», «а не пора ли озаботиться тем, будет ли оно выдерживать нагрузку», «а почему у нас задачи по исправлению багов в функционале Х делаются в три раза дольше, чем добавление нового функционала в проекте У». И что еще важнее, эти вопросы начинают обсуждаться.

                        • dimm_ddr
                          /#19151805

                          Если есть нормальный QA или как вы этих людей называете, то такие вопросы должны задаваться в любом варианте работы команды. Но вот в скраме с их сторипоинтами и спринтами вещи вроде:

                          а почему у нас задачи по исправлению багов в функционале Х делаются в три раза дольше, чем добавление нового функционала в проекте У

                          отследить обычно проще. Хотя бы потому уже что такая статистика в принципе собирается.

                          • staticlab
                            /#19152045

                            И какая же статистика в скраме помогает нам ответить на вопрос "Почему"?

            • staticlab
              /#19152031 / +1

              чем отличается СМ от менеджера

              Тем, что менеджер по определению кем-то руководит, а СМ — ни за что не отвечает.

      • JekaMas
        /#19149709

        Трудные будни продажи scrum master… Понимаю, сочувствую.

  7. eugenvz
    /#19147441

    Дубль комментария, просьба игнорировать.

  8. Tyiler
    /#19147513 / +5

    еще понравилось

    2. Скрам-мастер: несет ответственность за продвижение и поддержку Скрама в соответствии с Руководством по Скраму. Он достигает этих целей, помогая всем понять теорию, практики, правила и ценности Скрама.


    короче, работает работу.
    если б он еще массаж делал — шеи разминал, или там… чай разносил, больше пользы бы было.

  9. tangro
    /#19147575 / +6

    Скрам — это как ритуальные танцы шаманов для вызова дождя. Один шаман потанцует — и дождь идёт. А другой потанцует — и дождь не идёт. Это, наверное, потому, что второй неверно потанцевал?

    Если в хорошем проекте взять и выбросить, ну я не знаю, тимлида или сервер с базой данных — проекту станет плохо и это будет видно сразу. Если же в хорошем проекте взять и выбросить скрам-мастера, то не изменится ровным счётом ничего: и тимлид и сервер с базой данных продолжат работать. Как в том анекдоте, что простуда проходит за неделю, если лечить, и за 7 дней, если не лечить.

  10. Ermit
    /#19147591 / +2

    Всё хорошо в меру. Когда скрамом и аджайлом подменяется работа — тогда плохо. Когда они используются как инструменты (с максимальной эффективностью) — тогда хорошо. В любом случае, это зависит от команды и менеджмента, ибо нельзя техническими средствами решить организационные проблемы. А при хорошем менеджменте и эти костыльки будут работать не хуже прочих…

  11. maxzh83
    /#19147605 / +2

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

    • DikSoft
      /#19149499

      +1!
      Плюсом было бы, чтобы это не _навязывалось_ вообще везде. В команде развития ИТ инфраструктуры, например.

  12. geher
    /#19147667 / +3

    У меня вся эта клоунада вокруг технологий органзации работы навевает следующие мысли.
    Команда разработчиков должна выбирать не модную технологию, а ту, что удобна именно этой команде.
    Иначе почти гарантированно получается карго-культ со всеми его негативными последствиями.
    Самое "веселое" бывает, когда какая-то команда создает для себя удобную систему, потом этой системе дают звучное название, рекламу, внедряют направо и на лево, не задумываясь, а подходит ли оно данной конкретной команде. А потом со всех сторон идут негативные отзывы.
    Похоже, что именно это и произошло со скрамом, давно превратившимся из всего лишь одной из многих систем организации работы в команде в какой-то бессмысленный культ.
    И попытка "вернуться к истокам" уже ничего особо не дает, поскольку культ сформировался именно в том виде, который сейчас имеем.

    • Amokmorg
      /#19148645

      что б это не стало карго культом как раз и нужен скрам мастер.

      • geher
        /#19148745

        А если этот скрам мастер (со всеми бумажками) является частью или даже основанием карго культа?
        Ну да конечно, теперь мы знаем, что он не настоящий скрам мастер.
        Только непонятно, как это знание может помочь.

        • staticlab
          /#19148791 / +1

          Судя по принципам Манифеста Agile:


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

          Простота — искусство минимизации лишней работы — крайне необходима.

          Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.

          Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

          ответственная команда должна выгнать такого «скрам-мастера» и работать дальше самостоятельно. Иначе это будет не Agile.

          • geher
            /#19157367

            Фокус в том, что выгнать "неправильного" скрам-мастера может только настоящая скрам-команда. А если у нас просто клоунада с таким же названием, то и мастер соотвествующий, и выгнать его не получится.

  13. eugenvz
    /#19147695 / +1

    tangro, Ermit, maxzh83, geher,
    Да, отчасти про это и статья.
    Я, ровно как и создатели Скрам, не считаю Скрам серебряной пулей. Всему есть своё применение. Я также абсолютно не призываю «натягивать сову на глобус» (то есть использовать всем только Скрам).
    Речь о том, что не вникнув в суть чего-либо (в данном случае был выбран Скрам, а вообще можно к чему угодно применять) начинается череда незаслуженных оценок, негатива и пр.

    • Hokum
      /#19147739 / +1

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

      • eugenvz
        /#19147759

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

        • tangro
          /#19150125

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

      • boodda
        /#19148127

        «мне сказали делать — я делаю», это результат того, что «мы все решили — ваше дело сделать, кто не согласен может уходить»

        • Hokum
          /#19148201

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

    • Ermit
      /#19147765 / +1

      Да, это так. Но я два года жил под скрамом и мой опыт — практический. Никогда (слышите — никогда) я не стал бы использовать скрам на этапе проектирования. :) А вот на этапе отладки и рефакторинга — да, это годная методика.

  14. solver
    /#19147927 / +3

    Офис. С утра офисные сотрудники в спешке передвигают мебель с места на
    место, выравнивают все по сантиметру, компасу и т. д.
    Посредине всего этого хаотичного движения стоит старенькая уборщица в
    обнимку со шваброй, испуганно смотрит на все это действо и бормочет про
    себя:«Только помыла, сейчас все опять затопчут, уроды».
    Стояла долго смотрела на все это, потом спрашивает:
    — Милые, а что вы тут делаете? Переезжаете?
    — Да нет, бабуля, мы сейчас мебель по фен-шую передвинем и у нас сразу
    продажи взлетят до небес.
    — Сынки, я тут давно уже работаю, еще до революции полы в этом здании
    мыла. Так вот, до революции тут был публичный дом. Так там, когда касса
    падала, кровати не двигали — там сразу бл**ей меняли.

    • eugenvz
      /#19147975 / +1

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

      • solver
        /#19148333 / +4

        Я учавствовал в нескольких командах работающих по скраму. Проходил тренинги по скраму от скрамтека. Ничего кроме ритуалов не увидел.
        Зачем нужен дейли митинг? Он только ест время. Все тупо сидят и перечисляют что они делали. Никакой практической ценности это не может нести даже теоретически. Только отвлекает всех от работы.
        Все эти ужимки и приседания в виде планопокеров, митингов и прочего говна немогут заставить человека работать если он не хочет.
        Если подумать, то все сводится, условно, к задачам в джире.
        Человек берет задачу в джире и делает ее, например, 3 дня. Он делал бы эту задачу те же 3 дня и без аджайла. Без всех этих оценок и прочей пустой траты времени. И за неделю он сделат к примеру 7 задач. Есть аджайл или нет.
        В 98м году писали софт на дельфях. По понедельникам встречались с заказчиком, смотрели что сделано, планировали следующую неделю и делали. Никто это не называл никакими модными словами. Все работали. Не выдумывали этой дичи с планпокерами и прочими приседаниями.
        Не заставляли людей заниматься херней называя это фреймворками…

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

        • staticlab
          /#19150689

          Человек берет задачу в джире и делает ее, например, 3 дня. Он делал бы эту задачу те же 3 дня и без аджайла. Без всех этих оценок и прочей пустой траты времени. И за неделю он сделат к примеру 7 задач. Есть аджайл или нет.

          Разница только в том, что если оценивать задачи предварительно, то есть шанс их недооценить и, соответственно, не успеть закрыть спринт. Это не покер, а самый настоящий преферанс :)


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


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

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

  15. UnrealQW
    /#19147985 / -1

    Статья похоже на мысли вслух и поток сознания… Суть ее можно свести к следующим тезисам:

    1. Не все вещи являются тем, чем они выглядят, хотя могут и выглядят тем, чем являются, но не факт ибо см. п.2.
    2. Думайте во время работы как правильно работать ибо см. п.3.
    3. Скрам-гайд — библия

  16. avost
    /#19148063 / +3

    Любопытно, это только среди новообращённых скруммастеров популярна мантра — если у вас скрум не работает, значит вы используете не скрум и только бросаете на скрум тень? Никогда не слышал, чтобы условные "отвертко-мастера" на заявление, что не получается вкручивать отвёрткой гвозди заявляли, что всё получается, просто вы на самом деле использовали не отвёртку, поэтому нечего бросать на отвёртку тень, ею вполне можно закручивать гвозди!

    • eugenvz
      /#19148167

      Не знаю, что там с новообращёнными, но настоящие СМ свои ошибки признавать могут (да, я и такое видел). В каждом случае, почему Скрам не работает разбираться надо. Может его вообще не стоит в конкретном случае использовать (повторюсь, что я не за то чтобы Скрамом затыкать все дыры)?
      Более того, знают текущее состояние команды, и у них обязательно есть план по тому, как команде двигаться дальше.
      Я вас уверяю, что у большинства скептиков округлятся глаза при вопросах про метрики.
      Начнут рассуждать, что сейчас всё хорошо, и будет обязательно лучше.
      Беда вот только цифр обычно от них не допросишься…

      • avost
        /#19152203

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

        Почему не работает? Как-то там работает. Если достаточно долго мучаться, то и отверткой можно вкрутить гвоздь. Но зачем?


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

        А что не так с метриками?


        Беда вот только цифр обычно от них не допросишься…

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

        • time2rfc
          /#19152253

          Если достаточно долго мучаться, то и отверткой можно вкрутить гвоздь. Но зачем?

          А расскажите, пожалуйста, что работает? Мы думаем о возможном изменении процессов, интересен чужой позитивный опыт.

    • MacIn
      /#19149035 / +1

      Так обычный «ненастоящий шотландец» или как там.

  17. arielf
    /#19148303

    Любые «гибкие» способы разработки или управления вызывают у меня мигрень. Напрогибались. У меня не безумно сложные проекты были и размеры рабочей группы в 3 — 4 человека, но и в них любая «гибкость» вела к мгновенному неконтролируемому увеличению энтропии.

    Возможны ли scrum и прочая имитация бурной работы в, например, аэрокосмической инженерии? Не возможны — и слава Богу! Иначе Лунная программа так бы и не началась! В аэрокосмической инженерии невозможно на этапе финальной сборки ракеты сказать конструктору: «а увеличь-ка число её пассажиров на 5 человек, вам же не сложно? у вас же масштабируемая архитектура?»

    А в программной инженерии у заказчика требования по 5 раз в месяц меняются. И проекты зависают на месяцы или выпускаются сырыми! И сие не нормально! Требования нужно зафиксировать в проекте и не менять — а любое изменение, не заложеннное в нынешней архитектуре — новый проект, новые расчёты и новый заказ. Ну и сроки, конечно, приблизятся к срокам в аэрокосмической инженерии, но, оно и к лучшему — ибо и качество вполне возможно приблизится.

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

    • usego
      /#19148617

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

      • arielf
        /#19148803 / +2

        И в аэрокосмической инженерии невозможно всё заложить сразу. Но стараются — и на старте никому не стукнет в голову попросить впихнуть в ракету ещё пару человек. А причина — кажущаяся заказчику низкая цена и лёгкость изменений в программе. А Срам появился как попытка заказчика оправдать свою некомпетентность.

        • Hokum
          /#19148833 / -1

          Разные проекты — разные подходы. Это нормально, гибкие методологии не везде будут работать или не на всем жизненном цикле продукта. Тут в другой статье поднималась похожая тема: https://habr.com/post/422327/#comment_19073275.


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


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


          Применяется как эффективная практика организации труда небольших групп (которые делают однородную творческую работу) в объединении с управлением ими комбинированным (либеральным и демократическим) методом [Гибкая методология разработки].

        • MacIn
          /#19149037

          Все же сранивать негибкость железячных и программных технологий не очень верно.

          • arielf
            /#19149059 / +1

            Негибкость железячных технологий пошла им на пользу!

            • MacIn
              /#19149081

              И да и нет. В части продумыания наперед — да, но это сопряжено с увеличенными (по сравнению с софтом) сроками. Так что все как в золотом правиле механики.

  18. gennayo
    /#19148337

    А может кто-нибудь из сторонников SCRUM привести измеренные цифры роста эффективности разработки при его применении?

    • usego
      /#19148631 / +2

      Кто сказал что у скрама цель повысить эффективность? Цели несколько иные. Это в том числе методология работы со стейкхолдерами. В нашей команде это первое, чем помог скрам. Обозначил capacity команды и дал возможность заставить стейкхолдеров расставлять приоритеты по ограниченному ресурсу.

      • MacIn
        /#19149047 / +1

        А без scrum'а stakeholder'ы не поймут, что команда в 5 человек не может выполнить работу сотни?

        • usego
          /#19149973

          Они даже между собой не могут договориться о функционале. SPM — хороший способ заставить их хотя бы между собой поговорить, заодно расставив приоритеты поверх капасити.

          • MacIn
            /#19151235

            Project manager концентрирует и координирует обсуждение функционала. Скрам тут при чем?

            • usego
              /#19151495

              PMу (а в скраме это другая роль), надо оперировать какими-то KPI, что бы планировать / обосновывать ёмкость команды. Да это можно делать и не по скраму, а хоть в канбане, но у канбана свои грабли. Тут, как правильно написали, серебряной пули нет. Мой пойнт — не надо на скрам смотреть лишь с позиции программиста, так действительно непонятно на фига оно всё надо.

              • MacIn
                /#19152255

                надо оперировать какими-то KPI, что бы планировать / обосновывать ёмкость команды.

                Сами разработчики могут дать ETA. Как иначе? Данные по-любому с потолка ПМами не берутся. Только опять же — при чем тут скрам…

      • gennayo
        /#19149227

        Нет цели повысить эффективность??? Я Вам не верю…

  19. PerlPower
    /#19148447 / +3

    image НАСТОЯЩИЙ СКРАМ НИКОГДА НЕ БЫЛ ПОСТРОЕН!

  20. staticlab
    /#19148565

    Скажите, а всё-таки, в чём отличие Скрама от итеративной и спиральной моделей разработки? Почему на всех лекциях по Аджайлу упоминается только каскадная модель (она же Waterfall), которую не рекомендовал использовать даже впервые упомянувший о ней в 1970 году Уинстон Ройс, рекомендовавший итеративную модель?

    • eugenvz
      /#19148661 / -1

      Скрам — это, скажем так, одна из реализаций Agile.
      Agile использует итеративную модель.
      Полагаю, что отличий здесь не стоит искать.

  21. vladimir123456
    /#19148665

    Неужели есть профессиональные программисты которые серьезно воспринимают SCRUM?

    • eugenvz
      /#19148669 / -1

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

      • arielf
        /#19148863

        Какое у вас самомнение…

      • MacIn
        /#19149073 / +2

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

        Традиционных — это каких именно? И ведь мы говорим НЕ о методологиях, верно? Вы сами написали, что scrum — вариация итерационной методологии.

  22. nekt
    /#19149027 / -1

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

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

  23. vladimir123456
    /#19149509 / -2

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

    • DikSoft
      /#19150493

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

  24. ggo
    /#19150025 / +1

    Ребята… технари… ит-шники…

    Скрам — он не про ИТ.
    Скрам — он про бизнес.

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


    Здесь ничего про ИТ. Только про бизнес.
    Про то, как бизнесу в условиях неопределенности, выводить на рынок и развивать определенные продукты (не любые продукты).

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

    Очевидно, такое подходит не всем ит-шникам. Не все разделяют ценность бизнес-ориентирования. И тогда возникает, то что здесь в комментариях красочно живописано.

    И при этом нет правых и не правых.
    Есть разные подходы к ведению бизнеса. Скрам — один из.

    • DikSoft
      /#19150567

      Это реально не про ИТ, это про безответственность бизнеса. Менять ТЗ на ходу. Объявив это нормальным.

      • Hokum
        /#19151157

        Речь не про изменение ТЗ на ходу. Когда есть конкретное ТЗ, то нет места скраму. Это две разные модели. Если работать по ТЗ (в идеальном мире), то заказчик выдает определенный набор требования, команда оценивает и называет срок и сумму. В указанный срок заказчик приходит и ему отдают готовый протестированный продукт. Т.е. фактически покупается конечный продукт, в случае гибких методологий, заказчик покупает не продукт как таковой, а время команды разработки.


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


        Это если применительно к ИТ.

        • DikSoft
          /#19151199

          … в случае гибких методологий, заказчик покупает не продукт как таковой, а время команды разработки
          об этом я собственно и написал. У бизнеса появляется сценарий, когда он может ни за что не отвечать! Сейчас хочу так, завтра — эдак, но мы это обзовём новым словом «скрум» и будем парить мозг команде разработчиков перманентно и без конечных сроков!
          ЗЫ И главное — без ответственных за сорванные сроки проекта в целом. Потому как … Ну, Вы поняли?

          • Hokum
            /#19151259

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

          • ggo
            /#19151435

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

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

            • staticlab
              /#19151647

              В скраме нет деления бизнес/ит. Есть только команда, которая отвечает за продукт.

              Так есть же. Команда разработки отдельно, PO и SM — отдельно.

              • Hokum
                /#19152029

                PO, SM и Dev. T — все вместе скрам-команда. Это выделение ролей в процессе, но не разделение бизнес/не бизнес.

                • staticlab
                  /#19152097 / +1

                  Если PO не будет отражать текущие хотелки бизнеса в бэклоге, то команда будет делать совсем другой продукт, который бизнесу не нужен. Таким образом PO представляет продуктовые интересы бизнеса. Фактически PO и DT находятся в диалектическом противоречии. SM же здесь играет лишь вспомогательную роль.

                  • usego
                    /#19152667

                    PO ответственен за правильный беклог. Он не навязывает стресс по его burnout. Это как раз роль SM. Но по факту PO и SM часто одно и то же лицо.

                  • ggo
                    /#19152827

                    И все таки они команда.
                    А что у нас команда? Группа лиц объединенных одной целью.
                    В случае скрам-команды — объединенные целью создания и развития продукта.

                    В целом, я согласен, что настоящему итшнику крайне сложно разделять бизнес-ориентированные ценности, итшник стремится к построению идеального мира, где 1+1=2.
                    Но мир неидеален, и 1+1 не всегда =2.

                    • time2rfc
                      /#19153035

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

                      • ggo
                        /#19153957

                        Нуу, каждый делает свои выводы. У вас такие. У меня несколько другие.
                        Мне они (ваши выводы) тоже не нравятся.

                        • time2rfc
                          /#19154785

                          Можете первоначальную мысль тогда раскрыть чтобы мы лучше поняли друг друга?

                          • ggo
                            /#19157123

                            Мне больше нравится:
                            Хороший итшник с высоким уровнем саморефлексии создает больше ценности и потому больше востребован рынком, чем просто хороший итшник.

                            • time2rfc
                              /#19157945

                              Неправильно вас понял первый раз, спасибо.

  25. UnhappyPanda
    /#19150429

    Так вот, главным документом по Скрам является «The Scrum Guide», написанный в соавторстве Кеном Швабером и Джеффом Сазерлендом, доступный на многих языках, включая русский.
    На мой взгляд, для того, чтобы получить базовые знания по Скрам и, впоследствии не засорять своё сознание всевозможными неверно истолкованными дополнениями к Скрам, требуется всего два основных компонента: желание и вдумчивое прочтение «The Scrum Guide», причём не один раз.

    Согласен, что это приходится читать не один раз. Но не потому, что это такая классная вещь, что её стоило бы перечитать, а потому что она ужасно написана, и понять её с первого раза решительно невозможно. Постоянные упоминания неразъясненных терминов с ссылкой на что-то впереди. Обычное описание практически чего угодно там выглядит так (цитатаиз первого же абзаца документа):
    Это Руководство содержит описание Скрама, оно рассказывает о ролях, событиях, артефактах(2) и правилах фреймворка.
    и сноска
    2 Подробнее об артефактах будет рассказано на стр.16

    И так постоянно, чтобы целиком не заваливать цитатами вот просто сноски с первых пяти страниц:
    2 Подробнее об артефактах будет рассказано на стр.16

    6 Подробнее о Критериях Готовности будет рассказано на стр.19.

    7 Подробнее о Цели Спринта будет рассказано на стр.13

    8 Подробнее о Бэклоге Продукта будет рассказано на стр.16.

    Это совершенно невозможно читать последовательно. Почему люди, которые учат других людей создавать качественный продукт, не могут создать качественный читаемый 25-страничный документ?

    • DikSoft
      /#19150507

      Потому что цели такой не ставилось. Завтра, типа, соберемся, обсудим и исправим.

  26. vladimir123456
    /#19150697

    SCRUM по сути, если отбросить словесную шелуху, это элементарный micro management обёрнутый в набор ритуалов. Лучший ли это способ разрабатывать программное обспечение?

  27. mSnus
    /#19150779

    Интересно было бы почитать отклики компаний, ОТКАЗАВШИХСЯ от Скрам. Что-то вроде «мы отказались от Скрам и повысили эффективность на 20%!» Или «вместо того, чтобы вкладываться в Скрам, мы вложились в повышение комфорта разработчиков, и теперь люди бегут не о нас, а к нам»… ))

  28. vladimir123456
    /#19150939

    Все это напоминает сказку Андерсена «Новое Платье Короля».

  29. vladimir123456
    /#19151023

    Гибкая разработка и SCRUM не синонимы.
    SCRUM паразитирует на понятии гибкой разработки.

  30. time2rfc
    /#19151165

    Спасибо всем кто потратит немного времени и в 2-3-4 предложениях напишет какая модель управления в их компании работает лучше чем scrum и почему.

      • time2rfc
        /#19151921

        Спасибо, надеюсь еще парочку историй найду.


        p.s.
        Очень интересное видео про менеджеров и техлидов, отчеты которые пишут менеджеры команды не отвечающие за свой продукт итд.

        • vladimir123456
          /#19152807

          Напоминает басню Крылова «Квартет» — тут надо архитектуру продукта лечить, а не программистов пересаживать.

  31. Praporshik_Zadov
    /#19152327

    Судя по живости обсуждения Scrum на хабре становится таким же популярным, как и новости про криптовалюты.

  32. ilitaexperta
    /#19152403

    Очередное

    Это не Scrum плохой, просто у вас его неправильно реализовали
    Я знаю как делать правильный Scrum, пока конечно же не сделал, но я двигаюсь к этому!

    Нет никакого четкого определения что такое Scrum, существует только куча разных толкований от Scrum-евагелистов.

    Scrum это очередная бизнес-религия, созданная для того, чтобы такие сертифицированные балаболы как автор статьи могли паразитировать на бизнесе и балаболить за зарплату, по факту занимаясь пинанием всех известных органов

    • time2rfc
      /#19152463

      Поделитесь, пожалуйста, историями успеха — что работает и как правильно выбрать метадологию\процесс людям в начале пути?

  33. vladimir123456
    /#19152887

    Следуйте правилу: неправильная архитектура продукта не лечится правильной методологией.

    • ggo
      /#19152909

      Что есть архитектура продукта?

  34. eugene_bb
    /#19152971 / +1

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

    По моему наблюдению, чем слабее менеджмент (PO/PM/team lead/tech lead) и сильнее команда, тем больше выгоды. Если же менеджмент сильный, то всё случится не зависимо от методологии и команда будет подобрана сильная и сроки соблюдаться. Ну а если и команда и менеджмент так себе, то как было сказано выше, «как не садитесь, а в музыканты не годитесь».

    Но daily meeting и т.п. ритуалы из скрама, конечно могут принести больше вреда чем пользы.
    У нас например самый никчёмный программист был звездой daily meeting, он так рассказывал про успехи и борьбу с проблемами, что становилось завидно какой интересной жизнью человек живёт. А самый умный, наоборот, не блистал на митингах. Все конечно понимали что к чему, но мораль страдала.

    А когда пригласили на митинг по поводу увольнения того умного программиста, я чуть не прифигел. Оказывается VP который иногда участвовал в подобных daily meeting-ах, составил себе собственное мнение.

    А статья (как и многие другие) и особенно комментарии автора, являются антирекламой методологии.

  35. vladimir123456
    /#19153325

    Без daily meeting это уже извините не SCRUM.
    А кто сказал что для SCRUM нужны умные программисты?
    Нужны заменяемые с предсказуемой продуктивностью (пусть и небольшой).

  36. V-core
    /#19154171

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

  37. demet
    /#19158705

    Не раз встречаюсь с мнением, что при слабом руководстве вырастает сильная команда если внутри есть тимлид.

    Здесь писали в коментах, что часто именно слабое руководство хотят заменить методологией, и первое что гуглиться Agile и Scrum, ну и потом коучи с процентами эффективности приходят.

    И внедряют, по итогу руководство как было слабое так и осталось, а команда не готова с Scrum, вывод — Scrum/Agile не работают. Начинается поиск косяков метолодогии.

    Имхо внедрять нужно на уровне тимлида и при слабом руководстве этого тимлида выделить.

    Любая методология это инструмент и не более, не палочка-выручалочка, сначала голова потом Scrum (Mozg).