Мы команда из 3 человек. Мы адаптируем методологию scrum.
Все основано на канбане (трелло), где мы делаем ежедневные ретроспективы и планирование спринтов (задачи прогнозируются по рабочим часам).
Дело в том, что у меня есть быстрый разработчик и медленный разработчик. Быстрому разработчику всегда нужно «наверстывать» медленного. Я могу заметить медленного, потому что нахожусь в офисе, но, конечно, когда мы станем больше, его будет трудно заметить. Мы хотим выявлять медленных разработчиков, чтобы совершенствоваться и принимать меры. Как мы можем сделать это методом схватки?
Прочитайте этот ответ с энтузиазмом и открытым сердцем :)
Я отвечу на вопрос «как сделать так, чтобы разработчики озвучивали медленных разработчиков -или. В общем, любая проблема — «вместо «как обнаружить медленных разработчиков», поскольку я думаю, что это не основная проблема.
В двух словах способ сделать это:
Основная причина моего предложения заключается в том, что я думаю, что в долгосрочной перспективе это принесет гораздо больше пользы вашей команде. Вторая причина заключается в том, что я думаю, что гораздо проще обнаружить проблемы, убедившись, что вы работаете с людьми, которые будут активно работать над проблемами и решениями, чем путем использования метрик, KPI или общих механических систем для оценки производительности (это может обнаруживать только то, для чего они созданы, а не новые проблемы, возникающие в результате «человеческих» проблем).
И последнее замечание: убедитесь, что ретроспективы проводятся правильно. Этот конкретный вопрос с «медленным разработчиком» должен был подниматься на ретроспективах, и вы должны были говорить об этом открыто и прозрачно со своими коллегами.
Я предлагаю вам взглянуть на одну из моих любимых книг, в которой много рассказывается о работе в безопасных условиях и о том, как повысить производительность: Creativity Inc.
Я согласен с другими ответами здесь о более медленном человеке. Но почему другой человек быстрее?
Однажды в моей Скрам-команде был кто-то, кто был намного быстрее, чем кто-либо другой:
Да, они были ужасным командным игроком. В конце концов мы поняли, что нам не нужна та скорость, которую они предлагали.
Тот факт, что разработчик работает медленно, не означает, что он нуждается в улучшении.
Я являюсь и уже несколько лет остаюсь одним из наименее продуктивных членов команды разработчиков, в которой я работаю. Почему? Поскольку я руководитель группы, у меня есть много других обязанностей, включая наставничество, обучение, общение с заинтересованными сторонами, помощь в решении текущих вопросов и развитие сообщества компании. Ничего из этого не отображается на нашей канбан-доске.
Во-вторых, в конце проекта единственная скорость, которая действительно имеет значение, — это скорость вашей команды . Ваш «медленный разработчик» может работать за кулисами, чтобы помочь команде, и, как указывает @OneDayWhen, ваш «быстрый разработчик» может сидеть в бункере и накапливать знания. Возможно, они пропускают модульное тестирование, которое добросовестно делает ваш «медленный разработчик».
Вы спросили, какова реакция Scrum на это. Ответ заключается в том, чтобы использовать свои ежедневные стендапы, чтобы сосредоточиться на задачах. Ваша доска содержит все задачи, которые, по мнению вашей команды, должны быть выполнены для достижения цели спринта. Если вы хотите сделать это, то все задачи должны быть выполнены.
Если задача/история/функция/ошибка отстает и выглядит так, будто находится под угрозой, поднимите ее на стендапе. Это может быть связано с тем, что ваш «медленный разработчик» отвлекся или у него проблемы с этим. Это также может быть связано с тем, что кто-то заболел или был вызван на живое происшествие.
Как член скрам-команды, не беспокойтесь о личной эффективности, это работа менеджера, и она должна решаться в формате 1:1. Как мастер схватки, посмотрите на задачи, которые находятся под угрозой, и спросите команду, что можно сделать, чтобы наверстать упущенное.
Надеюсь, это очевидно, но скорость выполнения задания — не единственный критерий, по которому вы хотели бы оценивать практикующего. Во многих случаях скорость может даже не учитываться.
Также интересно, что OP указывает только на крайние значения производительности: высокий, низкий.
За исключением очень маленьких команд, для средних и крупных команд такой дихотомии не существует.
Я думаю, что при оценке вашей команды нужно понимать три аспекта: 1) используемые критерии; 2) распределение производительности; и 3) динамика наличия различных сильных и слабых сторон, которые в совокупности создают высокоэффективную команду.
1: Слишком часто мы сужаем определение высокой производительности до одного или двух критериев, сводя к минимуму или игнорируя другие показатели, как и в этом вопросе OP. Слишком узкое внимание к одному критерию за счет других приведет к тому, что ярлык высокой эффективности будет присвоен посредственному исполнителю.
2: Как на самом деле выглядит распределение производительности в любой команде в любой области? Нормально распределяется? Перекос? Самое распространенное мнение состоит в том, что производительность сильно искажается в положительную сторону , когда большая часть вашей команды посредственна, и очень немногие — сверхэффективны. Так что, возможно, в действительности, при условии, что ваши критерии верны, вы на самом деле идентифицируете только тех гипер-эффективников, которые могут просто выделиться.
3) Если вы смотрите на свою команду только в одном измерении, вы можете легко упустить из виду другие сильные стороны, которые существуют у человека, который может показаться посредственным по вашим критериям, но чья ценность способствует общей работе команды. Медленный исполнитель, рассматривающий только скорость как критерий, может предложить высокую степень точности в своей работе, которая может быть использована с точки зрения командной работы для обеспечения качества командного процесса. Таким образом, подготовка такого человека к этой конкретной командной роли повысит общую производительность команды, что гораздо важнее, чем производительность отдельного человека. И помните концепцию Эффекта Аполлона .
В моей практике я не беспокоюсь о том, чтобы смотреть на человека как такового. Я ищу ключевые сильные стороны, которые можно использовать, чтобы выполнить требования команды и помочь команде развиваться целостно с этими ролями. Гипер-исполнители редки и просто проявятся со временем. Экстремальные и довольно редкие низкоэффективные игроки также будут проявлять себя и со временем естественным или неестественным образом будут исключены из команды. В целом, наиболее важной метрикой для измерения является производительность команды с исходным предположением, что ваша команда будет заполнена посредственными или средними исполнителями, говоря статически.
Прозрачность и коммуникация — основа Agile-практик, и при правильном подходе они очень хорошо масштабируются. Scrum основан на результатах команды и плохо работает, если вы структурируете процесс Scrum как соревнование или пытаетесь измерить индивидуальные достижения, а не спортивное мастерство или командную работу.
Я могу заметить медленного, потому что нахожусь в офисе, но, конечно, когда мы станем больше, его будет трудно заметить. Мы хотим выявлять медленных разработчиков, чтобы совершенствоваться и принимать меры. Как мы можем сделать это методом схватки?
Многие другие ответы затронули некоторые замечательные моменты, но я хочу здесь кое-что забить.
Agile в целом и Scrum в частности — это измерение способности команды создавать ценность для бизнеса. В кросс-функциональной команде часто будут люди с разным набором навыков, разными способностями и уровнями знаний. Хороший аджилист измеряет эффективность команды в целом с точки зрения ее способности создавать ценность, а не противопоставлять членов команды друг другу.
Как правило, вы хотите измерять результаты проекта, а не скорость выполнения отдельных задач. Вместо того, чтобы предполагать, что у вас кадровая проблема, изучите свои первоначальные предположения. Просить:
Если пункты 1-4 отвечают «да» и больше никто не поднимает вопрос, вполне вероятно, что вы преследуете какую-то ложную экономию. Измеряйте правильные вещи, убедитесь, что у вас есть эффективный процесс, и постоянно получайте честную обратную связь от своей команды и заинтересованных сторон.
Традиционно у вас должен быть DevLead, который отвечает за выявление низкоэффективных сотрудников, делая это естественно, просто наблюдая, как быстро закрываются задачи.
Кстати, низкая производительность - это проблема? Если человек выполняет задачи в два раза медленнее и получает в два раза меньшую зарплату, то вроде все нормально, правда?..
В скраме в идеале должна быть самоорганизующаяся команда, где люди должны оценивать друг друга. И если низкоэффективные сотрудники снижают скорость команды, качество или что-то в этом роде и получают слишком много денег, тогда команда их поднимет — никто не хочет работать с низкоэффективными. Но если это просто вопрос разного уровня квалификации и опыта, то это должно компенсироваться более низкими зарплатами, и они должны научиться делать то, что нужно для ее повышения.
Если это не компенсируется зарплатой, то вы должны спросить у своей команды: нам нужно завершить проект к определенному сроку. Если парень продвигает нас вперед, даже с низкой скоростью, и нет другого человека, которого можно было бы нанять, то это может быть лучше, чем срыв сроков поставки.
Кажется, вы уже определили «медленного» разработчика. Ваша команда должна иметь систему контроля версий и отслеживать работу, включая невыполненную работу; большая часть вашей озабоченности может быть решена ежедневным просмотром завершенных функций или данных постфактум.
Выявление медленных разработчиков — это либо проблема с производительностью, когда человек недостаточно квалифицирован в инструментах и задачах разработчика, и вам следует найти нового разработчика или дать ему время на обучение, чтобы помочь им в улучшении, либо ссылка на «медленных разработчиков» является неправильное направление, и вы должны учитывать, что руководство просит разработчика выполнить задачи, и это управление терпит неудачу.
Приблизительные оценки по порядку величины являются полезным инструментом мозгового штурма при попытке оценить общие усилия одного и того же человека, которые схожи по объему и технологиям, могут помочь в совершенствовании набора навыков разработчиков, которые управляют, но не всегда полезны для итоговой прибыли. Если ваш «медленный» разработчик занимается управлением, планированием, планированием и постановкой в очередь работы, то он не развивается.
Вам может быть полезно прочитать и поделиться со своей командой «От худшего к лучшему за 9 месяцев: внедрение решения барабан-буфер-веревка в ИТ-отделе Microsoft» .
Поскольку это находится в стеке управления проектами, обратите внимание, что ваша слабо определенная проблема не относится к Agile (Scrum), управление проектами в программном обеспечении, как правило, можно сказать, что члены команды завершают работу в течение определенного периода времени. Научиться оценивать время до завершения — это навык. Будь то разработчик, оценивающий, сколько времени займет внедрение новой функции, или руководитель проекта, чтобы определить, соответствует ли количество человеко-часов в рамках бюджета.
Руководители проектов обычно не являются менеджерами по персоналу или супервайзерами. Если основное внимание уделяется предоставлению функций отдельным лицом или субподрядчиком, это может повлиять на график и стоимость проекта. Если основное внимание уделяется производительности человека, это кадровый вопрос, который следует рассматривать в контексте описания должности и ожиданий в контракте о найме, а также способность документировать, когда ожидания не оправдываются, чтобы позволить им улучшить или заменить их. для достижения результатов в рамках бюджета и временных ограничений.
Простые измерения количества функций, реализованных независимо друг от друга в каждом спринте, возможно, с атрибутами сложности (например, в баллах), могут показать вам скорость. Требуется контекст, чтобы знать, что это «медленно» или приемлемо для общих планов проекта.
Эрик