Толпа может работать с посредственными разработчиками? [закрытый]
def f(in_str):
out_str = in_str.upper()
return True, out_str # Creates tuple automatically
succeeded, b = f("a") # Automatic tuple unpacking
20 ответов
Я реализовал Scrum с такой командой.
Им потребовалось несколько итераций, чтобы попасть на борт, но они обнаружили, что Scrum сделал их лучшими разработчиками. Они ценили возможность влиять на процесс. На ретроспективе каждой итерации мы изучали факторы успеха и проблемы, и как команда мы работали над устранением препятствий, которые создавали проблемы.
На ежегодном обеде в честь сотрудников в том году моя команда номинировала меня на награду за достижения: не за мои достижения, но для достижений, которых команда смогла достичь в результате перехода на Scrum.
Слишком много команд проигрывают и теряют мотивацию, потому что они не имеют права голоса в процессе. Отсутствие личной ответственности и обязательств может быть артефактом текущего процесса разработки,
Самое важное - это их обучающая сила воли. Если они готовы учиться и развиваться, то Скрам может их направлять. Если их устраивает то, что описано, то ...
Более того, с помощью Scrum Команда быстрее узнает, как у них дела, что может бросить им вызов.
Если возможно, добавьте опытного разработчика, который подаст пример.
Я видел, как это делается со средними кодировщиками, и это работает. Хорошая вещь в scrum заключается в том, что на каждой итерации (спринте) вы можете использовать некоторое время, чтобы улучшить свои навыки (книги, видео ...), поместить старый код в тесты - возможно, целью может быть использование 1% старого кода в тест в каждом спринте - чтобы убрать беспорядок, займитесь парным программированием, чтобы они учились друг у друга ....
Это просто команда разработчиков, которая не привержена / не имеет мотивации, или это общее чувство в организации, то есть их отношение просто симптом более серьезных институциональных проблем?
В этом случае Scrum может быть более здесь полезным (как отмечали другие комментаторы), если у вас достаточно влияния, чтобы дать им свободу добиваться своей цели .
Знак хорошей совместной работы, нет Независимо от методики, это умение добиваться отличных результатов с обычными людьми. Это очень важно для мотивации, общения и сотрудничества. Если у вас их нет, не имеет значения, насколько талантливы люди.
Я думаю, что самое главное в Agile - это то, что вы должны работать в небольших группах. Что-то больше, чем около 6 человек, и ваша команда слишком большая. Лично я считаю, что 4 - хорошее число. Бонус заключается в том, что с гораздо меньшими командами люди намного счастливее взять на себя ответственность за то, что они делают, и столкнуться с последствиями своих ошибок (при условии, что остальная часть команды будет счастлива вмешаться и помочь с любыми отклонениями от графика, то есть не сидеть и не обвинять человек, который ошибся за все проблемы). Люди быстро учатся правильно планировать, потому что они планируют такие небольшие задачи. Через несколько месяцев они ДЕЙСТВИТЕЛЬНО узнают, сколько времени может занять выполнение той или иной задачи, и тогда система будет бесценной.
Если они все еще страдают через несколько месяцев, то она никогда не будет работать и, tbh, вряд ли что-нибудь сработает. заставить их работать. ИМХО, на этом этапе стоит признать, что они бесполезны. Некоторые могут не согласиться, но если вы даете людям шанс, а они им не пользуются, вы можете либо потратить все свое время, пытаясь заставить их быть полезными, направить их на то, что они МОГУТ сделать, либо избавиться от них. Я не вижу других вариантов ...
С сожалением вынужден сказать, что трехточечный аргумент Джейми Айдэ ошибочен. Предполагается, что многие команды, успешно использующие гибкие методы (пункт 2), состоят из посредственных разработчиков, описанных в пункте 1. Однако у нас нет свидетельств этого. С таким же успехом эти команды могут состоять преимущественно из разработчиков выше среднего. Это могло бы предложить альтернативное объяснение их успеха.
Что мне нравится в Scrum, так это: Именно команда оказывает давление на заблудших членов команды. Ни мастер схватки, ни руководитель группы (в схватке такого нет) и даже не менеджмент.
Это упрощает решение вопросов, касающихся обязательств и ответственности.
Посредственные разработчики определенно могут следовать Scrum и успешно применять его. Но это еще не конец, цель - производить программное обеспечение. Будут ли они производить хорошее программное обеспечение? Я так не думаю, по крайней мере, с очень высокой скоростью. Поиск инновационного решения, кодирование, постоянство, организация, дизайн и архитектура программного обеспечения, модульное тестирование, рефакторинг, обзоры кода, приемочное тестирование, сборка, автоматизация и т. Д. Требуют определенных навыков. Для этого вам понадобятся талантливые люди или хотя бы пара альфа-разработчиков.
С одной стороны, детальное планирование на короткий период времени, то есть спринт, будет работать хорошо. С другой стороны, у вас будут проблемы с тем, чтобы эти разработчики взяли на себя обязательство выполнить запланированную работу во время спринта.
Я думаю, что это может быть лучше, чем не делать это, но я желаю вам желаю удачи в любом случае. :)
Заявление об отказе от ответственности Agile Manifesto говорит о вашем вопросе. В первом пункте:
«Люди и взаимодействия важнее процессов и инструментов».
Есть МНОГО способов сделать это:
- Вы можете сделать это с помощью вилки (perldoc -f fork)
- или используя потоки (потоки perldoc). Оба они затрудняют передачу возвращенной информации обратно в основную программу.
- В системах, которые поддерживают это, вы можете установить сигнал тревоги (perldoc -f alarm), а затем очистить его в обработчике сигналов.
- Вы можете использовать цикл событий, такой как POE или Coro.
- Вместо обратных кавычек вы можете использовать open () или соответственно open2 или open3 (см. IPC :: Open2, IPC :: Open3) для запуска программы при получении ее STDOUT / STDERR через дескриптор файла. Запустите на нем неблокирующие операции чтения. Позже будет невероятно сложно улучшить стандарты продукта. (Вы можете закончить с «мертвым дизайном» продукта.)
- У вас будет ужасное время, пытаясь улучшить ситуацию, нанимая хороших разработчиков. Они не захотят трогать вашу команду штангой ...
Я лично не пробовал, но я увидел, что проект упал из-за этой проблемной ситуации.
Гибкая разработка требует дисциплины в разработчиках. Многие люди думают, что Agile означает отсутствие документации, планирования, спецификаций ... так что вам не нужна дисциплина.
Но для того, чтобы добиться успеха с гибкими методами, нужны приверженность и ответственность.
Если вам приходится работать в таком состоянии. среды более вероятно, что вы добьетесь успеха, используя более управляемую методологию. И не забывайте: Только потому, что вы не используете пуристический подход к аджилити («делать именно так, как они сказали нам в этом курсе CSM»), не означает, что вы не принимаете воспользоваться преимуществами ограниченных по времени итераций,
- Большинство разработчиков посредственный по определению . Большинство те, кто считает себя выдающимися, создают больше работы, чем они достигают чрезмерное усложнение каждой проблемы и решения. По-настоящему хорошие разработчики встречаются редко.
- Многие команды успешно используют гибкие методы.
- Поэтому гибкие методы хорошо подходят для посредственных разработчиков.
QED
Многие критики (и эксперты) говорят, что Agile работает только с блестящими разработчиками. Я склонен согласиться. Если вы мне доверяете, то Scrum не будет работать с посредственными разработчиками. : -)
Почему это так? Ну, потому что Agile предполагает, что так много всего появляется автоматически, когда разработчики пишут код. Например, редко планируют архитектуру; он должен появляться по мере того, как код добавляется и реорганизуется снова и снова. Блестящие разработчики могут добиться этого, а посредственные - нет.
Если вы включите некоторые идеи XP в свою структуру Scrum, вы можете иметь возможность немного увлечь за собой «более слабых» разработчиков. Вероятно, лучшим примером будет реализация парного программирования. Сначала я скептически относился к этому, но теперь полностью согласен с этой идеей. Хотя это в некоторой степени выходит за рамки методологии схватки, вам нужно выбрать то, что работает для вас, из всех гибких методологий, а не ограничиваться одним арендатором.
Я прочитал все ответы здесь и в другом месте, и ответ, похоже, такой ... Не используйте реестр! Неужели это действительно то, что Microsoft хочет, чтобы мы сделали с данными конфигурации программы, которые применимы ко всем пользователям!?
и сочли ее более успешной, чем традиционная водопадная методология с теми же людьми, по следующим причинам:работа выполняется (и прогресс измеряется) меньшими частями, поэтому, если ваша команда нарушит или пропустит дедлайн, вы знать раньше и быстрее приспособиться. также легче привлекать людей к ответственности за проблемы с однодневной работой по сравнению с месячными провалами.
Scrum требует более высоких ожиданий прозрачности в команде, поэтому, если что-то пойдет не так (как они, безусловно, будут с недостаточно мощными и / или недостаточно мотивированная команда) вам будет легче обнаружить проблемы. В традиционной каскадной методологии для разработчика более приемлемо «уходить в тупик» неделями подряд - а с плохой командой это худшее из возможных.
Разработчики, которые обладают хорошими базовыми навыками, но неаккуратны и / или немотивированы, могут особенно выиграть от инкрементального подхода Scrum с высокой степенью взаимодействия.
Ежедневные стендапы означают, что каждый член команды должен хотя бы каждый день приходить на работу и придумывать что-то, что он делал. Это может повысить мотивацию некоторых разработчиков, которые могут быть ленивыми или отвлекаться, но при этом не хотят смущаться перед своими сверстниками. А стендапы обеспечивают как минимум минимальную прозрачность и подотчетность, не требуя от сварливых членов команды письменных отчетов о состоянии дел.
Scrum также имеет более высокие ожидания прозрачности вне команды (владельцев бизнеса и т. Д.), Так что у большего числа людей больше возможностей увидеть, насколько плоха ваша команда разработчиков, и, следовательно, вы » с большей вероятностью заручитесь поддержкой вашей компании для обновления вашей команды.
если в вашей команде есть как хорошие, так и менее хорошие разработчики, Scrum (с более высокими ожиданиями прозрачности и более низкими ожиданиями индивидуальной собственности без обратной связи) делает Хорошим разработчикам легче поддерживать команду в правильном направлении.
Обратите внимание, что я согласен с другими ответами, что идеальная ситуация - получить лучшую команду. Но, безусловно, бывают случаи, когда у вас нет выбора, например, спасение проекта, который пошел наперекосяк всего за несколько месяцев до отгрузки, когда замена команды невозможна и вам нужно приложить максимум усилий с теми людьми, которые у вас есть.
Скрам (с более высокими ожиданиями прозрачности и более низкими ожиданиями индивидуальной собственности без обратной связи) упрощает для хороших разработчиков помощь команде.Обратите внимание, что я согласен с другими ответами, что идеальная ситуация - получить лучшую команду. Но, безусловно, бывают случаи, когда у вас нет выбора, например, спасение проекта, который пошел наперекосяк всего за несколько месяцев до отгрузки, когда замена команды невозможна и вам нужно приложить максимум усилий с теми людьми, которые у вас есть.
Скрам (с более высокими ожиданиями прозрачности и более низкими ожиданиями индивидуальной собственности без обратной связи) упрощает для хороших разработчиков помощь команде.Обратите внимание, что я согласен с другими ответами, что идеальная ситуация - получить лучшую команду. Но, безусловно, бывают случаи, когда у вас нет выбора, например, спасение проекта, который пошел наперекосяк всего за несколько месяцев до отправки, когда замена команды невозможна и вам нужно приложить максимум усилий с теми людьми, которые у вас есть.
Конечно, с такой командой работает. Это работает так, как вы и вы сами быстрее понимаете, что им нужно развивать некоторые навыки. При традиционном управлении проектами вы узнаете об этом в конце проекта.
Краткий ответ: да, Scrum работает с командами независимо от врожденных способностей членов команды .
Длинный ответ: команда разработчиков программного обеспечения будет иметь естественный наилучший уровень реализации функциональности. Большинство команд не работают с максимальной скоростью, потому что борются со скрытыми препятствиями. Скрам выявляет эти скрытые препятствия, чтобы их можно было устранить и устранить. Как только проблемы, связанные с процессами, будут решены, команда сможет сосредоточиться на улучшении навыков в качестве следующего шага к увеличению скорости.
Так что, возможно, команда совместных посредственных разработчиков не будет такой быстрой, как команда совместных суперзвезд, но совместная команда посредственных разработчиков, работающих с максимальной эффективностью, будет более продуктивна, чем дисфункциональная команда, состоящая из суперзвезд примадонны, каждая из которых работает самостоятельно. Фактически, коллективная команда, состоящая в основном из средних разработчиков с одной суперзвездой, которая может наставлять товарищей по команде и вмешиваться, чтобы помочь в решении их проблем, будет действительно очень продуктивной командой.
Вы можете использовать SCRUM в ваших интересах в вашей ситуации:
- Ежедневные встречи помогают людям не сбиться с пути и подотчетны
- Короткие спринты позволяют команде сосредоточиться на конкретных задачах, не получая потеряны на кроличьих тропах
- Меньшее количество движущихся частей между сборками означает меньше серьезных ошибок.
- Наличие Владельца продукта означает, что недисциплинированная команда не может сжечь деньги, пролетая мимо радара, так же легко, как просто позволить им бежать. учит дисциплине, навязывая распорядки и краткосрочные цели ... аналогично военной подготовке.