✖


Jump to content

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

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

Гибкая разработка программного обеспечения — это общий термин для подходов к разработке программного обеспечения , которые отражают ценности и принципы, согласованные Agile Alliance , группой из 17 практиков программного обеспечения в 2001 году. [1] Как указано в Манифесте гибкой разработки программного обеспечения, специалисты-практики ценят: [2]

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

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

Многие методы разработки программного обеспечения возникли из гибкого мышления. Эти гибкие практики, иногда называемые Agile (с большой буквы А). [4] включать в себя требования, открытия и улучшение решений посредством совместных усилий самоорганизующихся и межфункциональных команд со своими клиентами / конечными пользователями . [5] [6]

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

История

[ редактировать ]

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

В течение 1990-х годов ряд облегченных методов разработки программного обеспечения развился в ответ на преобладающие тяжеловесные методы (часто называемые « водопадными» ), которые критики описывали как чрезмерно регулируемые, планируемые и микроуправляемые . [15] Эти облегченные методы включали: быструю разработку приложений (RAD) с 1991 года; [16] [17] единый процесс (UP) и метод разработки динамических систем (DSDM), оба с 1994 года; Скрам , с 1995 года; Crystal Clear и экстремальное программирование (XP), оба с 1996 года; и разработка на основе функций (FDD) с 1997 года. Хотя все они возникли до публикации Agile Manifesto , теперь их все вместе называют гибкими методами разработки программного обеспечения. [3]

Уже с 1991 года подобные изменения происходили в производстве. [18] [19] и управленческое мышление [20] производные от бережливого управления .

В 2001 году семнадцать разработчиков программного обеспечения встретились на курорте в Сноуберде , штат Юта , чтобы обсудить облегченные методы разработки. Это были: Кент Бек (экстремальное программирование), Уорд Каннингем (экстремальное программирование), Дэйв Томас ( PragProg , Ruby), Джефф Сазерленд (Scrum), Кен Швабер (Scrum), Джим Хайсмит (разработка адаптивного программного обеспечения), Алистер Кокберн (Crystal). , Роберт С. Мартин ( SOLID ), Майк Бидл (Scrum), Ари ван Беннекум, Мартин Фаулер ( OOAD и UML ), Джеймс Греннинг, Эндрю Хант (PragProg, Ruby), Рон Джеффрис (экстремальное программирование), Джон Керн , Брайан Марик (Рубин, TDD ) и Стив Меллор ( OOA ). Группа The Agile Alliance опубликовала Манифест гибкой разработки программного обеспечения . [2]

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

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

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

Ценности и принципы

[ редактировать ]

Ценности

[ редактировать ]

Agile-манифест гласит: [2]

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

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

То есть, хотя элементы справа имеют ценность, мы ценим элементы слева больше.

Скотт Эмблер объяснил: [23]

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

Представляя манифест от имени Agile Alliance, Джим Хайсмит сказал:

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

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

Принципы

[ редактировать ]

Ценности основаны на следующих принципах: [25]

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

Обзор

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

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

[ редактировать ]

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

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

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

[ редактировать ]

Шестой принцип гибкого манифеста разработки программного обеспечения гласит: «Самый эффективный и действенный метод передачи информации внутри команды разработчиков — это личное общение». В манифесте, написанном в 2001 году, когда видеоконференции еще не получили широкого распространения, в отношении передачи информации говорится, что команда не обязательно должна располагаться в одном месте.

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

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

Информационный радиатор

[ редактировать ]

В гибкой разработке программного обеспечения информационный радиатор представляет собой (обычно большой) физический дисплей, доску с стикерами или что-то подобное, расположенный на видном месте рядом с командой разработчиков, где его могут видеть прохожие. [36] В нем представлена ​​актуальная сводка состояния разработки продукта. [37] [38] Световой индикатор сборки также можно использовать для информирования команды о текущем состоянии разработки продукта.

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

[ редактировать ]

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

Фокус на качестве

[ редактировать ]

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

Философия

[ редактировать ]

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

Адаптивный и прогнозирующий

[ редактировать ]

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

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

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

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

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

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

[ редактировать ]

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

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

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

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

[ редактировать ]

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

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

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

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

Методы

[ редактировать ]
Поддержка жизненного цикла разработки программного обеспечения [52]
Гибкий унифицированный процесс (AUP) основан на унифицированном процессе (итеративной и поэтапной структуре процесса разработки программного обеспечения).

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

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

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

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

[ редактировать ]

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

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

Разработка через приемочное тестирование

[ редактировать ]
Этот абзац представляет собой отрывок из книги « Разработка через приемочное тестирование» . [ редактировать ]
Разработка через приемочное тестирование (ATDD) — это методология разработки , основанная на общении между бизнес-заказчиками, разработчиками и тестировщиками. [54] ATDD включает в себя многие из тех же методов, что и спецификация на примере (SBE), [55] [56] развитие, основанное на поведении (BDD), [57] разработка на основе примеров (EDD), [58] и разработка на основе поддержки, также называемая разработкой на основе историй (SDD). [59] Все эти процессы помогают разработчикам и тестировщикам понять потребности клиента до внедрения и позволяют клиентам общаться на языке своей предметной области.

Гибкое моделирование

[ редактировать ]
Этот абзац представляет собой отрывок из Agile-моделирования . [ редактировать ]
Гибкое моделирование (AM) — это методология моделирования и документирования программных систем, основанная на передовом опыте. Это набор ценностей и принципов, которые можно применить в проекте разработки (гибкого) программного обеспечения. Эта методология более гибкая, чем традиционные методы моделирования, что делает ее более подходящей для быстро меняющейся среды. [60] Это часть набора инструментов гибкой разработки программного обеспечения.

