Comments 17
У нас как на последней картинке, но срам все равно не приживается.
Стало быть у вас уже следующее препятствие - люди)
Чтобы скрам заработал очень важно чтобы все участники команды горели (но не выгорали) целю сделать качественный продукт. Если в небольшом стартапе вполне возможно этого добиться создав стимул в виде доли в прибыли, то в более-менее крупном бизнесе затея чаще всего обречена на провал - оглушительный успех в лучшем случае обернется разовой выплатой бонусов, которые привязаны к окладу, а не к финансовому результату (но с другой стороны и при полном провале расходы лягут не на команду, а на компанию)
Да там целый вагон причин... У вас в чём боль?
В спринт успеваем половину, часто переносим задачи в следующий спринт, задачи пухнут, со временем или с ростом команды идет тренд на снижение velocity.
Ну дак, это неправильное планирование, а не проблема скрама. Не успеваете, но все равно берете столько же на следующий спринт? Вы, в таком случае, и по другой методологии не будете успевать. В скраме минимум бюрократии, надо лишь выделить фичи, распланировать и разбить на задачи. Зная задачи легко их сделать.
Либо уменьшать количество фичепоинтов на спринт, либо людей добавлять. Там вся идея в том, что команда постоянно подстраивается + ретроспектива должна выявлять причины "не успвания" и вводить коррективы
Мы уменьшаем, но все равно не успеваем.
Если люди делают задачи весь спринт, то когда им сидеть думать как разбить задачи на подзадачи? Аналитика не такая детерминированная задача - ее можно сделать и за день и за месяц, а спринт две недели.
Людей добавлять, к сожалению, не можем. Так то это происходит конечно, но медленней, чем хотелось бы. Там сразу другие проблемы появляются. Найм (когда собесы проводить? Если все заняты спринтом); онбоардинг (очень сильно влияет на вовлеченность в спринт одного человека); да и в целом закон Брукса про девять женщин.
Складывается ощущение, что для скрама надо человек 5-7 минимум - аналитиков, программистов, тестировщиков. А для микро команд в 1.5 программиста и 0.5 тестировщика это не работает.
Ну задачи надо планировать перед спринт ом и это делает обычно лидер. Иначе получается, вы не знаете что делать.
Лидер собственно только этим и заниматься должен, добить весь проект на мелкие задачи, чтобы их могли делать программисты любой квалификации.
Если у вас один человек или даже два все делают, то скрам вам не подходит.
У вас по сути процесса то и нет. Сел и делаю, как понимаю но в любом случае, даже если один делаешь, одну большую задачу, типа сделать. Все хорошо и красиво нужно разбивать на много мелких, которые можно сделать за день.
Вы же уходите домой бросив код на половине функции. Как минимум за день делается что то более менее завершенное. И вы понимали, что делали, значит можно распланировать такие задачи и на 2 недели вперёд.
На месяц уже сложно. А на короткий срок вполне возможно.
Проблема именно в постановке задач у вас и планировании
Стараемся планировать спринт перед спринтом - но из-за того что все заняты - это типа просто задачи перекинуть из одной папки в другую и немного подкорректировать оценку.
Лид - это кто? Кого вы имеете ввиду? Ведущий разработчик? Продукт овнер?
И вот да, сколько надо минимум людей чтоб скрам заработал?
Так вы сами пишите, что у вас каждый аналитик занят отдельным проектом. Из этого и надо исходить. Т.е. планерка должна быть по каждому проекту отдельно и только с людьми которые над ним и работают. В если у вас по 1 человеку из каждого отдела на проект, то и смысл в этой схеме?
Вы правы, схема может вводить в заблуждение, будто все работают над проектом одновременно. Я уточню этот момент.
Идея в том, что люди под проект «резервируются», но фактически они «распределены» по разным задачам, пока не придет их очередь. И здесь какие проблемы:
1 - Контекстный разрыв: Когда аналитику нужна помощь в декомпозиции или техническом решении прямо сейчас, разработчик отвечает: «Я занят на проекте Б». В итоге аналитик проектирует «в вакууме», а разработчик позже получает задачу, которую неудобно или невозможно реализовать. Даже если к задаче будет подключен, скажем, начальник отдела разработки, то сначала аналитик погрузит руководителя разработки в контекст и проблематику, а потом второй раз еще и разработчика.
2 - Про планерки: Представим период планирования в 4 недели. Если разработчику накидали задач из 5 разных проектов (5 дней на один, 7 на другой, 2 на третий и т.д.), он физически не может участвовать во всех планерках. Он либо не ходит на них вовсе, либо присутствует «мебелью», не фокусируясь и не вникая в обсуждаемые вопросы.
В итоге мы получаем не команду, а «аренду специалистов», которых подключают все же слишком поздно.
У нас отделы, но скрам прижился. Просто люди из отдела работают в разных проектах, где проводят скрамы лидеры по проектам.
Скрамы они по проектам, а не по отделам
тут чуть поспрашиваю ) Занятость участников на проекте у вас постоянная? Они не задействованы в других проектах, пока этот наш «разгоняется»?
И еще момент, тут получается у каждого сотрудника по 2 начальника: лидер проекта и начальник отдела. Тут конфликта не возникает? Например, когда у другого лидера проекта какие-то приоритетные приоритеты и начальник отдела принимает решение перекинуть часть ресурсов туда?
Да на время проекта в основном постоянная на проекте, но могут быть небольшие проекты, тогда сотрудник может в 2 или 3 участвовать. Но там и загрузка конечно не полная. За распределение ресурсов по проектам отвественный начальник отдела.
Каждый месяц есть так называем ресурс планниг там менджеры запрашивают ресурсы по проектам, и начальник отдела может выделить, а может нет. Все зависи от приоритета проекта. На приоритетные проекты всегда ресурсы выделяются. На не приоритетные по остаточному признаку.
Например, менеджер проекта запросил на приоритеный проект 4 человек, начальник отдела может снять прямо всех 4 с низкоприоритеного проекта и дать им. Но это все делается совместно со всеми менеджреами проекта на планировании ресурсами. Менеджер низкприоритетного проекта просто будет сдвигать график.
На месяц никаких движений ресурсов между проектами не будет и конфликтов тоже. А вот через месяц, снова планирование, там могут и приоритет поменять и меньше или больше ресурсов запросить.
Ну это условно, обычно конечно более длинный срок на выделение ресурсов, скажем пол года это 50% случаев.
Теперь структура виновата.
Да, возможно где-то и есть такое, что собирается отдел аналитиков, и каждый работает отдельно. Но это как раз редкость. Обычно все понимают правильно, что такое команда.
Для начала нужно понять, какую проблему решаем и потом, какой инструмент может помочь или наиболее эффективен для решения этой проблемы. А дальше самое сложное, если команда заинтересована решать проблему, то внедрение пройдет хорошо. А вот если нет, то будет сложно и не факт, что получится - тут либо как-то договориться, либо жёстко с контролем.
Отличный пример в статье о бесполезных ежедневных созвонах
Почему SCRUM не приживается? Главное препятствие — не люди, а структура