Кто-нибудь когда-либо пытался ассимилировать Scrum команде, где большинство разработчиков просто посредственно? Я имею в виду, что разработчики, которые не являются самыми техничными специалистами, имеют плохие навыки управления временем, но, прежде всего, испытывают чувство личной ответственности и приверженности.
Как вы думаете, это может сработать? Или вы бы попробовали другую методологию?
Я реализовал Scrum с такой командой.
Потребовалось несколько итераций для их выхода на борт, но они обнаружили, что Scrum сделал их лучшими разработчиками. Они оценили способность влиять на процесс. На каждой итерационной ретроспективе мы исследовали факторы успеха и проблемы, и в качестве команды мы работали над устранением барьеров, возникших в результате задач.
В этом году ежегодный ужин, посвященный узнаванию сотрудников, моя команда назначила меня на награду за достижения: не за мои достижения, а за достижения, которые команда смогла достичь в результате перехода на Scrum.
Слишком много команд избиты и демонизированы, потому что в этом процессе не говорят. Отсутствие личной ответственности и обязательств может стать артефактом текущего процесса разработки, и Scrum может помочь вашей команде преодолеть это.
Отказ от ответственности Agile Manifesto говорит по вашему вопросу. В первом пункте:
"Физические лица и взаимодействия над процессами и инструментами"
Я думаю, что если у людей есть проблемы, тогда методология бесполезна.
У меня была "привилегия" работы с менее оптимальными командами с использованием подобной Scrum методологии и оказалась более успешной, чем традиционная методология водопада была бы с теми же людьми по следующим причинам:
работа выполнена (и прогресс измеряется) в небольших кусках, поэтому, если ваша команда испортит или пропустит крайний срок, вы знаете раньше и можете быстрее скорректировать. это также легче удержать людей, ответственных за проблемы с однодневными рабочими элементами или месячными отвращениями.
Scrum имеет более высокое ожидание прозрачности внутри команды, поэтому, если что-то пойдет не так (как это определенно будет с недостаточной и/или недооцененной командой), вы с легкостью обнаружите проблемы. В традиционной методологии водопада более приемлемым для разработчиков "неделями" в течение нескольких недель - и с плохой командой это самое худшее, что может произойти.
Разработчики, обладающие хорошими базовыми навыками, но неаккуратные и/или не мотивированные, могут особенно выиграть от Scrum high-touch, инкрементного подхода.
Ежедневные ожидания означают, что каждый член команды должен хотя бы появляться на работе каждый день и придумывать что-то сказать, что они делали. Это может увеличить мотивацию для некоторых разработчиков, которые могут лениться или отвлекаться, но которые также не хотят смущаться перед своими сверстниками. И standups обеспечивает как минимум минимальный барьер прозрачности и подотчетности, не преследуя ворчащих членов команды за письменные отчеты о состоянии.
Scrum также имеет более высокое ожидание прозрачности вне команды (владельцы бизнеса и т.д.), поэтому есть больше возможностей для большего количества людей видеть, насколько плоха ваша команда разработчиков, и, следовательно, вы, скорее всего, получите поддержка вашей компании для обновления вашей команды.
Если у вас есть сочетание хороших и менее хороших разработчиков в вашей команде, Scrum (с более высокими ожиданиями прозрачности и меньшими ожиданиями индивидуальной собственности без обратной связи) облегчает для хороших разработчиков поддержку команды на ходу.
Обратите внимание, что я согласен с другими ответами, что идеальная ситуация - получить лучшую команду. Но есть, конечно, случаи, когда у вас нет выбора, например. спасая проект, который пошатнулся всего за несколько месяцев до отправки, где замена команды невозможна, и вам нужно сделать все возможное с теми, кто у вас есть.
Многие гибкие критики (и эксперты) говорят, что гибкий работает только с блестящими разработчиками. Я склонен согласиться. Если вы мне доверяете, Scrum не будет работать с посредственными разработчиками.: -)
Почему это так? Ну, потому что гибкий предполагает, что так много вещей появляется автоматически, как разработчики кода прочь. Например, архитектуру редко планируют; он должен появиться, когда код добавляется и реорганизуется снова и снова. Блестящие разработчики могут это сделать, но посредственные не могут.
Q.E.D.
Вы можете использовать SCRUM в своих интересах в вашей ситуации:
Если вы включите некоторые идеи XP в свою платформу scrum, вы, возможно, сможете принести "слабых" разработчиков понемногу. Вероятно, лучшим примером было бы реализовать парное программирование. Сначала я скептически относился к этому, но теперь я полностью продал эту идею. Несмотря на то, что он несколько выходит за рамки методологии схватки, вам нужно выбрать и выбрать то, что работает для вас, из всех гибких методологий, и не ограничиваться одним арендатором.
Я лично не пробовал это, но я видел, как проект спустился по этой проблемной ситуации.
Проворная разработка требует дисциплины у разработчиков. Многие люди считают, что гибкие средства, отсутствие документации, планирование, отсутствие спецификаций... поэтому вам не нужна дисциплина.
Но для успеха с гибкими методами требуется приверженность и ответственность.
Если вам нужно работать в такой среде, более вероятно, что вам удастся использовать более управляемую методологию. И не забывайте: Только потому, что вы не используете пуристический подход к ловкости ( "делать это точно так, как они сказали нам в этом курсе CSM" ), не означает, что вы не принимаете взять домой преимущества итераций во времени, парного программирования и т.д. Вы можете сделать много хороших практик без использования scrum - строго говоря.
Что мне нравится в Scrum, так это: Именно команда оказывает давление на ошибочных членов команды. Не мастер схватки, а не команда (нет такой вещи в схватке), и даже не Менеджмент.
Это облегчает решение проблем, связанных с обязательствами и ответственностью.
Я сожалею, что аргумент Jamie Ide 3-point ошибочен. Он предполагает, что многие команды, которые успешно используют гибкие методы (пункт 2), состоят из посредственных разработчиков, которые описаны в пункте 1. Однако у нас нет никаких доказательств этого. Эти команды также могут состоять преимущественно из разработчиков выше среднего уровня. Это предложит альтернативное объяснение того, почему они успешны.
Это зависит от вашего определения work.
Кен Швабер на самом деле сказал в своем Google Talk, что дерьмовые разработчики, которые используют безнадежные инструменты и ненавидят друг друга, могут, безусловно, следовать правилам схватки и производить приращения программного обеспечения дерьма вовремя и в бюджет.
... поэтому я думаю, что посредственные разработчики с отраслевым стандартом (т.е. средними инструментами) и средний уровень командной работы могут генерировать приращения посредственного программного обеспечения вовремя и бюджет.. p >
Если это то, что вы после этого хорошо, но вот проблемы:
Короткий ответ: да, Scrum работает с командами независимо от врожденной способности членов команды.
Длинный ответ: команда разработчиков программного обеспечения будет иметь естественный наилучший уровень функциональности. Большинство команд не работают по лучшему курсу, потому что они борются с скрытыми препятствиями. Scrum предоставляет скрытые препятствия, чтобы их можно было устранить и удалить. После того, как проблемы, связанные с процессом, исчезнут, команда может сосредоточиться на повышении квалификации в качестве следующего шага для увеличения скорости.
Итак, может быть, команда разработчиков со средним посредником будет не так быстро, как команда совлокальных суперзвезд, но совместная команда посредственных разработчиков, которые работают с максимальной эффективностью, будет более продуктивной, чем дисфункциональная команда, состоящая из примадонны суперзвезды, каждый из которых бежит самостоятельно. Фактически, коллективная команда в основном средних разработчиков с одной суперзвездой, которая может наставлять товарищей по команде и шаг за шагом, чтобы помочь решить их проблемы, действительно будет очень продуктивной командой.
Конечно, он работает с такой командой. Он работает так, как вы и сами быстрее понимаете, что им нужно развивать некоторые навыки. Благодаря традиционному управлению проектами вы узнаете об этом в конце проекта.
Как поясняет @Justin Grant, Scrum более высокая видимость и прозрачность могут помочь посредственным разработчикам мотивировать себя к более высокой производительности.
Поместите всю команду в одно пространство, чтобы обеспечить большую связь.
Используйте Программу Пара - это распространяет знания и помогает людям застревать и бить головой о стену. Кроме того, люди, естественно, тратят меньше времени на нерабочие, если рядом с ними кто-то сидит.
Держите спринт коротким (попробуйте начать с 1 недели), как сказал @richardtallent, чтобы команда не потерялась на кроличьих тропах.
Начните с традиционного 3-вопросного заседания: вчера я сделал то, что буду делать, и что на моем пути. Соедините членов команды, у которых есть проблемы с теми, кто может помочь. Другие обсуждения в автономном режиме.
Позаботьтесь, чтобы разбить истории на достаточно маленькие куски. Ежедневные встречи в стойке теряют эффективность, если в отчетах звучит так: "Я продолжаю работать над GiantDatabaseControllerManagerFactory" вместо "Вчера я получил предварительный просмотр печати для основного отчета. Сегодня я начну с печатной части - это займет 2 дней или меньше". Разрушительные истории - это умение. Методы исследования расщепления.
Вам понадобится хороший Владелец Продукта, тот, кто может уделять приоритетное внимание историям, чтобы обеспечить как можно больше того, что выполненная работа обеспечивает ценность для бизнеса.
Вам понадобится хороший мастер Scrum Master, тот, кто может распознать препятствия для прогресса команды и предложить шаги по их устранению. Ваша организация должна будет предоставить Scrum Master достаточные полномочия для действий.
Retrospectives Sprint очень важны. Спросите команду: что сработало? Что не так хорошо работает? Что нам нужно больше? Чего нам нужно меньше? Что мы должны добавить в наш процесс?
Будьте готовы к тому, чтобы некоторые члены команды были стойкими. Если вы не можете убедить их попробовать его на несколько спринтов, они могут уйти или вам может потребоваться оттолкнуть дверь.
Как ценный, как я думаю, Test Driven Design (TDD) и непрерывная интеграция (CI), они нетривиальны для изучения, особенно если команда не голодна, чтобы это сделать. Если вы можете получить несколько довольно успешных спринтов, возможно, в одной из ретроспектив вы можете решить проблему ошибок, воспитывая TDD и CI. Если вы можете заинтересовать команду, посмотрите, можете ли вы привлечь тренера и/или отправить несколько членов команды в класс.
Да. Scrum на самом деле очень хорош в повышении производительности для команд, которые не занимаются самообслуживанием, не совершают и не увлекаются своей работой. С другой стороны, нередко слышать от новаторских и преданных инженеров, что схватка фактически замедляет их.
С одной стороны, планирование в деталях за короткий период времени, который является спринтом, будет хорошо работать. С другой стороны, у вас будут проблемы с тем, чтобы эти разработчики действительно взяли на себя обязательство выполнить запланированную работу во время спринта.
Я думаю, что это может быть лучше, чем не делать этого, но я желаю вам удачи в любом случае.:)
Я думаю, что самое главное с Agile - это тот факт, что вы должны работать в небольших командах. Все, что больше, чем около 6 человек, и ваша команда слишком велика. Лично я думаю, что 4 - хорошее число. Бонус в том, что с гораздо меньшими командами люди намного счастливее, чтобы взять на себя ответственность за то, что они делают, и сталкиваются с последствиями своих ошибок (при условии, что остальная часть команды с удовольствием войдет и поможет с любым расписанием, т.е. Не сидеть и винить человек, который допустил ошибку для всех проблем). Быстро люди узнают, как правильно планировать, потому что они планируют такие небольшие задачи. Через несколько месяцев они будут знать TRULY, сколько времени может потребоваться любая заданная задача, и тогда система будет бесценной.
Если они по-прежнему страдают через несколько месяцев, это никогда не сработает, и, т.е. маловероятно, что что-то заставило их работать. ИМХО, в этот момент стоит признать, что они бесполезны. Некоторые могут не согласиться, но если вы дадите людям шансы, и они их не возьмут, вы можете либо потратить все свое время, пытаясь заставить их быть полезными, переместить их в то, что они МОГУТ, или избавиться от них. Я не вижу много другого выбора...
Знак хорошей командной работы, независимо от методологии, - это способность добиваться отличных результатов с обычными людьми. Это очень касается мотивации, общения и сотрудничества. Если у вас нет таких вещей, это действительно не имеет значения, насколько блестящими являются люди.
Разве это только команда разработчиков, которые не признаны/не имеют мотивации или что общее чувство внутри организации, т.е. является ли их отношение просто симптомом больших институциональных проблем?
В этом случае Scrum может быть больше полезен здесь (как отмечали другие комментаторы), если у вас достаточно силы, чтобы дать им свободу для выполнения.
Я видел это со средними кодировщиками, и это работает. Хорошая вещь о схватке заключается в том, что на каждой итерации (спринт) вы могли бы использовать некоторое время, чтобы улучшить свои навыки (книги, видео...), поставить старый код в тесты - может быть, цель может заключаться в том, чтобы поставить 1% старого кода в тест в каждом спринте - очистить беспорядок, сделать пару программ, чтобы они учились друг у друга....
Посреднические разработчики могут обязательно следовать Scrum и применять его успешно. Но это не конец, а конец - создание программного обеспечения. Будут ли они создавать хорошее программное обеспечение? Я так не думаю, или, по крайней мере, не с очень высокой скоростью. Поиск инновационных решений, кодирование, настойчивость, orm, разработка и архитектура программного обеспечения, модульное тестирование, рефакторинг, обзоры кода, приемочные испытания, сборка, автоматизация и т.д. Требуют определенных навыков. Для этого вам нужны талантливые люди или, как минимум, пара альфа-разработчиков.
Самым важным является их сила воли. Если они готовы учиться и развиваться, тогда Scrum может их вести. Если они удовлетворяются с вещами, как описано, тогда...
Кроме того, с Scrum Команда будет знать раньше, как они это делают, что может оспорить их.
Добавьте опытного разработчика, чтобы привести пример, если это возможно.