Гибкая разработка программного обеспечения в наши дни становится забавным модным словом.
Как разработчик, я понимаю прагматическую ценность итеративной разработки, но (чаще всего) разработчики не выбирают Agile-подход к разработке программного обеспечения. Это нисходящий выбор управления! Будь то кристалл, гибкие методы, dsdm, rup, xp, scrum, fdd, tdd, вы называете это. Это не выбор разработчика.
Для всех менеджеров, что является основными причинами выбора гибкой разработки, когда (по моему опыту) большинство менеджеров даже не коснулись кусочка кода в своей жизни!
project-management
agile
management
project
scrum
Agile Scout
источник
источник
Ответы:
Сдвиг требований, более быстрая доставка
Agile привлекательна тем, что дает возможность быстрее адаптироваться к изменяющимся потребностям (или вообще) и быстрее доставлять эти изменения клиенту.
Вот почему многие компании терпят неудачу при использовании Agile / Scrum: Менеджеры не понимают, что с большой властью (часто устанавливающей более быстрые даты выпуска и меняющихся требований) приходит ответственность полагаться на разработчиков для оценок . Чтобы гибкая работа работала, менеджер должен быть готов к сокращению объема работ.
Они хотят силы обоих.
источник
Следующие тенденции
Иногда люди делают что-то, не из-за заслуг того, что они предпринимают (гибкие), а просто потому, что это популярно, и другие люди пытаются сделать то же самое.
«Что? Macrojam делает Agile? Почему не мы? Мы не медлительны, мы Agile, черт побери!»
Некоторые люди не дают хорошего проклятого, что в действительности означает быть проворным. Это просто способ оправдать свое существование. Sheeple, давление со стороны сверстников и т. Д.
источник
Само по себе кодирование не является основной причиной, по которой менеджеры могут быть убеждены в том, чтобы выбрать agile в качестве метода. Тот факт, что вы можете быстрее реагировать на изменение требований и приоритетов, является привлекательным. «Менеджер» в конце концов должен предоставить решение конечному пользователю / клиенту / его менеджеру.
Если функциональность, которая казалась ключевой при запуске проекта, может быть отменена в середине проекта и заменена новыми, более актуальными требованиями, это является основным преимуществом.
Также важно то, что в основном (например, как в схватке) каждая промежуточная поставка должна быть почти готова к запуску в производство. В то же время наиболее актуальные функции были разработаны в первую очередь. Таким образом, в случае отмены проекта из-за какого-либо корпоративного решения руководство уверено, что в конечном итоге вы получите что-то, что сработает и может быть запущено в производство.
Надеюсь это поможет.
источник
Менеджеры, как правило , заинтересованы по видимости гибкой приносит, особенно схватку. Это один из наиболее популярных пунктов продажи на семинарах, ориентированных на менеджеров.
Более высокая производительность также обычно используется для их привлечения, поскольку это легко продемонстрировать (благодаря наглядности). Некоторые проворные евангелисты обещают им выдающуюся производительность от своих существующих сотрудников. «Что? Я уже давлю их как лимоны, а ты говоришь, что я могу получить еще больше » ?
Многие менеджеры используют Agile, чтобы еще больше сокрушить своих сотрудников, и я видел, как они использовали таблицу сгорания как бездельную охотничью машину в одной большой компании.
Результат? Многие команды в
distress
. Они думали, что Agile решит все их проблемы, но с точностью до наоборот. Проблема была в другом месте.Я активно борюсь с этим. Вот почему иногда, когда существует высокая вероятность, что гибкая методология будет
perverted
со стороны руководства, я предлагаю не упоминать об этом внутри компании.источник
Ответ на этот вопрос может заполнить книгу.
Я думаю, что одной из основных причин является то, что гибкая разработка фокусируется на результатах. Он всегда ориентирован на то, чтобы доставить именно то, что наиболее актуально здесь и сейчас.
Другая причина состоит в том, что основанные на истории практики планирования и оценки, которым следуют гибкие процессы, дают гораздо лучшую оценку того, что и когда можно доставить.
Хороший пример того, насколько эффективно планирование на основе истории, - это проект, над которым я работал. В течение пары месяцев (до того, как мы приняли гибкую разработку), руководитель проекта считал, что мы можем выполнить его в срок, и это было около 18 месяцев с момента его окончания. У всех разработчиков было ощущение, что это, вероятно, нереально. После начала гибкого планирования у руководителя проекта все еще была оптимистичная оценка ситуации. Но только после нескольких спринтов руководитель проекта понял, что у команды просто не было возможности выполнить все требования в ожидаемое время. И это было все еще больше чем 12 месяцев от крайнего срока.
Так что гибкие практики также проясняют реальность намного раньше.
И, наконец, гибкие команды, как правило, чаще применяют практики, которые создают лучшее качество кода, например, разработку на основе тестов, частый рефакторинг, постоянную интеграцию, обзор однорангового кода / парное программирование и т. Д. Не то, что традиционные программные проекты запрещают эти практики, они просто склонны не так много внимания.
источник
Я был разработчиком в течение 12 лет, а теперь менеджером в течение 5. В течение 5 лет я постепенно перешел от менеджера, который все еще программировался, к тому, чтобы быть в основном чистым менеджером (я все еще иногда исправляю ошибки или делаю упражнения по созданию прототипов).
Мы могли бы достичь этого другими способами, но использование гибких методологий и идей очень помогло нам.
Мы также продолжаем совершенствовать наш процесс. Например, баланс между проектной работой и дизайном, предшествующий реализации. Мы регулярно пересматриваем все наши решения, чтобы определить, не могли бы мы отложить прошлые проектные решения. И, если что-то пойдет не так, сколько нужно еще проделать, пока ошибка не будет выявлена. Зачастую сбои - это ключевые случаи, которые требуют глубокого анализа. Усилия, чтобы получить это подробно, часто равны стоимости выяснения этого по пути и рефакторинга. Команды не штрафуются за ошибки такого типа и поощряются быть более агрессивными.
источник
Я видел несколько компаний, которые "делают" гибкие. К сожалению, очень немногие из них принимают гибкие. То, что я имею в виду, - это просто итеративная разработка и ежедневные дежурства (в которых сидит большая часть команды) не делает команду гибкой. TDD, рефакторинг, непрерывная интеграция, присутствие клиентов, методы SOLID делают команду гибкой. Без них вы просто ходите кругами.
Послание Agile приносит много привлекательности. Адаптивность к изменениям является самой большой. К сожалению, ваш код не становится более адаптируемым только потому, что вы меняете способ управления проектом. Пока больше компаний не поймут это, мы будем только слышать о всё большем количестве провальных гибких проектов.
источник
Я не знаю о части модного слова. Я действительно делал это все время в не столь формализованном или определенном процессе. У меня были клиенты, которые буквально заглядывали мне через плечо, когда я создавал их сайт. Сохранено около 50 электронных писем, и клиент узнал кое-что об этом процессе - это не легко.
Идея состоит в том, что нам потребуется много времени, чтобы записать все, что пользователь хочет, чтобы программное обеспечение делало, а затем потребуется больше времени, чтобы создать то, что, как мы думаем, они хотят, только обнаружить в течение 2 секунд после попытки приложения, что это не то, что они ожидали, тошнит. Насколько сложно разбить какой-либо проект или приложение на несколько разумных частей, чтобы получить их и получить обратную связь, прежде чем создавать другую часть?
Я знаю, что это чрезмерное упрощение и не касается реальных практик разработчиков, но его нетрудно продать даже самому нетехническому менеджеру или клиенту. Какой другой подход является более привлекательным? Действительно ли клиентам нравится тот факт, что программисты не в себе на 6-12 месяцев, пока они развиваются во время какого-то проекта водопада? Вы бы наняли кого-нибудь, чтобы построить дом таким образом?
источник
Менеджмент не навязывает эти вещи разработчикам. Разработчики и команды должны проявлять инициативу и стремиться к тому, чтобы делать свою работу лучше. Работа менеджмента заключается в оказании поддержки этим инициативам.
источник
Как менеджер, который написал много кода в моей карьере, я не могу быть тем, кого вы ищете, чтобы ответить на этот вопрос. В любом случае, я думаю, что использование Agile в наши дни больше всего связано с более быстрым реагированием на потребности клиентов, а также с сокращением цикла обратной связи между спецификацией, кодированием, тестированием и клиентом. По этим причинам мы делаем шаг к более гибкой разработке.
источник
Я думаю, вам не следует путать Agile-процессы и практики кодирования / разработки. Например, Scrum не говорит вам, как вы должны разрабатывать свой код - все дело в процессе, который приветствует изменения.
источник
В конце концов, речь идет о расширении возможностей разработчика; Речь идет о признании того факта, что те ребята, которые находятся в самом низу иерархии, являются единственными, кто действительно понимает степень того, что необходимо сделать и как это сделать, поэтому, если вы уже наняли их для их опыта - почему не позволяйте им взять полный контроль или, вернее, зачем дистанцировать их от фактического принятия решения?
источник