Недавно наше внимание привлёк один вопрос, заданный на stackexchange.com. Этот вопрос был направлен на то, чтобы разобраться с влиянием скрама на работу программистов. Автор вопроса, пользователь Qiulang, поднимает довольно смелую тему: «Скрам превращает хороших разработчиков в программистов средней руки. Возможно ли это?».
Основная идея фреймворка скрам заключается в организации процесса разработки для более быстрого выполнения работ на различных этапах жизненного цикла проекта. Но всегда ли такой подход подталкивает разработчиков к правильным моделям поведения? Многие пользователи, присоединившиеся к обсуждению вышеупомянутого вопроса на Stack Overflow, сталкивались с похожими вещами, когда разработчики «срезают углы», слишком большое значение придают высоким баллам, назначенным их тикетам, или даже прикидываются перед менеджерами высокопроизводительными сотрудниками. Как избежать этих опасностей?
Вопрос, о котором идёт речь, перешёл с workplace.stackexchange.com на softwareengineering.stackexchange.com. Это говорит о том, что программисты рассматривают соображения, связанные со скрамом и с его эффективностью, как нечто достаточно серьёзное, выходящее за рамки управления циклом разработки ПО. Они ощущают воздействие этого метода управления проектами на рабочую обстановку в целом.
Является ли скрам причиной появления плохих практик разработки, или он лишь служит оправданием для этой проблемы?
Много споров вызвали рассуждения о воздействии скрама на команды и отдельных разработчиков, и об ограничениях, которые этот фреймворк налагает на тех, кто его использует. В то время как многие винят скрам в неудачах команд, другие полагают, что это — ошибка атрибуции, и что корни проблем в командах разработчиков уходят гораздо глубже.
Защитники скрама видят причину неприятностей в плохом менеджменте. Вот что говорит пользователь Llewellyn, подводя итоги: «Менеджмент, по сути, игнорирует разработчиков. Существуют фиксированные дедлайны, которые нужно выдержать, достигнув заранее заданных результатов. Работой занимается не команда, сосредоточенная на достижении одной и той же цели, а группа людей, в которой каждый беспокоится лишь о себе. Перспективное планирование и нестандартное не приветствуются. В таких условиях программист, в итоге, поддаётся обстоятельствам и находит спасение в простом выполнении назначаемых ему задач. Мне доводилось работать в таких условиях. Но не надо винить в этом скрам».
Пользователь DJClayworth выразил настроение многих комментариев, сказав, что программисты, которые думают, что на них оказывается давление, будут работать плохо при применении любой методологии управления разработкой.
Противоположное мнение по этому вопросу лучше всего выразил пользователь Martin Maat, который обратил внимание аудитории на то, что уже сам факт того, что так много людей чувствуют необходимость высказаться по этому вопросу, говорит о том расстройстве, которое у них вызывает скрам.
Каковы распространённые неприятности, сопровождающие применение скрама?
В комментариях всплыли сведения о некоторых распространённых «подводных камнях» скрама, которые появляются либо из-за того, что этот фреймворк применяют неправильно, либо из-за того, что они, по сути, являются врожденными проблемами скрама. Вот почти десяток проблем такого рода, которые привлекли наше внимание.
▍1. Ежедневные совещания предназначены для менеджеров
Первое критическое замечание в адрес скрама связано с тем, что в ходе ежедневных встреч (стендапов) возникают нежелательные тенденции. Один из аргументов в пользу этой идеи заключается в том, что стендапы могут деградировать до состояния мероприятий, участники которых только и делают, что говорят о своей продуктивности. Особенно — если на таких мероприятиях присутствуют менеджеры. Поэтому пользователь Matthew Gaiser (он уже писал для нас, но на его комментарий мы наткнулись случайно) назвал стендапы мероприятиями, которые направлены на информирование менеджеров о текущей ситуации (update management). Он полагает, что доклады разработчиков на таких мероприятиях лишь побуждают менеджеров к наблюдению за тем, над чем ведётся работа, но это не приносит никакой пользы. Это ещё в большей степени справедливо для распределённых команд, когда каждый из членов команды работает в собственном режиме.
▍2. Главную роль играет выполнение задач
Ещё одна идея, возникшая в комментариях, заключается в том, что любая методология разработки, делящая большие задачи на задачи более мелкие, и направленная на наблюдение за ходом выполнения этих задач, ведёт, умышленно или нет, к появлению новых подходов к оценке работы. Если просто начать применять какие-то метрики, это повлияет на поведение людей, деятельность которых оценивают в соответствии с этими метриками.
Многие комментаторы говорят, что это означает, что разработчики могут «срезать углы» для того чтобы завершить то, что нужно было сделать в текущем спринте. Проблема, на которую указывает пользователь Gaiser и другие пользователи, заключается в том, что отдельный тикет, над которым ведётся работа, и который, во время спринта, переводится в разряд «готовых», это — «чёрный ящик». Что бы ни было внутри этого «чёрного ящика», это на результат оценки скорости работы не повлияет. Пользователь Gaiser пишет, что некачественная реализация, которая прошла QA-отдел, и отлично протестированная и спроектированная реализация, ничем не отличаются друг от друга. В результате оказывается, что учёт количества закрытых тикетов — это недостоверный показатель производительности труда.
▍3. Крайне продуктивные разработчики, которые не работают как команда
В ещё одной ветке рассуждали о противоречии между отличными программистами-одиночками и отличными командами. Когда все следуют методологии скрам, некоторые разработчики могут оказаться чрезвычайно продуктивными, но тогда о «команде» можно забыть. Пользователь Gaiser говорит, что, без правильных стимулов, самоорганизация — это недостижимая цель: «Члены команды будут решать задачи так, как им удобно, или так, как им предписано. Если это не способствует формированию команды, многое окажется не сделанным, и члены команды просто, в беспорядке, будут двигаться вперёд».
Он же продолжает: «Более того, если позволить каждому разработчику выбирать собственные методы для решения задач, это означает усложнение отладки кода».
▍4. Сложные задачи отодвигаются на потом
Gaiser, рассуждая в том же русле, продолжает критику иллюзии продуктивности. Он говорит о том, что при применении скрама основное внимание уделяется тому, чтобы перевести тикет в состояние «Готово». Глубокое обдумывание задачи при этом не выглядит особенно продуктивным. Поэтому разработчики могут стремиться к тому, чтобы брать лёгкие задачи и избегать задач более сложных. Вот, опять, слова пользователя Gaiser: «Скрам подталкивает разработчиков к тому, чтобы они брали бы лёгкие задачи, на решение которых уходит немного времени, что позволяет разработчикам показывать стабильно высокую скорость работы». В результате оказывается, что ежедневный выбор задач и ежедневные отчёты о работе подталкивают к выбору задач, на решение которых нужен один день.
▍5. Возможности продукта оказываются важнее качества кода
Всё тот же Gaiser полагает, что применение фреймворка скрам ведёт к падению качества продуктов: «То, насколько хорош разработчик, обычно определяется по его способности разрабатывать надёжный код. Скрам, если только владелец продукта не разбирается в программировании и не проверяет код, серьёзно обесценивает эту характеристику проектов». Он делает тут ударение на том, что «готовность» тикета часто определяется не после проверки качества кода, а лишь после того, как реализована соответствующая возможность.
▍6. Отсутствие времени на обсуждение рабочих вопросов с коллегами
Если скорость разработки — это единственный показатель эффективности команды, это значит, что у членов команды больше нет времени на обсуждение друг с другом каких-то вопросов, на то, чтобы узнавать мнение других, или на то, чтобы проверять свои идеи, кому-то о них рассказывая. А ведь это — именно то, что делает команду командой. Вот, снова, слова пользователя Gaiser: «Отличные разработчики часто советуются с другими разработчиками и ищут альтернативу своим мнениям. Но подобные занятия отнимают время, необходимое на закрытие тикетов, а это снижает скорость разработки».
▍7. Недавно выявленным ошибкам приходится ждать своей очереди
Ещё одна плохая модель поведения, вызываемая применением скрама, заключается в том, что «ошибки находят после спринта и считают их новыми задачами». Это может подталкивать разработчиков к выпуску некачественного кода, так как в текущий спринт нельзя включить дополнительные задачи.
▍8. Архитектура, управляемая тикетами
На системе тикетов основано не только то, какие задачи выбирают себе разработчики. Пользователь Gaiser говорит ещё о том, что применение скрама, непреднамеренно, приводит к созданию запутанной архитектуры проектов, так как разработчики работают над тикетами в порядке их появления и независимо друг от друга. В результате «архитектура быстро становится отражением тикетов».
▍9. Методология управления разработкой, которая влияет абсолютно на всё
Читая дискуссию, можно обратить внимание на комментарии, авторы которых отмечают, что корень всех проблем заключается в недостаточно строгом соблюдении правил скрама. Однако, вероятно, самым сильным заявлением пользователя Gaiser, направленным против скрама, является то, что этот фреймворк подминает под себя всё остальное. Это может разрушить сильную команду. «[Скрам] искажает и ломает любые другие механизмы управления разработкой, этот фреймворк становится всеобъемлющим явлением, в котором ничто, кроме выполнения ритуалов, не делается единообразно, а выполнение этих ритуалов создаёт иллюзию успеха».
Мы обсудили довольно большой список проблем, которые, возможно, вызваны применением скрама, а, возможно, лишь стали заметнее благодаря применению этого фреймворка. Но в исследуемой нами дискуссии можно найти так же много идей, касающихся того, как разработчикам жить в мире и согласии, следуя правилам скрама.
Как добиться максимальной отдачи от скрама?
Многие ответы на замечания пользователя Gaiser, получившие множество положительных оценок, касались того, что то, о чём он говорит, это — не скрам. Вот что написал по этому поводу пользователь Stephen Byrne: «Думаю, что это — хороший ответ, содержащий некоторые ценные идеи, но я должен согласиться со многими другими комментаторами в том, что то, что тут описано, это, определённо, не скрам, хотя и рассматривается под видом скрама». Но многие либо открыто ненавидели скрам, либо соглашались с пользователем Gaiser в том, что, если при использовании скрама что-то идёт не так, это значит, что этот фреймворк просто неправильно применяется.
Как правильно пользоваться скрамом?
▍1. Ежедневные совещания — это не то же самое, что взятие новых тикетов каждый день
Многие говорили о том, что ежедневные совещания принуждают разработчиков к ежедневному закрытию тикетов. Но, как отметил DJClayworth, без приоритизации задач тоже обходиться нельзя. И если приоритеты не расставляются естественным образом, значит, эту задачу должен взять на себя скрам-мастер: «Нужно приоритизировать задачи в пределах спринтов, более масштабным задачам нужно отдавать более высокий приоритет, поэтому кто-то должен взять сложные задачи в первый день спринта. В любом случае, если ко второму дню никто не взял большую и сложную задачу, скрам-мастер должен заявить примерно следующее: «Вижу, никто не взял задачу по сжатию базы данных. А это — большая задача. Если мы собираемся завершить спринт, работу над этой задачей надо начать прямо сейчас.»».
▍2. Стоит прекратить оценивать результаты отдельных разработчиков и прекратить вычислять показатели, относящиеся к отдельным тикетам
Все задачи, решаемые в спринте, нужно разбивать на маленькие части. Это бесспорно. Но фреймворк скрам не говорит о том, что разработчики должны быть одержимы показателями, указывающими на некие результаты. Скрам не предлагает стравливать разработчиков друг с другом. Пользователь Gaiser предлагает совсем отказаться от учёта баллов отдельных программистов. Он указывает и на то, что многим менеджерам может понадобиться заново изучить правила скрама: «Сообщите менеджерам, что момент, когда они хвалят разработчиков, или дают им повышение, основываясь на количестве закрытых тикетов, становится тем моментом, когда они радикальным образом меняют поведение команды».
Пользователь DJClayworth соглашается с тем, что целенаправленное игнорирование метрик, связанных с отдельными тикетами, должно входить в задачи хорошего скрам-мастера: «Внимание должно быть приковано к тому, чтобы команда добивалась бы своих целей именно как команда. Скрам-мастер должен придерживаться именно такой линии поведения и избегать любых дискуссий или подсчётов показателей, основанных на том, сколько пользовательских историй продвинул каждый конкретный член команды».
▍3. К большим целям надо идти маленькими шагами, но при таком подходе не надо забывать об этих целях
Вот ещё одна идея, касающаяся разбиения больших задач на небольшие фрагменты: «Если работа ведётся над маленьким фрагментом головоломки, это не значит, что нужно забыть обо всей этой головоломке».
Пользователь Llewellyn особо отмечает то, что применение скрама не может служить оправданием полного игнорированию принципов разработки качественного программного обеспечения: «Вы должны хорошо представлять себе то, куда движется проект. Это знание можно использовать для планирования архитектуры проекта, занимаясь планированием даже в рамках текущего спринта».
Скрам не освобождает программистов от необходимости делать своё дело, вкладывая в него все свои знания и весь свой опыт. Поэтому призыв Llewellyn относится к программистам, которые есть среди читателей комментариев: «Вы были на совещании, вы можете заглянуть в бэклог, вы знаете о том, каким является общее видение проекта в организации. Вы стремитесь к тому, чтобы избежать необходимости траты больших отрезков времени на что-то из отдалённого будущего. Но нет ничего плохого в том, чтобы заложить базу для расширяемой, модульной системы, которая и подойдёт для решения текущих задач, и позволит без проблем, в будущем, создать уже запланированные дополнительные возможности».
▍4. Надо определиться с тем, что значит «Готово»
Одна из тем, поднятых в обсуждаемой нами дискуссии, касалась критериев готовности (Definition of Done, DoD), и того, как определение этих критериев помогает отдельным программистам придерживаться определённых стандартов качества и быть в курсе того, чего от них ожидают. Самый острый вопрос тут заключался в том, кто и когда вырабатывает эти критерии. В том, что касается «когда», обычно речь шла или о как можно более быстрой выработке критериев, или о том, что они должны вырабатываться в ходе планирования спринта.
Ответ на вопрос о том, кто вырабатывает DoD, был написан пользователем SpoonerNZ в виде ответа на другой вопрос на сайте Software Engineering. «Критерии готовности создаются командой, но этот процесс может потребовать присутствия скрам-мастера. Нужно это для того чтобы задать ограничения, касающиеся качества, в том случае, если у команды нет чётких стандартов разработки. Например, команда может не захотеть связываться с код-ревью или с модульными тестами, что приведёт к тому, что всё это будет добавлено в DoD по инициативе скрам-мастера с целью обеспечения высокого качества разработки. В идеальной ситуации команда, поняв сильные стороны того, что ей предлагают, с радостью это примет, но реальный мир не всегда идеален».
Кто должен работать, придерживаясь DoD? Естественная (и сложная) цель — это сделать так, чтобы положения, изложенные в DoD, применялись бы в одной команде, и чтобы их поддерживали бы все члены этой команды. Но есть веские причины распространить влияние DoD на несколько команд. Или даже на всю организацию. Вот что пишет об этом пользователь Alan Larimer: «Отсутствие общепризнанного определения DoD для продукта негативно сказывается на качестве и прозрачности результатов работы. Организационный уровень DoD должен быть минимальным, техническим, и иногда исходящим от организации, что может обеспечить универсальное применение критериев готовности. Организация может предложить стандарты написания кода. Организация может потребовать автоматизированного создания сборок, давая ресурсы для создания и поддержки сборок для каждого продукта. Любая часть DoD, создана ли она организацией, или отдельным разработчиком, должна приносить в критерии готовности что-то ценное».
▍5. Менеджеры должны играть роль молчаливых наблюдателей
Хотя то, что вынесено в заголовок этого раздела, уже закреплено в официальном руководстве по скрам, анализ дискуссии показывает, что это правило, что печально, часто нарушается на ежедневных совещаниях, на которых присутствуют менеджеры. Из-за этого программисты чувствуют необходимость объяснять то, почему работы по тикетам занимают у них больше времени, чем запланировано. Если же на совещании присутствуют одни лишь программисты, в таких объяснениях нет особой нужды. Вот что сказано об этом в руководстве по скраму: «Ежедневный Скрам — это внутренняя встреча команды разработки. Если на ней присутствует кто-то ещё, скрам-мастер следит, чтобы они не мешали встрече».
▍6. Люди должны быть важнее процессов
Если вам нужно руководство, касающееся применения правил скрам, то прочтите слова, написанные пользователем Frank Hopkins, напоминающие об одном классическом принципе: «Люди важнее процессов». Сюда он добавил следующее: «Хорошая команда должна определять свои процессы, жёстко заданные процессы не способствуют формированию хорошей команды».
Ещё один пользователь, meriton, указал на то, что применение скрам зависит от отдельных программистов: «В скраме не предусмотрено то, что разработчики трудятся независимо друг от друга. Скрам предусматривает то, что команда разработки самоорганизуется, то есть — что команда принимает решения о том, как взаимодействуют её члены».
Пользователь nvoigt отмечает, что команды в скраме самоорганизуются из-за того, что они приходят в проект с уже определённой миссией: «В основе фреймворка скрам лежит тот факт, что вы — это команда. В команде неважно, закрыт ли тикет вчера конкретным программистом. Тот, кто трудится в команде, понимает цель (то есть DoD) и стремится достичь её вместе с остальными членами команды».
▍7. Создавайте команды для работы по принципам скрама, но не ожидайте, что применение скрама приведёт к созданию команды
Пользователь nvoigt применил спортивную метафору: «Представьте себе, что 11 человек получили печатное руководство по футболу. Им сказали, что им нужно ежедневно, примерно в 10 утра, практиковаться в конференц-зале №5, затрачивая на это по 15 минут. Думаете, в результате получится хорошая футбольная команда? А что если эти 11 человек были хорошими, профессиональными футболистами? Всё равно команда не получилась бы? Да, не получилась бы. Просто футбольные команды так не создают. Как и любой командный спорт, скрам нуждается в том, чтобы те, кто применяет этот фреймворк, были бы командой. Если это — просто группа людей, каждый из которых всего лишь хочет заработать себе очки, показывая, как много баллов пользовательской истории он закрыл, или как много целей достиг, то эта группа всегда проиграет команде, члены которой играют вместе, а не рядом друг с другом, или против друг друга».
Итоги
Пользователь nvoigt готов признать, что скрам «не подходит для абсолютно всех людей или команд». И, как показал интерес сообщества к вопросу, который мы тут обсуждаем, применение набора правил, к выработке которого может подтолкнуть скрам, способно привести к построению такой рабочей среды, которая далека от той, которую хотелось бы построить.
Итог этого материала нам хотелось бы подвести словами пользователя Seth R. Он говорит, что от ритуалов agile-методологий не нужно ждать чудес. Слишком многого хотят те, кто стремится с их помощью, как по волшебству, исправить недостатки команды разработчиков. Вот как он видит ситуацию: «Всё это завязано на ускорении обратной связи. В результате у команды появляется возможность заниматься самопроверкой и принимать решения относительно того, как ей работать для достижения лучших результатов. Скрам не поможет вам создать более качественный продукт, но если вы серьёзно отнесётесь к самопроверке, это может помочь вам построить команду, которая будет лучше прежней. А это, в свою очередь, ведёт к разработке более качественного продукта».
Многие сравнивают этот фреймворк с демократией. Поэтому, может быть, скрам — это худшая форма управления процессом разработки, если не считать всех остальных?
Или, может быть это, как говорится в официальном руководстве, фреймворк, который прост для понимания, но труден для совершенного овладения им.
Как вы ответили бы на вопрос из заголовка этой статьи?
Автор: ru_vds
