Плохой Scrum Лучше Хорошего Agile

Залп сбил 50 офицеров и 760 рядовых.
Французы дрогнули, запаниковали и обратились в бегство.
«Здесь наши дела шли не очень хорошо», — описывает этот момент сражения официальная французская депеша.
Келли Дж.
Порох.
От алхимии до артиллерии.
Формирование Scrum-команды всегда сопряжено с множеством трудностей.
Почти каждый может изменить порядок своего рабочего процесса и начать выполнять некоторые необходимые Scrum-мероприятия.
Но лишь меньшинству удается получить видимую выгоду от этих формальных изменений и начать реально менять рабочий процесс.
В результате у команды формируется следующее мнение о Scrum: « Мы теряем время на митинги.
Скрам не работает. Что-то нужно изменить ”.
Пытаясь как-то спасти ситуацию, активисты Scrum вспоминают, что Scrum — это еще и фреймворк.
Объявлена новая стратегия: « Мы не только Scrum, мы еще и Agile! Мы используем лучшие практики, берем из Scrum только лучшее, то, что подходит конкретно для нашей ситуации, а все остальное лишнее и ненужное.
" И если так - " Мы молодцы и все делаем правильно ”.

К сожалению, это «спасение в схватке» зашло в тупик.
Идя по легкому пути, избавляясь от сложных элементов Scrum, не пытаясь искать и решать проблемы самостоятельно, копируя методики из случайно попавшихся под руку статей, можно построить некий процесс.
Но не Скрам.
Руководство по Scrum, заключительное примечание: « Роли, артефакты, события и правила Скрама неизменны, и хотя реализация только частей Скрама возможна, результат не является Скрамом.
”.
Scrum действительно является фреймворком, но не в том смысле, в котором это слово обычно понимается при разработке.
Скрам — это фреймворк, фундамент, основа рабочего процесса.
Все элементы Scrum созданы так, чтобы дополнять и поддерживать друг друга.
Однако они не дублируются.
В Scrum нет запаса прочности.
Поэтому все, что описано в Scrum Guide, необходимо реализовать; из Scrum ничего нельзя выкинуть.
Но его можно и нужно расширять.
Scrum Guide определяет рабочий процесс в общих чертах, поскольку у каждой команды есть своя специфика, и не существует универсального императивного решения для всех.
Каждая команда должна найти лучший способ организовать свою конкретную работу по Scrum. Децентрализованные команды могут проводить Daily через Skype, а при работе в одном месте можно собраться в рабочем помещении или выйти в переговорную или на улицу, если всегда светит солнце и нет дождя.
При условии принятие ценностей Scrum на уровне компании в целом Scrum может быть полностью внедрен в любой команде.
Начав работать по Scrum, команда гарантированно добьется значительного прогресса.
В книге " Скрам: искусство делать вдвое больше работы за половину времени » по Скраму Джефф Сазерленд обещает удвоить отдачу от работы команды.
На самом деле, если он и преувеличивает, то не так уж и много.
Возможно, не стоит сразу ожидать огромных улучшений.
Мы люди разумные и редко доводим работу до такого плачевного состояния, чтобы даже минимальная систематизация сразу давала отличный результат. Однако прогресс будет, и масштабы улучшений будут заметны невооруженным глазом.
А начнется все с того, что ранее молчавшие разработчики начнут говорить о вмешательстве в их работу, и с того, что к их мнению начнут прислушиваться.
Практика показывает, что сложнее всего наладить Scrum тем командам, которые уже начали «работать по Scrum», но на самом деле выстроили процесс хаотично.
Основывая работу на предрассудках, плохих методиках и плохом понимании того, как работает Scrum в целом, команда загонит себя в тупик.
Но даже эта ситуация не безнадежна.
Хотя такой команде, скорее всего, понадобится помощь извне.
Команда сможет разобраться, что она делает правильно, где идет не так и чего ей не хватает. Но это займет больше времени, чем у команды, избежавшей подобных ошибок в самом начале.
О Scrum существует множество ошибок и заблуждений, но некоторые из них возникают настолько часто, что начинают восприниматься всеми без всякой критики и превращаются в Карго-культ .
Чтобы самому не попасть в беду, стоит разобраться в некоторых из них.

