Обо мне написано в моем профиле. Я, выражая свои мысли, не прячусь за noname аватаром.
И для продолжения этого диалога мне бы все-таки хотелось, чтобы он держалась в конструктивном русле. И был более предметным. А то ваша манера вести диалог (со всей это религиозной примесью) больше напоминает крестовый поход, чем профессиональное мнение.
Отвечая на мой комментарий выше, вы, кажется, очень спешили, поэтому полностью проигнорировали его смысл. Давайте немного подрезюмирую, чтобы быть ближе к предмету диалога:
Scrum – это фреймоворк (не религия) организации деятельности команд для совместной их работы в условиях высокой неопределённости. В его основе лежит эмпиризм и деятельность кроссфункциональных команд (не более 10 человек), построенной на принципе самоорганизации.
Это подразумевает, что только сама команда решает, как ей делать ее работу и сама несет ответственность за результаты своей совместной деятельности.
Никто не навязывает команде решений по технической стороне реализации взятых задач. (только сами исполнители решают, как им делать их работу). Но команда может запросить экспертное мнение от узких специалистов или обратиться за поддержкой к техлидам по различим направлениям. Более того только сама команда определяет свою нагрузку на каждую итерацию, используя для этого эмпирические данные.
РО только определяет приоритетность тех или иных задач, основываясь на своих исследованиях, и помогает команде разораться в бизнесовой стороне вопроса. Для команды он скорее бизнес партнёр, с которым они также объединены одной целью.
Scrum мастер не руководит командой, а помогает ей в развитии самоорганизации и повышении качества внутренних и внешних коммуникаций. В Альфа банке роль командного Scrum мастера выполняет (совмещает) один из участников команды разработки.
Scrum – весьма сбалансированный инструмент, который однако не исключает интеграцию других практик. И является для них обёрткой (ну или коммуникационным каркасом). Но как и любой инструмент при не правильной эксплуатации, или поверхностном понимании, он может причинить больше вреда, чем пользы. Что в большинстве случаев и является причиной негатива.
Например, когда от Scrum берется только название событий (и формируется карго Scrum), но при этом команду лишают возможности самоорганизации. Процветает микроменеджмент. Или игнорируется суть итерационного инкрементного подхода.
Также стоит отметить, что Scrum применим не везде. Он, как и другие Agile фреймворки создавался в первую очередь для области разработки, так как она относится к среде с высокой неопределённость. И другие подходы, построенные на классических принципах организации труда сильно сказывались на итоговом качестве программных продуктов. Очень хорошо по этой теме написал Роберт Мартин («дядя Боб»). Кстати, так как он являлся инициатором встречи, на которой был подписан Agilе манифест, то его вопле можно назвать отцом Agile.
У каждого из нас свой профессиональный опыт. Я начинал, как инженер и потом перешел в управление. Мне приходилось работать в различных коллективах, с различными подходами к организации труда. В Agile я пришел уже достаточно зрелом возрасте, имея за спиной весьма солидный опыт работы в организациях, где процессы были построены на принципах классического менеджмента.
И по моему мнению, которое я и отразил в этой статье, принципы на которых построен Scrum (и которые раскрыты в Agilе манифесте) формируют рабочую среду с самым хорошим микроклиматом, и способствуют профессиональному развитию специалистов, вовлеченных в свою деятельность.
Как я уже писал много раз в этом странном диалоге: Scrum — это не религия, а инструмент. Его кто-то может любить, кто-то считать не удобным. Но, как и любой инструмент в разных руках он может либо причинить пользу, либо вред. И у него, как у каждого инструмента есть инструкция по эксплуатации. Если вы ее не читаете перед началом работ, то вероятность получения вреда резко возрастает.
Опять же не стоит ожидать, что какой-либо метод организации труда сразу решит все ваши проблемы. Ну и же винить только его во всех ваших бедах.
Вы пишите: "Вы сами недавно в другой ветке комментариев рассказывали про "уравнение труда", "коммандную организацию" и предпочитали их "иерархичному взаимодействию. В кейсе имеем как раз то, за что вы агитируете -- решения принимаются коммандно."
Поиск командного решение не равно «голосование». Да, команда должна сама решить, как она будет выполнять работу, учитывая при этом все вводные, наличие у кого-то в команде узкой экспертизы, например. И я уже приводил пример по этому поводу.
Ну и, кажется, вы неправильно прочитали мой комментарий. Я спрашивал вас: «Какой формат управления и организации труда для вас более приемлем?»
И судя по тому, что вы так усердно боритесь с фреймворком в основе которого лежит командное взаимодействие, а также уважение к экспертному мнению каждого участника команды, то вероятно вы предпочитаете более классические схемы: типа «я начальник – ты дурак». Меньшое зло «двух иерархичных систем»?)
С другой стороны дальше вы вроде пишите весьма правильные (с моей точки зрения) слова: «Для инженера ситуация "я принял неверные технические решения и из-за этого возникли пробемы" гораздо более предпочтительна ситуации "мне пришлось выполнять решения, навязанные мне посторонними людьми, с которыми я не согласен». Вроде это как раз в духе Scrum. Решения по реализации принимают сами исполнители.
И возможно, в вашем кейсе, если бы ситуация сложилась чуть по-другому, и позиция другого тимлида (или менеджера) была бы: оставляем все как есть. А команда настояла бы на другом (нормальном) решении, которое положительно бы сказалось на качестве. То сейчас вы был писали в кометах: «Scrum – сила»? )
Причина исключительно в вашей ужасной некомпетентности в данном вопросе и что habr пропускает такие материалы. Где явно виден подчерк нейросети. На мой взгляд это повод для блокировки.
Да, судя по вашим реакциям и тому, что вы пишите в комментариях, от Scrum вы взяли только названия событий (и листья для самолета).
Если паяльник держать не с той стороны, то его эксплуатация может вызывать сильную боль. Ну и, как следствие, желание потом писать про эту боль на Habr. Хотя вроде бы паяльник - это просто инструмент, созданный для определенных целей.
Пока мы не закопались еще глубже, хочу отметить, что в Scrum уделяется большая важность экспертному мнению и если команды испытывает в нем недостаток, то ей перед принятием каких-либо решений необходимо запросить доп.консультацию у специалистов. Ну и на практике, если команда оценивает какую-то задачу, то всегда учитывается мнение того, чей функционал является в ней ведущим, а не просто «большинством голосом». Да и вообще про «голосование» в Scrum гайде например нет ни слова. Без понятия откуда вы это берете.
Но давайте будем более предметными и последовательными. Правильно ли я понял из вашего ответа по кейсу, что если дать возможность: «фронтендщики принимают решения по фронтенду, бэкендщики -- по бэкенду» то в результате их деятельности через год никогда не будет тех проблем, о которых вы писали выше?
Ну склонность проводить параллели с религией как раз у тех, кто не за, а против)
Для меня Scrum – это надежный практический инструмент организации деятельности команд при работе в неопределенной среде. Он отлично сочетается с практиками Kanban, OKR, инженерными практиками XP (кстати принципы командой оценки в SP пришли к нам именно из XP).
А если все-таки заглянуть в Scrum гайд, то можно прочесть следующее: фреймворк позволяет применять различные процессы, техники и методы. Scrum служит оберткой для действующих практик, или подсвечивать их ненужность.
Но, к сожалению, хейтеры не любят читать про объект своих нападок, предпочитая экстраполировать свой субъективный опыт, основанный на весьма поверхностном знании предмета.
Есть такой термин, как карго-scrum, когда данный фреймворк рассматривается только как набор определенных событий, не углубляясь в его суть.
Но давайте все таки будем последовательными и выслушаем ваше мнение о том, как на сам деле (то есть правильно с вашей точки зрения) должно было бы все проходить в вашем кейсе, чтобы по итогу не получить "гневные суппорт-тикеты от пользвователей, эмерженси-фиксы и всё такое".
Честно говоря, меня немного пугает то, что вы сравниваете Scrum c религией. Давайте все-таки смотреть на вещи чуть проще.
Это просто инструмент, позволяющий решать сложные комплексные задачи за счет итерационного, инкрементного подхода. Основой которого являются самоорганизованые команды.
Для меня лично формат командного взаимодействия предпочтительней иерархичному. Поэтому я и задал вопрос, на который вы так и не ответили: что вы предлагаете на замену Scrum? Какой формат управления и организации труда для вас более приемлем?
Приведите практический пример, пожалуйста. Какой-нибудь реальный кейс по решению scrum командой задачи, когда «По ускоспециализированным вопросам неспециалисты переголосовывают специалистов -- просто берут числом, предпочитая менее удачные инженерные решения, которые потом приводят к переделыванию и исправлению ошибок».
Есть премии )) Но я имел ввиду другое: организовать производственный процесс и корпоративную культуру таким образом, чтобы разработчики не чувствовали себя изолированными винтиками или сотрудниками Макдональдс на линии, а могли вносить свой вклад, свои идеи, в развитие их продукта.
Чтобы ответить на эти вопросы, надо сперва понять, что вы пытаетесь противопоставить Scrum? Если не он, то что?
Если это другие Agilе фреймворки, то, например, в ХР сокращение цикла обратной связи – это один из базовых приемов. А Канбан стимулирует развитие культуры взаимопомощи и погружению в смежные компетенции.
Другой вопрос, что современный Scrum, являясь коммуникационным каркасом, который «помогает создавать ценность с помощью адаптивных решений комплексных проблем». И служит обёрткой для существующих практик, давно уже впитал в себя множество различных лучших решений от других фреймворков. Просто бери и пользуйся.
* И да, «если условный программист Вася ушёл в запой и не пришёл на работу, то отвечает тоже вся команда». За итоговый результат, не за Васю. Потом уже, на ретроспективе, команд сама решит по пути ей дальше с Васей или нет.
И поверьте мне (был у меня в практике очень похожий случай), если Вася получит свой второй шанс, то он будет, цитирую: «ночью если надо буду работать, чтобы только больше не подвести ребят». Ведь наша ответственность перед маленьким слаженным коллективом профессионалов больше, чем перед любым «начальником».
Хотя, как я уже писал: не все готовы принять этот вызов. И некотором действительно для работы необходим «строгий, но справедливый» босс, и четкие БТ)
Про дизайнеров скорее нет (по крайней мере в моих командах), а вот QA обязательно! Тестирование – это неотъемлемая часть процесса разработки, так же как и код ревью, например. Поэтому его объем и сложность обязательно должны быть учтены на этапе планирования и включены в оценку задачи. Но чтобы это сделать правильно, надо сперва разобраться в принципах работы с относительной системой оценивания. На Habr есть несколько очень грамотных статей по этому вопросу.
"тирания большинства -- страшная вещь". Вот серьёзно, не понимаю откуда вы это берете? Какая может быть "тирания" в небольшой группе компетентных специалистов различного профиля, объединенных общей целью?
По поводу работы на компанию - я согласен. Это одна из причин по которой стартапы работаю на скоростях, недоступных энтерпрайзу. Но одна из задач Scrum как и заключается в создании таких небольших команд - мини стартапов внутри большого энтерпрайза. Где общие командные цели не размываются, а четко коррелируют с личными достижениями.
Признание - это конечно мощный мотиватор, но он присутствует и в командной работе тоже. Например: профессиональное признание коллег, благодарность за помощь в достижении общего результата мотивируют не хужу публичности. Хотя и для этой цели в Альфе проводится множество различных конференций, где также можно широко заявить о себе, как о профессионале.
Далее по пунктам:
Я не согласен, что “случайно появившийся в команде Мастер” будет отвергнут командой. Практика показывает обратное: он начинает лидировать различные процессы. И Scrum для этого создает благотворную почву. И, да, у нас такой сотрудник получает всю необходимую поддержку. Так как мы в Альфе умеем ценить и компетентность и вовлеченность. А роль командного scrum-мастера у нас выполняет кто-то из команды разработки (аналитик, разработчик, QA).
Все заточено на то, чтобы развивать энтузиазм и давать расти Мастерам. И поверьте каждый сотрудник с таким типом мышления видит в другом Мастере не конкурента, а надежного партнера, разделяющего его ценности. А споры - это неотъемлемая часть творческого процесса. И их отсутствие - это как раз признак дисфункции команды.
Другой вопрос, что в небольшом сплоченном коллективе (численность команды в среднем 6-8 человек) они носят конструктивный характер и желание достичь общей цели, а “отстаивания своей правоты перед начальством”. Да и начальства у scrum команды как такового нет. Задача РО в определении того, что сейчас надо делать. А как и за сколько определяет только сама команда.
По поводу иерархии и разделения компетентности: какие еще голосования, в которых “наиболее компетентные будут оказываться в меньшинстве”? Где они (голосования) должны проводиться?
Разработка давно уже ушла от создание профильных команд (отдельно бэк, отделано фронт, отдельно QA) и специализированных отделов со строгой иерархией. *Как решались проблемы бесшовной программных продуктов отлично описал как раз дядя Боб.
Сейчас золотой стандарт - это кроссфункциональное команды (до 10 человек), объединяющие специалистов различных специализаций. Которые только совместными усилиями могут сделать что-то завершенное и ценное для бизнеса. И задача этих специалистов на планировании каждой итерацией четко сбиться кто, как и что будет делать по своему профилю, чтобы достичь этой цели. А для этого очень важно видеть целостность процесса и четко понимать те запросы, которые решает разрабатываемый функционал. О чем и написано в статье.
Артем, есть Scrum, есть Kanban - выверенные и хорошо описанные фреймворки, в которых есть свои роли, их количество и определённые события.
Да, Kanban более эволюционный путь, чем Scrum. Позволяя наращивать функционал по чуть-чуть. И поэтому он вызывает меньше сопротивления.
Но то, что в вашей практике, вы ограничивались частичным использованием каких-то отдельных элементов, как например, только канбан-доски, вовсе не означает, что это предел его эффективности. Возможно, только в вашем случае, при определённом размере вашей команды и их количестве. Совмещение ролей тоже возможно до определенного этапа (у меня уже был негативный опыт совмещения ролей владельца продукта и скрам-мастера). Но при увеличении масштаба решаемых задач все упрощения сразу станут проявляться не самым лучшем образом.
Это как рассуждать по поводу правил дорожного движения: наличие светофора в населённом пункте из двух дорог тоже может показаться избыточным, но это не значит что на "практике" они не эффективны )
Обо мне написано в моем профиле. Я, выражая свои мысли, не прячусь за noname аватаром.
И для продолжения этого диалога мне бы все-таки хотелось, чтобы он держалась в конструктивном русле. И был более предметным. А то ваша манера вести диалог (со всей это религиозной примесью) больше напоминает крестовый поход, чем профессиональное мнение.
Отвечая на мой комментарий выше, вы, кажется, очень спешили, поэтому полностью проигнорировали его смысл. Давайте немного подрезюмирую, чтобы быть ближе к предмету диалога:
Scrum – это фреймоворк (не религия) организации деятельности команд для совместной их работы в условиях высокой неопределённости. В его основе лежит эмпиризм и деятельность кроссфункциональных команд (не более 10 человек), построенной на принципе самоорганизации.
Это подразумевает, что только сама команда решает, как ей делать ее работу и сама несет ответственность за результаты своей совместной деятельности.
Никто не навязывает команде решений по технической стороне реализации взятых задач. (только сами исполнители решают, как им делать их работу). Но команда может запросить экспертное мнение от узких специалистов или обратиться за поддержкой к техлидам по различим направлениям. Более того только сама команда определяет свою нагрузку на каждую итерацию, используя для этого эмпирические данные.
РО только определяет приоритетность тех или иных задач, основываясь на своих исследованиях, и помогает команде разораться в бизнесовой стороне вопроса. Для команды он скорее бизнес партнёр, с которым они также объединены одной целью.
Scrum мастер не руководит командой, а помогает ей в развитии самоорганизации и повышении качества внутренних и внешних коммуникаций. В Альфа банке роль командного Scrum мастера выполняет (совмещает) один из участников команды разработки.
Scrum – весьма сбалансированный инструмент, который однако не исключает интеграцию других практик. И является для них обёрткой (ну или коммуникационным каркасом). Но как и любой инструмент при не правильной эксплуатации, или поверхностном понимании, он может причинить больше вреда, чем пользы. Что в большинстве случаев и является причиной негатива.
Например, когда от Scrum берется только название событий (и формируется карго Scrum), но при этом команду лишают возможности самоорганизации. Процветает микроменеджмент. Или игнорируется суть итерационного инкрементного подхода.
Также стоит отметить, что Scrum применим не везде. Он, как и другие Agile фреймворки создавался в первую очередь для области разработки, так как она относится к среде с высокой неопределённость. И другие подходы, построенные на классических принципах организации труда сильно сказывались на итоговом качестве программных продуктов. Очень хорошо по этой теме написал Роберт Мартин («дядя Боб»). Кстати, так как он являлся инициатором встречи, на которой был подписан Agilе манифест, то его вопле можно назвать отцом Agile.
У каждого из нас свой профессиональный опыт. Я начинал, как инженер и потом перешел в управление. Мне приходилось работать в различных коллективах, с различными подходами к организации труда. В Agile я пришел уже достаточно зрелом возрасте, имея за спиной весьма солидный опыт работы в организациях, где процессы были построены на принципах классического менеджмента.
И по моему мнению, которое я и отразил в этой статье, принципы на которых построен Scrum (и которые раскрыты в Agilе манифесте) формируют рабочую среду с самым хорошим микроклиматом, и способствуют профессиональному развитию специалистов, вовлеченных в свою деятельность.
У вас, как я понимая, было по другому
Как я уже писал много раз в этом странном диалоге: Scrum — это не религия, а инструмент. Его кто-то может любить, кто-то считать не удобным. Но, как и любой инструмент в разных руках он может либо причинить пользу, либо вред. И у него, как у каждого инструмента есть инструкция по эксплуатации. Если вы ее не читаете перед началом работ, то вероятность получения вреда резко возрастает.
Опять же не стоит ожидать, что какой-либо метод организации труда сразу решит все ваши проблемы. Ну и же винить только его во всех ваших бедах.
Вы пишите: "Вы сами недавно в другой ветке комментариев рассказывали про "уравнение труда", "коммандную организацию" и предпочитали их "иерархичному взаимодействию. В кейсе имеем как раз то, за что вы агитируете -- решения принимаются коммандно."
Поиск командного решение не равно «голосование». Да, команда должна сама решить, как она будет выполнять работу, учитывая при этом все вводные, наличие у кого-то в команде узкой экспертизы, например. И я уже приводил пример по этому поводу.
Ну и, кажется, вы неправильно прочитали мой комментарий. Я спрашивал вас: «Какой формат управления и организации труда для вас более приемлем?»
И судя по тому, что вы так усердно боритесь с фреймворком в основе которого лежит командное взаимодействие, а также уважение к экспертному мнению каждого участника команды, то вероятно вы предпочитаете более классические схемы: типа «я начальник – ты дурак». Меньшое зло «двух иерархичных систем»?)
С другой стороны дальше вы вроде пишите весьма правильные (с моей точки зрения) слова: «Для инженера ситуация "я принял неверные технические решения и из-за этого возникли пробемы" гораздо более предпочтительна ситуации "мне пришлось выполнять решения, навязанные мне посторонними людьми, с которыми я не согласен». Вроде это как раз в духе Scrum. Решения по реализации принимают сами исполнители.
И возможно, в вашем кейсе, если бы ситуация сложилась чуть по-другому, и позиция другого тимлида (или менеджера) была бы: оставляем все как есть. А команда настояла бы на другом (нормальном) решении, которое положительно бы сказалось на качестве. То сейчас вы был писали в кометах: «Scrum – сила»? )
.
Причина исключительно в вашей ужасной некомпетентности в данном вопросе и что habr пропускает такие материалы. Где явно виден подчерк нейросети. На мой взгляд это повод для блокировки.
Да, судя по вашим реакциям и тому, что вы пишите в комментариях, от Scrum вы взяли только названия событий (и листья для самолета).
Если паяльник держать не с той стороны, то его эксплуатация может вызывать сильную боль. Ну и, как следствие, желание потом писать про эту боль на Habr. Хотя вроде бы паяльник - это просто инструмент, созданный для определенных целей.
Пока мы не закопались еще глубже, хочу отметить, что в Scrum уделяется большая важность экспертному мнению и если команды испытывает в нем недостаток, то ей перед принятием каких-либо решений необходимо запросить доп.консультацию у специалистов. Ну и на практике, если команда оценивает какую-то задачу, то всегда учитывается мнение того, чей функционал является в ней ведущим, а не просто «большинством голосом». Да и вообще про «голосование» в Scrum гайде например нет ни слова. Без понятия откуда вы это берете.
Но давайте будем более предметными и последовательными. Правильно ли я понял из вашего ответа по кейсу, что если дать возможность: «фронтендщики принимают решения по фронтенду, бэкендщики -- по бэкенду» то в результате их деятельности через год никогда не будет тех проблем, о которых вы писали выше?
Ну склонность проводить параллели с религией как раз у тех, кто не за, а против)
Для меня Scrum – это надежный практический инструмент организации деятельности команд при работе в неопределенной среде. Он отлично сочетается с практиками Kanban, OKR, инженерными практиками XP (кстати принципы командой оценки в SP пришли к нам именно из XP).
А если все-таки заглянуть в Scrum гайд, то можно прочесть следующее: фреймворк позволяет применять различные процессы, техники и методы. Scrum служит оберткой для действующих практик, или подсвечивать их ненужность.
Но, к сожалению, хейтеры не любят читать про объект своих нападок, предпочитая экстраполировать свой субъективный опыт, основанный на весьма поверхностном знании предмета.
Есть такой термин, как карго-scrum, когда данный фреймворк рассматривается только как набор определенных событий, не углубляясь в его суть.
Но давайте все таки будем последовательными и выслушаем ваше мнение о том, как на сам деле (то есть правильно с вашей точки зрения) должно было бы все проходить в вашем кейсе, чтобы по итогу не получить "гневные суппорт-тикеты от пользвователей, эмерженси-фиксы и всё такое".
Ок, а как по вашем должно было бы все проходить?
Ужасно не компетентно. Но подчерк узнаваем. Скажите честно, промт был типа: "напиши 10 причин почему Kanban лучше Scrum "?
Честно говоря, меня немного пугает то, что вы сравниваете Scrum c религией. Давайте все-таки смотреть на вещи чуть проще.
Это просто инструмент, позволяющий решать сложные комплексные задачи за счет итерационного, инкрементного подхода. Основой которого являются самоорганизованые команды.
Для меня лично формат командного взаимодействия предпочтительней иерархичному. Поэтому я и задал вопрос, на который вы так и не ответили: что вы предлагаете на замену Scrum? Какой формат управления и организации труда для вас более приемлем?
Приведите практический пример, пожалуйста. Какой-нибудь реальный кейс по решению scrum командой задачи, когда «По ускоспециализированным вопросам неспециалисты переголосовывают специалистов -- просто берут числом, предпочитая менее удачные инженерные решения, которые потом приводят к переделыванию и исправлению ошибок».
Есть премии )) Но я имел ввиду другое: организовать производственный процесс и корпоративную культуру таким образом, чтобы разработчики не чувствовали себя изолированными винтиками или сотрудниками Макдональдс на линии, а могли вносить свой вклад, свои идеи, в развитие их продукта.
Нет, просто у нас действительно ценится компетентность и вовлеченность. Или вы думаете, что этот пункт должен быть закрыт NDA ? :)
Прикольно ))
Чтобы ответить на эти вопросы, надо сперва понять, что вы пытаетесь противопоставить Scrum? Если не он, то что?
Если это другие Agilе фреймворки, то, например, в ХР сокращение цикла обратной связи – это один из базовых приемов. А Канбан стимулирует развитие культуры взаимопомощи и погружению в смежные компетенции.
Другой вопрос, что современный Scrum, являясь коммуникационным каркасом, который «помогает создавать ценность с помощью адаптивных решений комплексных проблем». И служит обёрткой для существующих практик, давно уже впитал в себя множество различных лучших решений от других фреймворков. Просто бери и пользуйся.
*
И да, «если условный программист Вася ушёл в запой и не пришёл на работу, то отвечает тоже вся команда». За итоговый результат, не за Васю. Потом уже, на ретроспективе, команд сама решит по пути ей дальше с Васей или нет.
И поверьте мне (был у меня в практике очень похожий случай), если Вася получит свой второй шанс, то он будет, цитирую: «ночью если надо буду работать, чтобы только больше не подвести ребят». Ведь наша ответственность перед маленьким слаженным коллективом профессионалов больше, чем перед любым «начальником».
Хотя, как я уже писал: не все готовы принять этот вызов. И некотором действительно для работы необходим «строгий, но справедливый» босс, и четкие БТ)
Про дизайнеров скорее нет (по крайней мере в моих командах), а вот QA обязательно! Тестирование – это неотъемлемая часть процесса разработки, так же как и код ревью, например. Поэтому его объем и сложность обязательно должны быть учтены на этапе планирования и включены в оценку задачи.
Но чтобы это сделать правильно, надо сперва разобраться в принципах работы с относительной системой оценивания. На Habr есть несколько очень грамотных статей по этому вопросу.
"тирания большинства -- страшная вещь". Вот серьёзно, не понимаю откуда вы это берете? Какая может быть "тирания" в небольшой группе компетентных специалистов различного профиля, объединенных общей целью?
По поводу работы на компанию - я согласен. Это одна из причин по которой стартапы работаю на скоростях, недоступных энтерпрайзу. Но одна из задач Scrum как и заключается в создании таких небольших команд - мини стартапов внутри большого энтерпрайза. Где общие командные цели не размываются, а четко коррелируют с личными достижениями.
Признание - это конечно мощный мотиватор, но он присутствует и в командной работе тоже. Например: профессиональное признание коллег, благодарность за помощь в достижении общего результата мотивируют не хужу публичности. Хотя и для этой цели в Альфе проводится множество различных конференций, где также можно широко заявить о себе, как о профессионале.
Далее по пунктам:
Я не согласен, что “случайно появившийся в команде Мастер” будет отвергнут командой. Практика показывает обратное: он начинает лидировать различные процессы. И Scrum для этого создает благотворную почву. И, да, у нас такой сотрудник получает всю необходимую поддержку. Так как мы в Альфе умеем ценить и компетентность и вовлеченность. А роль командного scrum-мастера у нас выполняет кто-то из команды разработки (аналитик, разработчик, QA).
Все заточено на то, чтобы развивать энтузиазм и давать расти Мастерам. И поверьте каждый сотрудник с таким типом мышления видит в другом Мастере не конкурента, а надежного партнера, разделяющего его ценности. А споры - это неотъемлемая часть творческого процесса. И их отсутствие - это как раз признак дисфункции команды.
Другой вопрос, что в небольшом сплоченном коллективе (численность команды в среднем 6-8 человек) они носят конструктивный характер и желание достичь общей цели, а “отстаивания своей правоты перед начальством”. Да и начальства у scrum команды как такового нет. Задача РО в определении того, что сейчас надо делать. А как и за сколько определяет только сама команда.
По поводу иерархии и разделения компетентности: какие еще голосования, в которых “наиболее компетентные будут оказываться в меньшинстве”? Где они (голосования) должны проводиться?
Разработка давно уже ушла от создание профильных команд (отдельно бэк, отделано фронт, отдельно QA) и специализированных отделов со строгой иерархией.
*Как решались проблемы бесшовной программных продуктов отлично описал как раз дядя Боб.
Сейчас золотой стандарт - это кроссфункциональное команды (до 10 человек), объединяющие специалистов различных специализаций. Которые только совместными усилиями могут сделать что-то завершенное и ценное для бизнеса. И задача этих специалистов на планировании каждой итерацией четко сбиться кто, как и что будет делать по своему профилю, чтобы достичь этой цели. А для этого очень важно видеть целостность процесса и четко понимать те запросы, которые решает разрабатываемый функционал. О чем и написано в статье.
Артем, есть Scrum, есть Kanban - выверенные и хорошо описанные фреймворки, в которых есть свои роли, их количество и определённые события.
Да, Kanban более эволюционный путь, чем Scrum. Позволяя наращивать функционал по чуть-чуть. И поэтому он вызывает меньше сопротивления.
Но то, что в вашей практике, вы ограничивались частичным использованием каких-то отдельных элементов, как например, только канбан-доски, вовсе не означает, что это предел его эффективности. Возможно, только в вашем случае, при определённом размере вашей команды и их количестве. Совмещение ролей тоже возможно до определенного этапа (у меня уже был негативный опыт совмещения ролей владельца продукта и скрам-мастера). Но при увеличении масштаба решаемых задач все упрощения сразу станут проявляться не самым лучшем образом.
Это как рассуждать по поводу правил дорожного движения: наличие светофора в населённом пункте из двух дорог тоже может показаться избыточным, но это не значит что на "практике" они не эффективны )