Гибкая разработка программного обеспечения - Agile software development

Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
инструменты
Стандарты и свод знаний
Глоссарии
Контуры

В разработка программного обеспечения, проворный (иногда пишется Agile)[1] практический подход к выявлению требований и разработке решений посредством совместных усилий самоорганизующийся и кросс-функциональный команды и их клиент (ы) /конечные пользователи).[2] Он выступает за адаптивное планирование, эволюционное развитие, раннюю доставку и постоянное улучшение, и поощряет гибкую реакцию на изменения.[3][4][требуется дальнейшее объяснение ]

Это было популяризировано Манифест гибкой разработки программного обеспечения.[5] Ценности и принципы, провозглашенные в этом манифесте, основаны на широком диапазоне фреймворки для разработки программного обеспечения, в том числе Scrum и Канбан.[6][7]

Хотя существует множество неофициальных доказательств того, что внедрение гибких практик и ценностей повышает гибкость профессионалов, команд и организаций в области программного обеспечения, эмпирические доказательства неоднозначны и их трудно найти.[8][9]

История

Итерационные и инкрементные методы разработки программного обеспечения можно проследить еще в 1957 году,[10] с эволюционным управлением проектами[11][12] и адаптивная разработка программного обеспечения[13] возникшие в начале 1970-х гг.[14]

