"Глупый учится на своих ошибках, умный на чужих".
Всем доброго дня.
В этой статье я намереваюсь разобрать ошибки произошедшие и досконально описанные в топике Обратная сторона Agile
Это ни в коей мере не holywar, ни тем более какой-либо blame. Мне лишь интересно препарировать эти вопросы со стороны исследования и отчасти восстановить доброе имя SCRUM'a.
Вопросы и ответы. Всё коротенько.
Прежде чем мы перейдём к разборам ситуаций и попыткам найти правильные решения, а я верю, что практически в любой ситуации его можно найти и тем более применить (иногда через очень больно), я бы хотел ответить на несколько вопросов которые могут возникнуть у читателя.
-
Кто ты такой чтобы рассуждать о SCRUM'е и разбирать ошибки? — Я сертифицированный SCRUM master по программе SCRUM.org'а. Сейчас PSM level I. Да, я получил сертификат недавно, но практикую и готовлю данную методологию (framework ;) ) уже на протяжении последних лет 5, если не больше, как с нуля, так и меняя существующие.
- Ты то здесь что забыл? — У меня свои корыстные цели: я готовлюсь сейчас к сертификации PSM level II, а для подтверждения второго уровня необходимо разбирать кейсы, а не бездумно кликать на правильные ответы, сверяясь со SCRUM Guide. Поэтому подобные случаи для меня — золотой кладезь (да и если кому-то будет интересно, присылайте мне Ваши случаи, постараюсь их препарировать, ну или возопию о помощи и пойду её искать).
Итак, если со всеми вопросами разобрались, приступим.
Вносите пациента.
В один прекрасный момент руководство компании решило попробовать новомодную для России методологию разработки. Был выбран Agile (Scrum), в компанию нанят скрам-мастер, все разработки были переведены в TargetProcess. С точки зрения менеджмента это было сделано для того, чтобы улучшить скорость и качество разработки, а также получить понимание, на что тратят время разработчики.
- Найм SCRUM master'а (везде далее SM) — это хороший и логичный шаг, потому что иногда встречаются попытки приготовить SCRUM на своём зачастую специфическом понимании. Надеюсь опыт у человека в этой области был, т.к. делать SCRUM с нуля, занятие далеко не простое, хотя, судя по дальнейшему содержанию исходной статьи, я в этом сильно сомневаюсь. Но пока что оставим его компетенцию под вопросом.
- Коснёмся хотелок менеджмента: улучшение скорости и качество — хорошо, на что тратят время разработчики — это мимо и не к SCRUM'у. Это обычный time-tracking, никак не описанный в SCRUM Guide и его можно применять для любой методологии, будь то KonьBan, Waterfall или прочие RUP'ы.
Я, конечно, прекрасно понимаю, что времена меняются, и раньше, возможно, разработка проекта была чем-то вроде творчества. Теперь это отлаженный бизнес-процесс, целью которого является зарабатывание денег. Но доведенный до апофеоза этот процесс может подавить в разработчиках тягу к креативу и заинтересованности в развитии проекта.
- Как раз задача SCRUM'а — поддержание креативности, заинтересованности и хорошей атмосферы. Основной нюанс — правильно научиться его применять и не менять основные правила, т.к. если в хорошо отлаженном механизме заменить одну деталь совершенно другой, неподходящей ни по размеру, ни по функциям, то получится одно большое ничего из всего механизма.
Поначалу, после внедрения новомодного Скрама, все радовались его логичности и внешней простоте. Всё понятно, делим процесс разработки на спринты, получаем от менеджеров user-story (задачи что делать), включаем их в те или иные спринты, в конце спринта делаем ретроспективу (смотрим что сделали, и что пошло не так) и зацикливаем этот процесс.
- Тут и первая серьёзная ошибка — получение user-story от менеджеров. Из всего текста, прочитанного мною в изначальном топике, я не встретил упоминания роли Product Owner (везде далее РО). Кто же такой РО — человек ответственный за конечное видение, развитие проекта и управление бэклогом проекта, у него есть ещё ряд обязанностей, но пока что ограничимся этими. Т.е. PO — первый сдерживающий барьер от всего стада менеджерья обитающего на просторах вашего офиса. Так это должно выглядеть и работать.
У команды есть РО, который агрегирует все хотелкивиденияфидбэки от всех заинтересованных лиц, обрабатывает этот список и доносит его до команды и РО должен быть один и только один(!) для SCRUM команды, а не куча менеджеров, потому что получится как в той басне Крылова:
Когда в товарищах согласья нет,
На лад их дело не пойдет,
И выйдет из него не дело, только мука.
- Следующий нюанс — отсутствие факта оценки. Может быть автор статьи забыл указать, а может её просто не было, но команда должна давать свою оценку на ту или иную User Story. Если оценка дана кем-то другим, не Development Team'ом (везде далее DT), то это будет больпечаль и вообще так делать нельзя. Должен соблюдаться постулат, кто выполняет задачу, тот и даёт оценку. Не менеджер Вася, а весь DT.
Менеджмент начал конвертировать задачи во время их выполнения и естественно в стоимость. Тут, как водится, сразу возникло недопонимание между менеджментом и разработчиками. Как перенос проекта с Symfony 2.6 на Symfony 3.0 может занять почти неделю времени разработчика, ведь это просто обновление с одной версии на другую? Возможно, отдел разработки с точки зрения бизнеса всегда выглядит как ленивые сотрудники, которые хорошо, если бы смогли работать втрое, а лучше в пять раз быстрее, чтобы снизить расходы на разработку и увеличить её скорость.
- Вот в этот момент должен был вступить в игру SM и
послать всех менеджеров в пешее эротическое путешествиеоградить разработчиков(DT) от менеджерского беспредела. Желание менеджмента понятно и применимо: оценить, измерить, сэкономить бабла (не ну всё менеджеры этим занимаются, от этого никуда не деться). Но в данном случае в дело должен был вмешаться SM, принимая весь удар на себя, объясняя всем что делает команда, чем занимается и почему их нельзя трогать. Ну а если в комнату к DT прокрадётся какой-либо особо ретивый менеджер, то гнать его ссаными тряпками. Да, я предвижу возражения: "Чел, этож менеджеры, кто им слово-то против скажет, не говоря про тряпки?", но тут всё достаточно просто, SM заранее должен договориться с ТОПМегаТОП и прочими большими менеджерами, что команду не трогают и работают через него. Собственно, это одна из обязанностей SM'а — внедрять SCRUM в организации и внедрять его правильно, а не тяп ляп. Тут же судя по всем SM устранился от проблемыи сидел гамал в танчики?
Но, с точки зрения разработчиков, появилась несколько иная картина, разработчики и так были не обделены работой, работая параллельно над тремя-пятью проектами каждый, как тут появилось давление со стороны менеджмента и отчет за каждый час рабочего времени. Стали возникать вопросы в духе «почему вы потратили целый день на разработку или тестирование того-то»?
- Один DT — один PO и желательно один проект (или обязательно один Product Backlog), или необходимо менять серьёзно процесс, менять методологию с чистого SCRUM'а на Kanban (а ещё лучше помесь сделать SCRUMBan, и да, тут нет ничего страшного, если будет интересно, расскажу, как это делать и внедрять
плюс всякой разной чернухи). Т.е. когда много реквестов с многих проектов, то это уже попахивает support'ом и тут лучше уходить от SCRUM'а. Плюс где был SM (аааууу?), почему не защищал DT? Он точно SCRUM знал? Был готов его внедрять? Имел опыт? К этому абзацу я уже сомневаюсь в положительных ответах на эти вопросы чуть более чем полностью.
Стали выполняться только задачи (User Story), приходящие от менеджеров, ни на какую незаметную, но полезную деятельности времени у разработчиков оставаться не стало.
- Не было PO, неверно внедрён SCRUM — отсюда и лютая боль. Если бы был один(!) PO, который отвечал за управление ProjectProduct Backlog'ом, а не стадо оголтелых менеджеров, то всё было бы проще (Да ему бы пришлось ругаться с менеджерами и быть ими нелюбимым, ну а что делать? Судьба у него такая в некоторых реалиях. Это потом бы уже все попривыкли и смирились.)
Доходило до того, что при нахождении бага где-то на продакшне разработчики не могли его чинить, т.к. на это требуется задача, чтобы списывать туда время. Да и сами разработчики были завалены своими задачами. Задачам стали присваивать приоритеты. Менеджеры начали конфликтовать между собой, пытаясь присвоить своей userStory высший приоритет, т.к. у них обязательства перед заказчиками и никого не волнует занятость разработчиков.
- Я повторюсь если скажу, что PO нет и SM мудак и это основная проблема? На самом деле Backlog item (в нашем случае User Story) — это необходимый артефакт, кто-то скажет, что это дань формализму, но тут я посмею возразить — нет. Это описание, понимание и видение конечных результатов того что должно быть сделано. И должно это быть оформлено таким образом, что ВасяПетяКтулху из DT — все понимали, что нужно сделать и могли это объяснить PO и SM'у. Зачем объяснять им если они и так знают? Затем, чтобы увидеть, что члены DT правильно понимают и нет разночтений. По рекомендациям — всё просто, выставить PO и SM'a на переднюю линию обороны DT, чтобы все какашки летели в них, а DT отсечь от мира и подогнать им чайкофепеченюшкикуртизанок.
Методология Скрам, превращающая процесс разработки в конвейер, не учитывает прежде всего человеческих взаимоотношений в команде, не учитывает того, что некоторые вещи в компании могут делаться только из-за энтузиазма сотрудников, и не могут быть завернуты в UserStory.
- Framework, Bro. Не методология, ни разу. Она учитывает человеческие отношения это одна из основных целей SCRUM'а и базируется на этих отношениях. Почему я так решил, да вот почему (кусок выдран из SCRUM Guide'а):
When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. The Scrum Team members learn and explore those values as they work with the Scrum events, roles and artifacts. Successful use of Scrum depends on people becoming more proficient in living these five values. People personally commit to achieving the goals of the Scrum Team. The Scrum Team members have courage to do the right thing and work on tough problems. Everyone focuses on the work of the Sprint and the goals of the Scrum Team. The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. Scrum Team members respect each other to be capable, independent people
Согласно SCRUM'у люди — основа. Хотя, чего я тут его восхваляю — люди основа везде у любого управленца и при любом процессеподходеметодологии. Если нет, если же менеджеры думают седалищем, то тут всё плохо.
Уважаемый Keks650, я могу постараться даже дополнить вашу статью, как мне кажется вы забыли упомянуть один серьёзный фактор, который сильно повлиял на всю команду и на весь процесс. Возможно я и ошибусь, но как мне подсказывает интуиция он имел место быть — оценка для User Story рассматривалась как commitment, и разработчики сидели в овертаймах по самые уши. Угадал?
- Казалось бы, это как-то незначительно commitment или прогноз. Какая в пень разница? А различие на самом деле огромно. В SCRUM Guide нет такого понятия как commitment по срокам выполнения. Если задача была оценена невернонеправильно или не учтены все факторы, то это предмет торга между DT и PO, но никак не "умри, но сделай". Да и вообще есть понятие прогноз, если обратить внимание, то SCRUM Guide не описывает способы эстимации и единицы измерения. Все эти часы, покеры и прочие размеры трусов, появились как локальные расширения, которые "прижились". Но в первоскраме их попросту нет. Таким образом если прогноз не удался, то в рамках Retro, DT должна рассмотреть чтопочему и как это исправить, чтобы подобного не повторялось. И если SCRUM внедрён нормально, то проблем с этим не возникает.
Посмертный эпикриз.
Я так полагаю что пациент спасён не был, поэтому подведём итоги.
В принципе все фиксы для ошибок описаны в статье, но ниже я соберу короткое резюме:
- РО и SM должны быть и должны быть вовлечены в процесс согласно своим обязанностям.
- РО должен работать напрямую с stakeholder’ами. DT должна только исполнять видение РО согласно бэклогу проекта и не общаться с менеджерами вообще, кроме как для уточняющих вопросов и получения обратной связи в рамках ревью.
- SM должен быть не для галочки, не потому что это модномолодёжно, не для попила бабла, а для настройки процесса, т.к. без грамотного SM’a весь процесс пойдёт прахом. В частности, в данной ситуации он должен был инициировать создание роли РО, затем обучить его как работать с бэклогом, DT и внешними менеджерами. Так же на первых парах смотреть чтобы он не накосячил и на него не оказывали излишнее влияние менеджеры.
Затем работать с командой, получая от неё обратную связь и устраняя то что команде мешает: будь то сквозняк в помещении или какой-либо особо назойливый и ретивый менеджер. - У РО должен быть проработанный и приоритезированный Project Backlog, с чётким определением приоритетов, а не так что пришёл очередной парниша и ввёл супер-пупер приоритет потому что ему так надо.
Эпилог
Почему я так отреагировал на статью, местами теряя нить логического повествования и скатываясь в рассуждения - потому что у меня подгорело пожалуй потому что SCRUM хаят очень часто не разобравшись. Как итог это приведёт к тому, что кто-то скажет: "%username%, ты знаешь SCRUM — гавно, соковыжималка и фашизм. Не будем его внедрять." и как итог все что-нибудь потеряют.
В изначальном топике явно видны огромные проблемы в организации самого процесса, на которые забилиположилиподставить_на_своё_усмотрение. SCRUM как раз тут не причём. При правильном подходе он просто бусечка и вообще
Это я могу заявить с полной уверенностью человека, делавшего SCRUM с нуля, изменявшего SCRUM, миксовавшего его с Kanban, использовавшего его успешно с проектами Fixed Price(!).
Да, переход на него агрессивен, новшества всегда, пожалуй, неожиданны и больны, но если его правильно преподнести, то он будет работать очень хорошо.
PS — я не призываю что SCRUM — панацея от всего. Иногда бывает, что он не применим, какие бы асаны ему не пели, но эта неприменимость заключается в разных факторах: бюджет, ограничения, необходимость применять другой процесс. Но, его неприменимость нельзя относить на счёт кривых рук. Кривые руки — это кривые руки, ими можно изговнять всё, не только SCRUM.
Почти все мои рассуждения пересекаются со SCRUM Guide. Очень рекомендую изучить внимательно и работать активно с этим документом, а не слепо следовать за чьим кривым мнением.
Автор: Mephistophele
