Является ли Scrum Evil?

Ответ 1

Лично. Я думаю, что Scrum легче принять для старого-научного стиля управления, чем любой из гибких методов. Scrums, которые должны занимать 30 минут или менее, превращаются в долговременные обновления состояния... (теперь каждый день и постоянно!)

Как и большинство проворных вещей. Я думаю, что ошибка кроется в

• не понимает принципы методологии... приводя к следующим перечисленным методам слепой веры и беспомощности, когда они не работают.
• не адаптировать методологию к проблеме. Стандартизация настолько заманчива. Chasing Templatized решения для всех проблем. "это наш новый процесс. Все должны соблюдать.
• не приспосабливается к реальностям земли и ретроспективам.
• Фиксирующие симптомы, а не болезнь.

Хорошие люди будут делать хорошее программное обеспечение (даже без проворства, SCRUM или что-то еще)... посредственные и более низкие люди будут выпускать аналогичное программное обеспечение даже с их самодельным разнообразием проворства. Однако люди, которые делают гибкие, как это было предназначено для..., приведут к улучшению продуктов

Обновление: JFYI.. Просто нашел каталог ' Scrum запахи' на сайте Майка Кон. Короткая, красиво написанная и от самого человека.

Ответ 2

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

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

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

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

Ответ 3

Некоторые наблюдения об отрицательных аспектах SCRUM в моем опыте:

Обманчивое чувство детализации.

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

За приложение.

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

Давление для близорукости

SCRUM поощряет краткосрочную работу над конкретными задачами. Менее четко определенная работа (особенно работа, которая не имеет артефактов, уже существующих в системе), таких как исследование или стратегическое планирование, находится в невыгодном положении для получения времени разработчика.

Неверный кредит

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

FUD

Те, кто больше всего тренируется в SCRUM, по-видимому, являются наиболее слепой защитой от этого, настолько, что пытаются напугать людей, думая, что даже малейшее отклонение от истинного SCRUM-пути ведет к страшному "водопаду", обработать. Учитывая огромную множественность различных процессов развития, многие из них с большим количеством хороших качеств сами по себе, эта тенденция довольно смехотворна. Кроме того, есть идея, что единственный способ быть гибким - использовать SCRUM (TM) или TDD (TM) или XP (TM), когда на самом деле существует множество способов достижения гибкости разработки без какой-либо из этих конкретных методологий. Истина заключается в том, что ни один процесс разработки не является серебряной пулей, и лучшие процессы разработки действительно только постепенно лучше лучших 2-го, 3-го и т.д. Лучших процессов.

Ответ 4

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

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

Я жил с "Agile" и "Scrum" в течение года, и видел, как многие другие компании используют его. Я убежден, что "мы проворны" просто означает "у нас нет инстинктов или мудрости о разработке программного обеспечения, поэтому мы просто слышим друг друга по 30 минут в день и притворяемся, что мы хороши в этом".

Хорошо, да, по моему опыту, схватка - это зло. "Agile" - отличное маркетинговое слово, но ужасная методология.

Ответ 5

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

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

Разумеется, развертка "agile" делает его загруженным оружием в руках плохой команды управления, и у меня меньше времени на такие вещи, как XP и часовые сеансы схватки, но это не провал принципа гибкого развитие. Разумеется, сообщение SGS дает хорошее представление о том, что более жесткие методологии могут лучше подходить к посредственным разработчикам и программному обеспечению factory, но я уверен, что это не относится к OP;)

В малой ширине моей карьеры до сих пор я могу сказать, что каждый проект водопада в конечном итоге стал неудачным подвижным, когда foo попадает в бар, и только проворные (полностью охваченные) получили поддержку все стороны в конце проекта. Является ли это предубеждением в пользу того, что всегда делалось лучше?

Резюме: Я категорически не согласен. Agile - это будущее.

Ответ 6

Во-первых, примите SCRUM за то, что это такое, набор методов управления для содействия сотрудничеству между разработчиками и деловым партнером. Как набор управленческих практик, они, как правило, легко внедряются и следуют и обеспечивают почти почти немедленную выгоду для проекта.

