Является ли Agile новым микроуправлением?


80

Этот вопрос уже давно готовился у меня в голове, поэтому я хотел спросить тех, кто придерживается практики Agile / Scrum в своих средах разработки.

Моя компания наконец решила внедрить гибкие методы и начала с командой из 4 разработчиков в гибкой группе на экспериментальной основе. Прошло 4 месяца с 3 итерациями, и они продолжают делать это, не оставаясь полностью гибкими для всех нас. Это связано с тем фактом, что руководство доверяет удовлетворению бизнес-требований с помощью специального запроса типа «сверху».

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

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

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

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

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


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

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

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

У них 5 минут ежедневных встреч. Но не разрешается общаться или разговаривать с кем-то за пределами их команды. Все внимание сосредоточено на работе.


71
Я видел больше злоупотреблений во имя гибкой, чем я хочу комментировать. Много раз «мы делаем гибкие» означает «мы отбрасываем все подобие процесса и делаем то, что мы хотим, Yeehaw!» (для очевидной ссылки ковбоя). Безусловно, спокойная обстановка помогает, но вы должны позволить разработчикам общаться друг с другом и решать проблемы без одобрения диктатора .
Берин Лорич

28
Ну, вы не делаете Agile ...
CaffGeek

13
Это действительно речь. Не вопрос.
JohnFx

8
2 дня на сертифицированном курсе Scrum Master не превращают менеджера в Scrum Master, как 24 часа обучения с C ++ за 24 часа не делают вас способным программистом C ++. Они просто делают это неправильно.
Мэтт

9
требуется чтение: наполовину проворный манифест «Мы слышали о новых способах разработки программного обеспечения, платя консультантам и читая отчеты Gartner ...»
gnat

Ответы:


89

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


7
Единственное, что мне удалось найти, - это пост «Joel on Software», посвященный 12 основным вещам, которые каждая компания должна предоставить своим программистам. Один из 12 был тихим местом для работы. Хотя я сомневаюсь, что Джоэл Спольски имел в виду это.
Берин Лорич

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

5
@ Кевин Кэткарт, у нас с этим жестокое соглашение. Я был в компании, где все было наоборот. У нас было около 40 человек в КПЗ с открытыми столами и без кубов. Единственная команда, которая могла сделать что-либо, была той, которая сделала большинство шума. Это тип среды, от которой вы хотите защитить.
Берин Лорич

8
@Kevin - Мой отдел разработки - это открытая ферма, расположенная рядом с множеством трех колоколов с надписями «Продажа», «Большая продажа» и «Огромная продажа». Несколько раз в день продавцы звонят им и кричат ​​«уууууу!». : - \
Дэн Рэй

2
@ Дэн, у меня было несколько интервью несколько лет назад, когда три стартапа сказали мне, что им нужно отодвинуть продавцов от разработчиков, потому что они слишком громкие!
Эрик Реппен

46

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

Это на самом деле не часть гибких практик - это отдельная проблема.

Большой мотивацией Agile методологий является усиление общения между разработчиками. Ограничение взаимодействия разработчиков <-> - это отдельная проблема от Agile-практик. Я не говорю, что этого не происходит - это, очевидно, так, и это помечается как часть «гибкого» развертывания в вашей организации, но это действительно отдельная проблема от гибкой (и в некоторой степени противоречащей духу гибкой разработки, ИМО).


29
Это абсолютно противоречит самому первому принципу Agile Manifesto: «Индивидуумы и взаимодействия над процессами и инструментами». Смотрите agilemanifesto.org для получения дополнительной информации.
Берин Лорич

«Это абсолютно против самого первого принципа Манифеста <XXX>»; замените что-нибудь на XXX, и у вас будет свой культ выбора. ;-) Серьезно, разве это не заставляет задуматься?
CesarGon

5
@CesarGon, в данном случае мы говорим о принципах гибкой работы. Если вы не можете приписать основные принципы гибкой, то, возможно, вы не хотите гибкой. Довольно просто Я не говорю «обращайся в веру», я говорю «делай то, что говоришь, веришь». Серьезно, не что делают вам интересно?
Берин Лорич

1
@CesarGon, то, что описал ОП, о полярной противоположности цели этой директивы, которую вы можете получить. В какой момент вы считаете свой средний тон достаточно близким? То, как вы говорите, звучит так, как будто разница между 95% тонов достаточно близка. Да ладно. И дай мне кредит. Я давно работаю в реальном мире и определяю процессы в корпорациях. Я прекрасно понимаю, что достаточно близко, и что описал ОП, не правда ли?
Берин Лорич