Гибкое тестирование

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

Невыполненные работы

[ редактировать ]
Этот абзац представляет собой выдержку из журнала отставания продукта . [ редактировать ]
В рамках гибкого управления проектами бэклог продукта относится к приоритетному списку функций, которые должен содержать продукт. Иногда его называют списком дел . [61] и считается «артефактом» (формой документации) в среде разработки программного обеспечения Scrum . [62] В разных средах управления проектами журнал невыполненных работ по продукту называется по-разному, например журнал невыполненных работ по продукту в Scrum, [62] [63] список рабочих задач в дисциплинированном agile , [63] [64] и пул опционов в бережливом режиме . [63] В рамках Scrum создание и постоянное поддержание бэклога продукта входит в обязанности владельца продукта . [65]

Развитие, основанное на поведении

[ редактировать ]
Этот абзац представляет собой отрывок из книги «Разработка, основанная на поведении» . [ редактировать ]
Разработка, управляемая поведением (BDD), включает в себя наименование тестов программного обеспечения с использованием языка предметной области для описания поведения кода .

Непрерывная интеграция

[ редактировать ]
Этот абзац представляет собой отрывок из книги « Непрерывная интеграция» . [ редактировать ]
Непрерывная интеграция (CI) — это практика частой интеграции изменений исходного кода и обеспечения работоспособности интегрированной кодовой базы.

Межфункциональная команда

[ редактировать ]
Этот абзац представляет собой отрывок из книги «Кросс-функциональная команда» . [ редактировать ]
( Межфункциональная команда XFN), также известная как многопрофильная команда или междисциплинарная команда, [66] [67] [68] — это группа людей с разным функциональным опытом, работающих для достижения общей цели. [69] В него могут входить люди из отделов финансов , маркетинга , операций и кадров . Обычно в него входят сотрудники всех уровней организации. Члены также могут быть не из организации (в частности, от поставщиков, ключевых клиентов или консультантов).

Ежедневный стендап

[ редактировать ]
Этот абзац представляет собой отрывок из стендапа . [ редактировать ]
Стоячее собрание (стум) — это собрание , в котором участники обычно участвуют стоя . Дискомфорт от длительного стояния предназначен для того, чтобы собрания были короткими.

Метод адаптации

[ редактировать ]

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

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

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

Соответствие ситуации следует рассматривать как отличительную характеристику между гибкими методами и более плановыми методами разработки программного обеспечения, при этом гибкие методы позволяют командам разработчиков продуктов адаптировать рабочие методы в соответствии с потребностями отдельных продуктов. [71] [70] Потенциально большинство гибких методов могут подойти для адаптации методов. [52] например, DSDM, адаптированный к контексту CMM . [72] и XP, адаптированные с использованием методики описания правил (RDP). [73] Однако не все сторонники agile согласны с тем, что Швабер отмечает, что «именно поэтому мы изначально и попали в беду, думая, что проблема заключалась в отсутствии идеальной методологии. Усилия [должны] быть сосредоточены на изменениях, [необходимых] на предприятии». . [74] Бас Водде подкрепил эту точку зрения, предположив, что в отличие от традиционных больших методологий, которые требуют от вас выбирать элементы, Scrum предоставляет основы, поверх которых вы добавляете дополнительные элементы для локализации и контекстуализации его использования. [75] Практики редко используют методы разработки систем или, в частности, гибкие методы, согласно книге, часто предпочитая опустить или адаптировать некоторые практики метода, чтобы создать собственный метод. [76]

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

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

[ редактировать ]

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

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

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

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

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

[ редактировать ]

Гибкие методы разработки программного обеспечения изначально считались наиболее подходящими для разработки некритических продуктов, поэтому их исключали из использования в регулируемых областях, таких как медицинское оборудование , фармацевтика, финансы, ядерные системы, автомобильная промышленность, авионика и т. д. Однако в последние несколько лет было предпринято несколько инициатив по адаптации гибких методов для этих областей. [85] [86] [87] [88] [89]

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

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

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

[ редактировать ]

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

Измерение гибкости

[ редактировать ]

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

[ редактировать ]

Индекс измерения гибкости , среди прочего, оценивает разработки по пяти измерениям разработки продукта (продолжительность, риск, новизна, усилия и взаимодействие). [92] Другие методы основаны на измеримых целях. [93] и одно исследование предполагает, что скорость можно использовать как показатель ловкости. Существуют также гибкие методы самооценки, позволяющие определить, использует ли команда методы гибкой разработки программного обеспечения (тест Nokia, [94] Карлскруна тест, [95] тест 42 балла). [96]

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

[ редактировать ]

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

Аналогичный опрос State of Agile проводится каждый год, начиная с 2006 года, с участием тысяч участников со всего сообщества разработчиков программного обеспечения. Это отслеживает тенденции в отношении предполагаемых преимуществ гибкости, извлеченных уроков и передовой практики. В каждом опросе сообщается о росте числа людей, утверждающих, что гибкая разработка программного обеспечения помогает им быстрее доставлять программное обеспечение; улучшает их способность управлять меняющимися приоритетами клиентов; и повышает их продуктивность. [98] Опросы также неизменно показывают лучшие результаты при использовании гибких методов разработки продуктов по сравнению с классическим управлением проектами. [99] [100] В целом, есть сообщения о том, что некоторые считают, что методы гибкой разработки еще слишком молоды, чтобы обеспечить проведение обширных академических исследований их успеха. [101]

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

[ редактировать ]

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

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

[ редактировать ]

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

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

