Что делает разработку программного обеспечения Agile такой привлекательной?

17

Гибкая разработка программного обеспечения в наши дни становится забавным модным словом.

Как разработчик, я понимаю прагматическую ценность итеративной разработки, но (чаще всего) разработчики не выбирают Agile-подход к разработке программного обеспечения. Это нисходящий выбор управления! Будь то кристалл, гибкие методы, dsdm, rup, xp, scrum, fdd, tdd, вы называете это. Это не выбор разработчика.

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

Agile Scout
источник
2
Частично это должно быть сделано для того, чтобы они (как более старшие менеджеры и / или клиенты) могли видеть «новейшие» технологии и методы разработки.
ChrisF
2
По моему опыту, когда нетехнические менеджеры настаивают на «гибкости», это, как правило, обусловлено соответствием модным словам, а не какими-либо преимуществами, которые надеется обеспечить гибкая разработка.
Carson63000
3
Что делает его привлекательным для менеджмента, так это то, что у него есть сексуальное имя, и «agile» в их словаре обычно означает «с меньшим количеством людей» (см. «Мы хотим стать более гибкой компанией») как синоним «Мы хотим уволить». половина рабочей силы. ")
biziclop
Как далеко назад «эти дни», как мне кажется, я слышал об Agile, по крайней мере, несколько лет, что уже давно в технических кругах?
JB King
Основная причина заключается в том, что менеджеры могут показывать ползучесть и говорить: «Это часть гибкости»
Стивен Эверс

Ответы:

26

Сдвиг требований, более быстрая доставка

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

Вот почему многие компании терпят неудачу при использовании Agile / Scrum: Менеджеры не понимают, что с большой властью (часто устанавливающей более быстрые даты выпуска и меняющихся требований) приходит ответственность полагаться на разработчиков для оценок . Чтобы гибкая работа работала, менеджер должен быть готов к сокращению объема работ.

Они хотят силы обоих.

Николь
источник
2
@ Пит, тогда ты будешь быстро использовать свои голоса ... :)
Николь
Еще один способ сказать это: способность действительно стрелять и поражать движущуюся цель.
Бьярке Фрейнд-Хансен
9

Следующие тенденции

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

«Что? Macrojam делает Agile? Почему не мы? Мы не медлительны, мы Agile, черт побери!»

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

Марк Канлас
источник
Да, тысячу раз это. «Там нет серебряной пули» ... за исключением Agile / Scrum, по-видимому, по мнению слишком многих менеджеров.
Kyralessa
«Agile решит все наши проблемы». Так почему у нас все еще есть проблемы?
Марк Канлас
8

Само по себе кодирование не является основной причиной, по которой менеджеры могут быть убеждены в том, чтобы выбрать agile в качестве метода. Тот факт, что вы можете быстрее реагировать на изменение требований и приоритетов, является привлекательным. «Менеджер» в конце концов должен предоставить решение конечному пользователю / клиенту / его менеджеру.

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

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

Надеюсь это поможет.

Франс Ванхалевейк
источник
6

Увеличьте видимость того, что происходит, и увеличьте производительность

  1. Менеджеры, как правило , заинтересованы по видимости гибкой приносит, особенно схватку. Это один из наиболее популярных пунктов продажи на семинарах, ориентированных на менеджеров.

  2. Более высокая производительность также обычно используется для их привлечения, поскольку это легко продемонстрировать (благодаря наглядности). Некоторые проворные евангелисты обещают им выдающуюся производительность от своих существующих сотрудников. «Что? Я уже давлю их как лимоны, а ты говоришь, что я могу получить еще больше » ?

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

Результат? Многие команды в distress. Они думали, что Agile решит все их проблемы, но с точностью до наоборот. Проблема была в другом месте.

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

back2dos
источник
4

Ответ на этот вопрос может заполнить книгу.

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

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

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

Так что гибкие практики также проясняют реальность намного раньше.

И, наконец, гибкие команды, как правило, чаще применяют практики, которые создают лучшее качество кода, например, разработку на основе тестов, частый рефакторинг, постоянную интеграцию, обзор однорангового кода / парное программирование и т. Д. Не то, что традиционные программные проекты запрещают эти практики, они просто склонны не так много внимания.

Пит
источник
4

большинство менеджеров даже не коснулись куска кода в своей жизни!

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

Каковы основные причины для выбора гибкой разработки

  • Visibility или Succeed fast / Fail fast - Мы являемся магазином для разработки продуктов с циклами от 6 до 24 месяцев. Итеративная разработка с работающими, протестированными функциями лучше отражала статус проекта.
  • Изменения - в нашей среде требования и время имеют тенденцию быть фиксированными. Но бизнес на слишком регулярной основе претерпевает быстрые, резкие изменения в направлении. Итеративная, видимая разработка позволила проектам сменить направление.
  • Требования на основе истории с итеративной разработкой облегчают работу с бизнесом, который не всегда понимает технические аспекты требований или полностью понимает бизнес-факторы некоторых деталей. В наших прошлых усилиях спецификации высокого уровня или маркетинговые требования не всегда были достаточными. Теперь, когда проекты развиваются, могут проводиться параллельные исследования рынка и клиентов.
  • Изменение процесса сопровождалось множеством других атрибутов разработки, таких как TDD, автоматизированное и ручное тестирование, более жесткие циклы тестирования (у нас больше нет группы контроля качества, только группа контроля качества), а также более высокая оценка и усилия, связанные с качеством (мы используем намного больше инструментов и метрик).

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

Мы также продолжаем совершенствовать наш процесс. Например, баланс между проектной работой и дизайном, предшествующий реализации. Мы регулярно пересматриваем все наши решения, чтобы определить, не могли бы мы отложить прошлые проектные решения. И, если что-то пойдет не так, сколько нужно еще проделать, пока ошибка не будет выявлена. Зачастую сбои - это ключевые случаи, которые требуют глубокого анализа. Усилия, чтобы получить это подробно, часто равны стоимости выяснения этого по пути и рефакторинга. Команды не штрафуются за ошибки такого типа и поощряются быть более агрессивными.

Джим Раш
источник
3

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

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

Майкл Браун
источник
3

Я не знаю о части модного слова. Я действительно делал это все время в не столь формализованном или определенном процессе. У меня были клиенты, которые буквально заглядывали мне через плечо, когда я создавал их сайт. Сохранено около 50 электронных писем, и клиент узнал кое-что об этом процессе - это не легко.

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

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

JeffO
источник
1

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

CaffGeek
источник
4
В идеальном мире менеджмент не делает этого; В реальности управление может и происходит в зависимости от вашего места работы. Горячие темы на последней конференции часто оказываются навязанными команде разработчиков просто потому, что они изображены как спасители жизненного цикла. Имейте в виду, что разработчики также делают это, за исключением того, что они рекламируют следующий замечательный язык и инфраструктуру, которые должны обеспечить масштабируемый код или что-то подобное. Нам всем нравятся новые вещи ... это человеческая природа.
Аарон Макивер
1

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

Дэйв Кинкейд
источник
0

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

Сергей Пожаров
источник
-1

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

Филипп Дупанович
источник
1
Поскольку программисты не оплачивают счета, клиенты платят, и именно поэтому они контролируют ситуацию.
Джеффо