«Глупый человек учится на своих ошибках, умный — на чужих».
Добрый день всем.
В этой статье я намерен проанализировать возникшие ошибки и подробно описанные в теме.
Это ни в коем случае не холивар, и уж тем более не обвинение.
Меня интересует лишь анализ этих проблем с исследовательской стороны и частичное восстановление доброго имени SCRUM.
Вопросы и ответы.
Все коротко.
Прежде чем мы перейдем к анализу ситуаций и попыткам найти правильное решение, а я считаю, что практически в любой ситуации его можно найти и, более того, применить (иногда через сильную боль), мне хотелось бы ответить на несколько вопросов, которые волнуют читателя.
можно иметь.
- Кто вы такой, чтобы говорить о SCRUM и разбирать ошибки? — Я сертифицированный SCRUM-мастер по программе SCRUM.org. Сейчас уровень PSM I. Да, сертификат я получил недавно, но практикую и готовлю эту методику (фреймворк ;)) уже лет 5, если не больше, как с нуля, так и меняя существующие.
- Что, черт возьми, ты забыл? — У меня свои корыстные цели: я сейчас готовлюсь к сертификации PSM II уровня, и для подтверждения второго уровня необходимо анализировать кейсы, а не бездумно нажимать на правильные ответы, проверяя SCRUM Guide. Поэтому такие случаи для меня — золотая жила (и если кому интересно, присылайте мне свои дела, я попробую их разобрать, или позову на помощь и пойду искать).
Приведите пациента.
В какой-то момент руководство компании решило попробовать новую для России методологию разработки.Был выбран Agile (Scrum), в компанию нанят Scrum-мастер, а все разработки перенесены в TargetProcess. С точки зрения руководства это было сделано для того, чтобы улучшить скорость и качество разработки, а также получить понимание того, как разработчики тратят свое время.
- Наем SCRUM-мастера (далее СМ) — хороший и логичный шаг, потому что иногда предпринимаются попытки подготовить SCRUM, используя собственное, зачастую специфическое понимание.
Надеюсь, у человека был опыт в этой области, потому что.
делать SCRUM с нуля далеко не просто, хотя, судя по дальнейшему содержанию оригинальной статьи, я в этом сильно сомневаюсь.
Но пока оставим его компетентность под вопросом.
- Коснемся пожеланий руководства: улучшение скорости и качества — хорошо, на что разработчики тратят время — неактуально и не для SCRUM. Это обычный тайм-трекинг, никак не описанный в SCRUM Guide и его можно использовать для любой методологии, будь то Kon Ban, Waterfall или другие RUP.
Я, конечно, прекрасно понимаю, что времена меняются, и раньше, возможно, разработка проекта была чем-то вроде творчества.Сейчас это налаженный бизнес-процесс, цель которого – заработать деньги.
Но этот процесс, доведенный до апофеоза, может подавить стремление разработчиков к творчеству и интерес к развитию проекта.
- Сама задача SCRUM — поддерживать креативность, интерес и хорошую атмосферу.
Главный нюанс - научиться правильно его применять и не менять основных правил, т.к.
если в исправно работающем механизме заменить одну деталь на совершенно другую, неподходящую ни по размерам, ни по функциям, то получится весь механизм.
быть одним большим ничем.
Поначалу, после внедрения новомодного Scrum, все радовались его логике и кажущейся простоте.Все понятно, разбиваем процесс разработки на спринты, получаем user-story (задачи, что делать) от менеджеров, включаем их в тот или иной спринт, в конце спринта делаем ретроспективу (смотрим, что мы делаем).
сделал и что пошло не так) и зациклите этот процесс.
- Вот первая серьезная ошибка — получение user-story от менеджеров.
Из всего прочитанного в исходной теме текста я не увидел ни одного упоминания о роли Product Owner (далее RO).
Кто такой РО — человек, ответственный за финальное видение, разработку проекта и управление бэклогом проекта, у него есть ряд других обязанностей, но пока ограничимся этими.
Те.
ПО — это первый сдерживающий барьер от всего стада менеджеров, живущих на просторах вашего офиса.
Вот как это должно выглядеть и работать.
В команде есть РО, которое агрегирует все пожелания/видения/отзывы всех заинтересованных сторон, обрабатывает этот список и доставляет его команде, причем для SCRUM-команды РО должен быть один и только один(!), а не кучка менеджеров, потому что получится как в той басне Крылова:
Когда нет согласия среди товарищей, Дела у них пойдут не очень хорошо, И ничего из этого не выйдет, одни мучения.
- Следующий нюанс – отсутствие факта оценки.
Может быть, автор статьи забыл указать, а может быть, ее просто не было, но команда должна дать свою оценку той или иной User Story. Если оценку дал кто-то другой, а не Команда Разработки (далее — ДТ), то это будет боль/печаль и вообще не может быть сделано таким образом.
Необходимо соблюдать постулат: оценку дает тот, кто выполняет задание.
Не менеджер Вася, а весь ДТ.
Руководство начало конвертировать задачи в процессе их выполнения и, естественно, в стоимость.Тут как обычно сразу возникло недопонимание между руководством и разработчиками.
Как миграция проекта с Symfony 2.6 на Symfony 3.0 может занять почти неделю времени разработчиков, если это всего лишь переход с одной версии на другую? Возможно, отдел разработки с точки зрения бизнеса всегда выглядит как ленивые сотрудники, которые могли бы работать в три, а еще лучше, в пять раз быстрее, чтобы снизить затраты на разработку и увеличить ее скорость.
- Именно в этот момент в дело должна была вступить SM и отправить всех менеджеров в эротическое прогулочное путешествие, чтобы защитить разработчиков (DT) от управленческого беспредела.
Желание руководства понятно и применимо: оценить, измерить, сэкономить (не все менеджеры так делают, от этого никуда не деться).
Но в данном случае SM пришлось вмешаться в дело, приняв весь удар на себя, объяснив всем, чем занимается команда, чем занимается и почему их нельзя трогать.
Ну а если какой-нибудь особо ретивый менеджер прокрадется в комнату ДТ, то прогоните его ссаными тряпками.
Да, предвижу возражения: «Чувак, это же менеджеры, кто что-то против них скажет, не говоря уже о тряпкахЭ», но тут всё довольно просто, СМ надо заранее договориться с ТОП\МегаТОП и другими большими менеджерами, что команда не будем трогать и работать над этим.
Собственно, это одна из обязанностей СМ — внедрить SCRUM в организации и внедрить его правильно, а не оплошно.
Сразу, судя по всем, СМ избавился от проблемы и сел в танки?
Но, с точки зрения разработчиков, вырисовывалась несколько иная картина: разработчики уже не были лишены работы, работая параллельно над тремя-пятью проектами каждый, когда появилось давление со стороны руководства и отчет за каждый час рабочего времени..
Стали возникать вопросы в духе «почему ты потратил целый день на разработку или тестирование того-то и того-то»?
- Одно ДТ - одно ПО и желательно один проект (или обязательно один Product Backlog), или надо серьезно менять процесс, менять методологию с чистого SCRUM на Kanban (а еще лучше сделать помесь SCRUMBan, и да, там ничего страшного, если интересно, я расскажу как это сделать и реализовать, плюс всякие разные штуки).
Те.
когда много запросов от многих проектов, то это уже попахивает поддержкой и тут лучше отходить от SCRUM. Плюс где был СМ (аууу?), почему он не защитил ДТ? Действительно ли он знал SCRUM? Были ли вы готовы это реализовать? Был ли у вас опыт? К этому абзацу я уже сомневаюсь в положительных ответах на эти вопросы чуть более чем полностью.
Стали выполняться только задачи (User Story), поступающие от менеджеров, и времени на какие-то незаметные, но полезные занятия у разработчиков уже не оставалось.
- ПО не было, SCRUM был реализован неправильно — отсюда и сильная боль.
Если бы за управление Бэклогом Проекта\Продукта отвечал один(!) ПО, а не стадо оголтелых менеджеров, то всё было бы проще (Да, ему пришлось бы ссориться с менеджерами и не нравиться им, но что делать? Судьба у него такая в каких-то реалиях.
Тогда бы все привыкли и смирились.
)
Доходило до того, что если где-то в продакшене обнаруживался баг, то разработчики не могли его исправить, потому что там требуется задание списать время.Да и сами разработчики были завалены своими задачами.
Задачам стали присваиваться приоритеты.
Менеджеры начали конфликтовать друг с другом, пытаясь присвоить своей userStory высший приоритет, потому что.
у них есть обязательства перед клиентами и никто не заботится о трудоустройстве разработчиков.
- Повторюсь, если скажу, что ПО нет, а СМ - мудак и это основная проблема? По сути, элемент Backlog (в нашем случае User Story) — необходимый артефакт; кто-то скажет, что это дань формализму, но здесь я смею возразить – нет. Это описание, понимание и видение конечных результатов того, что необходимо сделать.
И оформить это надо так, чтобы Вася\Петя\Ктулху из ДТ - все понимали, что нужно делать, и могли объяснить это ПО и СМ.
Зачем им объяснять, если они и так знают? Потом посмотреть, что члены ДТ понимают правильно и нет расхождений.
По рекомендациям все просто, поставьте ПО и СМ на передовую защиту ДТ, чтобы все какашки летели в них, а ДТ оторвите от мира и дайте им чай/кофе/печенье/куртизанки.
Методология Scrum, превращающая процесс разработки в конвейер, не учитывает, прежде всего, человеческие взаимоотношения в команде, не учитывает тот факт, что некоторые вещи в компании можно делать только благодаря энтузиазм сотрудников и не может быть обернут в UserStory.
- Рамки, Бро.
Ни методологии, ни разу.
Он учитывает человеческие отношения — это одна из основных целей SCRUM и на этих отношениях основано.
Почему я так решил и вот почему (кусок из SCRUM Guide):
Когда Скрам-команда воплощает и реализует ценности преданности делу, смелости, сосредоточенности, открытости и уважения, столпы Скрама, такие как прозрачность, проверка и адаптация, оживают и укрепляют доверие для всех.
Члены Scrum-команды изучают и исследуют эти ценности, работая с событиями, ролями и артефактами Scrum. Успешное использование Scrum зависит от того, насколько люди станут более опытными в соблюдении этих пяти ценностей.
Люди лично обязуются достичь целей Scrum-команды.
Члены Scrum-команды имеют смелость поступать правильно и работать над сложными проблемами.
Все фокусируются на работе Спринта и целях Scrum-команды.
Скрам-команда и ее заинтересованные стороны соглашаются открыто рассказывать обо всей работе и проблемах, связанных с ее выполнением.
Члены Scrum-команды уважают друг друга как способных и независимых людей.
Хотя, чего я его тут хвалю - везде основой любого менеджера и любого процесса/подхода/методологии являются люди.
Если нет мозгов, если менеджеры думают своим местом, то всё плохо.
Дорогой Кекс650 , могу даже попытаться дополнить вашу статью, так как мне кажется, вы забыли упомянуть один серьёзный фактор, который сильно повлиял на всю команду и весь процесс.
Возможно, я ошибаюсь, но, как подсказывает мне моя интуиция, так оно и было — оценка User Story считалась обязательством, а разработчики были по уши в сверхурочной работе.
Вы правильно догадались?
- Казалось бы, это какое-то незначительное обязательство или прогноз.
Какая разница? И разница на самом деле огромная.
В SCRUM Guide нет такого понятия, как соблюдение сроков.
Если задание было оценено неправильно/неправильно или не были учтены все факторы, то это предмет торга между ДТ и ПО, а не «умри и сделай».
И вообще есть понятие прогноза; если вы обратите внимание, в SCRUM Guide не описаны методы оценки и единицы измерения.
Все эти часы, кочерги и прочие размеры трусиков появились как локальные расширения, которые «прижились».
Но в первом Scrum их просто не существует. Таким образом, если прогноз не удался, то в рамках Ретро ДТ должен подумать, что\почему и как это исправить, чтобы подобное не повторилось.
И если SCRUM реализован нормально, то проблем с этим нет.
Посмертный эпикриз.
Я считаю, что пациента не удалось спасти, поэтому подведем итоги.
В принципе все исправления ошибок описаны в статье, но ниже я подведу краткий итог:
- RO и SM должны быть вовлечены в процесс в соответствии со своими обязанностями.
- Представительство должно работать напрямую с заинтересованными сторонами.
ДТ должен выполнять видение РО только по бэклогу проекта и вообще не общаться с менеджерами, кроме уточнения вопросов и получения обратной связи в рамках проверки.
- СМ должно быть не для галочки, не потому что это модно/молодежно, не для пропитки денег, а для настройки процесса, т.к.
без грамотного СМ весь процесс пойдет впустую.
В частности, в этой ситуации ему пришлось инициировать создание роли РО, затем обучать его работе с бэклогом, ДТ и внешними менеджерами.
Также в первые пару лет следите за тем, чтобы он не накосячил и чтобы менеджеры не оказывали на него чрезмерного влияния.
Затем работайте с командой, получая от нее обратную связь и устраняя то, что беспокоит команду: будь то сквозняк в комнате или какой-то особо надоедливый и ретивый менеджер.
- У RO должен быть хорошо разработанный и расставленный по приоритетам бэклог проекта с четким определением приоритетов, а не просто какой-то парень, который придет и введет супер-пупер приоритет, потому что он ему так нужен.
Эпилог
Почему я так отреагировал на статью, местами теряя нить логического повествования и скатываясь к рассуждениям - потому что я обжегся, возможно, потому, что SCRUM очень часто критикуют, не понимая его.В результате это приведет к тому, что кто-то скажет: «%username%, вы знаете SCRUM — хрень, соковыжималка и фашизм.
Давайте не будем это внедрять».
и в результате каждый что-то потеряет. В исходной теме явно видны огромные проблемы в организации самого процесса, которыми они пренебрегли\поставили\подменили по_вашем_усмотрению.
SCRUM не имеет к этому никакого отношения.
При правильном подходе он просто бусинка и вообще 
Я могу сказать это с полной уверенностью человека, который сделал SCRUM с нуля, изменил SCRUM, смешал его с Kanban и успешно использовал его в проектах с фиксированной ценой(!).
Да, переход к нему агрессивный, инновации всегда, пожалуй, неожиданные и болезненные, но если его правильно подать, то он будет работать очень хорошо.
PS — Я не говорю, что SCRUM — панацея от всего.
Иногда бывает, что он неприменим, какие бы асаны к нему ни пели, но эта неприменимость кроется в разных факторах: бюджете, ограничениях, необходимости применить другой процесс.
Но его неприменимость нельзя списать на кривые руки.
Кривые руки — это кривые руки, они могут прогнать всё, не только SCRUM. Почти все мои рассуждения совпадают с Руководство по SCRUM .
Очень рекомендую внимательно изучить и активно поработать с этим документом, а не слепо следовать чьему-то кривому мнению.
Теги: #agile #scrum #командная работа #Управление проектами #agile #Управление персоналом
-
Танго - Операционная Система Из Будущего
19 Oct, 24 -
Инвентаризация Оргтехники
19 Oct, 24 -
Где, Черт Возьми, Мэтт?
19 Oct, 24 -
Нужны Ли Хедхантеры?
19 Oct, 24 -
Как Организовать Фестиваль?
19 Oct, 24
