В конечном счете, процесс Scrum лишает членов команды их соответствующих навыков?

Моя организация экспериментировала с внедрением более "гибких" методов. Мы очень долго пытаемся использовать подход Scrum, и большая часть команды, более или менее, адаптирована к нему. Мне нравится это в целом, но меня беспокоит одно потенциально серьезное влияние методологии: поскольку команды постоянно сосредоточены на функциях и отставаниях, а тестеры более интегрированы с общим процессом разработки, кажется, что наборы навыков становятся размыты, и люди чувствуют меньше уважения к своим индивидуальным способностям.

Некоторые из наших разработчиков превосходны на серверных технологиях и оптимизируют подготовку тяжелых грузов. Другие инвестировали большую часть своей карьеры, изучая технологии графического интерфейса пользователя, и разработали фундаментальное понимание пользователей и удобство использования в приложении. Ни умение не лучше другого, но они, безусловно, разные.

Является ли это неизбежным результатом процесса Scrum? Поскольку каждый в команде (как я понимаю) способствует удовлетворению следующей функции/требования, элементам отставания или проверке цели под рукой, основная философия, похоже, "кто-то может это сделать". Это, по моему опыту, просто неправда. Большинство инженеров (разработчиков, тестеров и т.д.) Имеют определенный набор навыков, которые они оттачивали на протяжении многих лет, а методология Scrum, на мой взгляд, имеет тенденцию девальвировать те самые способности, за которыми они ранее уважались.

Вот пример для пояснения:

Если при подготовке данных на стороне сервера происходит внезапное изменение технологии, и каждый элемент списка дел для спринта основан на этом новом изменении, разработчики графического интерфейса (которые, вероятно, не успели стать адаптированные с использованием новой технологии), возможно, не смогут внести свой вклад в спринт. По крайней мере, им нужно будет инвестировать время, чтобы ускориться, и тогда их код будет подозрительным из-за их отсутствия опыта.

Я понимаю необходимость быстрого развития, чтобы препятствовать "силосам роли", но не обесценивает одну фундаментальную реальность: люди развивают навыки в соответствии с необходимостью, интересами или опытом. Люди кажутся менее мотивированными, когда они понимают, что их позиция является одной из "плагинов" (например, мы можем "подключить" кого-либо к этой конкретной задаче). Как Scrum адресует это? Если это не так, кто-нибудь обратился к этому при принятии методологии Scrum?

Ответ 1

Точка Scrum предназначена для самоорганизации разработчиков. Мы используем scrum, где я есть, и задания пассивно сортируются в центре внимания человека. Мы не делаем это нарочно с диаграммой и списком, это просто происходит. Мы все знаем, кто лучше всего в чем, или каковы их основные/второстепенные фокусы. Если "основной" человек нуждается в помощи, он помогает человеку/людям со вторичным фокусом в этом помочь. У нас есть много задач, которые не обязательно соответствуют нашему конкретному фокусу, но вы всегда знаете, с кем обращаться за помощью.

В вашем примере - я не знаю, что если вы скажете, что у 3 реселлеров и 5 парней gui, вы ожидаете получить всю работу, выполненную в этом спринте (если ребята сервера + какая-то помощь от других было недостаточно). Способ, которым должен работать спринт, состоит в том, что из списка приоритетов разработчики выбирают то, что, по их мнению, они могут сделать в течение 30-дневного таймфрейма. Если это означало, что для пользователей GUI понадобилось 2 дня обучения на стороне сервера, чтобы помочь, что бы это значило. Если бы не были параллельные вещи, также высоко поднял список, который они могли бы сделать вместо этого. Задачи спринта не должны быть продиктованы руководством как истекающий срок.

Если у вас есть учетная запись Safari, есть интересная книга по изучению конкретных ситуаций одного из тех парней, которые изобрели скрипку.

Ответ 2

Короткий ответ - подчеркнутый НЕТ! Scrum не размывает или не обесценивает навыки, необходимые для специализации. Scrum не способствует обобщению.

Длинным ответом является то, что в Scrum самое главное - получить работу "Готово". Команда, как команда (в отличие от коллекции отдельных "звезд" ), при необходимости сотрудничает, чтобы выполнить свою работу. Что бы это ни стоило - но они хотят (Scrum - это самоуправление, самомотивирующиеся команды, верно?).

Это означает, что команда по сбору может состоять из нескольких специалистов, которые в основном выполняют то, что они специализируются (DBA, Graphic Design, даже технические писатели). Команда в целом должна обладать всеми навыками, необходимыми для выполнения требований. Это не то же самое, что сказать, что каждая команда должна иметь все вышеперечисленные навыки.

Это, как говорится, часто желательно - часто самими членами, - что члены, отличные от специалистов, по меньшей мере адекватны навыкам, отличным от их специальности. Еще один плакат уже упомянул Скотта Амблера "Общий специалист". Это помогает команде, когда слишком много работы одного вида, когда специалист отсутствует, и он помогает члену, когда он действительно хочет получить опыт за пределами своей специальности.

