Залп скосил 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.
— Дмитрий Мамонов
Департамент разработки,
Подразделение мержа в мастер,
Отдел работы с гит,
Старший оператор баш консоли
Комментарии (14)
Aingis
29.11.2016 16:29+7На бумаге было гладко, но возникают закономерные вопросы:
Начав работать по Scrum, команда гарантированно добьется существенного прогресса.
Неприкрытая реклама. Прогресса по сравнению с чем? Сколько будет в цифрах? Если команда уже хорошо сработана, общается и т.п., то почему скрам должен дать какой-то прогресс? Особенно учитывая дальнейшие вопросы.
Если дизайнер Иннокентий нарисовал отличный дизайн, но команда не смогла его реализовать и зарелизить — это провал команды в целом и каждого участника в команды в частности. Иннокентий, вместо того чтобы пенять на JavaScript и QA, что те медленно работают, должен задуматься: может быть, он может изменить что-то в своей работе, чтобы в следующий раз команда добилась результата.
Может и так, а может просто понабрали джунов, которые не осилили архитектуру (пример гипотетический). И как тут поможет скрам?
Понятно, что если джуны не совсем плохие, то они со временем научатся и даже смогут что-то выдать, но будет ли в этом заслуга скрама? Или надо менять что-то другое в компании?
При этом все участники Scrum команды имеют одну должность: Разработчик.
Опять же к примеру про джунов: если нет сениоров, то кто будет архитектуру продумывать? А то поналепят фич, а потом к огромную куску легаси никто прикасаться не захочет. И следующие фичи будут уже доставляться долго и с большим скрипом.
Например Иннокентий не имеет права игнорировать замечания Татьяны о том, что красный цвет шрифта на рыжем фоне — это плохое визуальное решение. Не смотря на то, что Татьяна имеет специализацию в тестировании, увидев проблему, она имеет право высказаться, и ее мнение не могут отказаться выслушать потому что она, видите ли, QA. В Development Team все равны, и это действительно важно.
В реальной жизни, если это вскрылось на этапе тестирования, то никто не будет ничего менять, так как сроки горят, а команда подписалась. А потом пойдут уже другие задачи.
Важно найти в команде разработчика, способного выполнять эту роль. Дать ему такую возможность, сняв с него существенную часть нагрузки, которую он сейчас выполняет. И главное, начать учить.
А по факту внезапно оказывается, что скрам-мастер должен делать основную работу как и все. А если не хочет остаться без премии и работы, то ещё и скрам-мастерить при этом. Бизнес хочет, чтобы все эффективно работали.
В Scrum нет Product Manager’ов, или любых других менеджеров, так же как нет Demo. Тем не менее, разработка может быть скоординирована в рамках Scrum.
Интересно как: менеджера нет, а его работу должен кто-то делать. Получается, что все разработчики должны быть понемногу менеджерами, что, вообще-то, странно, так как в разработку идут обычно те, кто не хочет быть менеджером. Не говоря уж про то, что если нет главного, то нет ответственности. (И снова вопрос: а если все сработанные, самостоятельные и общительные, то какая нужда в скраме?)
Процесс планирования реализует систему вытягивания, когда, вместо того чтобы говорить команде, что она должна делать за спринт, Product Owner предлагает возможные варианты, из которых команда выбирает работу в том объеме, в котором она может ее сделать.
… к окончании спринта все начатые работы должны быть выполнены до конца.
Работая вместе, все эти техники позволяют не только увеличить производительность команды…
А теперь к практике: команда должна набрать работы меньше чем времени чтобы гарантированно успеть. При том, что оценки задач — это тыканье пальцем в небо: на исправление бага может уходить от получаса до одной недели, значимую часть времени в конце спринта разработчики должны сидеть и плевать в потолок. Новые задачи брать нельзя, так как это запрещает условие окончания работ (да и вперёд планирования выходит). Тестировщики наоборот скучают в начале спринта, и зашиваются в конце. Разработчики конечно могут им помочь, но они явно будут тестировать дольше и хуже.
Вопрос: как при таки вводных может утверждаться, что производительность команды улучшается? (По сравнению с методикой: «пиши код!» при грамотном продуктовом менеджере.)
Практика показывает, что если задачи достаточно хорошо декомпозированы, оценка не представляет существенных сложностей.
Опять же кто-то это должен делать, или команда, теряя время на очередных бесконечных встречах, либо кто-то ещё, кто непонятно как относится к процессу. Если это какой-то внешний специалист, не относящийся к команде, но от него зависит процесс, то получается, что команда несамостоятельна и успех спринта может совсем от неё не зависеть.
dm_wrike
08.12.2016 13:31Прошу прощения что долго не отвечал, надеюсь мой ответ все еще будет полезен.
Вы указали большое количество организационных проблем,
пытаться спорить по каждому из пунктов думаю нет смысла — каждая гипотетическая ситуация возможна.
Ситуация когда разработка работает по «Scrum», при этом бизнес продолжает отношения с разработкой
по старому «В реальной жизни», «А по факту» и т.д. на самом деле складывается достаточно часто.
И это большая проблема.
Я бы посоветовал вам прочитать мою предыдущую статью в которой я пытаюсь предостеречь от внедрения Scrum только в разработке, без договоренности об изменении подхода к работе с бизнесом.
В описанной вами ситуации подход «пиши код!» действительно может оказаться наиболее эффективным,
просто потому что он соответствует ожиданиям бизнеса от разработки.
Aleks_ja
29.11.2016 19:16+1Все элементы Scrum задуманы взаимно дополнять и поддерживать друг друга. При этом они не дублируются. В Scrum нет запаса прочности. По этому все, что описано в Scrum Guide обязательно к реализации, из Scrum нельзя ничего выбрасывать. Но можно и нужно расширять.
Я люблю скрам. Но тут звучит так, как будто скрам создали боги.
Если делать «без головы» — то на скрам ниодну команду по-нормальному перевести не получится, даже имея продукт овнеров в одной комнате с вами на стэндапе. Более того, команда должна быть готовой.
Нужно чётко понимать что для чего. Поэтому, не вижу чего-то страшного в отхождении от канонов.
У нас, например, каждый день скрам мастером на Стэнд Ап выбирается кто-то с команды путём бросания кубика. До стэндапа — прессует QA команду, чтобы она всё до-проверяла, что не успела и перевесила что-нибудь в done. Этот человек подключается к митингу с Америкой, полностью ведёт сам стэндап, подводит итог дня (озвучивает сколько поинтов сделано), высылает follow-up в котором вкратце кто что сказал + burn-down чарт. Это плохо? Всё это вышло эволюционно, и, от части, требование продукт овнеров.dm_wrike
03.12.2016 15:15Большое спасибо за комментарий и прошу прощения за задержку с ответом.
1. Конечно Scrum создали не боги, но его создали умные люди с обширным жизненным опытом.
За 20 лет существования Scrum он был достаточно глубоко продуман и сбалансирован.
2. Конечно в Scrum нужно «делать с головой», Scrum Guide очень сложен. Кроме того Scrum Guide
это не готовое решение, а способ его получить.
3. «ничего страшного в отхождении от канонов» — вот тут нужно быть очень аккуратным,
это тонкий лед который может треснуть и вы провалитесь в ледяную воду.
4. то что вы выбираете «скрам мастера» перед стендапом, на самом деле не противоречит Scrum,
поскольку Scrum Master не обязан сам организовывать что либо, он должен обеспечить организацию.
Если вы пришли к тому что игра с кубиком для вас подходит, отлично.
Правда называть человека проводящего дейли «скрам мастером» неправильно — это подмена понятий.
5. «прессует QA команду» — я уверен что ваши отношения с QA на самом деле хорошие,
вы просто выбрали неудачную формулировку. Тем не менее тут есть большая проблема.
Наверняка тестирование является обязательной частью вашего процесса,
необходимым шагом что бы выполнить работу. Из того что вы сформулировали кажется
что либо QA не входят в вашу команду, либо формально входят но на самом деле живут отдельной
от программистов жизнью. Так часто бывает. И то и другое плохо для разработки в целом,
поскольку в таком случае не имеете возможность довести работу до конца в рамках Scrum команды.
6. То что вы отчитываетесь о прогрессе каждый день тоже имеет свои подводные камни.
Организация работы в рамках спринта это полностью ответственность Development Team,
и в нее никто не должен вмешиваться (механизм влияния на команду это Review).
Описанный вами подход ведет к следующим проблемам:
а) микроменеджмент команды вместо самоорганизации
б) ежедневное изменение планов вместо движения к цели (какая у вас цель спринта?)
Возможно вашей команде следует добиться большей самостоятельности,
но конечно я могу ошибаться.
vyatsek
29.11.2016 20:33+4>В Scrum нет Demo
Вранье! Есть там demo, более того оно необходимо, для демонстрации той части продукта, которая был сделана во время спринта. Именно ёё ждут заказчики, т.к. для них это ВАЖНО! Demo делается для обратной связи.
>Команда
Scrum команда подбирается таким образом, чтобы не было необходимости брать кого-то со стороны, все участники которые заняты в разработке продукта, они находятся в команде, может частично, но они есть и они рядом.
Review — обсуждение процесса
>Scrum-мастер
Это не человек, это роль. В scrum лишь говорится что эта роль не должна пересекаться с ролью product owner'a. По своей сути это менджер модератор, без особых прав.
Изначально я скептически относился к скраму. О нем слишком много говорят, а работают как всегда. После треннигов я кардинально поменял мнение. Scrum это всего лишь фрейморв и набор каких-то правил. Он не сделает из глупого управленца умного и не повысит квалификацию разработчиков. Прежде чем применять scrum надо точно понимать что он вписывается в условия работы. Люди почему-то называют scrum, ведение jira, стояние у доски и прочий карго культ, забывая что конечным результатом является продукт.
Scrum очень умело приподнесли слабому менеджменту в виде «серебряной пули», мол онрешит все ваши проблемы. Люди бездумно кинулись его внедрять: без понимания контекста, особенностей бизнес процесса и собственно самого scrum. Например команда из 10 человек, включая оунеров, разработчиков, тестировщиков и т.д. делает продукт, они что на столько глупы что не могут договориться между собой? Они делают какую-то космическую ракету в которой все до запятой должно соотвествовать спецификации, а под спецификацией 3 года физ-мат расчетов?
Современная разработка ПО скорее напоминает бригаду по ремонту квартиры, нежели, чем наукоемкое и высокоточное производство.
Отдельно я бы вынес софтверных гигантов, у которых процесс создания ПО по сложности близок к производственным на уровне завода
.
Качественный продукт делает талантливая команда, а не процес.
Lofer
03.12.2016 02:04Как показывает практика, корректный процесс как раз позволяет нивелировать раздолбайство команды :)
На старте, гениальная команда выйграет. это факт, Но через время методичная команда, работающая «по процессу» выигрывает у гениев, поскольку накладные расходы на коммуникацию, координацию и устранение «а хто эта сделал ?!» никто не отменял.
В этом отношение review, проведенной корректно — очень полезно и служит этим «великим уравнителем».
uamarshall
29.11.2016 21:38-1Очень часто вижу как скрам интепретируется разными авторами по разному и каждый раз далеко от реальности. Сам практикую скрам уже более двух лет и нареканий на него еще не было. Очень качественный фреймворк, при чем даже в условиях фикс прайса и вотерфола. Не понимаю почему скрам часто мешают с agile и путают принципы и практики. Для примера, в скраме самое главное это прозрачность процесса, и своевременность в принятии решений и поднятию проблем. Каждую неделю все в курсе всех событий, всегда актуален план на неделю и представление о следующих неделях. Вот и весь его профит. Считаю его идеальным фреймворком в первую очередь — КОММУНИКАЦИЙ. Не более того. Управление разработкой и скрам лежат в разных плоскостях. Тот же скрам использую для управления документированием проекта, его ресёрчем, дизайном. Главное это прозрачность в планировании, исполнении, произведению выводов. Прекрасный процесс
asirazhi
03.12.2016 02:04Отличная статья! Автору респект!
Одно только замечание, хоть и некоторые активности скрама могут быть возложены на разработчиков, но скрам мастер не должен быть членом команды. Это принципиальный момент и последствиями будут как раз таки «забивание» на скрам практики, когда будет не хватать времени, которого всегда не хватает.
Спасибо за отличную статью! Такие статьи помогают в работе с коллегами.dm_wrike
03.12.2016 15:38Прошу прощения что тянул с ответом.
Конечно вы имели в виду что Scrum Master не должен быть частью именно Development Team,
а в Scrum Team он само собой входит.
Да, с ролью Scrum Mater есть сложность. Но из своего опыта я не могу ни согласиться с вами ни опровергнуть.
С одной стороны если Scrum Master является частью Development Team:
1. Хорошо — он вовлечен в процесс и отлично понимает все его тонкости. Главное, команда воспринимает его как равного.
2. Плохо — он может быть завален работой по разработке и не сможет исполнять роль мастера должным образом.
3. Плохо — если в команде возникнут проблемы касающиеся именно его работы, ему сложно будет беспристрастно разобрать такую ситуацию с командой и найти решение.
С другой стороны, если Scrum Master это работа на полный день:
1. Хорошо — что Scrum Master имеет достаточно времени выполнять свою роль.
2. Хорошо — что позиция Scrum Master независимая и он может без лишних эмоций разбирать любые конфликты.
3. Плохо — что он не вовлечен в реальный рабочий процесс. Это отделяет его от команды. Как офицер который командует рядовыми из бункера.
Вероятно оба подхода имеют право на жизнь, и нужно просто постараться получить максимум
от конкретной сложившейся ситуации а не пытаться искать недостижимый идеал на рынке труда.
Хотя чем черт не шутит, вдруг повезет.
asirazhi
03.12.2016 15:45Спасибо за очень развернутый ответ — раскрыли интересные грани, и за полезную ссылку!))
Приятно общаться с профи!))
ihs
Удивительно, адекватная статья про scrum без всякого бреда, хотя первое впечатление по заголовкам было обратным.
Смысл заголовка статьи правда так и остался для меня тайной.
И Agile — набор ценностей и принципов, а не тактик. Тактика это всё же нечто, что можно применить будучи беспринципным и с ценностями насекомого.
dm_wrike
Спасибо за комментарий. К сожалению на ваше замечание я смогу ответить не раньше пятницы. В вопросах есть много интересных тем которые хотелось бы проработать со скрам мастерами прежде чем давать личный ответ. Прошу прощения за задержку.
dm_wrike
Прошу прощения что тянул с ответом.
Говоря что Agile это набор тактик я не имел в виду нравственную оценку идей Agile.
Ценности Agile, например то что работающее приложение важнее исчерпывающей документации,
позволяют принять решение в конкретной тактической ситуации. Вложиться и исправить проблемы
с тем что приложение хронически крешится вместо того что бы расписывать сотни воркэранудов.
При этом можно придумать миллионы вариантов процессов которые содержать в себе ценности Agile,
но совсем не похожи друг на друга и работают совершенно по разному для разных команд.
Можно найти разнообразие статей предлагающих разные Agile процессы, многие из них являются
описанием плохо реализованного Scrum из опыта конкретной компании. Такой подход может быть и сработал для авторов статьи, но нет причин что бы он сработал у вас.
Scrum не единственный подход к разработке. Но противопоставлять ему Agile неправильно.
Шилдик Agile вешают на все товары подряд, так что нужно быть очень внимательным в выборе производителя
что бы получить качественный продукт.