Комментарии 14
За теорию мотивации спасибо, но когда вы попытались натянуть на неё скрам, стало смешно.
Если у команды разработки убрать scrum и позволить им самим организовать свою работу, то и проблем с мотивацией не будет. Scrum удобен менеджерам для имитации бурной деятельности, большенству разработчиков удобней работать по своим правилам. Так же популярны kanban или waterfall.
Scrum и менеджмент - различные вещи с точки зрения подхода. Попытка совмещения приводит к "карго-скраму". Цель данного фреймворка именно в самостоятельной организации работы и принятия решений.
Другой вопрос, что команда, как коллектив, - это всегда набор различных мнений и "своих правил". Так что для эффективной работы команды (особенно на начальном этапе) необходимо принять определённые рамки (фреймы) в пределах которых и будет проходить процесс совместной деятельности.
Давайте будем честными, когда разработчикам разрешали самим выбирать фреймворк для орагнизации работы? Чаще всего в компании уже есть scrum-мастера, agile-коучи и прочие сектанты, которые будут просто не нужны, если разработчики самостоятельно организуются.
И чтобы не потерять свою работы и теплое место, agile-сектанты начинают принудительно заставлять разработчиков работать по тому же scrum. Даже если сам проект этого не требует, а в штате 2 разаработчкиа, но зато есть скрам-мастер, продакт менеджер, продактоунер, бизнес анлитик, аджайл-коуч и т.д. И вместе работы все занимаются дейликами,груммингами,покер-планированием, кикофми,демо,ретро и т.д. а вместо продукта заказчику можно показывать красивые графики сгоряния задач в jira.
Артем, как-то у вас все в кучу смешалось. Прежде всего Agile - это философия, которая как раз и идет вразрез с принципами классического менеджмента и директивного управления.
Поэтому в Scrum и нет такой роли, как продакт-менеджер. Есть владелец продукта, который осуществляет поставку входящих задач и скрам-мастер, задача которого не управлять командой, а помогать ей. В том числе и с соблюдением всех необходимых событий, которые и определяют те самые рамки (фреймы).
Ежедневные встречи как раз и должны занимать не более 15 минут, чтобы не отвлекать разработчиков от их работы без надобности. Так же основной смысл Agile и Scrum, в частности, в регулярной демонстрации именно продукта, а не графиков. Для того чтобы команда могла напрямую получить обратную связь от пользователей продукта.
Наверное, было бы неплохо, если вы расскажите о своем личном опыте. Исходя из которого вы судите о Scrum в целом. Возможно это внесет какую-то ясность.
К сожалению это не у меня в кучу смешалось, это суровая отечественная действительность. Я работал в разных компаниях и в каждой готовили scrum по разному. Кто во что гораз и как он это понимает. Как пример - sbergile (на хабре есть статья).
По-этому, я рассказываю из опыта разработчика. Я видел как увольнялись целиком команды,только из-за того что внедрялся scrum и разработка превращалась в соблюдение scrum-церемоний вместо написание кода.
Извините конечно, но у вас больше теоретические рассуждения,как это должно быть. Печальная действительность совсем другая.
Scrum гайд - это всего 16 страниц текста. С точки зрения процессов он прост и понятен. Другой вопрос, как вы правильно заметили, его применение (внедрение) на практике. Если делать это топорно, пытаясь совмещать скрам с устоявшимся директивным менеджментом, тем самым снижать значимость вышеуказанных факторов, то ничего хорошего из этого естественно не выйдет. Но хочу подчеркнуть, что проблема здесь не в скраме, а именно в способах его применения.
Вот эти шаблонные фразы : "проблема здесь не в скраме, а в способах его применения","мы гибкие" и "соблюдение церемоний повышает продуктивность" постоянно и слышу от скрам-сектантов. Да и вообще они всегда только шаблонными фразами из книг и манифестов общаются.
Возникает вопрос - а зачем этот скрам вообще нужен,если от него столько проблем и негатива? Может стоит или чётко прописать все правила или вообще его не применять? Сейчас вы пытаетесь защитить скрам,перекладывая ответственность за реализацию на кого угодно,только не на самих адептов скрама )))
Есть kanban и waterfall. Разработчикам с ними комфортно, зачем натягивать сову на глобус?
Артем, говоря о неправильном применении, я совершенно не пытаюсь снять ответственность с тех, кто должен заниматься правильной организацией всех скрам процессов. Как раз наоборот!
И чтобы из скарма не получился карго-скрам, как раз им и стоит внимательно учитывать все, что написано в Agile манифесте.
Кстати, вы его читали? Мало какой разработчик будет не согласен с тем, что там написано.
Как и с тем, что автономия в работе и в принятии решений, осознание важности своего вклада и наличие обратной связи положительно сказывается на ее эффективности.
Кстати, ничего не имею против Канбан - отличный метод, позволяющий хорошо визуализировать и оптимизировать все процессы. В котором есть все те же роли, что и в скрам и примерно тот же набор событий (встреч).
Очень часто половина команд в рамках одной компании работает по канбан, а половина по скрам. Были даже попытки интеграции этих моделей)
А вот движение по водопадной структуре с связке с классическим управлением, в свое время у меня привело к очень большим издержкам. Что и послужило поиску альтернативных методов реализации проектов.
Agile-манифест читал, и не только его: книги, митапы. Плотно знакомился с вопросом, чтобы продуктивно спорить с scrum-сектантами.
За роли и события в kanban не согласен. Всё таки их существенно меньше. Но вот если kanban внедряет scrum-сектант, то получаются те же яйца,только в профиль.
Спасибо за продуктивный спор, интересно было послушать вашу точку зрения!
По ролям в скрам и канбан (без учета команды разработки), давайте посчитаем вместе:
* Scrum: Product Owner, Scrum master - итого 2;
* Kanban: Service Request Manager, Service Delivery Manager - итого 2;
Вроде ничья )
Спасибо за беседу, Артем! Да, было интересно )
Опять же это в вашем радужном мире теории. На практике в канбане нет Service Request Manager, Service Delivery Manager. А есть команда разработки и тимлид команды, который рулит созданием задач и приоритетами.
https://scrumtrek.ru/blog/kanban/5796/kanban-scrum-agile-otlichiya/
Обратите внимание на раздел "Разница с точки зрения предусловий"
Артем, есть Scrum, есть Kanban - выверенные и хорошо описанные фреймворки, в которых есть свои роли, их количество и определённые события.
Да, Kanban более эволюционный путь, чем Scrum. Позволяя наращивать функционал по чуть-чуть. И поэтому он вызывает меньше сопротивления.
Но то, что в вашей практике, вы ограничивались частичным использованием каких-то отдельных элементов, как например, только канбан-доски, вовсе не означает, что это предел его эффективности. Возможно, только в вашем случае, при определённом размере вашей команды и их количестве. Совмещение ролей тоже возможно до определенного этапа (у меня уже был негативный опыт совмещения ролей владельца продукта и скрам-мастера). Но при увеличении масштаба решаемых задач все упрощения сразу станут проявляться не самым лучшем образом.
Это как рассуждать по поводу правил дорожного движения: наличие светофора в населённом пункте из двух дорог тоже может показаться избыточным, но это не значит что на "практике" они не эффективны )
Проблемы мотивации команд и их решения в Scrum