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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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