Поговорим о магии и единорогах SCRUM? 
Не секрет, что многие пытались внедрить SCRUM, но не у всех это получалось, и многие не понимают, откуда может взяться волшебство.
Давайте сразу договоримся, что единственным руководством по SCRUM является Скрам-руководства , она меняется и обновляется, поэтому советую регулярно ее перечитывать.
Данная серия статей не заменит прочтение руководства, а станет дополнением руководства с некоторыми личными дополнениями от автора.
И начнем пожалуй с того, что написано на последней странице мануала: Роли, события, артефакты и правила Скрама неизменны, и хотя реализация только частей Скрама возможна, результат не является Скрамом.
(Роли, события, артефакты и правила Scrum не изменяются.
И хотя реализация только частей Scrum возможна, результат не будет Scrum.) О чем это говорит мне, у которого уже мозоль на лбу от тех граблей, на которые мы наступили, после 4 преобразований в компании.
По поводу того - если мы хотим получить бензин А95, то, наверное, нужно строго соблюдать нормы производства, нагревать масло в ратификационной колонне до строго определенной температуры, улавливать пары на определенной высоте, добавлять компоненты не "на глазок", Но выполняй всё до последнего пункта, его мать! технологический процесс.
Чтобы конечный результат был А95, а не какой-то хлам, который испортит вашу машину.
Но почему? Почему же типичный (классический) менеджер, который вдруг решил внедрить SCRUM в своей компании, думает, что «технологического процесса» нет в его компании.
Люди у него другие, руки или ноги у них другие, код написан не там? И вообще, кажется, что все 30 лет эволюции подходов к управлению не имеют значения.
Есть миллион причин впервые из миллиона изобрести свой велосипед, а потом с гордостью написать о нем на Хабре или даже написать о своем книгу.
Популяризируя ту «бодягу», через боль и слезы разработчиков разрушили устоявшийся классический процесс, с которым компания жила десятилетиями до этого, и в итоге ничего не получилось.
//SCRUM — это просто для понимания
Вот что я имею в виду.Что может быть проще, чем SCRUM: займитесь планированием, потратьте пять минут утром, а через 2 недели соберите всех, позвольте им показать вам результат (он обычно никому уже не нужен), и с тоской ждите продукта, который принесет деньги, радость.
и гордость всем! Только? Давайте реализуем, скажут менеджеры! На этот «крючок» обычно попадаются молодые и неопытные люди, ведь опытные (читатели) уже знают, что все не так просто.
//SCRUM — это сложно освоить
Знаете ли вы, что спрятали Джефф и Кен на этих 19 страницах руководства? Одна простая истина – Чем больше менеджер/руководитель/начальник «перезаботится» о своей команде, тем хуже самоорганизация команды, тем хуже результат ее работы.Всем известно, что плохой менеджер (с которым команда деградирует) – это:
- не могу делегировать
- сам распределяет работу, сам принимает результат
- контролирует ежедневно
- требует постоянной подготовки отчетов, документации, заполнения табелей учета рабочего времени (графиков присутствия)
- не доверяет команде
- навязывает свои решения
С помощью этой команды это обязательно сотворит плохую магию:
- команда теряет способность мыслить.
(Вы менеджер, хватит тут философствовать, а просто скажите, что делать)
- команда работает над задачами, а не над результатом, иногда «имитируя» активную деятельность.
(Выполняем задачу 1, задачу 2, задачу 3, но прод упал, пусть админы/разработчики разбираются.
)
- команда занята написанием отчетов, документированием, но не работой.
(Отчеты пишу полдня в понедельник и пятницу, но задач не выполняю.
)
- команда сопротивляется любым нововведениям.
(Что за автотесты? Дайте мне на это задание.
)
Нужны доказательства? Держите все в соответствии с Scrum Guide:
Стендап, только для команды разработчиков!
Каждый Scrum-мастер знает, что как только приходит «менеджер», даже «наш друг» Product Owner, стендап моментально превращается в «отчет о состоянии».Команда больше не будет обсуждать, что им следует сделать для достижения целей спринта, а вдруг начнет «танцевать перед начальником» и рассказывать им, что я сделал и какой я молодец, во всех подробностях.
И поверьте, это сразу занимает гораздо больше, чем 15 минут, и самое печальное, что это абсолютно бесполезная трата времени для всех членов команды.
В гайде не зря написано так - Ежедневный Scrum — это внутреннее собрание команды разработчиков.
Если присутствуют другие люди, Скрам-мастер гарантирует, что они не сорвут встречу.
(Ежедневный Скрам — это внутреннее собрание Команды Разработки.
Если присутствует кто-то еще, Скрам-мастер следит, чтобы он не мешал встрече) Но бывшие менеджеры, которые в новом процессе обычно становятся владельцами продукта, ненавидят, когда их не приглашают на стендапы.
И первое, что ломают в технологическом процессе SCRUM, — это посещение всех стендапов, потому что «контроль превыше всего».
На встречи с командой выделяется не более 10% времени Владельца Продукта и не более минуты.
(имеются в виду те, на которых есть ПО, команда всегда может обратиться к ПО, если им это нужно) Потому что для 2-недельного спринта это строго регламентированные 3 встречи:
- максимум 4 часа на планирование спринта
- максимум 2 за обзор спринта
- и 1,5 часа спринта ретро
Остальные 90% времени команда работает над целью спринта.
(Задумывались ли вы, сколько на самом деле может кодировать ваша команда?) На самом деле, конечно, наш бывший «менеджер» этого не потерпит и разобьет весь этот «бардак» парой промежуточных отчетов и совещаний.
Команда должна реализовывать потребности клиента, а не личные цели Владельца Продукта.
Потому что нигде не написано, что Product Owner должен сам написать требования к продукту, а написано, что он должен расставить приоритеты и сделать их понятными для всех.
Хороший Scrum-мастер знает, что для обеспечения прозрачности необходимо обязательно приглашать клиентов User Story, для которых приоритетом являются встречи с командой.
Установите прямое общение с клиентом.
Потому что обещания, данные клиенту, ох как сильно мотивируют команду.
3 принципа SCRUM: прозрачность, исследование, адаптация Но какой здравомыслящий «менеджер» это позволит? Оказывается, эта «управленческая истина» ставится под сомнение, это шанс команды «переоговориться» и разрушить все планы карьерного роста и захвата вселенной.
Нет, SCRUM — это кошмар для классического менеджера и людей, привыкших жить в «процессах».
Вот почему они обычно пытаются сломать весь этот SCRUM-процесс, добавить больше контроля, меньше прозрачности и никакой адаптации или развития.
Подводя итог: лучший способ похоронить SCRUM — это назначить бывших проектов или собственных менеджеров владельцами продукта.
- ПО, а не менеджер.
- ПО должен быть человеком с уникальными способностями — видеть стекхолдера там, где его не видят другие.
- ОП должен понимать, где больше, а где меньше денег/ценностей и расставлять приоритеты.
- ПО должно быть в состоянии привлечь в команду заинтересованную сторону, где команда сама будет продавать свой продукт.
Пусть хорошие люди читают хорошие статьи :) Теги: #Управление продуктом #agile #команда разработчиков #scrum #продуктивность
-
Судо Для Windows Vista
19 Oct, 24 -
G.ho.st: Сетевая Ос Эмулирует Windows
19 Oct, 24 -
Пользователи Не Видят Баннеры
19 Oct, 24
