Когда Agile идет не так [закрыто]

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

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

На что обращать внимание, когда Agile-проект работает неправильно?

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

• Ежедневные дежурства (которые длятся около часа)
• Разбить работу на спринты
• Пользовательские истории (которые обычно немного больше, чем предложение, но ожидается оценка)

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

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

Другие ключевые фразы: «Я знаю, что эти истории не полностью определены, но мы делаем гибкие, поэтому мы можем исправить их по ходу дела».

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

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

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

Люди, которые не понимают, что такое agile (было?) И применяют его к:

• клиенты, недоступные для комментариев до истечения срока
  ... и последующие угрозы судебного иска ;

• менеджеры, которые держат разработчиков подальше от клиента (возможно, потому что им немного недоплачивают, и они могут прыгать на корабли, собираясь работать на указанного клиента) и играть в игру « сломанный телефон » в отчаянной (часто успешной, хотя) попытке выглядеть занятым и полезным,

  См. Также: управление грибами , иначе говоря, «держали в тени, кормили навозом» и боссов с острыми волосами . :)

• команды, которые слишком велики, чтобы идти куда угодно;

• компании, которые платят за свою зарплату когда-то известным дизайнерам системной архитектуры, которые отчаянно отвлекают внимание от того факта, что они полностью упустили из виду реальное ремесло кодирования, переиздавая великолепные, непрактичные, труднодостижимые, семейства саграда UML .

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

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

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

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

• Является ли Agile новым микроуправлением?
• Agile процесс: как и что нужно документировать?
• Правильное сочетание планирования и программирования нового проекта

Вы когда-нибудь слышали о "псевдо Agile"? Вот несколько записей в блоге об этом:

• От псевдо-Agile к водопаду - путь маленькой и новой компании-разработчика программного обеспечения
• Псевдо Agile!

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

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

У успешного был следующие элементы:

• Поистине «проворные» требования. Были пользовательские истории, и мы закодировали их.
• Доступен владелец продукта. Если пользовательская история, от которой я писал код, была неполной, я мог бы легко обратиться к владельцу продукта, спросить его, что там должно быть, добавить его и заполнить код.
• Приверженность процессу и осознание того, что это была кривая обучения.
• Сосредоточенная команда.
• Менеджеры, которые знали и понимали Agile-способ ведения дел, которые были привержены тому, чтобы заставить его работать.

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

Команда, в которой я был, не очень хорошо работала с Agile, тоже имела несколько элементов:

• Отсутствие обязательств со стороны руководства. Менеджмент не верил в философию и в результате не решался на это.
• Требования задокументированы в других местах, кроме пользовательских историй. Смотрите выше об обязательстве руководства. Кроме того, у нас были высокооплачиваемые аналитики по требованиям и большие дорогостоящие инструменты, которые кто-то должен был оправдать.

Я добавлю к уже опубликованным отличным ответам, которые, по моему опыту, гибки и, в частности, Scrum будут работать только в том случае, если руководство И команда готовы сделать видимость того, что происходит.

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

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

• Проекты, продукт которых важен для жизни или имущества. Например, вы не хотите использовать agile для разработки программного обеспечения, которое запускает кардиостимулятор. Зачем? Потому что у вас почти нулевая терпимость к ошибкам. Рассмотрим классический пример ошибки программирования в медицине в отношении Therac 25 . Конечно, это не было построено с гибкой, но суть в том, что развитие жизненной или имущественной важности не место, чтобы сказать, «мы очистим это на следующем спринте» или «нам не нужно великое, просто хорошее достаточно."

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

• Проекты, которые требуют более высокого уровня контроля или планирования, чем те, которые традиционно предлагаются с Agile.

Я предполагаю, что или кто-то другой подскочит и поможет с лучшими примерами, или преуменьшу этот кусок обмана, который я написал ;-).

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

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

Я бы не сказал, однако, что Waterfall обязательно будет работать в такой среде, это не черно-белая ситуация, очень мало по-настоящему черно-белой.

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

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

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