2
@Berin Loritsch: я даю вам кредит; я не собирался появляться иначе. Мое первоначальное замечание о культах на самом деле звучало шутливо. Суть, которую я пытаюсь подчеркнуть, заключается в том, что нам не нужно несколько строк в манифесте для защиты чего-то, что явно противоречит здравому смыслу. ОП описывает ситуацию, при которой все аварийные сигналы звонят. Я надеюсь, вы хорошо это воспримете; извините, если я был слишком резок. :-)
CesarGon

31

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


24

Окружающая среда, которую вы описываете, звучит как псевдо-Agile ерунда .

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

Сегодняшняя проблема, которую я подробно объясняю в другом месте , состоит в том, что большинство людей, «принимающих Agile» в наши дни, не заинтересованы в улучшении чего-либо, если это делает их неудобными. Так что для них «Agile» - это просто новая палка, которая побеждает разработчиков таким же старым способом. В противоположность, скажем, способу радикального повышения производительности при устранении всей ерунды, которая замедляет развитие.

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

Итак, чтобы ответить на ваш вопрос напрямую: Agile не должен быть новым микроуправлением. Речь должна идти о расширении возможностей людей, выполняющих реальную работу, чтобы делать дерьмо. Но в вашем случае Agile звучит как последняя ложь, которую они вам говорят, пока они потворствуют своим собственным плохим инстинктам. За что мне очень жаль.


4
+1. Agile / scrum / xp или что-то еще - просто термины "mumbo jumbo" для IT-магазинов, которые не являются настоящими компаниями-разработчиками программного обеспечения Как вы сказали, никто не вносит радикальных изменений, зарываясь головой в песок с этими практиками. Все, что нужно прочитать, - это великолепный Lean Software Development: Agile Toolkit и оставить все позади. Эти практики не для айтишников, это мой вывод.
Смит Джеймс

23

Это не ловко.

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

Хорошо, разборки закончились!

Во-вторых, основополагающий принцип XP, который, как я считаю, является фундаментальным для любого гибкого процесса, заключается в том, что он ориентирован на разработчика . Это способ дать разработчикам возможность выполнять работу, которая, как они знают, им нужна, и которую так часто не позволяют делать. Гибкая команда может быть структурирована как демократия или самодержавие, но лидеры - разработчики. Есть роли для руководителей проектов и так далее - жизненно важные роли - но это не одна из командных руководств. Наличие менеджера - извините, «мастера схватки» - сидение там и руководство людьми - верный признак того, что команда не работает гибко.

Я чувствую, что должно быть третье. Нет


-1 я не согласна Гибкая разработка также означает, что вы очищаете и облегчаете процессы, а также способность адаптироваться к изменениям. Что именно то, о чем Scrum. Скрам также о требованиях и планировании, просто по-другому.
Сокол

6
Да ладно, это 2012 год. Процитируйте публичное письмо Кента Бека или оставьте его. Не имеет значения, если он сплющил на вашем диване.
nes1983 15.12.12

6
@ nes1983: Я написал это в 2011 году. Тогда все было иначе.
Том Андерсон

3
Я никогда не слышал термин «технический долг» до тех пор, пока на моем радаре не возникла схватка. Я был на тренировке. Легко продаваемое Snake Oil предназначено для обращения к руководству за счет долгосрочных соображений качества продукции. 100% фигня. Хотя я бы полностью проглотил это, если бы Scrum Masters принесли меч в стиле Конана, чтобы уничтожить людей, которые угрожали целостности процесса.
Эрик Реппен

2
+1 к Scrum-разглагольствованиям. Я считаю Scrum методологией Agile для людей, которые так любят водопад, что хотят делать это каждые две недели.
Kyralessa

16

Scrum - ублюдок Agile. Это самый водопадный стиль из всех гибких методологий, и поэтому он наиболее популярен среди менеджеров.

Все гибкие методы предназначены для создания рабочего кода без всякой чуши. Прочитайте это снова. И снова.

Все, что мешает достижению этой цели, независимо от «гибких правил», плохо. Если правила мешают, измените правила f * * ! Это гибкий способ, вот что делает его актуальным и эффективным.

Лучший пример этого дан Алистер Кокберн (один из создателей проворного манифеста):

«Поместите 4-6 человек в комнату с рабочими станциями и досками и доступом для пользователей. Попросите их предоставлять работающее, протестированное программное обеспечение пользователям один или два месяца, а в остальном оставляйте их в покое ».

Если это работает на качество парней, которые у вас есть, то это все, что вам нужно. Вам не нужен мастер схватки или любая «гибкая» методология. Если у вас работает ежедневная схватка, тогда е * * * сделайте это. Заставить вас встать - это всего лишь жалкая аннулирование вашей способности думать самостоятельно.