В течение 1990-х годов ряд легкий методы разработки программного обеспечения развивались в ответ на преобладающие тяжеловес методы (часто вместе именуемые водопад ), которые критики описали как чрезмерно регулируемые, спланированные и микроуправляемый. К ним относятся: быстрая разработка приложений (РАД), с 1991 г .;[15][16] то единый процесс (Вверх и метод разработки динамических систем (DSDM), оба с 1994 г .; Scrum, с 1995 г .; Кристально чистый и экстремальное программирование (XP), оба с 1996 г .; и функциональная разработка, с 1997 года. Хотя все они возникли до публикации Agile манифест, теперь все вместе они именуются гибкими методами разработки программного обеспечения.[7] В то же время аналогичные изменения происходили и в производстве.[17][18] и управленческое мышление[нужна цитата ].

В 2001 году эти семнадцать разработчиков программного обеспечения встретились на курорте в Снежная птица, Юта чтобы обсудить эти облегченные методы разработки: Кент Бек, Уорд Каннингем, Дэйв Томас, Джефф Сазерленд, Кен Швабер, Джим Хайсмит, Алистер Кокберн, Роберт С. Мартин, Майк Бидл, Ари ван Беннекум, Мартин Фаулер, Джеймс Греннинг, Эндрю Хант, Рон Джеффрис, Джон Керн, Брайан Марик и Стив Меллор. Вместе они опубликовали Манифест гибкой разработки программного обеспечения.[5]

В 2005 году группа, возглавляемая Кокберном и Хайсмитом, написала приложение к управление проектом принципы, Декларация о взаимозависимости PM,[19] направлять управление проектами программного обеспечения в соответствии с методами гибкой разработки программного обеспечения.

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

В 2011 году Agile Alliance создал Руководство по гибким методам разработки (переименован в Глоссарий Agile в 2016 г.),[20] развивающийся открытый сборник рабочих определений гибких практик, терминов и элементов, а также руководств по интерпретации и опыту от мирового сообщества практиков гибкой разработки.

Манифест гибкой разработки программного обеспечения

Ценности гибкой разработки программного обеспечения

Основываясь на совместном опыте разработки программного обеспечения и помощи другим в этом, семнадцать подписантов манифеста заявили, что они ценят:[5]

  • Лица и взаимодействия над процессами и инструментами
  • Рабочий софт над исчерпывающей документацией
  • Сотрудничество с клиентами по переговорам по контракту
  • Реагируя на изменения за следование плану

То есть предметы слева ценятся больше, чем предметы справа.

Так как Скотт Эмблер выяснил:[21]

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

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

Движение Agile - это не анти-методология, на самом деле многие из нас хотят восстановить доверие к слову «методология». Мы хотим восстановить баланс. Мы принимаем моделирование, но не для того, чтобы поместить какую-нибудь схему в пыльный корпоративный репозиторий. Мы принимаем документацию, но не сотни страниц никогда не обслуживаемых и редко используемых фолиантов. Мы планируем, но осознаем ограниченность планирования в неспокойной среде. Те, кто называет сторонников XP, SCRUM или любой другой гибкой методологии «хакерами», не знают ни методологий, ни первоначального определения термина «хакер».

— Джим Хайсмит, История: Манифест Agile[22]

Принципы гибкой разработки программного обеспечения

В Манифест гибкой разработки программного обеспечения основан на двенадцати принципах:[23]

  1. Удовлетворенность клиентов за счет своевременной и постоянной поставки ценного программного обеспечения.
  2. Приветствуем меняющиеся требования даже на поздней стадии разработки.
  3. Часто доставляйте работающее программное обеспечение (недели, а не месяцы)
  4. Тесное ежедневное сотрудничество деловых людей и разработчиков.
  5. Проекты строятся вокруг мотивированных людей, которым следует доверять
  6. Личный разговор - лучшая форма общения (совместное размещение)
  7. Работающее программное обеспечение - главный показатель прогресса
  8. Устойчивое развитие, способное поддерживать постоянный темп
  9. Постоянное внимание к техническому совершенству и хорошему дизайну
  10. Простота - искусство максимизировать объем незавершенной работы - очень важна.
  11. Лучший архитектуры, требования и дизайн рождаются из самоорганизующихся команд
  12. Команда регулярно размышляет о том, как стать более эффективными, и соответствующим образом корректирует

Обзор

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

Итеративный, инкрементный и эволюционный

Большинство гибких методов разработки разбивают работу по разработке продукта на небольшие этапы, которые сводят к минимуму объем предварительного планирования и проектирования. Итерации или спринты - это короткие временные рамки (временные рамки ), которые обычно длятся от одной до четырех недель. Каждая итерация включает межфункциональная команда работает во всех функциях: планирование, анализ, дизайн, кодирование, модульное тестирование, и приемочное тестирование. В конце итерации заинтересованным сторонам демонстрируется рабочий продукт. Это сводит к минимуму общий риск и позволяет продукту быстро адаптироваться к изменениям.[24] Итерация может не добавить достаточной функциональности, чтобы гарантировать выпуск на рынок, но цель состоит в том, чтобы получить доступный выпуск (с минимальным ошибки ) в конце каждой итерации.[25] Благодаря инкрементальной разработке у продуктов есть возможность «часто и рано выходить из строя» на протяжении каждой итеративной фазы, а не резко в дату окончательного выпуска.[26] Для выпуска продукта или новых функций может потребоваться несколько итераций. Работающее программное обеспечение - это главный показатель прогресса.[23]

Эффективное личное общение

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

Независимо от того, какой метод разработки используется, каждая команда должна включать представитель заказчика («Владелец продукта» в Scrum ). Этот человек согласован заинтересованными сторонами действовать от их имени и берет на себя личное обязательство быть доступным разработчикам для ответов на вопросы на протяжении всей итерации. В конце каждой итерации заинтересованные стороны и представитель заказчика проверяют прогресс и повторно оценивают приоритеты с целью оптимизации прибыль на инвестиции (ROI) и обеспечение соответствия потребностям клиентов и целям компании. Важность удовлетворенности заинтересованных сторон, подробно описываемая путем частого взаимодействия и анализа в конце каждого этапа, является причиной того, что методологию часто называют «методологией, ориентированной на клиента».[29]

В гибкой разработке программного обеспечения информационный радиатор представляет собой (обычно большой) физический дисплей, расположенный на видном месте рядом с командой разработчиков, где его могут видеть прохожие. Он представляет собой актуальную сводку о состоянии разработки продукта.[30][31] А световой индикатор сборки также может использоваться для информирования команды о текущем статусе разработки продукта.

Очень короткий цикл обратной связи и цикл адаптации

Общей характеристикой гибкой разработки программного обеспечения является ежедневный стендап (а ежедневная схватка в рамках Scrum). Во время короткой сессии члены команды сообщают друг другу, что они сделали накануне для достижения цели итерации своей команды, что они собираются сделать сегодня для достижения цели, а также обо всех препятствиях или препятствиях, которые они могут увидеть на пути к цели.[32]

Ориентация на качество

Конкретные инструменты и методы, такие как непрерывная интеграция, автоматизированный модульное тестирование, парное программирование, разработка через тестирование, шаблоны проектирования, поведенческая разработка, предметно-ориентированный дизайн, рефакторинг кода и другие методы часто используются для улучшения качества и повышения гибкости разработки продукта.[33] Это зависит от качества проектирования и создания с самого начала и возможности демонстрировать программное обеспечение для клиентов в любой момент или, по крайней мере, в конце каждой итерации.[34]

Философия

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

Адаптивная и предсказательная

Методы развития существуют в непрерывном виде из адаптивный к предсказательный.[37] Методы гибкой разработки программного обеспечения лежат в основе адаптивный сторона этого континуума. Один из ключевых методов адаптивного развития - это катящаяся волна подход к планированию графика, который определяет вехи, но оставляет гибкость на пути их достижения, а также позволяет изменять сами вехи.[38]

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

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

Анализ риска можно использовать для выбора между адаптивными (проворный или ориентированный на ценность) и прогнозирующий (плановый) методы.[39] Барри Бем и Ричард Тернер предполагают, что каждая сторона континуума имеет свой собственный домашняя земля, следующим образом:[40]

Домашние площадки разных методов развития
Ценностно-ориентированные методыПлановые методыФормальные методы
Низкая критичностьВысокая критичностьЧрезвычайная критичность
Старшие разработчикиМладшие разработчики (?)Старшие разработчики
Требования часто меняютсяТребования меняются не частоОграниченные требования, ограниченные функции см. Закон вирта[требуется разъяснение ]
Небольшое количество разработчиковБольшое количество разработчиковТребования, которые можно смоделировать
Культура, которая реагирует на измененияКультура, требующая порядкаВысочайшее качество

Agile против водопада

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

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

Этот итеративный подход поддерживает товар а не проект образ мышления. Это обеспечивает большую гибкость в процессе разработки; тогда как в проектах требования определены и заблокированы с самого начала, что затрудняет их изменение позже. Итерационная разработка продукта позволяет программному обеспечению развиваться в ответ на изменения бизнес-среды или требований рынка.[41]

Из-за короткого итерационного стиля гибкой разработки программного обеспечения он также имеет прочные связи с бережливый стартап концепция.

Код против документации

В письме к IEEE Computer, Стивен Ракитин цинично высказался по поводу гибкой разработки программного обеспечения, назвав это "еще одна попытка подорвать дисциплину программной инженерии"и перевод"рабочее программное обеспечение над исчерпывающей документации" так как "мы хотим тратить все свое время на кодирование. Помните, настоящие программисты не пишут документацию."[42]

Это оспаривается сторонниками гибкой разработки программного обеспечения, которые заявляют, что разработчики должны писать документацию, если это лучший способ достижения соответствующих целей, но что часто есть более эффективные способы достижения этих целей, чем написание статической документации.[43]Скотт Эмблер заявляет, что документация должна быть «едва ли достаточной» (JBGE),[44] что слишком большая или полная документация обычно приводит к расточительству, а разработчики редко доверяют подробной документации, потому что она обычно не синхронизируется с кодом,[43] в то время как слишком мало документации может также вызвать проблемы для обслуживания, общения, обучения и обмена знаниями. Алистер Кокберн написал о Кристально чистый метод:

Кристалл рассматривает разработку как серию кооперативных игр и рассчитывает, что документации будет достаточно, чтобы помочь следующей победе в следующей игре. Рабочие продукты для Crystal включают варианты использования, список рисков, план итераций, модели основной предметной области и заметки о дизайне для информирования о вариантах выбора ... однако для этих документов нет шаблонов, и описания обязательно расплывчаты, но цель ясна, достаточно документации для следующей игры. Я всегда склонен характеризовать это для своей команды так: что бы вы хотели знать, если бы присоединились к команде завтра.

— Алистер Кокберн.[45]

Методы гибкой разработки программного обеспечения

Поддержка жизненного цикла разработки программного обеспечения[46]

Методы гибкой разработки программного обеспечения поддерживают широкий спектр жизненный цикл разработки программного обеспечения.[46] Некоторые методы ориентированы на практические приемы (например, XP, прагматическое программирование, гибкое моделирование), а некоторые - на управление потоком работы (например, Scrum, Kanban). Некоторые виды деятельности поддерживают спецификацию требований и разработку (например, FDD), в то время как другие стремятся охватить полный жизненный цикл разработки (например, DSDM, RUP ).

Известные рамки гибкой разработки программного обеспечения включают:

ФреймворкГлавный участник (и)
Адаптивная разработка программного обеспечения (ASD)Джим Хайсмит, Сэм Байер
Гибкое моделированиеСкотт Эмблер, Роберт Сесил Мартин
Гибкий унифицированный процесс (AUP)Скотт Эмблер
Дисциплинированная гибкая доставкаСкотт Эмблер
Метод разработки динамических систем (DSDM)
Экстремальное программирование (XP)Кент Бек, Роберт Сесил Мартин
Разработка на основе функций (FDD)Джефф Де Лука
Бережливая разработка программного обеспеченияМэри Поппендик, Том Поппендик
Бережливый стартапЭрик Райс
КанбанТайити Оно
Быстрая разработка приложений (РАД)Джеймс Мартин
ScrumКен Швабер, Джефф Сазерленд
Scrumban
Масштабируемая гибкая среда - SAFeScaled Agile, Inc.

Практики гибкой разработки программного обеспечения

Гибкая разработка программного обеспечения поддерживается рядом конкретных практик, охватывающих такие области, как требования, дизайн, моделирование, кодирование, тестирование, планирование, управление рисками, процесс, качество и т. Д. Некоторые известные практики гибкой разработки программного обеспечения включают:[47]

ПрактикаГлавный участник (и)
Разработка через приемочные испытания (ATDD)
Гибкое моделирование
Гибкое тестирование
Задержки (Продукт и Спринт)Кен Швабер
Поведенческая разработка (BDD)Дэн Норт, Лиз Кио
Непрерывная интеграция (CI)Грейди Буч
Межфункциональная команда
Ежедневный Stand-up / Ежедневный ScrumДжеймс О Коплиен
Домен-ориентированный дизайн (DDD)Эрик Эванс
Итеративная и инкрементальная разработка (IID)
Платформы разработки low-code
Парное программированиеКент Бек
Планирование покераДжеймс Греннинг, Майк Кон
РефакторингМартин Фаулер
Ретроспектива
Scrum события (планирование спринта, обзор спринта и ретроспектива)
Уточнение на примере
Сюжетное моделированиеАльберт Цюндорф
Разработка через тестирование (TDD)Кент Бек
Таймбоксинг
История пользователяАлистер Кокберн
Отслеживание скорости

Адаптация метода

В литературе различные термины относятся к понятию адаптации метода, включая «адаптацию метода», «адаптацию фрагмента метода» и «разработку ситуационного метода». Адаптация метода определяется как:

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

— Мехмет Нафиз Айдын и др., Используемый метод разработки гибких информационных систем[48]

Приемлемость ситуации следует рассматривать как отличительную характеристику гибких методов и методов разработки программного обеспечения, в большей степени основанных на планах, с гибкими методами, позволяющими группам разработки продукта адаптировать рабочие практики в соответствии с потребностями отдельных продуктов.[49][48] Потенциально, наиболее гибкие методы могут быть подходящими для адаптации методов,[46] такие как DSDM скроенный в CMM контекст.[50] и XP с учетом Правило Описание Практики (RDP) техника.[51] Однако не все сторонники гибкой разработки согласны с тем, что Швабер отмечает, что «именно поэтому мы в первую очередь попали в беду, думая, что проблема заключалась в отсутствии совершенной методологии. Усилия [должны] сосредоточиваться на изменениях [необходимых] на предприятии». .[52] Бас Водде усилил эту точку зрения, предположив, что в отличие от традиционных крупных методологий, требующих от вас выбора элементов, Scrum предоставляет основы, поверх которых вы добавляете дополнительные элементы для локализации и контекстуализации его использования.[53] Практики редко используют методы разработки систем, или, в частности, гибкие методы, по инструкции, часто предпочитая опускать или адаптировать некоторые практики метода, чтобы создать собственный метод.[54]

На практике методы можно адаптировать с помощью различных инструментов. Общие языки моделирования процессов, такие как Единый язык моделирования может использоваться для адаптации методов разработки программного обеспечения. Однако специальные инструменты для разработки методов, такие как Essence Theory of Software Engineering of SEMAT тоже существуют.[55]

Крупномасштабные, оффшорные и распределенные

По общему мнению, гибкая разработка программного обеспечения хорошо подходит для определенных типов сред, включая небольшие группы экспертов, работающих над новые проекты,[40][56]:157 а также проблемы и ограничения, возникающие при внедрении гибких методов разработки программного обеспечения в большой организации с унаследованная инфраструктура хорошо задокументированы и понятны.[57]

В ответ на это был разработан ряд стратегий и шаблонов для преодоления проблем с помощью крупномасштабных разработок (> 20 разработчиков).[58][59] или распределенные (не колокационные) команды разработчиков,[60][61] среди других проблем; и в настоящее время существует несколько признанных структур, которые стремятся смягчить или избежать этих проблем.

Существует множество противоречащих друг другу точек зрения на то, все ли они эффективны или действительно подходят под определение гибкой разработки, и это остается активной и постоянной областью исследований.[58][70]

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

Регулируемые домены

Методы гибкой разработки программного обеспечения изначально рассматривались как наиболее подходящие для некритичных разработок продуктов, поэтому были исключены из использования в регулируемых областях, таких как медицинское оборудование, фармацевтический, финансовый, ядерный, автомобильный и авионический секторы и т. д. Однако в последние несколько лет было выдвинуто несколько инициатив по адаптации гибких методов для этих областей.[71][72][73][74][75]

Существует множество стандартов, которые могут применяться в регулируемых доменах, в том числе ISO 26262, ISO 9000, ISO 9001, и ISO / IEC 15504. Ряд ключевых проблем имеют особое значение в регулируемых доменах:[76]

  • Гарантия качества (QA): систематическое и неотъемлемое управление качеством, лежащее в основе контролируемого профессионального процесса, а также надежности и правильности продукта.
  • Безопасность и защищенность: формальное планирование и управление рисками для снижения рисков безопасности для пользователей и надежной защиты пользователей от непреднамеренного и злонамеренного злоупотребления.
  • Прослеживаемость: Документация, предоставляющая проверяемые доказательства соответствия нормативным требованиям и упрощающая отслеживание и расследование проблем.
  • Верификация и валидация (V&V): встроены в процесс разработки программного обеспечения (например, спецификация требований пользователя, функциональная спецификация, спецификация дизайна, проверка кода, модульные тесты, интеграционные тесты, системные тесты).

Опыт и принятие

Хотя гибкие методы разработки программного обеспечения могут использоваться на практике с любой парадигмой программирования или языком, изначально они были тесно связаны с объектно-ориентированными средами, такими как Smalltalk и Lisp, а затем и Java. Первоначальными приверженцами гибких методов обычно были небольшие или средние команды, работавшие над беспрецедентными системами с требованиями, которые было трудно завершить и которые, вероятно, изменились по мере разработки системы. В этом разделе описаны общие проблемы, с которыми сталкиваются организации, когда они пытаются внедрить методы гибкой разработки программного обеспечения, а также различные методы измерения качества и производительности гибких команд.[77]

Измерение маневренности

Внутренние оценки

В Индекс измерения ловкости, среди прочего, оценивает разработки по пяти параметрам разработки продукта (продолжительность, риск, новизна, усилия и взаимодействие).[78][79] Другие методы основаны на измеримых целях.[80] и одно исследование предполагает, что скорость может использоваться как показатель маневренности.[81] Также существует гибкая самооценка, чтобы определить, использует ли команда методы гибкой разработки программного обеспечения (тест Nokia,[82] Карлскруна тест,[83] 42 балла).[84]

Общественные опросы

Одним из первых исследований, в которых сообщалось о повышении качества, производительности и удовлетворенности бизнеса за счет использования методов гибкой разработки программного обеспечения, было исследование, проведенное Shine Technologies с ноября 2002 по январь 2003 года.[85]

Похожий опрос Состояние Agile, проводится ежегодно, начиная с 2006 года, с тысячами участников из всего сообщества разработчиков программного обеспечения.Это отслеживает тенденции в отношении предполагаемых преимуществ гибкости, извлеченных уроков и передовых методов. В каждом опросе сообщалось о росте числа заявлений о том, что гибкая разработка программного обеспечения помогает им быстрее доставлять программное обеспечение; улучшает их способность управлять изменяющимися приоритетами клиентов; и увеличивает их производительность.[86] Опросы также неизменно показывают лучшие результаты при использовании гибких методов разработки продуктов по сравнению с классическим управлением проектами.[87][88] В целом, есть сообщения о том, что некоторые считают, что методы гибкой разработки еще слишком молоды, чтобы проводить обширные академические исследования их успеха.[89]

Распространенные ошибки гибкой разработки программного обеспечения

Организации и команды, внедряющие гибкую разработку программного обеспечения, часто сталкиваются с трудностями при переходе от более традиционных методов, таких как развитие водопада, например, команды, которым навязывают гибкий процесс.[90] Их часто называют гибкие антипаттерны или чаще проворные запахи. Ниже приведены несколько распространенных примеров:

Отсутствие общего дизайна продукта

Цель гибкой разработки программного обеспечения - больше сосредоточиться на создании рабочего программного обеспечения, а не на документации. Это отличается от каскадных моделей, в которых процесс часто строго контролируется, а незначительные изменения в системе требуют значительного пересмотра сопроводительной документации. Однако это не оправдывает полного отказа от анализа или проектирования. Отсутствие внимания к дизайну может привести к тому, что команда поначалу будет действовать быстро, но затем потребуется существенная переделка, когда они попытаются масштабировать систему. Одна из ключевых особенностей гибкой разработки программного обеспечения - это итеративность. Когда все сделано правильно, дизайн проявляется по мере разработки системы и выявления общих черт и возможностей для повторного использования.[91]

Добавление историй в текущую итерацию

В гибкой разработке программного обеспечения рассказы (похожий на вариант использования описания) обычно используются для определения требований и итерация - это короткий период времени, в течение которого команда стремится к конкретным целям.[92] Добавление историй в текущую итерацию пагубно сказывается на рабочем процессе. Их следует добавить в список невыполненных работ по продукту и назначить им приоритет для последующей итерации, или в редких случаях итерацию можно отменить.[93]

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

Отсутствие спонсорской поддержки

Гибкая разработка программного обеспечения часто реализуется на низовом уровне в организациях группами разработчиков программного обеспечения, которые пытаются оптимизировать свои процессы разработки и обеспечить согласованность жизненного цикла разработки программного обеспечения. Не имея спонсорской поддержки, команды могут столкнуться с трудностями и сопротивлением со стороны деловых партнеров, других команд разработчиков и руководства. Кроме того, они могут пострадать без соответствующего финансирования и ресурсов.[94] Это увеличивает вероятность выхода из строя.[95]

Недостаточная подготовка

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

Роль владельца продукта не заполнена должным образом

В Владелец продукта отвечает за представление бизнеса в процессе разработки и часто является самой ответственной ролью.[97]

Распространенной ошибкой является то, что роль владельца продукта исполняет кто-то из команды разработчиков. Это требует от команды принятия собственных решений по расстановке приоритетов без реальной обратной связи со стороны бизнеса. Они пытаются решать бизнес-задачи внутри компании или откладывают работу, обращаясь за указаниями за пределы команды. Это часто приводит к отвлечению внимания и срыву сотрудничества.[98]

Команды не сосредоточены

Гибкая разработка программного обеспечения требует от команд выполнения обязательств по продукту, а это означает, что они должны сосредоточиться только на работе над этим продуктом. Однако от членов команды, которые кажутся свободными, часто ожидается, что они возьмут на себя другую работу, из-за чего им будет сложно помочь завершить работу, которую взяла на себя их команда.[99]

Чрезмерная подготовка / планирование

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

Решение проблем в ежедневных стендапах

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

Назначение задач

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

Назначенная работа также ограничивает членов команды определенными ролями (например, член команды A всегда должен выполнять работу с базой данных), что ограничивает возможности для перекрестного обучения.[101] Члены команды сами могут решать задачи, расширяющие их возможности и предоставляющие возможности для перекрестного обучения.

Скрам-мастер как участник

Скрам-мастер - это человек, ответственный за обеспечение того, чтобы процесс схватки происходил, и инструктаж команды схватки через этот процесс. Распространенная ошибка состоит в том, что мастер схватки выступает в качестве участника. Хотя это и не запрещено методологией Scrum, мастер схватки должен убедиться, что у него есть способность сначала действовать в роли мастера схватки, а не работать над задачами разработки. Роль мастера схватки - способствовать процессу, а не создавать продукт.[102]

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

Отсутствие автоматизации тестирования

Из-за итеративного характера гибкой разработки часто требуется несколько раундов тестирования. Автоматическое тестирование помогает снизить влияние повторяющихся модульных, интеграционных и регрессионных тестов и позволяет разработчикам и тестировщикам сосредоточиться на более ценной работе.[103]

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

Разрешение нарастать техническому долгу

Сосредоточение внимания на предоставлении новых функций может привести к увеличению технический долг. Команда должна дать себе время на исправление дефектов и рефакторинг. Технический долг мешает планированию из-за увеличения объема внеплановой работы, поскольку производственные дефекты отвлекают команду от дальнейшего прогресса.[104]

По мере развития системы важно рефакторинг поскольку энтропия системы естественно возрастает.[105] Со временем отсутствие постоянного обслуживания приводит к увеличению дефектов и затрат на разработку.[104]

Попытка взять на себя слишком много за итерацию

Распространенное заблуждение состоит в том, что гибкая разработка программного обеспечения допускает непрерывные изменения, однако невыполненная итерационная работа - это договоренность о том, какую работу можно выполнить во время итерации.[106] Слишком много незавершенное производство (WIP) приводит к неэффективности, такой как переключение контекста и организация очередей.[107] Команда должна избегать ощущения давления, заставляющего выполнять дополнительную работу.[108]

Фиксированное время, ресурсы, объем и качество

При гибкой разработке программного обеспечения время (продолжительность итерации), качество и, в идеале, ресурсы фиксируются заранее (хотя поддержание фиксированных ресурсов может быть затруднено, если разработчиков часто отвлекают от задач для обработки производственных инцидентов), при этом объем остается переменным. Заказчик или владелец продукта часто настаивают на фиксированном объеме итерации. Тем не менее, команды не должны стремиться использовать ограниченное время, ресурсы и объем (широко известный как треугольник управления проектом ). Попытки увеличить объем к фиксированному времени и ресурсам гибкой разработки программного обеспечения могут привести к снижению качества.[109]

Выгорание разработчика

Из-за целенаправленного темпа и непрерывного характера гибких практик существует повышенный риск выгорания среди членов команды доставки.[110]

Гибкое управление

Основная статья: Гибкое управление

Период, термин гибкое управление применяется к итеративному, инкрементному методу управления деятельностью по проектированию и строительству инженерных, информационных технологий и других сфер бизнеса, которые направлены на предоставление разработки новых продуктов или услуг в очень гибкой и интерактивной манере на основе принципов, выраженных в Манифест гибкой разработки программного обеспечения.[111]

Методы Agile X также можно назвать экстремальное управление проектами. Это вариант итеративный жизненный цикл[112] где Практические результаты подаются поэтапно. Основное различие между гибкой и итеративной разработкой заключается в том, что гибкие методы завершают небольшие части результатов в каждом цикле (итерации) доставки,[113] в то время как итерационные методы развивают весь набор результатов с течением времени, завершая их ближе к концу проекта. Итеративные и гибкие методы были разработаны как реакция на различные препятствия, возникшие в более последовательных формах организации проекта. Например, по мере того, как технологические проекты становятся все сложнее, конечные пользователи, как правило, испытывают трудности с определением долгосрочных требований, не имея возможности просматривать прогрессивные прототипы. Проекты, которые развиваются в итерациях, могут постоянно собирать отзывы, чтобы помочь уточнить эти требования.

Гибкое управление также предлагает простую структуру, способствующую общению и размышлению о прошлой работе среди команда члены.[114] Команды, которые использовали традиционное водопадное планирование и выбрали гибкий путь разработки, обычно проходят фазу трансформации и часто получают помощь от гибких тренеров, которые помогают командам пройти плавную трансформацию. Как правило, существует два стиля гибкого коучинга: на основе толчка и agile-коучинг на основе вытягивания. Подходы к гибкому управлению также были применены и адаптированы к бизнесу и правительству. Например, в пределах федеральное правительство США, то Агентство США по международному развитию (USAID) нанимает совместное управление проектами подход, ориентированный на включение сотрудничество, обучение и адаптация (CLA) стратегии для повторения и адаптации программирования.[115]

Гибкие методы упоминаются в Руководство к своду знаний по управлению проектами (Руководство PMBOK) в соответствии с определением жизненного цикла проекта:

Адаптивный жизненный цикл проекта, жизненный цикл проекта, также известный как управляемые изменениями или гибкие методы, который предназначен для облегчения изменений и требует высокой степени постоянного акционер участие. Адаптивные жизненные циклы также являются итеративными и инкрементными, но отличаются тем, что итерации выполняются очень быстро (обычно длительностью 2-4 недели) и фиксируются по времени и Ресурсы.[116]

Приложения за пределами разработки программного обеспечения

Конференция Agile Brazil 2014

По словам Жан-Лу Рише (научный сотрудник ESSEC Institute for Strategic Innovation & Services) «этот подход может быть эффективно использован для непрограммных продуктов и для управления проектами в целом, особенно в областях инноваций и неопределенности». Конечным результатом является продукт или проект, который наилучшим образом удовлетворяет текущие потребности клиентов и реализуется с минимальными затратами, отходами и временем, что позволяет компаниям достичь чистой прибыли раньше, чем с помощью традиционных подходов.[117]

Методы гибкой разработки программного обеспечения широко используются для разработки программных продуктов, и некоторые из них используют определенные характеристики программного обеспечения, такие как объектные технологии.[118] Однако эти методы можно применять для разработки непрограммных продуктов, таких как компьютеры, медицинские устройства, продукты питания, одежда и музыка.[119] Методы гибкой разработки программного обеспечения использовались без разработки ИТ-инфраструктура развертывания и миграции. Некоторые из более широких принципов гибкой разработки программного обеспечения также нашли применение в общем менеджменте.[120] (например, стратегия, управление, риск, финансы) в соответствии с условиями гибкость бизнеса или гибкое управление бизнесом.

Парадигмы гибкой разработки программного обеспечения можно использовать в других сферах жизни, например в воспитании детей. Его успех в развитии ребенка может быть основан на некоторых основных принципах управления; общение, адаптация и осведомленность. В TED Talk Брюс Фейлер поделился, как он применял базовые методики гибкой разработки к ведению домашнего хозяйства и воспитанию детей.[121]

Критика

Практики Agile могут быть неэффективными в крупных организациях и при определенных типах разработок.[122] Многие организации считают, что методологии гибкой разработки программного обеспечения слишком экстремальны, и используют гибридный подход.[123] в котором сочетаются элементы гибкой разработки программного обеспечения и плановые подходы.[124] Некоторые методы, такие как метод разработки динамических систем (DSDM) попытайтесь сделать это дисциплинированно, не жертвуя фундаментальными принципами.

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

Алистер Кокберн организовали празднование 10-летия Манифест гибкой разработки программного обеспечения в Сноуберд, штат Юта, 12 февраля 2011 года, собрав около 30+ человек, которые принимали участие в первоначальной встрече и с тех пор. Список примерно из 20 слоны в комнате («не подлежащие обсуждению» гибкие темы / проблемы) были собраны, включая аспекты: альянсы, неудачи и ограничения гибкой практики разработки программного обеспечения и контекста (возможные причины: коммерческие интересы, деконтекстуализация, отсутствие очевидного способа добиться прогресса на основе неудач, ограниченные объективные доказательства , когнитивные предубеждения и рассуждения), политика и культура.[126] Так как Филипп Крюхтен написал:

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

— Филипп Крухтен[126]

«Манифест», возможно, оказал негативное влияние на менеджмент и руководство высшего образования, где он предложил администраторам заменить более медленные традиционные и совещательные процессы более «проворными». Эта концепция никогда не находила признания среди преподавателей университета.[127]

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

Смотрите также

использованная литература

  1. ^ Ралли (2010). "Agile с большой буквы" A "против Agile с большой буквы" a"". Архивировано 5 января 2016 года.. Получено 9 сентября 2015.CS1 maint: неподходящий URL (ссылка на сайт)
  2. ^ Кольер, Кен В. (2011). Agile Analytics: ориентированный на ценность подход к бизнес-аналитике и хранилищам данных. Pearson Education. стр.121 и сл. ISBN  9780321669544. Что такое самоорганизующаяся команда?
  3. ^ Бек, Кент М .; Бидл, Майк; Беннекум, Ари ван; Кокберн, Алистер; Каннингем, Уорд; Фаулер, Мартин; Греннинг, Джеймс; Хайсмит, Джим; Хант, Энди; Джеффрис, Рон; Керн, Джон; Марик, Брайан; Martin, R.C .; Меллор, Стив Дж .; Швабер, Кен; Сазерленд, Джефф; Томас, Дэйв. «Манифест для гибкой разработки программного обеспечения». Неопределенный. S2CID  109006295.
  4. ^ «Что такое гибкая разработка программного обеспечения?». Agile Alliance. 8 июня 2013 г.. Получено 4 апреля 2015.
  5. ^ а б c Кент Бек; Джеймс Греннинг; Роберт С. Мартин; Майк Бидл; Джим Хайсмит; Стив Меллор; Ари ван Беннекум; Эндрю Хант; Кен Швабер; Алистер Кокберн; Рон Джеффрис; Джефф Сазерленд; Уорд Каннингем; Джон Керн; Дэйв Томас; Мартин Фаулер; Брайан Марик (2001). «Манифест для гибкой разработки программного обеспечения». Agile Alliance. Получено 14 июн 2010.
  6. ^ Что лучше - Канбан или Скрам?, 4 марта 2016
  7. ^ а б Ларман, Крэйг (2004). Гибкая и итеративная разработка: руководство для менеджера. Эддисон-Уэсли. п. 27. ISBN  978-0-13-111155-4.
  8. ^ Диба, Тор; Дингсёйр, Торгейр (1 августа 2008 г.). «Эмпирические исследования гибкой разработки программного обеспечения: систематический обзор». Информационные и программные технологии. 50 (9–10): 833–859. Дои:10.1016 / j.infsof.2008.01.006. ISSN  0950-5849.
  9. ^ Ли, Кванху; Ся, Вэйдун (2010). «К Agile: комплексный анализ количественных и качественных полевых данных о гибкости разработки программного обеспечения». MIS Quarterly. 34 (1): 87–114. Дои:10.2307/20721416. JSTOR  20721416. S2CID  26477249.
  10. ^ Джеральд М. Вайнберг, как указано в Ларман и Базили 2003, pp. 47–56 «Мы занимались постепенным развитием еще в 1957 году в Лос-Анджелесе под руководством Берни Димсдейла в Корпорация сервисного бюро IBM. Он был коллегой Джон фон Нейман, так что, возможно, он выучил это там или считал это совершенно естественным. Я действительно помню, как Херб Джейкобс (в первую очередь, хотя мы все участвовали) разрабатывал большую симуляцию для Motorola, в которой использовалась техника, насколько я могу судить ... Все мы, насколько я помню, думали, что водопад представляет собой огромный проект был довольно глупым или, по крайней мере, игнорировал реалии. Я думаю, что описание водопада заставило нас понять, что мы занимаемся чем-то другим, чем-то неназванным, кроме «разработки программного обеспечения» ».
  11. ^ «Эволюционное управление проектами (Исходная страница, внешний архив)». Гилб. Архивировано из оригинал 27 марта 2016 г.. Получено 30 апреля 2017.
  12. ^ «Эволюционное управление проектами (Новая страница)». Гилб. Получено 30 апреля 2017.
  13. ^ Эдмондс, Э.А. (1974). «Процесс разработки программного обеспечения для нетехнических пользователей в качестве адаптивной системы». Общие системы. 19: 215–18.
  14. ^ Гилб, Том (1 апреля 1981). «Эволюционное развитие». Примечания по разработке программного обеспечения ACM SIGSOFT. 6 (2): 17. Дои:10.1145/1010865.1010868. S2CID  33902347.
  15. ^ Мартин, Джеймс (1991). Быстрая разработка приложений. Макмиллан. ISBN  978-0-02-376775-3.
  16. ^ Керр, Джеймс М .; Хантер, Ричард (1993). Внутри RAD: как построить полностью функциональную систему за 90 дней или меньше. Макгроу-Хилл. п. 3. ISBN  978-0-07-034223-1.
  17. ^ Институт Якокки (1991). «Стратегия производственного предприятия 21-го века: вид, управляемый отраслью». Институт Якокка, Университет Лихай, Вифлеем, Пенсильвания.
  18. ^ Пресли, А., Дж. Миллс и Д. Лайлс (1995). «Гибкое аэрокосмическое производство». Nepcon East 1995, Бостон.
  19. ^ Андерсон, Дэвид (2005). «Декларация взаимозависимости». Архивировано из оригинал 27 января 2018 г.. Получено 4 октября 2018.
  20. ^ Макдональд, Кент (1 ноября 2016 г.). «Как вы можете помочь Agile Alliance помочь вам». Блог Agile Alliance. Получено 4 июля 2017.
  21. ^ «Изучение Agile-манифеста». Ambysoft Inc. Получено 6 апреля 2011.
  22. ^ Джим Хайсмит (2001). "История: манифест Agile". agilemanifesto.org.
  23. ^ а б Кент Бек; Джеймс Греннинг; Роберт С. Мартин; Майк Бидл; Джим Хайсмит; Стив Меллор; Ари ван Беннекум; Эндрю Хант; Кен Швабер; Алистер Кокберн; Рон Джеффрис; Джефф Сазерленд; Уорд Каннингем; Джон Керн; Дэйв Томас; Мартин Фаулер; Брайан Марик (2001). «Принципы Agile Manifesto». Agile Alliance. В архиве из оригинала 14 июня 2010 г.. Получено 6 июн 2010.
  24. ^ Моран, А. (2014). Гибкое управление рисками. Springer Verlag. ISBN  978-3319050072.
  25. ^ Бек, Кент (1999). «Принятие изменений с помощью экстремального программирования». Компьютер. 32 (10): 70–77. Дои:10.1109/2.796139.
  26. ^ Мергель, Инес (июль 2016 г.). «Гибкое управление инновациями в правительстве: программа исследований». Ежеквартальная правительственная информация. 33 (3): 516–523. Дои:10.1016 / j.giq.2016.07.004.
  27. ^ Прейс, Дебора Хартманн (13 октября 2006 г.). «Этюд: совместные команды против фермы в кубикл». InfoQ. Получено 23 октября 2018.
  28. ^ Кокберн, Алистер (2007). «Гибкая разработка программного обеспечения: совместная игра». www.pearson.com (2-е изд.). Эддисон-Уэсли Профессионал. Получено 23 октября 2018.
  29. ^ Джайн, Парита; Шарма, Арун; Ахуджа, Лакшми (август 2018 г.). «Влияние гибкого процесса разработки программного обеспечения на качество программного продукта». 2018 7-я Международная конференция по надежности, инфокоммуникационным технологиям и оптимизации (тенденции и будущие направления) (ICRITO). Нойда, Индия: IEEE: 812–815. Дои:10.1109 / ICRITO.2018.8748529. ISBN  978-1-5386-4692-2.
  30. ^ Кокберн, Алистер (19 июня 2008 г.). «Информационный радиатор».
  31. ^ Эмблер, Скотт (12 апреля 2002 г.). Agile Modeling: эффективные методы экстремального программирования и унифицированный процесс. Джон Вили и сыновья. С. 12, 164, 363. ISBN  978-0-471-20282-0.
  32. ^ Василяускас, Видас (2014). «Разработка гибких проектных задач и методов управления командой». Эйлин. Архивировано из оригинал 15 сентября 2014 г.. Получено 15 сентября 2014.
  33. ^ Джеффрис, Рон; Андерсон, Энн; Хендриксон, Чет (2001). Установлено экстремальное программирование. Аддисон-Уэсли. стр.72–147. ISBN  978-0201-70842-4.
  34. ^ Лиза Криспин; Джанет Грегори (2009). Гибкое тестирование: практическое руководство для тестировщиков и гибких команд. Эддисон-Уэсли.
  35. ^ Митчелл, Ян (2016). Гибкая разработка на практике. Tamare House. п. 11. ISBN  978-1-908552-49-5.
  36. ^ Ларман, Крейг (2004). Гибкая и итеративная разработка: руководство для менеджера. Эддисон-Уэсли. п. 27. ISBN  978-0-13-111155-4.
  37. ^ Бём, Б.; Р. Тернер (2004). Уравновешивание ловкости и дисциплины: руководство для озадаченных. Бостон, Массачусетс: Аддисон-Уэсли. ISBN  978-0-321-18612-6. Приложение A, страницы 165–194
  38. ^ Ларман, Крэйг (2004). «Глава 11: Практические советы». Гибкая и итеративная разработка: руководство для менеджера. п. 253. ISBN  9780131111554. Получено 14 октября 2013.
  39. ^ Слайгер, Микеле; Бродерик, Стейша (2008). Мост менеджера программного проекта к гибкости. Эддисон-Уэсли. п. 46. ISBN  978-0-321-50275-9.
  40. ^ а б Бём, Б.; Р. Тернер (2004). Уравновешивание ловкости и дисциплины: руководство для озадаченных. Бостон, Массачусетс: Аддисон-Уэсли. С. 55–57. ISBN  978-0-321-18612-6.
  41. ^ «В начале: разработка проекта против разработки продукта». AltexSoft Inc. 12 февраля 2016 г.. Получено 31 мая 2016.
  42. ^ Ракитин, Стивен Р. (2001). "Manifesto Elicits Cynicism: Читательское письмо редактору Стивена Р. Ракитина". IEEE Computer. 34: 4. Статья под названием «Гибкая разработка программного обеспечения: бизнес инноваций» ... это еще одна попытка подорвать дисциплину разработки программного обеспечения ... Мы хотим тратить все свое время на кодирование. Помните, настоящие программисты не пишут документацию.
  43. ^ а б Скотт Эмблер. «Agile / Lean Documentation: Стратегии гибкой разработки программного обеспечения».
  44. ^ Скотт Эмблер. «Достаточно хороших моделей и документов: передовая практика Agile».
  45. ^ Джеффри Уайзман (18 июля 2007 г.). "Требуется ли для гибких методов документация?". InfoQ. цитирование Купер, Ян (6 июля 2007 г.). «Сигналы стаккато: гибкость и документация». WordPress.com.
  46. ^ а б c Абрахамсон П., Сало О., Ронкайнен Дж., Варста Дж. (2002). Методы гибкой разработки программного обеспечения: обзор и анализ (PDF) (Технический отчет). VTT. 478.
  47. ^ «Руководство по гибким методам разработки». Agile Alliance. Архивировано из оригинал 9 февраля 2014 г.
  48. ^ а б Айдын, М.Н .; Harmsen, F .; Slooten; Стэгви, Р. А. (2004). «Используемый метод разработки гибких информационных систем». Турок Дж Элек Энгин. 12 (2): 127–138.
  49. ^ Моррис, Дэвид (2015). Парадокс гибкой трансформации: почему излишние попытки быть гибкими не позволяют организациям стать по-настоящему гибкими. НЗ: Оклендский университет. Дои:10.13140 / RG.2.2.32698.08640.
  50. ^ Абрахамссон, П., Варста, Дж., Сипонен, М.Т., и Ронкайнен, Дж. (2003). Новые направления гибких методов: сравнительный анализ. Материалы ICSE'03, 244-254
  51. ^ Мирахорли, М .; Rad, A.K .; Shams, F .; Pazoki, M .; Мирахорли, А. (2008). «Техника RDP: практика настройки xp». Материалы международного семинара 2008 года по изучению гибких практик или перестрелки в гибком загоне (APOS '08). ACM. С. 23–32. Дои:10.1145/1370143.1370149. ISBN  978-1-60558-021-0. S2CID  9528636.
  52. ^ Швабер, К. (2006) Скрам сложен и разрушителен.
  53. ^ Водде, B (2016) История LeSS. Заключительный доклад. Скрам Австралия, Мельбурн. Апрель 2016 г.
  54. ^ Lagstedt, A., and Dahlberg, T. (2018). Понимание редкости выбора метода ISD - ограниченная рациональность и функциональная глупость. Протокол PACIS 2018. 154. https://aisel.aisnet.org/pacis2018/154.
  55. ^ Парк, Дж. С., МакМахон, П. Э. и Майбург, Б. (2016). Scrum на основе Essence. ACM SIGSOFT Software Engineering Notes, 41 (1), стр. 1–8.
  56. ^ Бек, К. (1999). Объяснение экстремального программирования: примите изменения. Бостон, Массачусетс: Аддисон-Уэсли. ISBN  978-0-321-27865-4.
  57. ^ Эванс, Ян. «Гибкая доставка в British Telecom». Получено 21 февраля 2011.
  58. ^ а б В. Скотт Эмблер (2006) Больше меня в журнале доктора Добба, 15 февраля 2006 г.
  59. ^ Шааф, Р.Дж. (2007). Ловкость XL Конференция по системам и программным технологиям 2007 г. В архиве 13 марта 2016 г. Wayback Machine, Тампа, Флорида
  60. ^ «Преодолевая расстояние». Sdmagazine.com. Получено 1 февраля 2011.
  61. ^ Фаулер, Мартин. «Использование гибкого программного процесса с оффшорной разработкой». Martinfowler.com. Получено 6 июн 2010.
  62. ^ Леффингуэлл, Дин. «Масштабируемая гибкая структура». Масштабируемая гибкая структура.
  63. ^ Швабер, Кен. «Руководство по Nexus: полное руководство по Nexus: экзоскелет масштабной разработки Scrum» (PDF). scrum.org. Получено 14 сентября 2015.
  64. ^ Сазерленд, Джефф; Браун, Алекс (23 июля 2014 г.). «Scrum в масштабе: часть 1». Получено 14 сентября 2015.
  65. ^ Бидл, Майк. «Enterprise Scrum». Получено 25 сентября 2015.
  66. ^ Эббадж, Майкл. «Сетчу - гибкость в масштабе». Получено 30 сентября 2015.
  67. ^ «XSCALE Alliance». XSCALE Альянс. Получено 15 октября 2020.
  68. ^ «Agilepath - Сотрудничай. Инновации. Успех». Agile-path.com. 18 января 2019 г.. Получено 26 марта 2019.
  69. ^ «Архивная копия». Архивировано из оригинал 28 декабря 2018 г.. Получено 18 сентября 2019.CS1 maint: заархивированная копия как заголовок (ссылка на сайт)
  70. ^ Семинар по гибким процессам II. Управление несколькими параллельными проектами Agile. Вашингтон: OOPSLA 2002
  71. ^ Коули, Оисин; Ван, Сяофэн; Ричардсон, Ита (2010). Абрахамссон, Пекка; Оза, Нилай (ред.). Методологии Lean / Agile разработки программного обеспечения в регулируемых средах - современное состояние. Программное обеспечение и системы для экономичного предприятия. Конспект лекций по обработке деловой информации. 65. С. 31–36. Дои:10.1007/978-3-642-16416-3_4. HDL:10344/683. ISBN  978-3-642-16415-6.
  72. ^ МакХью, Мартин; Маккаффери, Фергал; Коуди, Гаррет (4 ноября 2014 г.). Митасюнас, Антанас; Раут, Терри; О'Коннор, Рори В .; и другие. (ред.). Гибкое внедрение в организации по разработке программного обеспечения для медицинских устройств. Улучшение программного процесса и определение возможностей. Коммуникации в компьютерных и информационных науках. 477. С. 190–201. Дои:10.1007/978-3-319-13036-1_17. ISBN  978-3-319-13035-4.
  73. ^ Ван, Ян; Рамадани, Жасмин; Вагнер, Стефан (29 ноября 2017 г.). Исследовательское исследование применения процесса разработки Scrum для систем, критически важных для безопасности. Улучшение процесса разработки программного обеспечения, ориентированного на продукт. Конспект лекций по информатике. 10611. С. 324–340. arXiv:1703.05375. Bibcode:2017arXiv170305375W. Дои:10.1007/978-3-319-69926-4_23. ISBN  9783319699257. S2CID  4585465.
  74. ^ «SafeScrum - SINTEF». Sintef.no. Получено 26 марта 2019.
  75. ^ Тор Миклебуст, Тор Столхане, Гейр Кьетил Ханссен, Тормод Вин и Бёрге Хаугсет: Scrum, документация и стандарт программного обеспечения IEC 61508-3: 2010, http://www.sintef.no/globalassets/ec-61508-documentation-and-safescrum-psam12.pdf
  76. ^ Фитцджеральд, В .; Stol, K.-J .; O'Sullivan, R .; О'Брайен, Д. (май 2013 г.). Масштабирование гибких методов в регулируемых средах: отраслевой пример. 2013 35-я Международная конференция по программной инженерии (ICSE). С. 863–872. Дои:10.1109 / ICSE.2013.6606635. HDL:10344/3055. ISBN  978-1-4673-3076-3. S2CID  192403.
  77. ^ Бек, Кент (2000). Объяснение экстремального программирования. Эддисон-Уэсли. стр.1–24. ISBN  978-0201616415.
  78. ^ Датта, Субхаджит (2006). «Индекс измерения гибкости: метрика на перекрестке методологий разработки программного обеспечения». ACM-SE 44 Материалы 44-й ежегодной Юго-восточной региональной конференции. п. 271. Дои:10.1145/1185448.1185509. ISBN  1595933158.
  79. ^ "Интернет-журнал Дэвида Бока: Интернет-журнал". Jroller.com. Архивировано из оригинал 11 января 2006 г.. Получено 2 апреля 2010.
  80. ^ Питер Лаппо; Генри К. Андрей. «Оценка ловкости» (PDF). Архивировано из оригинал (PDF) 15 сентября 2009 г.. Получено 6 июн 2010.
  81. ^ Куриан, Тисни (2006). Метрики гибкости: количественный нечеткий подход для измерения гибкости программного процесса, ISAM-Proceedings of International Conference on Agile Manufacturing'06 (ICAM-2006), Норфолк, США
  82. ^ Джо Литтл (2 декабря 2007 г.). «Тест Nokia, специальный тест для схватки». Agileconsortium.blogspot.com. Получено 6 июн 2010.
  83. ^ Марк Зойфферт; Майберг, Швеция. «Тест Карлскруны, общий тест на адаптацию к гибкой методике». Mayberg.se. Получено 5 апреля 2014.
  84. ^ «Насколько вы проворны? (Пройдите этот тест на 42 балла)». allaboutagile.com/. Архивировано из оригинал 5 мая 2014 г.. Получено 3 апреля 2014.
  85. ^ «Результаты исследования гибких методологий» (PDF). Shine Technologies. Январь 2003 г. Архивировано с оригинал (PDF) 21 августа 2010 г.. Получено 3 июн 2010. 95% заявили, что не было никакого эффекта или снижение затрат ... 93% заявили, что производительность была лучше или значительно лучше ... 88% заявили, что качество было лучше или значительно лучше ... 83% заявили, что удовлетворенность бизнесом была лучше или значительно лучше
  86. ^ «Отчет о состоянии гибкой разработки за 2013 год: почему именно гибкая разработка?». stateofagile.com. 27 января 2014 года. Архивировано с оригинал 28 августа 2014 г.. Получено 13 августа 2014.
  87. ^ Статус-кво Agile, Второе исследование успеха и форм использования гибких методов. Дата обращения 1 июля 2015.
  88. ^ Эмблер, Скотт (3 августа 2006 г.). «Исследование говорит: Agile работает на практике». Доктора Добба. Получено 3 июн 2010. Только 6% указали, что их производительность снизилась ... 34% респондентов не сообщили об изменении производительности, а 60% сообщили о повышении производительности ... 66% [ответили], что качество выше ... 58% организаций сообщили повышение удовлетворенности, тогда как только 3% сообщают о снижении удовлетворенности.
  89. ^ "Отвечая на вопрос" Где доказательства того, что гибкие методы работают ". Agilemodeling.com. 19 января 2007 г.. Получено 2 апреля 2010.
  90. ^ Берег и смотритель 2008, п. 47
  91. ^ Бек, Кент (2000). Объяснение экстремального программирования. Эддисон-Уэсли. стр.48–49. ISBN  978-0201616415.
  92. ^ Роуз, Маргарет. «Определение спринта (разработка программного обеспечения)». searchsoftwarequality.techtarget.com. Получено 2 октября 2015.
  93. ^ Гольдштейн, Илан (11 октября 2011 г.). «Проблемы со спринтом - когда спринт превращается в обход». www.axisagile.com.au. Получено 8 июн 2014.
  94. ^ «Роли проекта и распределение ответственности». agile-only.com. Получено 15 июн 2014.
  95. ^ Борн, Линда. «Чем на самом деле занимается спонсор проекта?». blogs.pmi.org. Получено 8 июн 2014.
  96. ^ «9-й отчет о состоянии гибкой разработки». Этап Agile Survey. VersionOne. Архивировано из оригинал 12 января 2015 г.. Получено 8 июн 2014.
  97. ^ Симс, Крис; Джонсон, Хиллари Луиза (15 февраля 2011 г.). Элементы Scrum (Разжечь ред.). Dymaxicon. п. 73.
  98. ^ Ротман, Джоанна Ротман (25 августа 2011 г.). «Когда у вас вообще нет владельца продукта». www.jrothman.com. Получено 8 июн 2014.
  99. ^ Фокс, Алисса (8 апреля 2014 г.). «Работа с несколькими Agile-командами». techwhirl.com/. Получено 14 июн 2014.
  100. ^ «Ежедневная встреча Scrum». www.mountaingoatsoftware.com. Получено 14 июн 2014.
  101. ^ а б Мэй, Роберт. «Эффективное планирование спринта». www.agileexecutives.org. Архивировано из оригинал 28 июня 2014 г.. Получено 14 июн 2014.
  102. ^ а б Берчук, Стив. «Выполненная миссия: Скрам-мастер и технический участник». www.agileconnection.com. Получено 14 июн 2014.
  103. ^ Намта, Раджниш. «Мысли об автоматизации тестирования в Agile». www.infoq.com. Получено 14 июн 2014.
  104. ^ а б Band, Zvi (22 марта 2014 г.). «Технический долг + Красный Октябрь». Получено 8 июн 2014.
  105. ^ Шор, Джеймс. «Искусство гибкой разработки: рефакторинг». www.jamesshore.com. Получено 14 июн 2014.
  106. ^ «Шаг 4: планирование спринта (задачи)». www.allaboutagile.com. Архивировано из оригинал 29 июня 2014 г.. Получено 14 июн 2014.
  107. ^ Джордж, Клэр (3 марта 2014 г.). «Зачем ограничивать ваши незавершенные дела». leankit.com. Получено 14 июн 2014.
  108. ^ «Встреча по планированию спринта». www.mountaingoatsoftware.com. Получено 14 июн 2014.
  109. ^ Макмиллан, Кейт. «Время, ресурсы, объем ... и качество». www.adeptechllc.com. Получено 15 июн 2014.
  110. ^ «Текущее исследование ограничений Agile». Процедуры информатики. 78: 291–297. Январь 2016 г. Дои:10.1016 / j.procs.2016.02.056.
  111. ^ Моран, Алан (2015). Управление Agile: стратегия, реализация, организация и люди. Springer. ISBN  978-3-319-16262-1.
  112. ^ ExecutiveBrief, Какой жизненный цикл лучше всего подходит для вашего проекта?, Пм Хижина. По состоянию на 23 октября 2009 г.
  113. ^ «Гибкое управление проектами». VersionOne. Получено 1 июня 2015.
  114. ^ «Что такое гибкое управление?». Проект Laneways. Получено 1 июня 2015.
  115. ^ ТЫ СКАЗАЛ. «ADS Глава 201 Операционная политика программного цикла». Проверено 19 апреля 2017 г.
  116. ^ Институт управления проектами, Руководство к своду знаний по управлению проектами (Руководство PMBOK), пятое издание
  117. ^ Рише, Жан-Лу (2013). Гибкие инновации. Случаи и прикладные исследования, № 31. ESSEC-ISIS. ISBN  978-2-36456-091-8
  118. ^ Смит, Престон G (2007). Гибкая разработка продукта. Джосси-Басс. п. 25. ISBN  978-0-7879-9584-3.
  119. ^ Ньютон Ли (2014). «Попадание в чарты Billboard: производство музыки как гибкая разработка программного обеспечения», Цифровой да Винчи: компьютеры в музыке. Springer Science + Business Media. ISBN  978-1-4939-0535-5.
  120. ^ Моран, Алан (2015). Управление Agile: стратегия, реализация, организация и люди. Springer Verlag. ISBN  978-3-319-16262-1.
  121. ^ «Гибкое программирование - для вашей семьи».
  122. ^ Ларман, Крейг; Bas Vodde (13 августа 2009 г.). Десять основных организационных препятствий для широкомасштабного внедрения гибкой разработки. InformIT.
  123. ^ «Введение в управление гибридными проектами». 20 июля 2016 г.
  124. ^ Barlow, Jordan B .; Джастин Скотт Гибони; Марк Джеффри Кейт; Дэвид У. Уилсон; Райан М. Шуэцлер; Пол Бенджамин Лоури; Энтони Вэнс (2011). «Обзор и руководство по гибкой разработке в крупных организациях». Коммуникации Ассоциации информационных систем. 29 (1): 25–44. Дои:10.17705 / 1CAIS.02902.
  125. ^ Куперсмит, Купе. «Agile - это причуда».
  126. ^ а б Крухтен, Филипп (20 июня 2011 г.). "Подростковый кризис Agile?". InfoQ.
  127. ^ Ричард Утц, "Против админского языка", Хроника высшего образования, 24 июня 2020 г.
  128. ^ Кон, Майк (2015). Успех с Agile. Пирсон. С. 5–10. ISBN  978-0-321-57936-2.

дальнейшее чтение

внешние ссылки