Залп скосил 50 офицеров и 760 рядовых. Французы дрогнули, запаниковали и — обратились в бегство. «Тут дела наши пошли не вполне хорошо», — описывает этот момент битвы официальная французская депеша.
Келли Дж. Порох. От алхимии до артиллерии.
Формирование Scrum команды всегда сопряжено со многими трудностями. Почти все справляются с тем, чтобы изменить порядок рабочего процесса и начать проводить некоторые из необходимых по Scrum событий. Но получить от этих формальных изменений видимую пользу и начать действительно менять рабочий процесс удается меньшинству. В результате у команды формируется следующее мнение о Scrum: “Мы без толку тратим время на митинги. Scrum не работает. Нужно что-то менять”.
Пытаясь как-то спасти положение, активисты Scrum вспоминают, что Scrum — это же еще и framework. Объявляется новая стратегия: “Мы не только Scrum, мы еще и Agile! Мы используем best practices, берем из Scrum только самое лучшее, то, что подходит конкретно для нашей ситуации, а все остальное лишнее и необязательно”. А раз так — “Мы — молодцы и все делаем правильно”.
К сожалению, такое “спасение Scrum” — это тупик. Пойдя по легкому пути, избавившись от сложных элементов Scrum, не пытаясь самостоятельно искать и решать проблемы, копируя приемы из случайно подвернувшихся под руку статей, можно построить какой то процесс. Но не Scrum. Scrum Guide, End Note: “Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum”.
Scrum — это действительно Framework, но не в том смысле, как это слово обычно понимают в разработке. Scrum — это каркас, фундамент, основа рабочего процесса. Все элементы Scrum задуманы взаимно дополнять и поддерживать друг друга. При этом они не дублируются. В Scrum нет запаса прочности. По этому все, что описано в Scrum Guide обязательно к реализации, из Scrum нельзя ничего выбрасывать. Но можно и нужно расширять.
Scrum Guide определяет рабочий процесс в общих терминах, поскольку у каждой команды есть своя специфика, и универсального императивного решения для всех нет и быть не может. Каждая команда должна найти наилучший способ организации конкретно своей работы по Scrum. Децентрализованные команды могут проводить Daily по Skype, а, работая в одном месте, можно собираться в рабочей комнате или уходить в переговорную или на улицу, если там всегда светит солнце и не бывает дождей.
При условии принятия ценностей Scrum на уровне компании в целом, Scrum может быть реализован полностью и в любой команде. Начав работать по Scrum, команда гарантированно добьется существенного прогресса.
В книге “Scrum: The Art of Doing Twice the Work in Half the Time” автор Scrum Jeff Sutherland обещает удвоение отдачи от работы команды. В действительности если он и преувеличивает, то не слишком. Пожалуй, не стоит ждать грандиозных улучшений мгновенно. Мы разумные люди и редко доводим работу до столь плачевного состояния, что даже минимальная систематизация сразу даст грандиозный результат. Однако прогресс случится, и масштаб улучшений будет заметен невооруженным глазом. И начнется все с того, что ранее молчавшие разработчики начнут говорить о помехах в работе, и с того, что к их мнению начнут прислушиваться.
Практика показывает, что труднее всего наладить Scrum в тех командах, которые уже начали «работать по Scrum”, но в действительности построили процесс хаотично.
Основывая работу на предрассудках, неудачных техниках и плохом понимании того, как Scrum устроен вообще, команда загонят себя в тупик. Но даже эта ситуация небезнадежна. Хотя некоторая помощь со стороны такой команде скорее всего потребуется. Команда сможет разобраться в том, что она делает правильно, а где заблуждается и что упускает. Но на это уйдет больше времени, чем для команды, которая избежала таких ошибок в самом начале.
Ошибок и заблуждений о Scrum множество, но некоторые встречаются настолько часто, что начинают приниматься всеми без какой либо критики и превращаются в Карго-культ. Чтобы не попасть впросак самому, стоит разобраться в некоторых из них.
Scrum: Работа над ошибками
Про команды
Часто можно услышать следующее:
“Scrum-команда должна состоять только из разработчиков, каждый из которых должен уметь делать всю необходимую работу. Где нам таких взять? У нас есть только дизайнеры, девелоперы, верстальщики и тестировщики. Раз так, Scrum-команда у нас все равно не получится, будем работать по-старому”.
Но в действительности в Scrum Guide говорится следующее: “Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment”. Да, команда должна быть универсальной, но она должна быть универсальной в целом. Если для доведения разработки до релиза нужен JavaScript разработчик, QA и дизайнер, в команде должны быть они все. Иначе “телега не поедет”.
При этом и за результат своей работы команда отвечает целиком. Scrum Guide: “Individual Development Team members may have specialized skills and areas of focus but accountability belongs to the Development Team as a whole”. Это не пустые слова. Если дизайнер Иннокентий нарисовал отличный дизайн, но команда не смогла его реализовать и зарелизить — это провал команды в целом и каждого участника в команды в частности. Иннокентий, вместо того чтобы пенять на JavaScript и QA, что те медленно работают, должен задуматься: может быть, он может изменить что-то в своей работе, чтобы в следующий раз команда добилась результата.
При этом все участники Scrum команды имеют одну должность: Разработчик. Scrum Guide: “Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule”.
Во первых, это ключ к увеличению производительности команды. Например, несмотря на то, что Иннокентий имеет специализацию в дизайне, и наиболее эффективен именно в этом виде работ, тем не менее он вполне в состоянии помочь команде с тестированием, если именно этот этап разработки является узким местом на текущий момент. Подробнее об этом — в книге Элияху Голдратта “Цель” (The Goal в оригинале).
Во вторых, это позволяет всем участникам команды обсуждать все вопросы на равных. Идеи, оценки, проблемы — каждый имеет право высказать свое мнение. Например Иннокентий не имеет права игнорировать замечания Татьяны о том, что красный цвет шрифта на рыжем фоне — это плохое визуальное решение. Не смотря на то, что Татьяна имеет специализацию в тестировании, увидев проблему, она имеет право высказаться, и ее мнение не могут отказаться выслушать потому что она, видите ли, QA. В Development Team все равны, и это действительно важно. Такой подход неуникален для Scrum, подробнее о важности этого принципа можно прочитать в книге Jeffrey Rothfeder “Driving Honda”.
Именно взаимовыручка и взаимное уважение составляют основу успешной Scrum команды.
Про ревью
“На Demo нужно приглашать пользователей, а мы делаем веб-приложение и наши пользователи где-то далеко. Может быть там, в солнечной Калифорнии, Scrum-команды и могут приглашать пользователей на демо, но не в нашей стране морозов, медведей и матрешек”.
В Scrum нет Demo. Тем не менее, это не мешает многим проводить именно Demo. Например, собрать 200 человек разработки в одном зале с проектором и 5 часов мучить друг друга демонстрациями. Энтерпрайзно. Эпично. Бесполезно.
В Scrum есть Ревью. И ревью подразумевает обсуждение проделанной работы, достигнутых результатов и дальнейших планов с заинтересованными лицами [stakeholders]. Коммуникация и обратная связь — это ключевые элементы ревью, у всех приглашенных на ревью должна быть возможность высказаться и обсудить свою точку зрения с командой и другими стейкхолдерами. Поэтому количество приглашенных на ревью должно быть ограничено, иначе нормальное обсуждение будет невозможно. Пригласить на ревью наиболее ценных людей — ответственность Product Owner’а. Scrum Guide: “Attendees include the Scrum Team and key stakeholders invited by the Product Owner”.
К заинтересованным лицам относятся не только владельцы бизнеса или заказчики, но и любые другие сотрудники компании, которые могут предоставить команде качественную оценку результатов ее работы и при этом заинтересованы в общем успехе. Это могут быть представители технической поддержки, аналитики, эксперты по разработке, руководители подразделений, Product Owner’ы других команд и любые другие сотрудники вне зависимости от их должности и рода деятельности. Важно, что их мнение по каким-то причинам ценно для команды. Наконец, да, конечные пользователи, если в этом есть смысл.
Подробнее про ревью можно прочитать в книге Кеннета Рубина “Основы Scrum”.
Про ретроспективу
“Мы пробовали пару раз провести ретроспективу, но говорить было особо не о чем. Вообще в нашей команде проблем нет, так что это лишний митинг — пустая трата времени. Давайте лучше поработаем лишние пару часов”.
Ретроспектива должна быть обязательно. Только научившись находить и исправлять проблемы в работе команды, можно увеличить ее производительность. Научиться качественно проводить ретроспективу очень сложно. Книжки не помогут. Здесь нужен практический опыт.
В команде должен быть либо сильный Scrum Master, который научит команду проводить ретроспективу изнутри, либо кто-то из опытных менеджеров, который сможет помочь команде со стороны.
Работая со стороны, нужно быть очень аккуратным и лишь подталкивать команду в правильном направлении, а не кормить ее готовыми решениями. Иначе команда никогда не станет самостоятельной и после снятия “опеки” быстро вернется к тому, с чего начала. Кроме того, команды всегда лучше воспринимают решения, к которым они пришли сами, и внедряют их быстрее и эффективнее, чем любые решения со стороны, даже если эти решения сами по себе хороши.
Добившись первых успехов в улучшении процесса на ревью, нужно удвоить усилия. Если кажется, что сейчас никаких проблем нет, — это четкий признак того, что все очень плохо. Проблемы есть всегда. Ретроспектива — это Kaizen, непрерывный и бесконечный процесс улучшений.
Про Scrum-мастера
“Scrum-мастер в каждой команде — это расточительство. Да и где их взять? Мы открыли вакансию и за полгода наняли только одного, и то почти без опыта. Делать ему особо нечего, ревью мы проводим раз в квартал, ежедневные стендапы команды сами организуют, и вообще справляются, проблем нет. Он, конечно, слишком много времени проводит в комнате с xBox, но проджект овнеры им довольны, говорят, он помогает старших разработчиков на планирование собирать и отчеты по командам делает в конце месяца. В общем одного нам хватит, а вакансию можно закрыть, что без толку искать”.
Действительно, нанять Scrum-мастера, а в особенности хорошего — кто же будет плохого нанимать — практически невозможно. Но это и не нужно. Важно найти в команде разработчика, способного выполнять эту роль. Дать ему такую возможность, сняв с него существенную часть нагрузки, которую он сейчас выполняет. И главное, начать учить.
Да, учить Scrum-мастеров нужно. Для выполнения этой роли нужен навык, который не появляется сам собой. Можно отправить “мастеров” на тренинг, это несложно, но результат будет скромный. Гораздо важнее приучить “мастеров” различных команд регулярно собираться и вместе обсуждать проблемы, с которыми они сталкиваются и решения, которые они находят. Также будет полезно, если “мастера” начнут сами готовить и проводить внутренние семинары по Scrum на интересные им темы.
Scrum-мастер может найти много полезного в Scrum Guide.
Про координацию работ
“Scrum предназначен только для маленьких, отдельных, независимых команд. А нас 30 разработчиков, не считая тестировщиков, разрабатывающих одно приложение. Мы работаем с общим кодом и общей базой, какая уж тут независимость. Мы поделились на шесть команд, которые должны взаимодействовать а Scrum этого не подразумевает. Так что увеличения производительности ждать не стоит. Ну хотя бы Product Manager’ам больше не нужно торговаться за каждого конкретного разработчика”.
Да, совместные усилия нескольких Scrum-команд, работающих над общим продуктом, требуются регулярно, и это нормально.
В Scrum нет Product Manager’ов, или любых других менеджеров, так же как нет Demo. Тем не менее, разработка может быть скоординирована в рамках Scrum.
Продуктовые изменения, не требующие сложных технических усилий, могут быть просто согласованы между Product Owner’ами команд и спланированы с высоким приоритетом.
Сложные технические работы, обеспечение целостности архитектуры приложения, избежание “конструирования велосипедов” обеспечиваются регулярным приглашением на ревью и планированием технических экспертов приложения. Scrum Guide: “The Development Team may also invite other people to attend [on Sprint Planning] in order to provide technical or domain advice”. В компании для этого могут быть выделенные роли архитекторов приложения вне команд или это могут быть просто опытные и высококвалифицированные разработчики, работающие в конкретных командах, но активно взаимодействующие по вопросам разработки продукта в целом.
Про планирование и DoD
“Планирование всей командой — это бред. Пустая трата времени. В прошлый раз дизайнеры целый час торговались, какого цвета делать кнопки, а нам их слушать? Мы планируем целый день, а успеваем только половину задач, лучше бы это время на работу потратили. И вообще планировать работу на две недели бесполезно, потому что завтра появится баг, который нужно будет срочно пофиксить, и весь план развалится. А некритичные баги мы вообще не фиксим, потому что план спринта менять нельзя. ДоД? Что это?”.
В планировании действительно должна участвовать вся Scrum команда. Это важно. Таким образом гарантируется, что все будут знать что и как команда будет делать в спринте, чтобы не играть в “испорченный телефон” в процессе работы. Так же это позволяет сразу учесть все замечания со всех точек зрения.
Однако команда должна научиться использовать время, отведенное на планирование, с пользой и прорабатывать разные задачи параллельно в необходимом для обсуждения вопроса составе.
Полный состав команды при планировании требуется при первичном разборе бэклога перед оценкой, при формировании цели спринта и составлении плана действий по его достижению.
Цель спринта и список задач, взятых в спринт, часто путают. Вплоть до формулировки “наша цель, сделать все задачи, взятые в спринт”. Это ошибка.
Цель должна определять ожидаемый качественный результат от предстоящей работы, и такая цель должна быть одна. Цель не должна меняться в течении спринта. Scrum Guide: “No changes are made that would endanger the Sprint Goal”. Наличие цели дает команде некоторую тактическую свободу в выборе того, что и как будет реализовано, что часто бывает очень важно. Scrum Guide: “The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint”. Это не только возможность отказаться от реализации менее ценных задач, если ресурсов недостаточно, но и повод сделать больше, если есть хорошая идея или возможность.
Возможно и ожидаемо, что список работ, запланированных в спринт, будет меняться. Scrum Guide: “Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned” и “If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint”. Вносить изменения в спринт нормально и ожидаемо. Подозрительно обратное, когда команда работает весь спринт по исходному плану, не внося в него никаких изменений вообще.
Команды часто “забывают” о Definition of “Done” (DoD) — критериях выполненной работы. Это кажется само собой разумеющимся, выполнена значит выполнена, что тут непонятного.
Без четких и разделяемых всеми критериев завершенной работы команда будет постоянно промахиваться с планированием: “Мы все сделали! А что осталось? Протестить и зарелизить…”.
Также критерии выполненной работы важны для анализа результатов спринта, понимание того, что именно не было сделано для завершения работы, дает отличную тему для ретроспективы и позволяет сформулировать конкретные шаги для решения такой проблемы.
По этой теме Scrum довольно много заимствует из Бережливого производства (lean).
Фиксированная длительность спринта здесь соответствует времени такта. Процесс планирования реализует систему вытягивания, когда, вместо того чтобы говорить команде, что она должна делать за спринт, Product Owner предлагает возможные варианты, из которых команда выбирает работу в том объеме, в котором она может ее сделать.
Концепция DoD обеспечивает исключение потерь незавершенного производства, самого крупного из выделяемых в lean видов потерь, поскольку к окончании спринта все начатые работы должны быть выполнены до конца. Scrum Guide: “At the end of a Sprint, the new Increment must be Done”.
Работая вместе, все эти техники позволяют не только увеличить производительность команды, но и сконцентрироваться на более ценной работе быстро меняя приоритеты.
Подробнее о видах потерь в производстве и Бережливом производстве можно прочитать в книге Джефри Лайкера “Дао Toyota”, также этой теме посвящена целая глава в книге Сазерленда “Scrum. Революционный метод управления проектами”, упоминавшейся выше. Одна из техник планирования, основанная на пользовательских историях, хорошо раскрыта у Кеннета Рубина в “Основы Scrum”.
Про Scrum-покер
“От Scrum-покера никакого толку. Разработчики два часа мусолят задачки, делают какие-то оценки. И что в итоге? Каждый раз мы берем в спринт в два раза больше задач, чем реально делаем”.
Идея Scrum-покера настолько растиражирована, что многие думают, что это неотъемлемая часть Scrum и без него вообще никуда. Это не так. Scrum-покер — это всего лишь одна из техник, имеющая свои достоинства и недостатки, так же как использование Scrum-доски или планирование работ в виде Пользовательских историй.
Если Scrum покер работает — хорошо. Если команда регулярно и сильно ошибается с оценкой спринта, используя “покер”, значит именно для этой команды именно этот способ подходит плохо.
Возможно, стоит начать играть на деньги. А возможно, персональные оценки разработчиков будут работать лучше чем усредненные.
Практика показывает, что если задачи достаточно хорошо декомпозированы, оценка не представляет существенных сложностей. Важно, чтобы суммарная оценка по всем задачам, выбранным в спринт, в итоге соответствовала тому что команда может сделать, а то, что отдельные задачи будут оценены с той или другой ошибкой на самом деле не принципиально.
Про Scrum в целом
“Scrum — это чисто теоретический подход, который может сработать только в идеальных, парниковых условиях, в реальной жизни Scrum не применим. И вообще Scrum это вчерашний день, сейчас все нужно делать по Agile!”.
Если разобраться, Scrum не так уж и страшен. И вполне себе доступен для грамотной и качественной реализации.
Не стоит путать Scrum и Agile, эти концепции не являются альтернативными, не противостоят и не заменят друг друга.
По большому счету Agile — это набор тактик, которые безусловно разумны, но недостаточны для построения полноценного рабочего процесса. Вариантов agile-процессов множество, хороших среди них не так много.
Scrum — это хорошо продуманный рабочий процесс, основанный на принципах и тактиках, доказавших свою практическую ценность. К слову, Scrum появился раньше Agile, и авторы Scrum причастны к Agile-манифесту.
Да, Scrum не дается без труда.
C’est la vie.
— Дмитрий Мамонов
Департамент разработки,
Подразделение мержа в мастер,
Отдел работы с гит,
Старший оператор баш консоли
ссылка на оригинал статьи https://habrahabr.ru/post/316342/
Добавить комментарий