[ редактировать ]

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

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

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

[ редактировать ]

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

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

[ редактировать ]

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

Роль владельца продукта заполнена неправильно.

[ редактировать ]

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

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

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

[ редактировать ]

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

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

[ редактировать ]

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

Решение задач в ежедневном стендапе

[ редактировать ]

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

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

[ редактировать ]

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

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

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

[ редактировать ]

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

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

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

[ редактировать ]
Дополнительная информация: Автоматизация тестирования.

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

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

Допустить накопление технического долга

[ редактировать ]
Дополнительная информация: Технический долг.

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

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

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

[ редактировать ]

Распространенным заблуждением является то, что гибкая разработка программного обеспечения допускает непрерывные изменения, однако журнал невыполненных итераций — это соглашение о том, какая работа может быть завершена во время итерации. [119] Слишком большой объем незавершенной работы (НЗП) приводит к неэффективности, например переключению контекста и организации очередей. [120] Команда должна избегать ощущения давления, требующего выполнения дополнительной работы. [121]

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

[ редактировать ]

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

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

[ редактировать ]

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

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

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

Гибкое управление проектами — это итеративный процесс разработки, в ходе которого от пользователей и заинтересованных сторон постоянно собирается обратная связь для создания правильного пользовательского опыта. Для выполнения гибкого процесса можно использовать разные методы, к ним относятся Scrum , экстремальное программирование , Lean и Kanban . [124] Термин гибкое управление применяется к итеративному, поэтапному методу управления деятельностью по проектированию и созданию инженерных, информационных технологий и других областей бизнеса, которые направлены на обеспечение разработки новых продуктов или услуг очень гибким и интерактивным способом, основанным на выраженных принципах. в Манифесте гибкой разработки программного обеспечения . [125] Метрики гибкого управления проектами помогают уменьшить путаницу, выявить слабые места и измерить производительность команды на протяжении всего цикла разработки. Гибкость цепочки поставок — это способность цепочки поставок справляться с неопределенностью и изменчивостью предложения и спроса. Гибкая цепочка поставок может быстро увеличивать и уменьшать свои мощности, поэтому она может адаптироваться к быстро меняющемуся потребительскому спросу. Наконец, стратегическая гибкость — это способность организации менять свой образ действий по мере развития ее среды. Ключом к стратегической гибкости является достаточно раннее распознавание внешних изменений и распределение ресурсов для адаптации к этим меняющимся условиям. [124]

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

Гибкое управление также предлагает простую структуру, способствующую общению и размышлению о прошлой работе среди членов команды . [128] Команды, которые использовали традиционное каскадное планирование и приняли гибкий способ разработки, обычно проходят этап трансформации и часто обращаются за помощью к agile-коучам, которые помогают командам провести более плавную трансформацию. Обычно существует два стиля гибкого коучинга: Agile-коучинг, основанный на подталкивании и вытягивании. Здесь «толкающая система» может относиться к предварительной оценке того, какие задачи могут быть включены в спринт (подталкивающая работа), например, типично для Scrum; тогда как «вытягивающая система» может относиться к среде, в которой задачи выполняются только при наличии ресурсов. [129] Гибкие подходы к управлению также использовались и адаптировались к деловому и государственному секторам. Например, в федеральном правительстве США Агентство США по международному развитию (USAID) использует подход к совместному управлению проектами, который фокусируется на включении стратегий сотрудничества, обучения и адаптации (CLA) для повторения и адаптации программ. [130]

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

В жизненном цикле проекта обычно имеется одна или несколько фаз.которые связаны с разработкой продукта, услуги или результата. Это называется жизненным циклом разработки (...). Адаптивные жизненные циклы бывают гибкими, итеративными или инкрементными. Подробный объем определяется и утверждается перед началом итерации. Адаптивные жизненные циклы также называют гибкими или ориентированными на изменения жизненными циклами. [131]

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

[ редактировать ]
Конференция Agile Brazil 2014

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

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

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

Критика

[ редактировать ]

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

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

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

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

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

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

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

См. также

[ редактировать ]

Ссылки

