- PVSM.RU - https://www.pvsm.ru -
"Глупый учится на своих ошибках, умный на чужих".
Всем доброго дня.
В этой статье я намереваюсь разобрать ошибки произошедшие и досконально описанные в топике Обратная сторона Agile [1]
Это ни в коей мере не holywar, ни тем более какой-либо blame. Мне лишь интересно препарировать эти вопросы со стороны исследования и отчасти восстановить доброе имя SCRUM'a.
Прежде чем мы перейдём к разборам ситуаций и попыткам найти правильные решения, а я верю, что практически в любой ситуации его можно найти и тем более применить (иногда через очень больно), я бы хотел ответить на несколько вопросов которые могут возникнуть у читателя.
Кто ты такой чтобы рассуждать о SCRUM'е и разбирать ошибки? — Я сертифицированный SCRUM master по программе SCRUM.org'а. Сейчас PSM level I. Да, я получил сертификат недавно, но практикую и готовлю данную методологию (framework ;) ) уже на протяжении последних лет 5, если не больше, как с нуля, так и меняя существующие.
Итак, если со всеми вопросами разобрались, приступим.
В один прекрасный момент руководство компании решило попробовать новомодную для России методологию разработки. Был выбран Agile (Scrum), в компанию нанят скрам-мастер, все разработки были переведены в TargetProcess. С точки зрения менеджмента это было сделано для того, чтобы улучшить скорость и качество разработки, а также получить понимание, на что тратят время разработчики.
Я, конечно, прекрасно понимаю, что времена меняются, и раньше, возможно, разработка проекта была чем-то вроде творчества. Теперь это отлаженный бизнес-процесс, целью которого является зарабатывание денег. Но доведенный до апофеоза этот процесс может подавить в разработчиках тягу к креативу и заинтересованности в развитии проекта.
Поначалу, после внедрения новомодного Скрама, все радовались его логичности и внешней простоте. Всё понятно, делим процесс разработки на спринты, получаем от менеджеров user-story (задачи что делать), включаем их в те или иные спринты, в конце спринта делаем ретроспективу (смотрим что сделали, и что пошло не так) и зацикливаем этот процесс.
У команды есть РО, который агрегирует все хотелкивиденияфидбэки от всех заинтересованных лиц, обрабатывает этот список и доносит его до команды и РО должен быть один и только один(!) для SCRUM команды, а не куча менеджеров, потому что получится как в той басне Крылова:
Когда в товарищах согласья нет,
На лад их дело не пойдет,
И выйдет из него не дело, только мука.
Менеджмент начал конвертировать задачи во время их выполнения и естественно в стоимость. Тут, как водится, сразу возникло недопонимание между менеджментом и разработчиками. Как перенос проекта с Symfony 2.6 на Symfony 3.0 может занять почти неделю времени разработчика, ведь это просто обновление с одной версии на другую? Возможно, отдел разработки с точки зрения бизнеса всегда выглядит как ленивые сотрудники, которые хорошо, если бы смогли работать втрое, а лучше в пять раз быстрее, чтобы снизить расходы на разработку и увеличить её скорость.
Но, с точки зрения разработчиков, появилась несколько иная картина, разработчики и так были не обделены работой, работая параллельно над тремя-пятью проектами каждый, как тут появилось давление со стороны менеджмента и отчет за каждый час рабочего времени. Стали возникать вопросы в духе «почему вы потратили целый день на разработку или тестирование того-то»?
Стали выполняться только задачи (User Story), приходящие от менеджеров, ни на какую незаметную, но полезную деятельности времени у разработчиков оставаться не стало.
Доходило до того, что при нахождении бага где-то на продакшне разработчики не могли его чинить, т.к. на это требуется задача, чтобы списывать туда время. Да и сами разработчики были завалены своими задачами. Задачам стали присваивать приоритеты. Менеджеры начали конфликтовать между собой, пытаясь присвоить своей userStory высший приоритет, т.к. у них обязательства перед заказчиками и никого не волнует занятость разработчиков.
Методология Скрам, превращающая процесс разработки в конвейер, не учитывает прежде всего человеческих взаимоотношений в команде, не учитывает того, что некоторые вещи в компании могут делаться только из-за энтузиазма сотрудников, и не могут быть завернуты в UserStory.
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 [3], я могу постараться даже дополнить вашу статью, как мне кажется вы забыли упомянуть один серьёзный фактор, который сильно повлиял на всю команду и на весь процесс. Возможно я и ошибусь, но как мне подсказывает интуиция он имел место быть — оценка для User Story рассматривалась как commitment, и разработчики сидели в овертаймах по самые уши. Угадал?
Я так полагаю что пациент спасён не был, поэтому подведём итоги.
В принципе все фиксы для ошибок описаны в статье, но ниже я соберу короткое резюме:
Почему я так отреагировал на статью, местами теряя нить логического повествования и скатываясь в рассуждения - потому что у меня подгорело пожалуй потому что SCRUM хаят очень часто не разобравшись. Как итог это приведёт к тому, что кто-то скажет: "%username%, ты знаешь SCRUM — гавно, соковыжималка и фашизм. Не будем его внедрять." и как итог все что-нибудь потеряют.
В изначальном топике явно видны огромные проблемы в организации самого процесса, на которые забилиположилиподставить_на_своё_усмотрение. SCRUM как раз тут не причём. При правильном подходе он просто бусечка и вообще
Это я могу заявить с полной уверенностью человека, делавшего SCRUM с нуля, изменявшего SCRUM, миксовавшего его с Kanban, использовавшего его успешно с проектами Fixed Price(!).
Да, переход на него агрессивен, новшества всегда, пожалуй, неожиданны и больны, но если его правильно преподнести, то он будет работать очень хорошо.
PS — я не призываю что SCRUM — панацея от всего. Иногда бывает, что он не применим, какие бы асаны ему не пели, но эта неприменимость заключается в разных факторах: бюджет, ограничения, необходимость применять другой процесс. Но, его неприменимость нельзя относить на счёт кривых рук. Кривые руки — это кривые руки, ими можно изговнять всё, не только SCRUM.
Почти все мои рассуждения пересекаются со SCRUM Guide [4]. Очень рекомендую изучить внимательно и работать активно с этим документом, а не слепо следовать за чьим кривым мнением.
Автор: Mephistophele
Источник [5]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/news/237663
Ссылки в тексте:
[1] Обратная сторона Agile: https://habrahabr.ru/post/319232/
[2] мозга: http://www.braintools.ru
[3] Keks650: https://habrahabr.ru/users/keks650/
[4] SCRUM Guide: http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf
[5] Источник: https://habrahabr.ru/post/320548/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.