Есть ответ на то, что вы делаете быстро. Это это. Распечатайте его и прикрепите где-нибудь, когда рядом никого нет, и пусть они обнаружат это для себя.


Вы имеете в виду, что они предоставляют пользователям запущенное, проверенное программное обеспечение каждые 2-3 недели?
user272671

2
@ user272671 НЕТ. Пусть они регулярно доставляют работающее, протестированное программное обеспечение пользователю. Не по тупо произвольному графику, как 2 или 3 недели. Если пользователи или сложность программного обеспечения таковы, что 6-недельный цикл работает, то делайте 6 недель. Если это можно сделать на «когда закончено», то сделайте это. Не мешайте себе искусственными ограничениями. Такой не проворный.
gbjbaanb

11

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

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

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

В любом случае, если разработчики отказываются от этого, не реализуйте это ! Или это будет катастрофа, которую вы описываете.


9

«Agile» и любая другая «методология управления» часто злоупотребляют, чтобы навязать людям микроуправление. OTOH также иногда злоупотребляют, чтобы защитить плохое мастерство.

«Мы Agile» - самое частое оправдание, которое я слышу из-за недостатка планирования, отсутствия размышлений о дизайне, функциях, качестве, циклах выпуска. Это обычно от разработчиков и низшего руководства. Это безумно также наиболее часто используемое оправдание, которое я слышу от менеджеров среднего звена, архитекторов, продавцов и т. Д. За микроуправление, постоянно меняющиеся сроки и списки функций, навязывание массовых сверхурочных работ людям (постоянно меняющиеся сроки и списки характеристик гарантируют это) и т. Д. И т. Д. И т. Д. ,

Конечно, они часто находятся в прямом противоречии и могут происходить в одном проекте.


По своему опыту ... я только слышал, чтобы agile (всегда scrum) вводили для объяснения микроуправления. Я не буду отрицать, Это другой и уникальный стиль микроуправления. Я никогда не слышал, чтобы разработчики говорили, что они проворны, и объясняют, что это не так. Какой вид управленческой принудительной схватки вы испытали?
Дж. М. Беккер

1
всякий раз, когда я сталкивался с scrum, он вводился потому, что менеджер (обычно выше, чем менеджер проекта) слышал об этом как о «вещи».
jwenting

7

Чтобы ответить на ваш первоначальный вопрос, является ли Agile новым микроуправлением, я бы сказал, нет.

Во-первых, прочитайте это (Agile манифест), и вы заметите, что не говорить с вашими со-разработчиками нет в списке.

На самом деле «Индивидуумы и взаимодействия» - это полная противоположность тому, чтобы не разговаривать с вашими со-разработчиками.


Что ж, «люди и взаимодействия» - это то, что они делают прямо сейчас в своей команде. Как обстоят дела с проворным манифестом, если вы смотрите с точки зрения мастера Scrum? В настоящее время проблема заключается в том, что они не должны взаимодействовать с другими командами, чтобы поддерживать свою производительность, что является причиной жалобы гибкой группы.
Смит Джеймс

Они не взаимодействуют. Это проблема. Конечно, разработчик может злоупотреблять привилегиями и часами говорить о бессмысленных вещах. Однако большинство хороших разработчиков хотят создать качественный проект. Это дело чести. Все, что делает мастер схваток, подрывает это, а вместо этого делает это вопросом репрессий. Это не то, что Agile о. Мастер схватки должен позволить команде быть продуктивной, а не взламывать кнут и сказать ей, чтобы она была продуктивной. Они уже хотят быть продуктивными.
Берин Лорич

2

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

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

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

Живи проворным манифестом

«Мы раскрываем лучшие способы разработки программного обеспечения, делая это и помогая другим делать это».

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

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


1

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

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


1
Развивать рабочие отношения после работы. Мы должны развивать наши часто забытые отношения между друзьями и семьей после работы. Учитывая, что коллеги редко дружат и пользуются большинством возможностей, чтобы помочь себе за чужой счет. Компания да-люди, друзья и инструменты просто не осознают этого, потому что возможности нечасты. ХР может иметь какое-то значение, у меня нет опыта, чтобы сказать иначе. Scrum стал другой версией микроуправления, по крайней мере, в трех или около того компаниях, которых я знал. .... Знаете, я слишком сильно ненавижу Корпоративную Америку, чтобы быть хоть немного объективной.
Дж. М. Беккер

0

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

Мои мысли на тему «Разработчики не общаются ни с кем, кроме мастера схватки»:

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

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