[ редактировать ]
  1. ^ «Что такое Agile?» . Гибкий Альянс . Проверено 16 июля 2024 г.
  2. ^ Перейти обратно: а б с Кент Бек ; Джеймс Греннинг; Роберт С. Мартин ; Майк Бидл; Джим Хайсмит ; Стив Меллор ; Арье ван Беннекум; Эндрю Хант ; Кен Швабер ; Алистер Кокберн ; Рон Джеффрис ; Джефф Сазерленд ; Уорд Каннингем ; Джон Керн; Дэйв Томас ; Мартин Фаулер ; Брайан Марик (2001). «Манифест гибкой разработки программного обеспечения» . Гибкий Альянс . Проверено 14 июня 2010 г.
  3. ^ Перейти обратно: а б Ларман, Крейг (2004). Гибкая и итеративная разработка: Руководство для менеджера . Аддисон-Уэсли. п. 27. ISBN  978-0-13-111155-4 .
  4. ^ Ралли (2010). «Agile с большой буквы «А» против Agile с маленькой буквы «а» » . Архивировано из оригинала 5 января 2016 года . Проверено 9 сентября 2015 г. {{cite web}}: CS1 maint: неподходящий URL ( ссылка )
  5. ^ Кольер 2011 .
  6. ^ «Что такое гибкая разработка программного обеспечения?» . Гибкий Альянс. 8 июня 2013 года . Проверено 4 апреля 2015 г.
  7. ^ Дыбо, Торе; Дингсойр, Торгейр (1 августа 2008 г.). «Эмпирические исследования гибкой разработки программного обеспечения: систематический обзор». Информационные и программные технологии . 50 (9–10): 833–859. дои : 10.1016/j.infsof.2008.01.006 . ISSN   0950-5849 . S2CID   2244031 .
  8. ^ Ли, Кванху; Ся, Вэйдун (2010). «На пути к Agile: комплексный анализ количественных и качественных полевых данных об гибкости разработки программного обеспечения». МИС Ежеквартально . 34 (1): 87–114. дои : 10.2307/20721416 . JSTOR   20721416 . S2CID   26477249 .
  9. ^ Кролл, Дж.; Ричардсон, И.; Прикладницкий Р.; Оди, JL (2018). «Эмпирические данные о разработке программного обеспечения Sun: систематическое картографическое исследование» . Информационные и программные технологии . 93 : 30–44. дои : 10.1016/j.infsof.2017.08.011 . hdl : 10344/6233 .
  10. ^ Джеральд М. Вайнберг , цитируется в Larman & Basili 2003 , стр. 47–56 «Мы занимались поэтапной разработкой еще в 1957 году в Лос-Анджелесе под руководством Берни Димсдейла из IBM's Service Bureau Corporation . Он был коллегой Джон фон Нейман , так что, возможно, он научился этому там или считал это совершенно естественным. Я помню, как Херб Джейкобс (в первую очередь, хотя мы все участвовали) разрабатывал большую симуляцию для 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. ^ Свамидасс, премьер-министр, изд. (2000), «Тяжёлая проектная организацияHEAVYWEIGHT PROJECT ORGANIZATION» , Энциклопедия производства и управления производством , Бостон, Массачусетс: Springer US, стр. 261–262, doi : 10.1007/1-4020-0612-8_400 , ISBN  978-1-4020-0612-8 , получено 22 июня 2022 г.
  16. ^ Мартин, Джеймс (1991). Быстрая разработка приложений . Макмиллан. ISBN  978-0-02-376775-3 .
  17. ^ Керр, Джеймс М.; Хантер, Ричард (1993). Внутри RAD: как построить полнофункциональную систему за 90 дней или меньше . МакГроу-Хилл. п. 3. ISBN  978-0-07-034223-1 .
  18. ^ Институт Якокки (1991). «Стратегия производственного предприятия XXI века: взгляд отрасли». Институт Якокки, Университет Лихай, Вифлеем, Пенсильвания.
  19. ^ Пресли, А., Дж. Миллс и Д. Лайлз (1995). «Гибкое аэрокосмическое производство». Nepcon East 1995, Бостон.
  20. ^ Санчес, Луис (ноябрь 2010 г.). «Обзор гибких производственных систем» . Международный журнал производственных исследований (39 (16): 3561-3600).
  21. ^ Андерсон, Дэвид (2005). «Декларация взаимозависимости» . Архивировано из оригинала 27 января 2018 года . Проверено 4 октября 2018 г.
  22. ^ Макдональд, Кент (1 ноября 2016 г.). «Как вы можете помочь Agile Alliance помочь вам» . Блог Agile Alliance . Проверено 4 июля 2017 г.
  23. ^ «Изучение Agile-манифеста» . Компания Ambysoft Inc. Проверено 6 апреля 2011 г.
  24. ^ Джим Хайсмит (2001). «История: Манифест Agile» . www.agilemanifesto.org.
  25. ^ Перейти обратно: а б Кент Бек ; Джеймс Греннинг; Роберт С. Мартин ; Майк Бидл; Джим Хайсмит ; Стив Меллор ; Арье ван Беннекум; Эндрю Хант ; Кен Швабер ; Алистер Кокберн ; Рон Джеффрис ; Джефф Сазерленд ; Уорд Каннингем ; Джон Керн; Дэйв Томас ; Мартин Фаулер ; Брайан Марик (2001). «Принципы Agile-манифеста» . Гибкий Альянс. Архивировано из оригинала 14 июня 2010 года . Проверено 6 июня 2010 г.
  26. ^ Институт управления проектами 2021 , 2.3.3 Подходы к развитию.
  27. ^ Рубин 2013 .
  28. ^ Институт управления проектами 2021 , §3.12 Включите изменения для достижения предполагаемого будущего состояния.
  29. ^ Моран, А. (2014). Гибкое управление рисками . Спрингер Верлаг. ISBN  978-3319050072 .
  30. ^ Бек, Кент (1999). «Принятие перемен с помощью экстремального программирования». Компьютер . 32 (10): 70–77. дои : 10.1109/2.796139 .
  31. ^ Мергель, Инес (июль 2016 г.). «Гибкое управление инновациями в правительстве: программа исследований» . Правительственная информация Ежеквартально . 33 (3): 516–523. дои : 10.1016/j.giq.2016.07.004 .
  32. ^ Пройсс, Дебора Хартманн (13 октября 2006 г.). «Исследование: совмещенные команды против фермы кабинок» . ИнфоQ . Проверено 23 октября 2018 г.
  33. ^ Кокберн, Алистер (2007). «Гибкая разработка программного обеспечения: совместная игра» . www.pearson.com (2-е изд.). Аддисон-Уэсли Профессионал . Проверено 23 октября 2018 г.
  34. ^ «Трансформация менеджмента | Исследования» .
  35. ^ Джайн, Парита; Шарма, Арун; Ахуджа, Лакшми (август 2018 г.). «Влияние гибкого процесса разработки программного обеспечения на качество программного продукта» . 2018 7-я Международная конференция по надежности, инфоком-технологиям и оптимизации (Тенденции и будущие направления) (ICRITO) . Нойда, Индия: IEEE. стр. 812–815. дои : 10.1109/ICRITO.2018.8748529 . ISBN  978-1-5386-4692-2 . S2CID   195775457 .
  36. ^ Институт управления проектами 2021 , §2.7.3.2 Информационные излучатели.
  37. ^ Кокберн, Алистер (19 июня 2008 г.). «Информационный радиатор» .
  38. ^ Эмблер, Скотт (12 апреля 2002 г.). Гибкое моделирование: эффективные практики экстремального программирования и унифицированного процесса . Джон Уайли и сыновья. стр. 12, 164, 363. ISBN.  978-0-471-20282-0 .
  39. ^ Василяускас, Видас (2014). «Разработка гибких методов управления проектами и командами» . Эйлин. Архивировано из оригинала 15 сентября 2014 года . Проверено 15 сентября 2014 г.
  40. ^ Джеффрис, Рон; Андерсон, Энн; Хендриксон, Чет (2001). Установлено экстремальное программирование . Аддисон-Уэсли. стр. 72–147 . ISBN  978-0201-70842-4 .
  41. ^ Лиза Криспин; Джанет Грегори (2009). Agile-тестирование: Практическое руководство для тестировщиков и Agile-команд . Аддисон-Уэсли.
  42. ^ Митчелл, Ян (2016). Гибкая разработка на практике . Дом Тамаре. п. 11. ISBN  978-1-908552-49-5 .
  43. ^ Ларман, Крейг (2004). Гибкая и итеративная разработка: Руководство для менеджера . Аддисон-Уэсли. п. 27. ISBN  978-0-13-111155-4 .
  44. ^ Бём, Б. ; Р. Тернер (2004). Баланс между ловкостью и дисциплиной: руководство для растерянных . Бостон, Массачусетс: Аддисон-Уэсли. ISBN  978-0-321-18612-6 . Приложение А, страницы 165–194.
  45. ^ Ларман, Крейг (2004). «Глава 11: Практические советы» . Гибкая и итеративная разработка: Руководство для менеджера . Аддисон-Уэсли Профессионал. п. 253. ИСБН  9780131111554 . Проверено 14 октября 2013 г.
  46. ^ Слайгер, Мишель; Бродерик, Стейша (2008). Мост менеджера проекта по разработке программного обеспечения к гибкости . Аддисон-Уэсли. п. 46. ​​ИСБН  978-0-321-50275-9 .
  47. ^ Перейти обратно: а б Бём, Б. ; Р. Тернер (2004). Баланс между ловкостью и дисциплиной: руководство для растерянных . Бостон, Массачусетс: Аддисон-Уэсли. стр. 55–57. ISBN  978-0-321-18612-6 .
  48. ^ Ракитин, Стивен Р. (2001). «Манифест вызывает цинизм: письмо читателя редактору Стивена Р. Ракитина». IEEE-компьютер . 34 (12): 4. дои : 10.1109/MC.2001.10095 . S2CID   221106984 . Статья под названием «Гибкая разработка программного обеспечения: бизнес инноваций»… является еще одной попыткой подорвать дисциплину разработки программного обеспечения… Мы хотим тратить все свое время на программирование. Помните, настоящие программисты не пишут документацию.
  49. ^ Перейти обратно: а б Скотт Эмблер (16 апреля 2023 г.). «Agile/Lean Документация: стратегии гибкой разработки программного обеспечения» .
  50. ^ Скотт Эмблер. «Едва достаточно хорошие модели и документы: лучшая практика Agile» . Архивировано из оригинала 8 октября 2014 года . Проверено 24 января 2014 г.
  51. ^ Джеффри Уайзман (18 июля 2007 г.). «Требуют ли гибкие методы документации?» . ИнфоВ. цитирование Купер, Ян (6 июля 2007 г.). «Сигналы стаккато: Agile и документация» . WordPress.com .
  52. ^ Перейти обратно: а б с Абрахамсон П., Сало О., Ронкайнен Дж., Варста Дж. (2002). Гибкие методы разработки программного обеспечения: обзор и анализ (PDF) (Технический отчет). ВТТ . 478.
  53. ^ «Руководство по гибким практикам» . Гибкий Альянс. Архивировано из оригинала 9 февраля 2014 года.
  54. ^ Пью, Кен (2011). Lean-Agile-разработка на основе приемочных испытаний: лучшее программное обеспечение благодаря сотрудничеству . Аддисон-Уэсли. ISBN  978-0321714084 .
  55. ^ Аджич, Гойко. (2009) Преодоление разрыва в общении: спецификация на примере и гибкое приемочное тестирование , Neuri Limited,
  56. ^ Аджич, Гойко (2011). Спецификация на примере: как успешные команды создают правильное программное обеспечение . Мэннинг. ISBN  978-0-321-27865-4 .
  57. ^ Челимский, Дэвид, Дэйв Астелс, Зак Деннис, Аслак Хеллесой, Брайан Хелмкамп и Дэн Норт. Книга RSpec: Разработка, основанная на поведении, с RSpec, Cucumber и друзьями. Прагматичная книжная полка.
  58. ^ «Примерный дизайн» . Проверено 15 апреля 2013 г.
  59. ^ «История разработки через тестирование» (PDF) . Проверено 15 апреля 2013 г.
  60. ^ Домашняя страница гибкого моделирования (AM), эффективные методы моделирования и документации.
  61. ^ Атласиан. «Журнал продукта: ваш окончательный список дел» . Атласиан . Проверено 19 декабря 2021 г.
  62. ^ Перейти обратно: а б «Что такое бэклог продукта?» . Скрам.орг . Проверено 19 декабря 2021 г.
  63. ^ Перейти обратно: а б с «Основная практика Agile: приоритетные требования» . www.agilemodeling.com . Проверено 19 декабря 2021 г.
  64. ^ «Артефакт: Список рабочих элементов» . www.utm.mx. ​Проверено 19 декабря 2021 г.
  65. ^ «Владелец продукта | Дирекция оцифровки» . Проверено 15 ноября 2021 г.
  66. ^ Что такое межфункциональная команда? Определение и значение
  67. ^ Использование XFN в качестве аббревиатуры
  68. ^ Блог лидеров под названием XFN.
  69. ^ Краевски, LJ и LP Ritzman. 2005. Управление операциями: процессы и цепочки создания стоимости. Образование Пирсона, река Аппер-Седл.
  70. ^ Перейти обратно: а б Айдын, Миннесота; Хармсен, Ф.; Слоотен; Стэгви, РА (2004). «Используется гибкий метод разработки информационных систем». Тюрк Дж. Элек Энгин . 12 (2): 127–138.
  71. ^ Моррис, Дэвид (2015). Парадокс гибкой трансформации: почему слишком усердные попытки стать гибкими мешают организациям стать по-настоящему гибкими . Новая Зеландия: Университет Окленда. дои : 10.13140/RG.2.2.32698.08640 .
  72. ^ Абрахамссон П., Варста Дж., Сипонен М.Т. и Ронкайнен Дж. (2003). Новые направления в гибких методах: сравнительный анализ. Труды ICSE'03 , 244-254.
  73. ^ Мирахорли, М.; Рад, АК; Шамс, Ф.; Пазоки, М.; Мирахорли, А. (2008). «Техника RDP: практика настройки XP». Материалы международного семинара 2008 года по изучению agile-практик или перестрелок в agile-загоне (APOS '08) . АКМ. стр. 23–32. дои : 10.1145/1370143.1370149 . ISBN  978-1-60558-021-0 . S2CID   9528636 .
  74. ^ Швабер, К. (2006) Скрам сложен и разрушительен.
  75. ^ Водде, Б. (2016) История LeSS. Заключительный доклад. Скрам Австралия, Мельбурн. Апрель 2016 г.
  76. ^ Лагстедт А. и Дальберг Т. (2018). Понимание редкости выбора метода ISD – ограниченная рациональность и функциональная глупость. Материалы конференции PACIS 2018. 154. https://aisel.aisnet.org/pacis2018/154 .
  77. ^ Парк, Дж. С., МакМахон, П. Е. и Майбург, Б. (2016). Скрам на базе Essence. Заметки по разработке программного обеспечения ACM SIGSOFT, 41 (1), стр. 1–8.
  78. ^ Бек, К. (1999). Объяснение экстремального программирования: примите изменения . Бостон, Массачусетс: Аддисон-Уэсли. ISBN  978-0-321-27865-4 .
  79. ^ Эванс, Ян. «Гибкая доставка в British Telecom» . Проверено 21 февраля 2011 г.
  80. ^ Перейти обратно: а б В. Скотт Эмблер (2006) Supersize Me в журнале доктора Добба, 15 февраля 2006 г.
  81. ^ Шааф, Р.Дж. (2007). Конференция Agility XL Systems and Software Technology 2007. Архивировано 13 марта 2016 г. в Wayback Machine , Тампа, Флорида.
  82. ^ «Преодолев расстояние» . Sdmagazine.com . Проверено 1 февраля 2011 г.
  83. ^ Фаулер, Мартин. «Использование гибкого процесса разработки программного обеспечения при оффшорной разработке» . Мартинфаулер.com . Проверено 6 июня 2010 г.
  84. ^ Семинар II по гибким процессам «Управление несколькими одновременными гибкими проектами». Вашингтон: OOPSLA 2002 г.
  85. ^ Коули, Оисин; Ван, Сяофэн; Ричардсон, Ита (2010). «Методологии бережливой/гибкой разработки программного обеспечения в регулируемых средах – современное состояние». В Абрахамссоне, Пекка; Оза, Нилай (ред.). Программное обеспечение и системы бережливого предприятия . Конспекты лекций по обработке деловой информации. Том. 65. стр. 31–36. дои : 10.1007/978-3-642-16416-3_4 . hdl : 10344/683 . ISBN  978-3-642-16415-6 .
  86. ^ Макхью, Мартин; Маккаффери, Фергал; Коуди, Гаррет (4 ноября 2014 г.). «Гибкая реализация в организации, занимающейся программным обеспечением медицинского оборудования». В Митасиунасе, Антанасе; Раут, Терри; О'Коннор, Рори В.; и др. (ред.). Улучшение процесса разработки программного обеспечения и определение возможностей . Коммуникации в компьютерной и информатике. Том. 477. стр. 190–201. дои : 10.1007/978-3-319-13036-1_17 . ISBN  978-3-319-13035-4 .
  87. ^ Ван, Ян; Рамадани, Жасмин; Вагнер, Стефан (29 ноября 2017 г.). «Исследовательское исследование по применению процесса разработки Scrum для систем, критически важных для безопасности». Улучшение процесса разработки программного обеспечения, ориентированного на продукт . Конспекты лекций по информатике. Том. 10611. С. 324–340. arXiv : 1703.05375 . Бибкод : 2017arXiv170305375W . дои : 10.1007/978-3-319-69926-4_23 . ISBN  9783319699257 . S2CID   4585465 .
  88. ^ «SafeScrum — СИНТЕФ» . Синтеф.номер . Проверено 26 марта 2019 г.
  89. ^ Тор Миклебуст, Тор Столхан, Гейр Кьетил Ханссен, Тормод Вен и Бёрге Хаугсет: Scrum, документация и стандарт программного обеспечения IEC 61508-3: 2010, http://www.sintef.no/globalassets/ec-61508-documentation-and -safescrum-psam12.pdf
  90. ^ Фицджеральд, Б.; Стол, К.-Дж.; О'Салливан, Р.; О'Брайен, Д. (май 2013 г.). «Масштабирование гибких методов в регулируемой среде: пример из отрасли». 2013 35-я Международная конференция по программной инженерии (ICSE) . стр. 863–872. дои : 10.1109/ICSE.2013.6606635 . HDL : 10344/3055 . ISBN  978-1-4673-3076-3 . S2CID   192403 .
  91. ^ Бек, Кент (2000). Объяснение экстремального программирования . Аддисон-Уэсли. стр. 1–24 . ISBN  978-0201616415 .
  92. ^ Датта, Субхаджит (2006). «Индекс измерения гибкости: показатель пересечения методологий разработки программного обеспечения». ACM-SE 44 Материалы 44-й ежегодной Юго-восточной региональной конференции . п. 271. дои : 10.1145/1185448.1185509 . ISBN  1595933158 .
  93. ^ Питер Лаппо; Генри CT Эндрю. «Оценка гибкости» (PDF) . Архивировано из оригинала (PDF) 15 сентября 2009 года . Проверено 6 июня 2010 г.
  94. ^ Джо Литтл (2 декабря 2007 г.). «Тест Nokia. Тест, специфичный для Scrum» . Agileconsortium.blogspot.com . Проверено 6 июня 2010 г.
  95. ^ Марк Зойферт; Майберг, Швеция. «Тест Карлскруны. Общий тест на внедрение Agile» . Mayberg.se . Проверено 5 апреля 2014 г.
  96. ^ «Насколько вы гибки? (Пройдите тест из 42 пунктов)» . allaboutagile.com/. Архивировано из оригинала 5 мая 2014 года . Проверено 3 апреля 2014 г.
  97. ^ «Результаты исследования гибких методологий» (PDF) . Сияющие Технологии. Январь 2003 г. Архивировано из оригинала (PDF) 21 августа 2010 г. . Проверено 3 июня 2010 г. 95% заявили, что эффекта либо не было, либо произошло снижение затрат... 93% заявили, что производительность стала лучше или значительно лучше... 88% заявили, что качество стало лучше или значительно лучше... 83% заявили, что удовлетворенность бизнесом стала выше или значительно лучше
  98. ^ «Отчет о состоянии Agile за 2013 год: почему Agile?» . Stateofagile.com. 27 января 2014 года. Архивировано из оригинала 28 августа 2014 года . Проверено 13 августа 2014 г.
  99. ^ Status Quo Agile , Второе исследование успеха и форм использования гибких методов. Проверено 1 июля 2015 г.
  100. ^ Эмблер, Скотт (3 августа 2006 г.). «Опрос показал: Agile работает на практике» . Доктор Добб . Проверено 3 июня 2010 г. Только 6% указали, что их производительность снизилась... Об изменении производительности сообщили 34% респондентов, а 60% сообщили о повышении производительности... 66% [ответили], что качество выше... 58% организаций сообщают повышение удовлетворенности, тогда как только 3% сообщают о снижении удовлетворенности.
  101. ^ «Ответ на вопрос «Где доказательства того, что гибкие методы работают?» . Agilemodeling.com. 19 января 2007 года . Проверено 2 апреля 2010 г.
  102. ^ Шор и Уорден 2008 , с. 47
  103. ^ Бек, Кент (2000). Объяснение экстремального программирования . Аддисон-Уэсли. стр. 48–49 . ISBN  978-0201616415 .
  104. ^ Роуз, Маргарет. «Определение спринта (разработки программного обеспечения)» . searchsoftwarequality.techtarget.com . Проверено 2 октября 2015 г.
  105. ^ Гольдштейн, Илан (11 октября 2011 г.). «Проблемы спринта – когда спринты превращаются в ползание» . www.axisagile.com.au . Проверено 8 июня 2014 г.
  106. ^ «Роли в проекте и распределение ответственности» . agile-only.com . Проверено 15 июня 2014 г.
  107. ^ Борн, Линда. «Чем на самом деле занимается спонсор проекта?» . blogs.pmi.org . Архивировано из оригинала 7 июня 2014 года . Проверено 8 июня 2014 г.
  108. ^ «9-й отчет о состоянии Agile» . Этап Agile-исследования . Версия первая. Архивировано из оригинала 12 января 2015 года . Проверено 8 июня 2014 г.
  109. ^ Симс, Крис; Джонсон, Хиллари Луиза (15 февраля 2011 г.). Элементы Scrum (изд. Kindle). Димаксикон. п. 73.
  110. ^ Ротман, Джоанна Ротман (25 августа 2011 г.). «Когда у вас вообще нет владельца продукта» . www.jrothman.com . Проверено 8 июня 2014 г.
  111. ^ Фокс, Алисса (8 апреля 2014 г.). «Работа в нескольких Agile-командах» . techwhirl.com/ . Проверено 14 июня 2014 г.
  112. ^ «Ежедневное Scrum-совещание» . www.mountaingoatsoftware.com . Проверено 14 июня 2014 г.
  113. ^ Перейти обратно: а б Мэй, Роберт. «Эффективное планирование спринта» . www.agileexecutives.org . Архивировано из оригинала 28 июня 2014 года . Проверено 14 июня 2014 г.
  114. ^ Берчук, Стив. «Миссия выполнима: ScrumMaster и технический участник» . www.agileconnection.com . Проверено 14 июня 2014 г.
  115. ^ «Как внедрить Agile Scrum» . Проверено 4 января 2022 г.
  116. ^ Намта, Раджниш. «Мысли об автоматизации тестирования в Agile» . www.infoq.com . Проверено 14 июня 2014 г.
  117. ^ Перейти обратно: а б Банда, Цви (22 марта 2014 г.). «Техдолг + Красный Октябрь» . Проверено 8 июня 2014 г.
  118. ^ Шор, Джеймс. «Искусство гибкой разработки: рефакторинг» . www.jamesshore.com . Проверено 14 июня 2014 г.
  119. ^ «Шаг 4: Планирование спринта (задачи)» . www.allaboutagile.com . Архивировано из оригинала 29 июня 2014 года . Проверено 14 июня 2014 г.
  120. ^ Джордж, Клэр (3 марта 2014 г.). «Почему ограничение незавершенной работы имеет значение» . сайт Leankit.com . Проверено 14 июня 2014 г.
  121. ^ «Совещание по планированию спринта» . www.mountaingoatsoftware.com . Проверено 14 июня 2014 г.
  122. ^ Макмиллан, Кейт (13 мая 2010 г.). «Время, ресурсы, объем... и качество» . www.adeptechllc.com . Проверено 15 июня 2014 г.
  123. ^ «Текущее исследование ограничений Agile» . Procedia Информатика . 78 : 291–297. Январь 2016 г. doi : 10.1016/j.procs.2016.02.056 .
  124. ^ Перейти обратно: а б «Призыв к закупкам для Agile. Что это значит?» . 1 ноября 2019 г.
  125. ^ Моран, Алан (2015). Управление Agile: стратегия, реализация, организация и люди . Спрингер. ISBN  978-3-319-16262-1 .
  126. ^ «Какой жизненный цикл лучше всего подходит для вашего проекта?» . ПМХут . 22 октября 2008 года . Проверено 23 октября 2009 г.
  127. ^ «Гибкое управление проектами» . Версия первая . Проверено 1 июня 2015 г.
  128. ^ «Что такое Agile-менеджмент?» . Проект «Лейнвейс» . Проверено 1 июня 2015 г.
  129. ^ Бенсон, Джим; Де Мария Барри, Тонианна (2011). Персональный канбан: работа с картами, навигация по жизни (1-е изд.). Сиэтл, Вашингтон: Modus Cooperandi Press. п. 38. ISBN  978-1-4538-0226-7 .
  130. ^ ЮСАИД. «Эксплуатационная политика программного цикла ADS, глава 201». Архивировано 23 октября 2019 года в Wayback Machine . Проверено 19 апреля 2017 г.
  131. ^ Институт управления проектами , Руководство по своду знаний по управлению проектами (Руководство PMBOK), шестое издание
  132. ^ Рише, Жан-Лу (2013). Гибкие инновации . Примеры и прикладные исследования, № 31. ЭССЕК-ИСИС. ISBN   978-2-36456-091-8
  133. ^ Смит, Престон Дж. (2007). Гибкая разработка продуктов . Джосси-Басс. п. 25. ISBN  978-0-7879-9584-3 .
  134. ^ Ньютон Ли (2014). «Попадание в чарты Billboard: музыкальное производство как гибкая разработка программного обеспечения», Digital Da Vinci: компьютеры в музыке . Springer Science+Business Media. ISBN  978-1-4939-0535-5 .
  135. ^ Моран, Алан (2015). Управление Agile: стратегия, реализация, организация и люди . Спрингер Верлаг. ISBN  978-3-319-16262-1 .
  136. ^ Барретт, М.; Гуделл, Дж. (2022), «Инструменты Lean-Agile разработки», Learning Engineering Toolkit , Routledge, стр. 269–278, doi : 10.4324/9781003276579-16 , ISBN  978-1-003-27657-9
  137. ^ «Гибкое программирование – для вашей семьи» .
  138. ^ Ларман, Крейг; Бас Водде (13 августа 2009 г.). Десять основных организационных препятствий на пути широкомасштабного внедрения Agile . ИнформИТ.
  139. ^ «Введение в управление гибридными проектами» . 20 июля 2016 г.
  140. ^ Барлоу, Джордан Б.; Джастин Скотт Гибони; Марк Джеффри Кейт; Дэвид В. Уилсон; Райан М. Шютцлер; Пол Бенджамин Лоури; Энтони Вэнс (2011). «Обзор и руководство по гибкой разработке в крупных организациях» . Сообщения Ассоциации информационных систем . 29 (1): 25–44. дои : 10.17705/1CAIS.02902 .
  141. ^ Куперсмит, Купе (4 июля 2011 г.). «Agile — это мода» .
  142. ^ Перейти обратно: а б Крухтен, Филипп (20 июня 2011 г.). «Подростковый кризис Agile?» . ИнфоВ.
  143. ↑ Ричард Утц, «Против административной речи», Хроника высшего образования , 24 июня 2020 г.
  144. ^ Кон, Майк (2015). Достижение успеха с помощью Agile . Пирсон. стр. 5–10. ISBN  978-0-321-57936-2 .

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

[ редактировать ]
[ редактировать ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Agile_software_development&oldid=1238706820#The_Manifesto_for_Agile_Software_Development"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: bea69ccc4e928de7af7193f36f561c70__1722834420
URL1:https://arc.ask3.ru/arc/aa/be/70/bea69ccc4e928de7af7193f36f561c70.html
Заголовок, (Title) документа по адресу, URL1:
Agile software development - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)