SCRUM - это не набор инженерных практик. Команда без набора инженерных практик - это команда, которая не сможет поддерживать доставку. SCRUM сам по себе недостаточен. Проворная команда, практикующая SCRUM, начнет терять скорость. Без надлежащей инженерной практики, например, XP, база кода становится более сложной для изменения, чем дольше выполняется проект.

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

Ответ 7

Как сказал Ф. Брукс, "нет серебряной пули", а гибкие процессы не отступают от этого и не могут применяться для всех видов проектов.

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

Очевидно, Scrum страдает от проектов [mis-], используя Scrum и failing. Это неизбежно. Но мы видели, что проекты Waterfall не удались, мы увидели неудачные проекты RAD, мы увидели неудачные проекты RUP, что он учит нас этим процессам?

Я лично считаю, что процессы Agile достигли своего уровня зрелости, но не уверены, что это означает, что они начали снижаться.

Ответ 8

Вы будете предоставлять ПО и Религию без границ - Code Complete.

Выбирайте и смешивайте практику, основанную на том, что подходит вашему текущему проекту. Не вводите методологию в религию. Помните, что мы все из разных миров. Стив Макконнелл уже много лет консультирует это - его книга Rapid Development дает каталог практик с руководством о том, подходят ли они вашим проект. Книга выиграла премию Jolt Award в 1997 году, а Стив МакКоннелл был чрезвычайно уважаемым, так что это время, когда он поймал.

Eric Sink поместите его как this ( язык в щеку):

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

Чтобы быть справедливым Алистер Кокберн Agile Software Development также советует прагматичный отбор практики, но ИМХО некоторые из других гибких гуру слишком евангельские. Другие выразили это сильнее.

Ответ 9

Я думаю, что это может быть полезно при определенных обстоятельствах. Но я думаю, что SCRUM или любая другая методология должны быть инструментом для нас, а не другим способом.

Когда он начинает создавать больше проблем, чем он решает, это не стоит времени.

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

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

Ответ 10

Интересно, что является жестоким злом ссылка не дает особенно негативной точки зрения на мой взгляд:

например. "Scrum - это зло, потому что...", когда он терпит неудачу, все вовлеченные люди думают, что все подвижные не являются хорошими (он отравляет колодец для гибкого)

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

Аналогично, сообщение Decline and Fall говорит, что слепое применение процесса (особенно SCRUM с его фокусом управления) без поддержки его хороших инженерная практика не имеет смысла.

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

Ответ 11

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

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

Тем не менее, если вы жаждете наиболее эффективных путей к славе, вам действительно нужно начинать с целей высшего качества организации в измеримой форме и использовать это понимание для выбора следующего шага (спринт, если хотите), оценивая его влияние на прогресс к этим целям. Том Гилб (см. Gilb.com) дает подробные методы в своем пособии "Конкурентная инженерия", хотя его гораздо более старые "Принципы управления программным обеспечением" гораздо легче читать с экрана на обложку.

Его увещевание выбрать и приспособиться из потока великих идей, которые он предлагает, - это большая сила его подхода.

Ответ 12

Scrum не злой, но люди могут быть. Если команда не понимает принципы [1] за пределами практики, они потерпят неудачу и, конечно же, они будут обвинять Scrum или любые другие методы Agile, которые, по их мнению, они используют.

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

Дорога к Agile полна боли и тяжелой работы. Это нелегко. Это культурные перемены, новое мышление, если вы предпочитаете [2].

Вот почему я думаю, что перед изучением Scrum, экстремального программирования или любой другой гибкой методологии люди должны прочитать о Lean Thinking [3]. Принципы, которые нам нужно понять, доступны там.

Литература:

[1] - http://www.agilemanifesto.org/principles.html

[2] - http://www.mrbool.com/articles/viewcomp.asp?comp=7480

[3] - http://www.lean.org/

Ответ 13

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

Ответ 14

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

Ответ 15

Да... SCRUM - это зло. Единственная причина, по которой менеджмент справляется с этим, в первую очередь - это шумиха. Это видео с юмором.

http://www.youtube.com/watch?v=nvks70PD0Rs

Джон