В противном случае разработчики ДОЛЖНЫ разговаривать друг с другом. Всегда. Это поможет вам быстрее справляться с проблемами, сближаться в команде и быстрее работать.

Просто чтобы предложить другую точку зрения: я также был в среде, где люди думали, что разработчики "слишком много говорили". После приседа мы обнаружили, что на самом деле переводится как «разработчики не достаточно независимы, чтобы выполнять свою собственную работу. Поскольку все настолько фрагментировано, разработчики должны обратиться к трем другим людям для выполнения небольшой задачи».

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


-1

Оригинальный автор Смит Джейнс мог бы дать опыт. Но это типичные проблемы, которые я обнаружил в Agile проекте.

  1. Большинство организаций-разработчиков должны работать в нескольких проектах, в Agile / Scrum. Спринты никогда не считаются этим фактом. Ваш Scrum Master предполагает, что вы должны покончить со своими историями в конце спринта. Ваш Scrum Master может быть посвящен только одному проекту, но не разработчикам. Это отвлечение - не нужно просто принимать телефонный звонок или разрешить телефонный звонок.
  2. Я видел Agile-проекты, в которых спринт планируется, истории включаются в спринт, без суеты .. на полпути или в середине спринта .. разработчики, находящие зависимости, не решены, требования или история не завершены, рассказаны ..... Это является одним из злоупотреблений в большинстве гибких проектов.
  3. Тестирование: TTD ... да, это очень хорошо ... но я видел большинство Agile проектов, полностью полагающихся на TTD ... нет возможностей или времени для функционального или человеческого тестирования ... Еще одно злоупотребление ... Много Scrum Masters также не знаю или не понимаю важность функционального тестирования. Ваш кусок кода может работать идеально, если он не отвечает бизнес-потребностям ... он бесполезен ... Это происходит, когда бизнес не участвует далеко впереди ... или участие есть ... но не отражает принятие бизнес-решений .. В конце концов, разработчики обвиняются, что вы не предоставили функциональность ... или это в конечном итоге будет изменено в последнюю минуту ... дополнительные долгие часы, потому что ваш мастер Scrum не хочет брать на себя вину за историю, не завершенную.

Злоупотребление здесь ... или низкое участие бизнеса или участника, не полностью осведомленного или делового человека, бросающего в середине спринта.

  1. Не все проекты подходят для Agile ... Большинство менеджеров или мастеров Scrum не знают об этом. Проекты обслуживания. Первоначально можно предположить, что дефект может быть устранен за 8 часов, что принято в спринте. Потратив 4 часа, обнаружил, что это Java / другой продукт ... (недавно я столкнулся с дефектом работы, связанным с Quartz Scheduler ... внутри нашего проекта), и этот дефект мог привести к обновлению продукта / пакета ... работа с бюрократией, одобрением, финансирование, новая версия или обновление должны быть одобрены Внутренним Инжинирингом и т. д., 5. Ретроспектива: только несколько Agile-проектов делают этот шаг. Если это вообще сделано .. Руководство Scrum Master никогда не брало на себя ответственность за провальные истории.
  2. Спаривание. Многие разработчики считают спаривание местом жестокого обращения с коллегами. Критикуют другие методы проектирования, кодирования. Считают, что это командная работа, учатся друг у друга ... Еще один способ злоупотребления Agile / Scrum.

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


см. эту ссылку .. почему провальные
mukunda

Я согласен с информацией, представленной в этой статье там тоже. Я понимаю, что есть те, кто считает Agile непогрешимым, но реальность в том, что Agile оставляет мало или не оставляет места для внедрения новых и более эффективных идей. is..brighthubpm.com / agile / 55778-why-do-agile-projects-fail
user272671

-3

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


2
Вы не могли быть более неправильным. В Agile команды должны иметь очень большой творческий контроль. Agile требует предельной инициативы, поскольку именно команда решает, как реализовать каждую историю. Управление на самом деле имеет очень мало контроля над гибким процессом. Лично три разные проворные команды, в которых я участвовал, были очень веселыми. Похоже, вы испытали некоторую серьезную некомпетентность, которая идентифицировала себя как гибкую, не будучи близко к гибкой.
Брайан Оукли

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

1
Я согласен с @Geo. На сегодняшний день у меня сложилось впечатление, что такое "Agile" в реальном мире. Когда у вас есть такая настройка на заводском цеху - это просто форма микроуправления. Теперь Манифест пытается сказать нам, что это не так. Но проект за проектом, я вынужден поверить еще больше, что это просто другое название «Микроуправление». И это убивает творчество.
user272671
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.