Скрам: работа над ошибками
О командах Часто можно услышать следующее: “ Scrum-команда должна состоять только из разработчиков, каждый из которых должен уметь выполнять всю необходимую работу.
Где мы можем их получить? У нас есть только дизайнеры, разработчики, верстальщики и тестировщики.
Если да, то как Scrum-команда у нас все равно не получится, будем работать как раньше.
”.
Но на самом деле Scrum Guide говорит следующее: « Команды разработчиков являются кросс-функциональными и обладают всеми командными навыками, необходимыми для создания продукта.
Да, команда должна быть универсальной, но она должна быть универсальной в целом.
Если вам нужен JavaScript-разработчик, QA и дизайнер, чтобы довести разработку до релиза, они все должны быть в команде.
В противном случае «тележки не будет».
двигаться.
" При этом команда несет полную ответственность за результаты своей работы.
Скрам-руководство: « Отдельные члены команды разработки могут обладать специальными навыками и сферами деятельности, но ответственность лежит на команде разработки в целом.
Это не пустые слова.
Если дизайнер Иннокентий нарисовал отличный дизайн, но команда не смогла его реализовать и выпустить, это провал команды в целом и каждого члена команды в частности.
Вместо этого Иннокентий обвинять JavaScript и QA в медленности, следует задуматься: может быть, он сможет изменить что-то в своей работе, чтобы в следующий раз команда смогла добиться результата.
При этом у всех членов Scrum-команды есть одна должность: Разработчик.
Скрам-руководство: « Scrum не признает никаких должностей для членов команды разработчиков, кроме «разработчика», независимо от работы, выполняемой этим человеком; из этого правила нет исключений ”.
Во-первых, это ключ к повышению продуктивности команды.
Например, несмотря на то, что Иннокентий имеет специализацию по дизайну и наиболее эффективен в этом виде работы, он тем не менее вполне способен помочь команде с тестированием, если именно этот этап разработки является узким местом на данный момент. Подробнее об этом читайте в книге «Лияху Голдратт».
Цель (Цель в оригинале).
Во-вторых, это позволяет всем членам команды обсуждать все вопросы на равных.
Идеи, оценки, проблемы – каждый имеет право высказать свое мнение.
Например, Иннокентий не имеет права игнорировать комментарии Татьяны о том, что красный цвет шрифта на красном фоне — плохое визуальное решение.
Несмотря на то, что Татьяна имеет специализацию по тестированию, когда она видит проблему, она имеет право высказаться, и к ее мнению не могут отказать, потому что она ведь QA. В команде разработчиков все равны, и это действительно важно.
Этот подход не уникален для Scrum; Подробнее о важности этого принципа вы можете прочитать в книге Джеффри Ротфедера « Вождение Хонды ”.
Взаимная помощь и взаимоуважение составляют основу успешной Scrum-команды.
Об обзоре “ Вам нужно пригласить пользователей в Demo, но мы делаем веб-приложение и наши пользователи где-то далеко.
Может быть, там, в солнечной Калифорнии, Scrum-команды могут пригласить пользователей на демо, но не в нашей стране морозов, медведей и матрешек.
”.
В Scrum нет демо.
Однако это не мешает многим проводить Демо.
Например, собрать 200 разработчиков в одной комнате с проектором и мучить друг друга демонстрациями в течение 5 часов.
Эпредприятие.
? придирчивый.
Бесполезный.
В Scrum есть обзор.
А обзор подразумевает обсуждение проделанной работы, достигнутых результатов и планов на будущее с заинтересованными сторонами.
Коммуникация и обратная связь являются ключевыми элементами обзора; каждый приглашенный на проверку должен иметь возможность высказаться и обсудить свою точку зрения с командой и другими заинтересованными сторонами.
Поэтому количество приглашенных на смотр людей должно быть ограничено, иначе нормальное обсуждение будет невозможно.
Владелец продукта несет ответственность за приглашение на обзор наиболее ценных людей.
Скрам-руководство: « В число участников входят Scrum-команда и ключевые заинтересованные стороны, приглашенные владельцем продукта.
”.
К заинтересованным сторонам относятся не только владельцы бизнеса или клиенты, но и любые другие сотрудники компании, которые могут предоставить команде качественную оценку результатов ее работы и при этом иметь заинтересованность в общем успехе.
Это могут быть представители техподдержки, аналитики, эксперты по разработке, руководители отделов, Владельцы продуктов других команд и любые другие сотрудники, независимо от их должности и рода деятельности.
Важно, чтобы их мнение по каким-то причинам было ценно для команды.
Наконец, да, конечные пользователи, если это имеет смысл.
Подробнее о рецензировании вы можете прочитать в книге Кеннета Рубина « Основы Скрама ”.
О ретроспективе “ Пару раз пытались сделать ретроспективу, но говорить было особо не о чем.
В целом в нашей команде проблем нет, поэтому лишняя встреча – пустая трата времени.
Давай поработаем еще пару часов ”.
Ретроспектива обязательна.
Только научившись находить и исправлять проблемы в работе команды, можно повысить ее продуктивность.
Научиться проводить качественную ретроспективу очень сложно.
Книги не помогут. Для этого необходим практический опыт. В команде должен быть либо сильный Скрам-мастер, который сможет научить команду проводить ретроспективу изнутри, либо один из опытных менеджеров, который сможет помочь команде извне.
Работая со стороны, нужно быть очень осторожным и только подталкивать команду в нужном направлении, а не кормить ее готовыми решениями.
В противном случае команда никогда не станет самостоятельной и после снятия «опеки» быстро вернется к тому, с чего начинала.
Кроме того, команды всегда лучше принимают решения, которые приходят к ним сами, и реализуют их быстрее и эффективнее, чем любые решения, принятые другими, даже если эти решения хороши сами по себе.
Добившись первых успехов в совершенствовании процесса рассмотрения, вам необходимо удвоить свои усилия.
Если кажется, что проблем сейчас нет, это явный признак того, что все очень плохо.
Всегда есть проблемы.
Ретроспектива — это Кайдзен, непрерывный и бесконечный процесс совершенствования.
О Скрам-мастере “ Скрам-мастер в каждой команде — это пустая трата.
И где я могу их получить? Мы открыли вакансию и за полгода взяли на работу только одного, и то практически без опыта.
Делать ему особо нечего, ревью проводим раз в квартал, команды сами устраивают ежедневные стендапы, и в целом справляются, без проблем.
Он, конечно, слишком много времени проводит в комнате с xBox, но владельцы проекта им довольны, говорят, он помогает старшим разработчикам собирать планирование и отчеты по командам в конце месяца.
В общем, нам достаточно одного, а вакансию можно закрыть, так что искать нет смысла.
”.
Действительно, нанять Скрам-мастера, а тем более хорошего — который бы нанял плохого — практически невозможно.
Но это не обязательно.
Важно найти в своей команде разработчика, который сможет выполнить эту роль.
Дайте ему такую возможность, сняв с него значительную часть той нагрузки, которую он сейчас выполняет. И самое главное, начать учиться.
Да, Scrum-мастеров необходимо обучать.
Выполнение этой роли требует навыка, который не приходит от природы.
Можно отправить «мастеров» на обучение, это несложно, но результат будет скромным.
Гораздо важнее научить «хозяев» разных команд регулярно встречаться и вместе обсуждать проблемы, с которыми они сталкиваются, и решения, которые они находят. Также будет полезно, если «мастера» начнут готовить и проводить внутренние Scrum-семинары на интересующие их темы.
Скрам-мастер может найти много полезной информации в Скрам-руководство .
О координации работы “ Скрам предназначен только для небольших, индивидуальных, независимых команд. А нас 30 разработчиков, не считая тестировщиков, разрабатывающих одно приложение.
Мы работаем с общим кодом и общей базой, какая тут независимость? Мы разделены на шесть команд, которые должны взаимодействовать, но Скрам этого не предполагает. Так что ожидать увеличения производительности не стоит. Ну, по крайней мере, менеджерам по продукту больше не нужно торговаться за каждого конкретного разработчика.
”.
Да, сотрудничество между несколькими Scrum-командами, работающими над общим продуктом, необходимо регулярно, и это нормально.
В Скраме нет ни продуктовых менеджеров, ни каких-либо других менеджеров, как нет и демо.
Однако разработку можно координировать в рамках Scrum. Изменения продукта, не требующие сложных технических усилий, могут быть просто согласованы Владельцами Продуктов команд и спланированы с высоким приоритетом.
Сложная техническая работа, обеспечение целостности архитектуры приложения и избежание «велосипедного проектирования» обеспечиваются регулярными приглашениями на обзоры и планированием технических экспертов приложения.
Скрам-руководство: « Команда разработчиков может также пригласить других людей принять участие [в планировании спринта], чтобы предоставить технические или предметные консультации.
Для этой цели в компании могут быть выделены функции архитектора приложений вне команд, или это могут быть просто опытные и высококвалифицированные разработчики, работающие в конкретных командах, но активно взаимодействующие по вопросам разработки продукта в целом.
О планировании и Министерстве обороны “ Планировать всей командой – это нонсенс.
Пустая трата времени.
В прошлый раз дизайнеры целый час торговались, какого цвета должны быть кнопки и стоит ли к ним прислушиваться? Планируем весь день, но успеваем выполнить только половину задач; лучше было бы потратить это время на работу.
И вообще, планировать работу на две недели бесполезно, потому что завтра появится ошибка, которую нужно будет срочно исправлять, и весь план развалится.
А некритичные ошибки мы вообще не исправляем, потому что план спринта изменить нельзя.
Министерство обороны? Что это? ”.
Вся Scrum-команда действительно должна участвовать в планировании.
Это важно.
Это гарантирует, что все знают, что и как команда будет делать в спринте, чтобы не играть в «сломанный телефон» в процессе работы.
Это также позволяет сразу учитывать все комментарии со всех точек зрения.
Однако команда должна научиться с пользой использовать время, отведенное на планирование, и параллельно работать над разными задачами в составе, необходимом для обсуждения вопроса.
Полный состав команды планирования необходим при первичном анализе бэклога перед оценкой, при формировании цели спринта и составлении плана действий по ее достижению.
Цель спринта и список задач, входящих в спринт, часто путают. Вплоть до формулировки «наша цель — выполнить все задачи, включенные в спринт».
Это ошибка.
Цель должна определять ожидаемый качественный результат от предстоящей работы, и такая цель должна быть только одна.
Цель не должна меняться во время спринта.
Скрам-руководство: « Никаких изменений, которые могли бы поставить под угрозу цель спринта, не вносится.
«Наличие цели дает команде некоторую тактическую свободу в выборе того, что и как будет реализовано, что зачастую очень важно.
Scrum Guide:» Цель спринта дает команде разработчиков некоторую гибкость в отношении функциональности, реализуемой в рамках спринта.
«Это не только возможность отказаться от реализации менее ценных задач, если ресурсов недостаточно, но и повод сделать больше, если есть хорошая идея или возможность.
Возможно и ожидается, что список работ, запланированных на спринт, изменится.
Скрам-руководство: « Объем может быть уточнен и пересмотрен между Владельцем продукта и командой разработчиков по мере получения дополнительной информации.
" И " Если работа оказывается отличаться от ожидаемой командой разработчиков, они сотрудничают с владельцем продукта, чтобы согласовать объем бэклога спринта в рамках спринта.
Внесение изменений во время спринта — это нормально и ожидаемо.
Подозрительно обратное, когда команда весь спринт работает по первоначальному плану, вообще не внося в него никаких изменений.
Команды часто «забывают» об определении «Готово» (DoD) — критерии завершенной работы.
Это кажется само собой разумеющимся, выполнено значит завершено, что тут непонятного.
Без четких и общих критериев завершенной работы команда будет постоянно промахиваться при планировании: «Мы закончили! То, что осталось? Тестируйте и выпускайте.
» Также критерии выполненной работы важны для анализа результатов спринта, понимание того, что именно не было сделано для завершения работы, дает отличную тему для ретроспективы и позволяет сформулировать конкретные шаги по решению такой проблемы.
В этой теме Scrum немало заимствует у бережливого производства ( наклонять ).
Фиксированная продолжительность спринта здесь соответствует времени такта.
Процесс планирования реализует систему вытягивания, в которой вместо того, чтобы сообщать команде, что она должна делать в спринте, Владелец продукта предлагает возможные варианты, из которых команда выбирает работу в той степени, в которой она может ее выполнить.
Концепция DoD обеспечивает устранение потерь незавершенного производства, самого крупного типа потерь, выявленного в бережливом производстве, поскольку к концу спринта вся начатая работа должна быть завершена.
Скрам-руководство: « В конце спринта должен быть выполнен новый инкремент. ”.
Работая вместе, все эти приемы позволяют не только повысить продуктивность команды, но и сосредоточиться на более ценной работе за счет быстрой смены приоритетов.
Подробнее о видах потерь на производстве и бережливом производстве вы можете прочитать в книге Джеффри Лайкера « Дао Тойоты », также этой теме посвящена целая глава в книге Сазерленда» Скрам.
Революционный метод управления проектами " упомянутое выше.
Один из методов планирования, основанный на историях пользователей, хорошо описан Кеннетом Рубином в « Основы Скрама ”.
О Скрам-покере “ Скрам-покер бесполезен.
Разработчики два часа обдумывают проблемы и дают некоторые оценки.
Так каков результат? Каждый раз за спринт мы берем в два раза больше задач, чем делаем на самом деле.
”.
Идея Scrum-покера настолько популяризирована, что многие думают, что это неотъемлемая часть Scrum и без него нельзя жить.
Это не верно.
Scrum-покер — это всего лишь один из методов, который имеет свои преимущества и недостатки, подобно использованию Scrum-доски или планированию работы в форме Истории пользователей .
Если Scrum-покер работает, хорошо.
Если команда регулярно и сильно ошибается в оценках спринта с помощью «покера», то именно этот метод этой команде не подходит. Возможно, вам стоит начать играть на деньги.
И возможно, личные оценки разработчиков сработают лучше, чем средние.
Практика показывает, что если задачи достаточно хорошо декомпозированы, оценка не представляет существенных трудностей.
Важно, чтобы общая оценка по всем задачам, выбранным для спринта, в конечном итоге соответствовала тому, что может сделать команда, а то, что отдельные задачи будут оценены с той или иной ошибкой, не так уж и важно.
О Scrum в целом “ Scrum — это чисто теоретический подход, который может работать только в идеальных, тепличных условиях; Скрам неприменим в реальной жизни.
И вообще Scrum — это вчерашний день, теперь все нужно делать в Agile! ”.
Если подумать, Scrum не так уж и страшен.
И это вполне доступно для грамотной и качественной реализации.
Не путайте Scrum и Agile; эти понятия не альтернативны, не противоречат и не заменят друг друга.
По большому счету, Agile — это набор тактик , что, безусловно, разумно, но недостаточно для построения полноценного рабочего процесса.
Существует множество вариантов гибких процессов, но не так уж много хороших.
Scrum — это продуманный рабочий процесс, основанный на принципах и тактиках, доказавших свою практическую ценность.
Кстати, Scrum появился раньше Agile, и авторы Scrum участвуют в Agile-манифесте.
Да, Scrum — это непросто.
Такова жизнь.
— Дмитрий Мамонов Департамент развития, Слияние подразделений, чтобы освоить, Гит-отдел, Старший оператор bash-консоли