Артем, говоря о неправильном применении, я совершенно не пытаюсь снять ответственность с тех, кто должен заниматься правильной организацией всех скрам процессов. Как раз наоборот!
И чтобы из скарма не получился карго-скрам, как раз им и стоит внимательно учитывать все, что написано в Agile манифесте. Кстати, вы его читали? Мало какой разработчик будет не согласен с тем, что там написано.
Как и с тем, что автономия в работе и в принятии решений, осознание важности своего вклада и наличие обратной связи положительно сказывается на ее эффективности.
Кстати, ничего не имею против Канбан - отличный метод, позволяющий хорошо визуализировать и оптимизировать все процессы. В котором есть все те же роли, что и в скрам и примерно тот же набор событий (встреч). Очень часто половина команд в рамках одной компании работает по канбан, а половина по скрам. Были даже попытки интеграции этих моделей)
А вот движение по водопадной структуре с связке с классическим управлением, в свое время у меня привело к очень большим издержкам. Что и послужило поиску альтернативных методов реализации проектов.
Scrum гайд - это всего 16 страниц текста. С точки зрения процессов он прост и понятен. Другой вопрос, как вы правильно заметили, его применение (внедрение) на практике. Если делать это топорно, пытаясь совмещать скрам с устоявшимся директивным менеджментом, тем самым снижать значимость вышеуказанных факторов, то ничего хорошего из этого естественно не выйдет. Но хочу подчеркнуть, что проблема здесь не в скраме, а именно в способах его применения.
Артем, как-то у вас все в кучу смешалось. Прежде всего Agile - это философия, которая как раз и идет вразрез с принципами классического менеджмента и директивного управления.
Поэтому в Scrum и нет такой роли, как продакт-менеджер. Есть владелец продукта, который осуществляет поставку входящих задач и скрам-мастер, задача которого не управлять командой, а помогать ей. В том числе и с соблюдением всех необходимых событий, которые и определяют те самые рамки (фреймы).
Ежедневные встречи как раз и должны занимать не более 15 минут, чтобы не отвлекать разработчиков от их работы без надобности. Так же основной смысл Agile и Scrum, в частности, в регулярной демонстрации именно продукта, а не графиков. Для того чтобы команда могла напрямую получить обратную связь от пользователей продукта.
Наверное, было бы неплохо, если вы расскажите о своем личном опыте. Исходя из которого вы судите о Scrum в целом. Возможно это внесет какую-то ясность.
Scrum и менеджмент - различные вещи с точки зрения подхода. Попытка совмещения приводит к "карго-скраму". Цель данного фреймворка именно в самостоятельной организации работы и принятия решений.
Другой вопрос, что команда, как коллектив, - это всегда набор различных мнений и "своих правил". Так что для эффективной работы команды (особенно на начальном этапе) необходимо принять определённые рамки (фреймы) в пределах которых и будет проходить процесс совместной деятельности.
Должен сказать, что мыслить бэклогами в части задач - весьма продуктивный способ мышления. То есть проблемы с каталогизацией и приоритизацией задач уже нет. Другой вопрос почему ваш темп не соответствует желаемому. Может стоит пойти путем WIP лимитов и не взваливать на себе слишком много? Здесь конечно требуется индивидуальный подход. В остальном вы правы: прокрастинация вызывает чувство вины, которая постепенно может привести к выгоранию и депрессии. Так что стоит отнестись к ней со всей серьёзностью
Мне кажется, что борьба с сопротивлением через глобальную смену деятельности выглядит слишком уж радикально. Прокрастинация - интересная область для изучения и уж точно ее нельзя отнести с псевдопсихологии (не путать с психиатрией). Перечень причин прокрастинации указанный в данной статье взят из работ Стила Пирса - канадского психолога, который проделал огромную работу в этой сфере. Его теория временной мотивации очень хорошо иллюстрирует какие факторы влияют на постоянное откладывание важных дел.
Во всем нужна мера и последовательность. Внедрение каких-либо изменений требует такого же тщательного продуманного подхода, как и написание кода. А кидание в крайности и хаотичность в решениях как раз и приводят к тому, что потом все инициативы направленные на улучшения воспринимаются, как очередная бредовая придумка от менеджмента.
По ролям в скрам и канбан (без учета команды разработки), давайте посчитаем вместе:
* Scrum: Product Owner, Scrum master - итого 2;
* Kanban: Service Request Manager, Service Delivery Manager - итого 2;
Вроде ничья )
Спасибо за беседу, Артем! Да, было интересно )
Артем, говоря о неправильном применении, я совершенно не пытаюсь снять ответственность с тех, кто должен заниматься правильной организацией всех скрам процессов. Как раз наоборот!
И чтобы из скарма не получился карго-скрам, как раз им и стоит внимательно учитывать все, что написано в Agile манифесте.
Кстати, вы его читали? Мало какой разработчик будет не согласен с тем, что там написано.
Как и с тем, что автономия в работе и в принятии решений, осознание важности своего вклада и наличие обратной связи положительно сказывается на ее эффективности.
Кстати, ничего не имею против Канбан - отличный метод, позволяющий хорошо визуализировать и оптимизировать все процессы. В котором есть все те же роли, что и в скрам и примерно тот же набор событий (встреч).
Очень часто половина команд в рамках одной компании работает по канбан, а половина по скрам. Были даже попытки интеграции этих моделей)
А вот движение по водопадной структуре с связке с классическим управлением, в свое время у меня привело к очень большим издержкам. Что и послужило поиску альтернативных методов реализации проектов.
Scrum гайд - это всего 16 страниц текста. С точки зрения процессов он прост и понятен. Другой вопрос, как вы правильно заметили, его применение (внедрение) на практике. Если делать это топорно, пытаясь совмещать скрам с устоявшимся директивным менеджментом, тем самым снижать значимость вышеуказанных факторов, то ничего хорошего из этого естественно не выйдет. Но хочу подчеркнуть, что проблема здесь не в скраме, а именно в способах его применения.
Артем, как-то у вас все в кучу смешалось. Прежде всего Agile - это философия, которая как раз и идет вразрез с принципами классического менеджмента и директивного управления.
Поэтому в Scrum и нет такой роли, как продакт-менеджер. Есть владелец продукта, который осуществляет поставку входящих задач и скрам-мастер, задача которого не управлять командой, а помогать ей. В том числе и с соблюдением всех необходимых событий, которые и определяют те самые рамки (фреймы).
Ежедневные встречи как раз и должны занимать не более 15 минут, чтобы не отвлекать разработчиков от их работы без надобности. Так же основной смысл Agile и Scrum, в частности, в регулярной демонстрации именно продукта, а не графиков. Для того чтобы команда могла напрямую получить обратную связь от пользователей продукта.
Наверное, было бы неплохо, если вы расскажите о своем личном опыте. Исходя из которого вы судите о Scrum в целом. Возможно это внесет какую-то ясность.
Анатолий, спасибо за статью! (утираю слезы смеха)
Scrum и менеджмент - различные вещи с точки зрения подхода. Попытка совмещения приводит к "карго-скраму". Цель данного фреймворка именно в самостоятельной организации работы и принятия решений.
Другой вопрос, что команда, как коллектив, - это всегда набор различных мнений и "своих правил". Так что для эффективной работы команды (особенно на начальном этапе) необходимо принять определённые рамки (фреймы) в пределах которых и будет проходить процесс совместной деятельности.
Буду рад, если вы поясните свою позицию )
Грамотное использование внешних стимулов - отдельный вид искусства! :)
Но все-таки это борьба с симптомами, без уделения внимания причинам
Должен сказать, что мыслить бэклогами в части задач - весьма продуктивный способ мышления. То есть проблемы с каталогизацией и приоритизацией задач уже нет. Другой вопрос почему ваш темп не соответствует желаемому. Может стоит пойти путем WIP лимитов и не взваливать на себе слишком много? Здесь конечно требуется индивидуальный подход. В остальном вы правы: прокрастинация вызывает чувство вины, которая постепенно может привести к выгоранию и депрессии. Так что стоит отнестись к ней со всей серьёзностью
Мне кажется, что борьба с сопротивлением через глобальную смену деятельности выглядит слишком уж радикально. Прокрастинация - интересная область для изучения и уж точно ее нельзя отнести с псевдопсихологии (не путать с психиатрией). Перечень причин прокрастинации указанный в данной статье взят из работ Стила Пирса - канадского психолога, который проделал огромную работу в этой сфере. Его теория временной мотивации очень хорошо иллюстрирует какие факторы влияют на постоянное откладывание важных дел.
Во всем нужна мера и последовательность. Внедрение каких-либо изменений требует такого же тщательного продуманного подхода, как и написание кода. А кидание в крайности и хаотичность в решениях как раз и приводят к тому, что потом все инициативы направленные на улучшения воспринимаются, как очередная бредовая придумка от менеджмента.