Учитывая, что команда самоорганизуется, если по какой-то причине специалист оказывается в середине спринта, без какой-либо работы по его специальности, лучший способ справиться с этим - просто спросить специалиста, что он хочет сделать. Пусть команда решит. Специалист может принять решение помочь в других областях адекватности, сделать POC для следующего спринта, "укрепить" оборону, зафиксировать какой-то давно забытый технический долг или осветить обувь членов, которые работают.

Угу. Я не знаю, если это длинный ответ . Но это был длинный ответ a. : -)

Ответ 3

Я работаю ScrumMaster около 18 месяцев и работал с двумя разными командами. Сначала я ожидал, что вы столкнетесь с потенциальными проблемами, которые вы поднимаете, но этого не произошло. То, что я обычно наблюдаю, состоит в том, что команда превращается в смесь специалистов и универсалов, поскольку люди находят себе подходящую роль - та, с которой они могут наслаждаться и быть успешными. Это самоорганизация на работе. У меня никогда не было случая, когда наши специалисты сидели без дела.

Если бы это произошло, я ожидал, что он будет поднят как проблема в Sprint Retrospective, и команда обсудит, как улучшить ситуацию. Наиболее очевидным (и жестоким) выводом было бы изменение состава команды.

Ответ 4

Я не уверен, почему набор навыков будет размытым. В гибком мире существует путаница. Scrum - это процесс управления проектами, а не процесс разработки программного обеспечения и не должен рассматриваться как один. Инженеры должны следовать своим собственным методологиям, таким как TDD или экстремальное программирование, чтобы добавить свою собственную часть в гибкую.

Ничего не происходит в схватке.

PM все еще документирует, когда они идут Архитекторы по-прежнему создают свои компоненты. Единственное, что они просто откладывают некоторые важные решения на более ответственный момент времени. Разработчики должны по-прежнему следовать лучшим методам, таким как SOLID принципы, чтобы обеспечить возможность рефакторинга в соответствии с изменениями функций.

Ответ 5

Я думаю, что Скотт Амблер очень подробно решает эту проблему в http://www.agilemodeling.com/essays/generalizingSpecialists.htm...

Его концепция специалиста по обобщению - это то, что требует коллективная собственность/команда Scrum, и имеет для меня общий смысл.

Его трудно достичь в реальной жизни, хотя; -)

Ответ 6

Если по какой-либо причине ( "внезапная смена технологии" или нет) вы обнаружите, что объем работы, требуемый для системы над спринтом, больше, чем доступная сумма, тогда возникает проблема с вашим расписанием.

Одно исправление заключается в том, что, как вы полагаете, вы берете программистов из других областей и бросаете их в микс. Насколько хорошо это работает, зависит от навыков этого человека и того, насколько отличается область проблем, но рассмотрение программистов как общих единиц, которые могут быть обработаны по мере необходимости, как правило, не является успешной стратегией разработки программного обеспечения.

Это все еще проблема планирования.

Ответ 7

Лучшее в Scrum - это то, что навыки немного размыты! Суть заключается в том, чтобы избегать силосов любой ценой, распространяя специальные знания в команде и позволяя людям немного работать вне зоны комфорта.

Очевидно, это не для всех. Некоторые разработчики довольны своей собственной узкой сферой специализации, и такие люди больше мешают процессу Scrum, чем актив, в то время как хорошо продуманные и талантливые люди, которые полны решимости выполнить свою работу, обычно очень хорошо адаптируются к он и намного более продуктивен.

Одним из ключевых преимуществ Scrum является привлечение всей команды и инвестиции в проект вместо того, чтобы решать свои собственные специальные задачи, а затем ехать на горизонте. Я бы сказал, что для большинства людей это гораздо более полезный способ работы, чем конвейерная лента - подход к водопадным процессам.

Поэтому я бы посоветовал смело принять смешение навыков и собрать людей, чтобы снять неприятные проблемы вместо того, чтобы полагаться на специализированные силосы. Результат команд, состоящих из мотивированных людей, может быть неожиданным.

Ответ 8

Похоже, это приведет к более продуманным разработчикам, а также позволит тем, кто является экспертами в определенных областях, продолжать вносить свой вклад.

Я еще не использовал Scrum сам (пока), но из вашего описания эти типы команд приведут к команде/организации, которая также будет более округлой в целом - и это не должно быть целью любой команды?

Ответ 9

Обработка внезапных изменений является частью Agile, и это может означать, что некоторые люди должны уйти и изучить новые навыки. Конечно, это больше в общей философии Agile, чем в любом Scrum-специфическом. Могут быть некоторые крайние случаи, когда заказчик или бизнес решают изменить мир, внося что-то новое и, следовательно, должны справиться с последующей болью этих людей, но если это то, что они хотят, а разработчики отменяются, то есть только несколько вариантов: (Возьми свои комки и попытайтесь справиться с основными изменениями) или (бросьте и уходите оттуда).

Хотя могут быть случаи, когда кто-то, кто специализировался во что-то, может делать что-то быстрее, это не обязательно означает много, если это всего лишь один человек в команде, который является экспертом, и есть достаточно работы в этот район для 10 человек на весь спринт. Должны ли те, кто не эксперт, просто не выполнять эту работу и позволить одному человеку попытаться пройти столько, сколько он может? Я так не думаю, но должно быть что-то сказать для тех, кто не лучший из того, что все еще пытается сделать то, что они могут сделать.