Гибкая разработка программного обеспечения
| Часть серии о |
| Разработка программного обеспечения |
|---|
Гибкая разработка программного обеспечения — это подход к разработке программного обеспечения , основанный на ценностях, согласованных Agile Alliance , группой из 17 практиков программного обеспечения в 2001 году. Как указано в их Манифесте гибкой разработки программного обеспечения, практикующие специалисты ценят: [1]
- Люди и взаимодействие над процессами и инструментами
- Рабочее программное обеспечение над подробной документацией
- Сотрудничество с клиентами во время переговоров по контракту
- Реагирование на изменения в соответствии с планом
Практики ссылаются на новые практики того времени, включая экстремальное программирование , Scrum , метод разработки динамических систем , адаптивную разработку программного обеспечения , и сочувствуют необходимости альтернативы тяжеловесным процессам разработки программного обеспечения, основанным на документации. [2]
Многие методы разработки программного обеспечения возникли из гибкого мышления. Эти Agile-практики, иногда называемые Agile (с большой буквы А). [3] включать в себя требования, открытия и улучшение решений посредством совместных усилий самоорганизующихся и межфункциональных команд со своими клиентами / конечными пользователями . [4] [5]
Хотя существует множество неофициальных свидетельств того, что гибкое мышление и методы, основанные на гибкой гибкости, улучшают процесс разработки программного обеспечения, эмпирические данные ограничены и далеко не убедительны. [6] [7] [8]
История [ править ]
Итеративные и инкрементные методы разработки программного обеспечения можно проследить еще в 1957 году. [9] с эволюционным управлением проектами [10] [11] и адаптивная разработка программного обеспечения [12] возникшие в начале 1970-х гг. [13]
В 1990-е годы ряд облегченных методов разработки программного обеспечения развился в ответ на преобладающие тяжеловесные методы (часто называемые « водопадными» ), которые критики описывали как чрезмерно регулируемые, плановые и микроуправляемые . [14] Эти облегченные методы включали: быструю разработку приложений (RAD) с 1991 года; [15] [16] единый процесс (UP) и метод разработки динамических систем (DSDM), оба с 1994 года; Скрам , с 1995 года; Crystal Clear и экстремальное программирование (XP), оба с 1996 года; и разработка на основе функций (FDD) с 1997 года. Хотя все они возникли до публикации Agile Manifesto , теперь их все вместе называют гибкими методами разработки программного обеспечения. [2]
Уже с 1991 года подобные изменения происходили в производстве. [17] [18] и управленческое мышление [19] производные от бережливого управления .
В 2001 году семнадцать разработчиков программного обеспечения встретились на курорте в Сноуберде , штат Юта , чтобы обсудить облегченные методы разработки. Это были: Кент Бек (экстремальное программирование), Уорд Каннингем (экстремальное программирование), Дэйв Томас ( PragProg , Ruby), Джефф Сазерленд (Scrum), Кен Швабер (Scrum), Джим Хайсмит (разработка адаптивного программного обеспечения), Алистер Кокберн (Crystal). , Роберт К. Мартин ( SOLID ), Майк Бидл (Scrum), Ари ван Беннекум, Мартин Фаулер ( OOAD и UML ), Джеймс Греннинг, Эндрю Хант (PragProg, Ruby), Рон Джеффрис (экстремальное программирование), Джон Керн , Брайан Марик (Рубин, TDD ) и Стив Меллор ( OOA ). Группа The Agile Alliance опубликовала Манифест гибкой разработки программного обеспечения . [1]
В 2005 году группа, возглавляемая Кокберном и Хайсмитом, написала дополнение к принципам управления проектами — Декларацию премьер-министра о взаимозависимости. [20] направлять управление программными проектами в соответствии с гибкими методами разработки программного обеспечения.
В 2009 году группа, работающая с Мартином, написала расширение принципов разработки программного обеспечения , « Манифест мастерства программного обеспечения» , чтобы направлять гибкую разработку программного обеспечения в соответствии с профессиональным поведением и мастерством.
В 2011 году Agile Alliance создал « Руководство по Agile-практикам» (в 2016 году переименованное в Agile Glossary ). [21] развивающийся сборник с открытым исходным кодом рабочих определений практик, терминов и элементов гибкой разработки, а также интерпретаций и руководств по опыту мирового сообщества практиков гибкой разработки.
Мышление [ править ]
Ценности [ править ]
Agile-манифест гласит: [1]
Мы открываем лучшие способы разработки программного обеспечения, делая это и помогая другим делать это. Благодаря этой работе мы пришли к выводу:
- Люди и взаимодействие над процессами и инструментами
- Рабочее программное обеспечение над подробной документацией
- Сотрудничество с клиентами во время переговоров по контракту
- Реагирование на изменения в соответствии с планом
То есть, хотя элементы справа имеют ценность, мы ценим элементы слева больше.
Скотт Эмблер объяснил: [22]
- Инструменты и процессы важны, но еще важнее иметь компетентных людей, эффективно работающих вместе.
- Хорошая документация помогает людям понять, как устроено программное обеспечение и как его использовать, но основной целью разработки является создание программного обеспечения, а не документации.
- Контракт важен, но он не заменяет тесного сотрудничества с клиентами, чтобы выяснить, что им нужно.
- План проекта важен, но он не должен быть слишком жестким, чтобы учитывать изменения в технологии или окружающей среде, приоритеты заинтересованных сторон и понимание людьми проблемы и ее решения.
Представляя манифест от имени Agile Alliance, Джим Хайсмит сказал:
Движение Agile не является антиметодологией, на самом деле многие из нас хотят восстановить доверие к слову «методология». Мы хотим восстановить баланс. Мы занимаемся моделированием, но не для того, чтобы закинуть какую-то диаграмму в пыльный корпоративный репозиторий. Мы принимаем документацию, а не сотни страниц никогда не поддерживаемых и редко используемых томов. Мы планируем, но осознаем пределы планирования в турбулентной среде. Те, кто называет сторонников XP, SCRUM или любой другой гибкой методологии «хакерами», не знают ни самих методологий, ни исходного определения термина «хакер».
— Джим Хайсмит, История: Манифест Agile [23]
Принципы [ править ]
Ценности основаны на следующих принципах: [24]
- Удовлетворение потребностей клиентов за счет своевременной и непрерывной поставки ценного программного обеспечения.
- Приветствуйте изменение требований, даже на поздней стадии разработки.
- Часто доставляйте работающее программное обеспечение (недели, а не месяцы).
- Тесное, ежедневное сотрудничество бизнесменов и девелоперов.
- Проекты строятся вокруг мотивированных людей, которым следует доверять.
- Разговор с глазу на глаз — лучшая форма общения (colocation).
- Работающее программное обеспечение является основным показателем прогресса.
- Устойчивое развитие, способное поддерживать постоянный темп.
- Постоянное внимание к техническому совершенству и хорошему дизайну.
- Простота – искусство максимизировать объем невыполненной работы – имеет важное значение.
- Лучшие архитектуры , требования и проекты создаются самоорганизующимися командами.
- Команда регулярно размышляет о том, как стать более эффективной, и соответствующим образом корректирует ситуацию.
Обзор [ править ]
Итеративный, инкрементный и эволюционный [ править ]
Большинство методов гибкой разработки разбивают работу по разработке продукта на небольшие этапы, которые минимизируют объем предварительного планирования и проектирования. Итерации или спринты — это короткие временные рамки ( таймбоксы ). [25] обычно это длится от одной до четырех недель. [26] : 20 В каждой итерации участвует межфункциональная команда , работающая над всеми функциями: планирование , анализ , проектирование , кодирование , модульное тестирование и приемочное тестирование . В конце итерации заинтересованным сторонам демонстрируется работающий продукт. Это сводит к минимуму общий риск и позволяет продукту быстро адаптироваться к изменениям. [27] [28] Итерация может не добавить достаточной функциональности, чтобы гарантировать выпуск на рынок, но цель состоит в том, чтобы иметь доступный выпуск (с минимальным количеством ошибок ) в конце каждой итерации. [29] Благодаря поэтапной разработке продукты имеют возможность « часто и рано выходить из строя » на каждом этапе итерации, а не резко в день окончательного выпуска. [30] Для выпуска продукта или новых функций может потребоваться несколько итераций. Работающее программное обеспечение является основным показателем прогресса. [24]
Ключевым преимуществом гибких подходов является скорость выхода на рынок и снижение рисков. На рынок обычно выводятся меньшие приращения, что снижает временные и финансовые риски, связанные с разработкой продукта, который не соответствует требованиям пользователя.
Эффективное и личное общение [ править ]
Шестой принцип гибкого манифеста разработки программного обеспечения гласит: «Самый эффективный и действенный метод передачи информации внутри команды разработчиков — это личное общение». В манифесте, написанном в 2001 году, когда видеоконференции еще не получили широкого распространения, в отношении передачи информации говорится, что команда не обязательно должна располагаться в одном месте.
Принцип совместного размещения заключается в том, что сотрудники одной команды должны располагаться вместе, чтобы лучше укрепить идентичность команды и улучшить общение. [31] Это обеспечивает личное взаимодействие , в идеале перед доской, что сокращает время цикла, которое обычно занимает, когда вопросы и ответы передаются по телефону, постоянному чату , вики или электронной почте. [32] С широким распространением удаленной работы во время пандемии COVID-19 и изменениями в инструментах было проведено больше исследований. [33] вокруг совместного размещения и распределенной работы, которые показывают, что совместное размещение становится все менее актуальным.
Независимо от того, какой метод разработки используется, в каждой команде должен быть представитель заказчика он называется владельцем продукта ( в Scrum ). Заинтересованные стороны соглашаются, что этот представитель будет действовать от их имени, и он берет на себя личное обязательство быть доступным для разработчиков, чтобы отвечать на вопросы на протяжении всей итерации. В конце каждой итерации участники проекта вместе с представителем заказчика анализируют ход выполнения и переоценивают приоритеты с целью оптимизации окупаемости инвестиций (ROI) и обеспечения соответствия потребностям заказчика и целям компании. Важность удовлетворения заинтересованных сторон, детализируемая посредством частого взаимодействия и анализа в конце каждого этапа, является причиной того, что этот подход часто называют методологией, ориентированной на клиента . [34]
Информационный радиатор [ править ]
В гибкой разработке программного обеспечения информационный радиатор представляет собой (обычно большой) физический дисплей, доску с стикерами или что-то подобное, расположенный на видном месте рядом с командой разработчиков, где его могут видеть прохожие. [35] В нем представлена актуальная сводка состояния разработки продукта. [36] [37] Световой индикатор сборки также можно использовать для информирования команды о текущем состоянии разработки продукта.
короткий цикл обратной связи и адаптации цикл Очень
Общей характеристикой гибкой разработки программного обеспечения является ежедневный стендап (известный как ежедневный Scrum в рамках Scrum). В ходе короткого занятия (например, 15 минут) члены команды коллективно анализируют, как они продвигаются к своей цели, и соглашаются, нужно ли им адаптировать свой подход. Чтобы соблюсти согласованный лимит времени, команды часто используют простые закодированные вопросы (например, что они выполнили накануне, что они планируют выполнить в этот день, есть ли какие-либо препятствия или риски для прогресса) и откладывают детальное обсуждение и решение проблем. решение до окончания стендапа. [38]
Фокус на качестве [ править ]
Конкретные инструменты и методы, такие как непрерывная интеграция , автоматизированное модульное тестирование , парное программирование , разработка через тестирование , шаблоны проектирования , разработка на основе поведения , проектирование на основе предметной области , рефакторинг кода и другие методы, часто используются для повышения качества и улучшения разработки продуктов. ловкость. [39] Это зависит от качества проектирования и создания с самого начала и возможности продемонстрировать программное обеспечение клиентам в любой момент или, по крайней мере, в конце каждой итерации. [40]
Философия [ править ]
По сравнению с традиционной разработкой программного обеспечения, гибкая разработка программного обеспечения в основном нацелена на разработку сложных систем и продуктов с динамическими, недетерминированными и нелинейными свойствами . Точные оценки, стабильные планы и прогнозы зачастую трудно получить на ранних стадиях, и доверие к ним, скорее всего, будет низким. Практикующие Agile используют свою свободную волю чтобы уменьшить « скачок веры », который необходим, прежде чем какие-либо доказательства ценности . , можно будет получить [41] Требования и проектирование считаются возникающими . В таких случаях большие предварительные спецификации, вероятно, приведут к большим потерям, т. е. будут экономически нецелесообразными. Эти основные аргументы и предыдущий отраслевой опыт , извлеченный из многих лет успехов и неудач, помогли сформировать в гибкой разработке предпочтение адаптивной, итеративной и эволюционной разработки. [42]
Адаптивный или прогнозирующий [ править ]
Существуют различные методы разработки: от адаптивных до прогнозирующих . [43] Гибкие методы разработки программного обеспечения лежат на адаптивной стороне этого континуума. Одним из ключевых методов адаптивной разработки является подход к планированию графика на основе катущей волны , который определяет вехи, но оставляет гибкость в пути их достижения, а также позволяет изменять сами вехи. [44]
Адаптивные методы направлены на быструю адаптацию к меняющимся реалиям. Когда потребности проекта меняются, меняется и адаптивная команда. Адаптивная команда испытывает трудности с точным описанием того, что произойдет в будущем. Чем дальше дата, тем более расплывчатым является адаптивный метод относительно того, что произойдет в эту дату. Адаптивная команда не может точно сообщить, какие задачи они будут выполнять на следующей неделе, а только то, какие функции они планируют реализовать в следующем месяце. Когда адаптивную команду спросят о выпуске через шесть месяцев, она сможет сообщить только формулировку миссии релиза или заявление об ожидаемой ценности и стоимости.
Прогностические методы, напротив, фокусируются на детальном анализе и планировании будущего и учитывают известные риски. В крайнем случае, команда прогнозистов может точно сообщить, какие функции и задачи запланированы на протяжении всего процесса разработки. Прогнозные методы основаны на эффективном анализе на ранней стадии, и если что-то пойдет не так, проекту может быть трудно изменить направление. Команды прогнозирования часто создают совет по контролю изменений , чтобы гарантировать, что они рассматривают только наиболее ценные изменения.
Анализ рисков можно использовать для выбора между адаптивными ( гибкими или ориентированными на ценность ) и прогнозирующими ( ориентированными на план ) методами. [45] Барри Бём и Ричард Тернер предполагают, что у каждой стороны континуума есть своя «домашняя территория» , а именно: [46]
| Методы, ориентированные на ценность (гибкие) | Плановые методы (водопад) | Формальные методы |
|---|---|---|
| Низкая критичность | Высокая критичность | Крайняя критичность |
| Старшие разработчики | Младшие разработчики(?) | Старшие разработчики |
| Требования часто меняются | Требования меняются не часто | Ограниченные требования, ограниченные возможности, см. закон Вирта. [ нужны разъяснения ] |
| Небольшое количество разработчиков | Большое количество разработчиков | Требования, которые можно смоделировать |
| Культура, которая реагирует на изменения | Культура, которая требует порядка | Экстремальное качество |
Agile против водопада [ править ]
Одним из отличий гибких методов разработки программного обеспечения от каскадных является подход к качеству и тестированию. В водопадной модели работа проходит через этапы жизненного цикла разработки программного обеспечения (SDLC) — причем один этап завершается до начала другого, поэтому этап тестирования является отдельным и следует за этапом сборки . Однако при гибкой разработке программного обеспечения тестирование завершается на той же итерации, что и программирование.
Поскольку тестирование проводится на каждой итерации, при которой разрабатывается небольшая часть программного обеспечения, пользователи могут часто использовать эти новые части программного обеспечения и проверять их ценность. После того, как пользователи узнают реальную ценность обновленной части программного обеспечения, они смогут принять более обоснованные решения относительно будущего программного обеспечения. Проведение ретроспективы ценности и сеанса перепланирования программного обеспечения на каждой итерации ( в Scrum обычно итерации длятся всего две недели) помогает команде постоянно корректировать свои планы, чтобы максимизировать приносимую ими ценность. Это следует шаблону, аналогичному циклу «планируй-делай-проверяй-действуй» (PDCA), поскольку работа планируется , выполняется , проверяется (в обзоре и ретроспективе), и любые согласованные изменения принимаются в действие.
Этот итеративный подход поддерживает продукт , а не проектное мышление. Это обеспечивает большую гибкость на протяжении всего процесса разработки; тогда как в проектах требования определены и зафиксированы с самого начала, что затрудняет их дальнейшее изменение. Итеративная разработка продукта позволяет программному обеспечению развиваться в ответ на изменения в бизнес-среде или требованиях рынка.
Код против документации [ править ]
В письме в IEEE Computer Стивен Ракитин выразил цинизм по поводу гибкой разработки программного обеспечения, назвав это « еще одной попыткой подорвать дисциплину разработки программного обеспечения » и переведя « работающее программное обеспечение вместо всеобъемлющей документации », поскольку « мы хотим тратить все свое время на программирование». Помните, настоящие программисты не пишут документацию ». [47]
Это оспаривается сторонниками гибкой разработки программного обеспечения, которые заявляют, что разработчики должны писать документацию, если это лучший способ достижения соответствующих целей, но часто существуют лучшие способы достижения этих целей, чем написание статической документации. [48] Скотт Эмблер утверждает, что документация должна быть «достаточно хорошей» (JBGE). [49] что слишком большая или исчерпывающая документация обычно приводит к ненужным тратам, а разработчики редко доверяют подробной документации, поскольку она обычно не синхронизирована с кодом, [48] в то время как слишком мало документации может также вызвать проблемы с обслуживанием, общением, обучением и обменом знаниями. Алистер Кокберн писал о методе Crystal Clear :
Кристал рассматривает разработку серии кооперативных игр и предполагает, что документации будет достаточно, чтобы помочь в следующей победе в следующей игре. Рабочие продукты для Crystal включают варианты использования, список рисков, план итераций, основные модели предметной области и примечания к проектированию, информирующие о выборе... однако для этих документов нет шаблонов, и описания обязательно расплывчаты, но цель ясна, просто документации достаточно для следующей игры. Я всегда склонен охарактеризовать это для своей команды так: что бы вы хотели знать, если бы присоединились к команде завтра.
— Алистер Кокберн [50]
Методы [ править ]
Гибкие методы разработки программного обеспечения поддерживают широкий спектр жизненного цикла разработки программного обеспечения . [51] Некоторые методы сосредоточены на практиках (например, XP , прагматическое программирование , гибкое моделирование), тогда как некоторые сосредоточены на управлении потоком работы (например, Scrum, Kanban). Некоторые поддерживают деятельность по спецификации и разработке требований (например, FDD ), тогда как некоторые стремятся охватить полный жизненный цикл разработки (например, DSDM , RUP ).
Известные гибкие среды разработки программного обеспечения включают:
| Рамки | Главный участник(и) |
|---|---|
| Адаптивная разработка программного обеспечения (ASD) | Джим Хайсмит , Сэм Байер |
| Гибкое моделирование | Скотт Эмблер , Роберт Сесил Мартин |
| Гибкий унифицированный процесс (AUP) | Скотт Эмблер |
| Дисциплинированная гибкая доставка | Скотт Эмблер |
| Метод разработки динамических систем (DSDM) | Дженнифер Стэплтон |
| Экстремальное программирование (XP) | Кент Бек , Роберт Сесил Мартин |
| Разработка на основе функций (FDD) | Джефф ДеЛука |
| Бережливая разработка программного обеспечения | Мэри Поппендик, Том Поппендик |
| Бережливый стартап | Эрик Райс |
| Канбан | Тайичи Оно |
| Быстрая разработка приложений (RAD) | Джеймс Мартин |
| Скрам | Кен Швабер , Джефф Сазерленд |
| Разрушение |
методы разработки Гибкие обеспечения программного
Гибкая разработка программного обеспечения поддерживается рядом конкретных практик, охватывающих такие области, как требования, проектирование, моделирование, кодирование, тестирование, планирование, управление рисками, процессы, качество и т. д. Некоторые известные гибкие методы разработки программного обеспечения включают в себя: [52]
| Упражняться | Главный участник(и) |
|---|---|
| Разработка через приемочное тестирование (ATDD) | |
| Гибкое моделирование | |
| Гибкое тестирование | |
| Бэклоги (продукт и спринт) | Кен Швабер |
| Разработка, основанная на поведении (BDD) | Дэн Норт, Лиз Кио |
| Непрерывная интеграция (CI) | Грейди Буч |
| Межфункциональная команда | |
| Ежедневный стендап / Ежедневный Scrum | Джеймс О'Коплиен |
| Доменно-ориентированное проектирование (DDD) | Эрик Эванс |
| Итеративная и инкрементальная разработка (IID) | |
| Парное программирование | Кент Бек |
| Планирование покера | Джеймс Греннинг, Майк Кон |
| Рефакторинг | Мартин Фаулер |
| Ретроспектива | |
| Скрам-мероприятия (планирование спринта, обзор и ретроспектива спринта) | |
| Спецификация на примере | |
| Сюжетное моделирование | Альберт Цюндорф |
| Разработка через тестирование (TDD) | Кент Бек |
| Таймбоксинг | |
| История пользователя | Алистер Кокберн |
| Отслеживание скорости |
Разработка через приемочное тестирование [ править ]
Гибкое моделирование [ править ]
Гибкое тестирование [ править ]
Невыполненные работы [ править ]
поведении , Разработка основанная на
Непрерывная интеграция [ править ]
Межфункциональная команда [ править ]
Ежедневный стендап [ править ]
Адаптация метода [ править ]
В литературе к понятию адаптации метода относятся разные термины, в том числе «адаптация метода», «адаптация фрагмента метода» и «инжиниринг ситуационного метода». Адаптация метода определяется как:
Процесс или способность, в которой агенты-люди определяют подход к разработке системы для конкретной проектной ситуации посредством оперативных изменений и динамического взаимодействия между контекстами, намерениями и фрагментами методов.
- Мехмет Нафиз Айдин и др., Используемый метод разработки гибких информационных систем. [69]
Соответствие ситуации следует рассматривать как отличительную характеристику между гибкими методами и более плановыми методами разработки программного обеспечения, при этом гибкие методы позволяют группам разработчиков продуктов адаптировать рабочие методы в соответствии с потребностями отдельных продуктов. [70] [69] Потенциально большинство гибких методов могут подойти для адаптации методов. [51] например, DSDM, адаптированный к контексту CMM . [71] и XP, адаптированные с использованием методики описания правил (RDP). [72] Однако не все сторонники agile согласны с тем, что Швабер отмечает, что «именно поэтому мы изначально и попали в беду, думая, что проблема заключалась в отсутствии идеальной методологии. Усилия [должны] быть сосредоточены на изменениях, [необходимых] на предприятии». . [73] Бас Водде подкрепил эту точку зрения, предположив, что в отличие от традиционных больших методологий, которые требуют от вас выбирать элементы, Scrum предоставляет основы, поверх которых вы добавляете дополнительные элементы для локализации и контекстуализации его использования. [74] Практики редко используют методы разработки систем или, в частности, гибкие методы, согласно книге, часто предпочитая опустить или адаптировать некоторые практики метода, чтобы создать собственный метод. [75]
На практике методы можно адаптировать с помощью различных инструментов. Универсальные языки моделирования процессов, такие как Unified Modeling Language, можно использовать для адаптации методов разработки программного обеспечения. специальные инструменты для разработки методов, такие как Essence Theory of Software Engineering SEMAT . Однако также существуют [76]
Крупномасштабные, оффшорные и распределенные [ править ]
Гибкая разработка программного обеспечения широко рассматривается как наиболее подходящая для определенных типов сред, в том числе для небольших групп экспертов, работающих над новыми проектами . [46] [77] а проблемы и ограничения, возникающие при внедрении гибких методов разработки программного обеспечения в крупной организации с устаревшей инфраструктурой, хорошо документированы и понятны. [78]
В ответ был разработан ряд стратегий и моделей для преодоления проблем с помощью крупномасштабных усилий по разработке (>20 разработчиков). [79] [80] или распределенные (не совмещенные) команды разработчиков, [81] [82] среди других проблем; и в настоящее время существует несколько признанных рамок, которые стремятся смягчить или избежать этих проблем.
Существует множество противоречивых точек зрения на то, эффективны ли все эти подходы или действительно ли они соответствуют определению гибкой разработки, и этот вопрос остается активной и постоянной областью исследований. [79] [83]
Когда гибкая разработка программного обеспечения применяется в распределенной среде (когда команды рассредоточены по нескольким офисам), ее обычно называют распределенной гибкой разработкой программного обеспечения . Цель состоит в том, чтобы максимально использовать уникальные преимущества, предлагаемые каждым подходом. Распределенная разработка позволяет организациям создавать программное обеспечение, стратегически создавая команды в разных частях земного шара, создавая программное обеспечение практически круглосуточно (чаще называемая моделью «следующего за солнцем»). С другой стороны, гибкая разработка обеспечивает повышенную прозрачность, постоянную обратную связь и большую гибкость при реагировании на изменения.
Регулируемые домены [ править ]
Гибкие методы разработки программного обеспечения изначально считались наиболее подходящими для разработки некритических продуктов, поэтому их исключали из использования в регулируемых областях, таких как медицинское оборудование , фармацевтика, финансы, ядерные системы, автомобильная промышленность, авионика и т. д. Однако в последние несколько В течение многих лет было предпринято несколько инициатив по адаптации гибких методов для этих областей. [84] [85] [86] [87] [88]
Существует множество стандартов, которые могут применяться в регулируемых областях, включая ISO 26262 , ISO 9000 , ISO 9001 и ISO/IEC 15504 . Ряд ключевых проблем имеет особое значение в регулируемых сферах: [89]
- Обеспечение качества (ОК): Систематическое и неотъемлемое управление качеством, лежащее в основе контролируемого профессионального процесса, а также надежности и правильности продукции.
- Безопасность и безопасность: формальное планирование и управление рисками для снижения рисков безопасности пользователей и надежной защиты пользователей от непреднамеренного и злонамеренного неправильного использования.
- Прослеживаемость : документация, обеспечивающая проверяемые доказательства соответствия нормативным требованиям и облегчающая отслеживание и расследование проблем.
- Верификация и валидация (V&V): встроены в процесс разработки программного обеспечения (например, спецификация требований пользователя, функциональная спецификация, спецификация проекта, проверка кода, модульные тесты, интеграционные тесты, системные тесты).
Опыт внедрение и
Хотя на практике методы гибкой разработки программного обеспечения можно использовать с любой парадигмой программирования или языком, изначально они были тесно связаны с объектно-ориентированными средами, такими как Smalltalk, Lisp, а затем с Java, C#. Первыми, кто применял гибкие методы, обычно были небольшие и средние команды, работавшие над беспрецедентными системами с требованиями, которые было трудно доработать и которые могли измениться по мере разработки системы. В этом разделе описаны общие проблемы, с которыми сталкиваются организации, когда пытаются внедрить гибкие методы разработки программного обеспечения, а также различные методы измерения качества и производительности гибких команд. [90]
гибкости Измерение
Внутренние оценки [ править ]
Индекс измерения гибкости , среди прочего, оценивает разработки по пяти измерениям разработки продукта (продолжительность, риск, новизна, усилия и взаимодействие). [91] Другие методы основаны на измеримых целях. [92] и одно исследование предполагает, что скорость можно использовать как показатель ловкости. Существуют также гибкие методы самооценки, позволяющие определить, использует ли команда методы гибкой разработки программного обеспечения (тест Nokia, [93] Карлскруна тест, [94] тест 42 балла). [95]
Общественные опросы [ править ]
Одним из первых исследований, сообщающих о повышении качества, производительности и удовлетворенности бизнеса за счет использования гибких методов разработки программного обеспечения, было исследование, проведенное Shine Technologies с ноября 2002 года по январь 2003 года. [96]
Аналогичный опрос State of Agile проводится каждый год, начиная с 2006 года, с участием тысяч участников со всего сообщества разработчиков программного обеспечения. Это отслеживает тенденции в отношении предполагаемых преимуществ гибкости, извлеченных уроков и передовой практики. В каждом опросе сообщается о росте числа людей, утверждающих, что гибкая разработка программного обеспечения помогает им быстрее доставлять программное обеспечение; улучшает их способность управлять меняющимися приоритетами клиентов; и повышает их продуктивность. [97] Опросы также неизменно показывают лучшие результаты при использовании гибких методов разработки продуктов по сравнению с классическим управлением проектами. [98] [99] В целом, есть сообщения о том, что некоторые считают, что методы гибкой разработки еще слишком молоды, чтобы проводить обширные академические исследования их успеха. [100]
гибкой разработки программного Распространенные ошибки обеспечения
Организации и команды, реализующие гибкую разработку программного обеспечения, часто сталкиваются с трудностями при переходе от более традиционных методов, таких как каскадная разработка , например, когда командам навязывают гибкий процесс. [101] Их часто называют гибкими антипаттернами или, чаще, гибкими запахами . Ниже приведены некоторые распространенные примеры:
Отсутствие общего дизайна продукта [ править ]
Цель гибкой разработки программного обеспечения — больше сосредоточиться на создании работающего программного обеспечения, а не на документации. В этом отличие от каскадных моделей, где процесс часто строго контролируется, а незначительные изменения в системе требуют значительного пересмотра сопроводительной документации. Однако это не оправдывает полного отказа от какого-либо анализа или проектирования. Неспособность уделить внимание дизайну может привести к тому, что команда сначала будет действовать быстро, но затем потребуется значительная доработка при попытке масштабирования системы. Одной из ключевых особенностей гибкой разработки программного обеспечения является то, что она является итеративной. Если все сделано правильно, гибкая разработка программного обеспечения позволяет проекту проявляться по мере разработки системы и помогает команде обнаружить общие черты и возможности для повторного использования. [102]
Добавление историй в итерацию в процессе [ править ]
При гибкой разработке программного обеспечения истории (похожие на описания вариантов использования ) обычно используются для определения требований, а итерация — это короткий период времени, в течение которого команда ставит перед собой конкретные цели. [103] Добавление историй в текущую итерацию вредит хорошему ходу работы. Их следует добавить в очередь продукта и расставить приоритеты для последующей итерации или, в редких случаях, итерацию можно отменить. [104]
Это не означает, что история не может расширяться. Командам приходится иметь дело с новой информацией, что может привести к появлению дополнительных задач для истории. Если новая информация не позволяет завершить историю во время итерации, то ее следует перенести на следующую итерацию. Однако ей следует отдать приоритет по сравнению со всеми остальными историями, поскольку новая информация могла изменить первоначальный приоритет истории.
Отсутствие спонсорской поддержки [ править ]
Гибкая разработка программного обеспечения часто реализуется в организациях как коллективная работа команд разработчиков программного обеспечения, пытающихся оптимизировать процессы разработки и обеспечить согласованность жизненного цикла разработки программного обеспечения. Не имея спонсорской поддержки, команды могут столкнуться с трудностями и сопротивлением со стороны деловых партнеров, других команд разработчиков и руководства. Кроме того, они могут пострадать без надлежащего финансирования и ресурсов. [105] Это увеличивает вероятность неудачи. [106]
Недостаточная подготовка [ править ]
Опрос, проведенный VersionOne, показал, что респонденты назвали недостаточное обучение наиболее значимой причиной неудачного внедрения agile. [107] Команды попали в ловушку, предполагая, что сокращение процессов гибкой разработки программного обеспечения по сравнению с другими подходами, такими как водопад, означает, что не существует реальных правил гибкой разработки программного обеспечения. [ нужна цитата ]
Роль владельца продукта заполнена неправильно [ править ]
Владелец продукта отвечает за представление бизнеса в процессе разработки и зачастую является самой ответственной ролью. [108]
Распространенной ошибкой является назначение на роль владельца продукта кого-то из команды разработчиков. Это требует от команды принятия собственных решений по расстановке приоритетов без реальной обратной связи со стороны бизнеса. Они пытаются решать бизнес-проблемы внутри компании или откладывают работу, обращаясь за советом за пределами команды. Это часто приводит к отвлечению внимания и нарушению сотрудничества. [109]
Команды не сфокусированы [ править ]
Гибкая разработка программного обеспечения требует от команд выполнения обязательств по продукту, а это означает, что они должны сосредоточиться на работе только над этим продуктом. Однако от членов команды, у которых, как представляется, есть свободные мощности, часто ожидают, что они возьмут на себя другую работу, что затрудняет им выполнение работы, которую взяла на себя их команда. [110]
подготовка планирование Чрезмерная /
Команды могут попасть в ловушку, тратя слишком много времени на подготовку или планирование. Это обычная ловушка для команд, менее знакомых с гибкой разработкой программного обеспечения, когда команды чувствуют себя обязанными иметь полное понимание и спецификацию всех историй. Команды должны быть готовы продвигаться вперед только с теми историями, в которых они уверены, а затем во время итерации продолжать обнаруживать и готовить работу для последующих итераций (часто это называется уточнением или очисткой отставания).
Решение проблем в ежедневном стендапе [ править ]
Ежедневный стендап должен представлять собой целенаправленную и своевременную встречу, на которой все члены команды распространяют информацию. Если в решении проблемы и происходит, то в нем часто могут участвовать только определенные члены команды, и это потенциально не лучшее использование времени всей команды. Если во время ежедневного стендапа команда начинает погружаться в решение проблем, его следует отложить до тех пор, пока подгруппа не сможет обсудить проблему, обычно сразу после завершения стендапа. [111]
Назначение задач [ править ]
Одним из предполагаемых преимуществ гибкой разработки программного обеспечения является предоставление команде возможности делать выбор, поскольку она ближе всего к проблеме. Кроме того, им следует делать выбор как можно ближе к реализации, чтобы использовать при принятии решения более своевременную информацию. Если членам команды поручают задачи другие или слишком рано в процессе, преимущества локализованного и своевременного принятия решений могут быть потеряны. [112]
Назначение работы также ограничивает членов команды определенными ролями (например, член команды А должен всегда выполнять работу с базой данных), что ограничивает возможности перекрестного обучения. [112] Сами члены команды могут брать на себя задачи, которые расширяют их способности и предоставляют возможности перекрестного обучения.
Скрам-мастер как участник [ править ]
В рамках Scrum, которая утверждает, что соответствует ценностям и принципам Agile, роль Scrum-мастера отвечает за обеспечение соблюдения процесса Scrum и за обучение Scrum-команды в ходе этого процесса. Распространенной ошибкой является то, что скрам-мастер выступает в роли участника. Хотя это и не запрещено структурой Scrum, Scrum-мастеру необходимо убедиться, что он способен сначала действовать в роли Scrum-мастера, а не работать над задачами разработки. Роль Scrum-мастера — облегчить процесс, а не создать продукт. [113]
Если Scrum-мастер одновременно выполняет несколько задач, это может привести к слишком большому количеству переключений контекста, что не позволит продуктивно работать. Кроме того, поскольку Scrum-мастер отвечает за устранение препятствий, чтобы команда могла продвигаться вперед, выгода, получаемая от продвижения отдельных задач, может не перевешивать препятствия, которые откладываются из-за нехватки возможностей. [114]
Отсутствие автоматизации тестирования [ править ]
Из-за итеративного характера гибкой разработки часто требуется несколько раундов тестирования. Автоматизированное тестирование помогает снизить влияние повторных модульных, интеграционных и регрессионных тестов и позволяет разработчикам и тестировщикам сосредоточиться на более ценной работе. [115]
Автоматизация тестирования также поддерживает постоянный рефакторинг, необходимый для итеративной разработки программного обеспечения. Разрешение разработчику быстро запускать тесты для подтверждения того, что рефакторинг не изменил функциональность приложения, может снизить рабочую нагрузку и повысить уверенность в том, что усилия по очистке не привели к появлению новых дефектов.
Допустить накопление технического долга [ править ]
Сосредоточение внимания на предоставлении новых функций может привести к увеличению технического долга . Команда должна выделить себе время на исправление дефектов и рефакторинг. Технический долг мешает планированию, увеличивая объем незапланированной работы, поскольку производственные дефекты отвлекают команду от дальнейшего прогресса. [116]
По мере развития системы важно проводить рефакторинг . [117] Со временем отсутствие постоянного обслуживания приводит к увеличению количества дефектов и затрат на разработку. [116]
Попытка взять на себя слишком много за итерацию [ править ]
Распространенным заблуждением является то, что гибкая разработка программного обеспечения допускает непрерывные изменения, однако журнал невыполненных итераций — это соглашение о том, какая работа может быть завершена во время итерации. [118] Слишком большой объем незавершенной работы (НЗП) приводит к неэффективности, например переключению контекста и организации очередей. [119] Команда должна избегать чувства давления, требующего выполнения дополнительной работы. [120]
Фиксированное время, ресурсы, объем и качество [ править ]
Гибкая разработка программного обеспечения заранее фиксирует время (продолжительность итерации), качество и, в идеале, ресурсы (хотя поддержание фиксированных ресурсов может быть затруднено, если разработчики часто отвлекаются от задач по устранению производственных инцидентов), в то время как объем остается переменным. Заказчик или владелец продукта часто настаивают на фиксированном объеме итерации. Однако командам не следует соглашаться на ограниченное время, ресурсы и объем (широко известный как треугольник управления проектами ). Попытки увеличить объем фиксированного времени и ресурсов гибкой разработки программного обеспечения могут привести к снижению качества. [121]
Выгорание разработчиков [ править ]
Из-за целенаправленного темпа и непрерывного характера agile-практик среди членов команды реализации существует повышенный риск выгорания. [122]
Гибкое управление [ править ]
Гибкое управление проектами — это итеративный процесс разработки, в ходе которого от пользователей и заинтересованных сторон постоянно собирается обратная связь для создания правильного пользовательского опыта. Для выполнения гибкого процесса можно использовать разные методы, к ним относятся Scrum , экстремальное программирование , Lean и Kanban . [123] Термин «гибкое управление» применяется к итеративному, поэтапному методу управления деятельностью по проектированию и созданию инженерных, информационных технологий и других областей бизнеса, целью которых является обеспечение разработки новых продуктов или услуг очень гибким и интерактивным способом на основе выраженных принципов. в Манифесте гибкой разработки программного обеспечения . [124] Метрики гибкого управления проектами помогают уменьшить путаницу, выявить слабые места и измерить производительность команды на протяжении всего цикла разработки. Гибкость цепочки поставок — это способность цепочки поставок справляться с неопределенностью и изменчивостью предложения и спроса. Гибкая цепочка поставок может быстро увеличивать и уменьшать свои мощности, поэтому она может адаптироваться к быстро меняющемуся потребительскому спросу. Наконец, стратегическая гибкость — это способность организации менять свой образ действий по мере развития ее среды. Ключом к стратегической гибкости является достаточно раннее распознавание внешних изменений и распределение ресурсов для адаптации к этим меняющимся условиям. [123]
Методы Agile X можно также назвать экстремальным управлением проектами . Это вариант итеративного жизненного цикла. [125] где результаты предоставляются поэтапно. Основное различие между гибкой и итеративной разработкой заключается в том, что гибкие методы завершают небольшую часть результатов в каждом цикле поставки (итерации). [126] в то время как итеративные методы со временем развивают весь набор результатов, завершая их ближе к концу проекта. И итеративные, и гибкие методы были разработаны как реакция на различные препятствия, возникшие в более последовательных формах организации проекта. Например, по мере усложнения технологических проектов конечным пользователям, как правило, трудно определить долгосрочные требования, не имея возможности просмотреть прогрессивные прототипы. Проекты, разрабатываемые итерациями, могут постоянно собирать отзывы, помогающие уточнить требования.
Гибкое управление также предлагает простую структуру, способствующую общению и размышлению о прошлой работе среди членов команды . [127] Команды, которые использовали традиционное каскадное планирование и приняли гибкий способ разработки, обычно проходят этап трансформации и часто обращаются за помощью к agile-коучам, которые помогают командам провести более плавную трансформацию. Обычно существует два стиля гибкого коучинга: Agile-коучинг, основанный на подталкивании и вытягивании. Здесь «система выталкивания» может относиться к предварительной оценке того, какие задачи могут быть включены в спринт (работа по продвижению), например, типичная для Scrum; тогда как «вытягивающая система» может относиться к среде, в которой задачи выполняются только тогда, когда работа доступна, например, что типично для канбана. [ нужны разъяснения ] Гибкие подходы к управлению также использовались и адаптировались к деловому и государственному секторам. Например, в федеральном правительстве США Агентство США по международному развитию (USAID) использует подход к совместному управлению проектами, который фокусируется на включении стратегий сотрудничества, обучения и адаптации (CLA) для повторения и адаптации программ. [128]
Гибкие методы упоминаются в Руководстве по своду знаний по управлению проектами ( Руководство PMBOK, 6-е издание ) в разделе определения жизненного цикла разработки продукта :
В жизненном цикле проекта обычно имеется одна или несколько фаз. которые связаны с разработкой продукта, услуги или результата. Это называется жизненным циклом разработки (...). Адаптивные жизненные циклы бывают гибкими, итеративными или инкрементными. Подробный объем определяется и утверждается перед началом итерации. Адаптивные жизненные циклы также называются гибкими или жизненными циклами, ориентированными на изменения. [129]
вне разработки обеспечения Приложения программного
По словам Жана-Лу Рише (научного сотрудника Института стратегических инноваций и услуг ESSEC ), «этот подход можно эффективно использовать для непрограммных продуктов и для управления проектами в целом, особенно в областях инноваций и неопределенности». Результатом является продукт или проект, который наилучшим образом соответствует текущим потребностям клиентов и поставляется с минимальными затратами, отходами и временем, что позволяет компаниям достичь прибыли раньше, чем при использовании традиционных подходов. [130]
Методы гибкой разработки программного обеспечения широко используются для разработки программных продуктов, и некоторые из них используют определенные характеристики программного обеспечения, такие как объектные технологии . [131] Однако эти методы могут быть применены к разработке непрограммных продуктов, таких как компьютеры, медицинские устройства, продукты питания, одежда и музыка. [132] Гибкие методы разработки программного обеспечения использовались при ИТ-инфраструктуры, развертывании и миграции не связанной с разработкой . Некоторые из более широких принципов гибкой разработки программного обеспечения также нашли применение в общем управлении. [133] (например, стратегия, управление, риск, финансы) в соответствии с терминами «гибкость бизнеса» или «гибкое управление бизнесом». Методологии гибкого программного обеспечения также были приняты для использования в процессе разработки обучения , итеративном процессе, основанном на данных, который применяет науки обучения , человеко-ориентированный дизайн и принятие решений на основе данных для поддержки учащихся и их развития. [134] .
Гибкие парадигмы разработки программного обеспечения можно использовать и в других сферах жизни, например, в воспитании детей. Его успех в развитии детей может быть основан на некоторых основных принципах управления; общение, адаптация и осведомленность. В своем выступлении на TED Брюс Фейлер рассказал, как он применяет базовые agile-парадигмы в ведении домашнего хозяйства и воспитании детей. [135]
Критика [ править ]
Гибкие методы были названы потенциально неэффективными в крупных организациях и определенных типах разработки. [136] Многие организации считают, что гибкие методологии разработки программного обеспечения слишком экстремальны, и применяют гибридный подход. [137] который сочетает в себе элементы гибкой разработки программного обеспечения и подходов, основанных на планах. [138] Некоторые методы, такие как метод разработки динамических систем (DSDM), пытаются сделать это дисциплинированно, не жертвуя фундаментальными принципами.
Растущее внедрение гибких практик также подвергается критике как управленческая причуда , которая просто описывает существующие передовые методы на новом жаргоне, продвигает единый подход, подходящий всем, к стратегиям развития и ошибочно ставит метод выше результатов. [139]
Алистер Кокберн организовал празднование 10-летия Манифеста гибкой разработки программного обеспечения в Сноуберде, штат Юта, 12 февраля 2011 года, собрав около 30+ человек, которые участвовали в первоначальной встрече и после нее. Был собран список из примерно 20 «слонов в комнате» («необсуждаемых» agile-тем/проблем), включая такие аспекты, как союзы, неудачи и ограничения практик и контекста гибкой разработки программного обеспечения (возможные причины: коммерческие интересы, деконтекстуализация, отсутствие очевидного способа добиваться прогресса, основываясь на неудачах, ограниченности объективных данных, когнитивных предубеждениях и ошибочных рассуждениях), политике и культуре. [140] Как писал Филипп Крухтен :
Agile-движение в некотором смысле похоже на подростка: очень застенчивый, постоянно проверяет свой внешний вид в зеркале, мало принимает критику, заинтересован только в общении со сверстниками, полностью отвергает всю мудрость прошлого только потому, что она он из прошлого, перенимает причуды и новый жаргон, временами дерзкий и высокомерный. Но я не сомневаюсь, что она будет взрослеть и дальше, станет более открытой для внешнего мира, более рефлексивной, а значит, и более эффективной.
— Филипп Крухтен [140]
«Манифест», возможно, оказал негативное влияние на управление и руководство высшим образованием, поскольку он предлагал администраторам заменить более медленные традиционные и совещательные процессы более «гибкими». Эта концепция редко находила признание среди преподавателей университетов. [141]
Другая критика заключается в том, что во многих отношениях гибкое управление и традиционные методы управления в конечном итоге противостоят друг другу. Распространенной критикой этой практики является то, что время, потраченное на ее изучение и внедрение, обходится слишком дорого, несмотря на потенциальные преимущества. Переход от традиционного управления к гибкому управлению требует полного подчинения гибкому подходу и твердой приверженности всех членов организации доведению этого процесса до конца. Такие проблемы, как неравные результаты во всей организации, слишком большие изменения, с которыми сотрудники не могут справиться, или отсутствие гарантий в конце трансформации — это лишь несколько примеров. [142]
См. также [ править ]
- Гибкая автоматизация
- Межфункциональная команда
- Скрам (разработка программного обеспечения)
- Fail fast (бизнес) , смежный предмет в управлении бизнесом.
- Канбан
- Гибкое лидерство
- Гибкие контракты
Ссылки [ править ]
- ^ Перейти обратно: а б с Кент Бек ; Джеймс Греннинг; Роберт С. Мартин ; Майк Бидл; Джим Хайсмит ; Стив Меллор ; Арье ван Беннекум; Эндрю Хант ; Кен Швабер ; Алистер Кокберн ; Рон Джеффрис ; Джефф Сазерленд ; Уорд Каннингем ; Джон Керн; Дэйв Томас ; Мартин Фаулер ; Брайан Марик (2001). «Манифест гибкой разработки программного обеспечения» . Гибкий Альянс . Проверено 14 июня 2010 г.
- ^ Перейти обратно: а б Ларман, Крейг (2004). Гибкая и итеративная разработка: Руководство для менеджера . Аддисон-Уэсли. п. 27. ISBN 978-0-13-111155-4 .
- ^ Ралли (2010). «Agile с большой буквы «А» против Agile с маленькой буквы «а» » . Архивировано из оригинала 5 января 2016 года . Проверено 9 сентября 2015 г.
{{cite web}}: CS1 maint: неподходящий URL ( ссылка ) - ^ Кольер 2011 .
- ^ «Что такое гибкая разработка программного обеспечения?» . Гибкий Альянс. 8 июня 2013 года . Проверено 4 апреля 2015 г.
- ^ Дыбо, Торе; Дингсойр, Торгейр (1 августа 2008 г.). «Эмпирические исследования гибкой разработки программного обеспечения: систематический обзор». Информационные и программные технологии . 50 (9–10): 833–859. дои : 10.1016/j.infsof.2008.01.006 . ISSN 0950-5849 . S2CID 2244031 .
- ^ Ли, Кванху; Ся, Вэйдун (2010). «На пути к Agile: комплексный анализ количественных и качественных полевых данных об гибкости разработки программного обеспечения». МИС ежеквартально . 34 (1): 87–114. дои : 10.2307/20721416 . JSTOR 20721416 . S2CID 26477249 .
- ^ Кролл, Дж.; Ричардсон, И.; Прикладницкий Р.; Оди, JL (2018). «Эмпирические данные о разработке программного обеспечения Sun: систематическое картографическое исследование» . Информационные и программные технологии . 93 : 30–44. дои : 10.1016/j.infsof.2017.08.011 . hdl : 10344/6233 .
- ^ Джеральд М. Вайнберг , цитируется в Larman & Basili 2003 , стр. 47–56 «Мы занимались поэтапной разработкой еще в 1957 году в Лос-Анджелесе под руководством Берни Димсдейла из IBM's Service Bureau Corporation . Он был коллегой Джон фон Нейман , так что, возможно, он научился этому там или считал это совершенно естественным. Я помню, как Херб Джейкобс (в первую очередь, хотя мы все участвовали) разрабатывал большую симуляцию для Motorola, где, насколько я могу судить, использовалась техника. ... Насколько я помню, все мы считали каскадирование огромного проекта довольно глупым или, по крайней мере, незнанием реалий. Я думаю, что описание водопада заставило нас осознать, что мы что-то делаем. еще что-то безымянное, за исключением «разработки программного обеспечения».
- ^ «Эволюционное управление проектами (Исходная страница, внешний архив)» . Гилб. Архивировано из оригинала 27 марта 2016 года . Проверено 30 апреля 2017 г. .
- ^ «Эволюционное управление проектами (Новая страница)» . Гилб . Проверено 30 апреля 2017 г. .
- ^ Эдмондс, Э.А. (1974). «Процесс разработки программного обеспечения для нетехнических пользователей как адаптивной системы». Общие системы . 19 : 215–18.
- ^ Гилб, Том (1 апреля 1981 г.). «Эволюционное развитие». Заметки по разработке программного обеспечения ACM SIGSOFT . 6 (2): 17. дои : 10.1145/1010865.1010868 . S2CID 33902347 .
- ^ Свамидасс, премьер-министр, изд. (2000), «Тяжеловесная проектная организацияHEAVYWEIGHT PROJECT ORGANIZATION» , Энциклопедия производства и управления производством , Бостон, Массачусетс: Springer US, стр. 261–262, doi : 10.1007/1-4020-0612-8_400 , ISBN 978-1-4020-0612-8 , получено 22 июня 2022 г.
- ^ Мартин, Джеймс (1991). Быстрая разработка приложений . Макмиллан. ISBN 978-0-02-376775-3 .
- ^ Керр, Джеймс М.; Хантер, Ричард (1993). Внутри RAD: как построить полнофункциональную систему за 90 дней или меньше . МакГроу-Хилл. п. 3. ISBN 978-0-07-034223-1 .
- ^ Институт Якокки (1991). «Стратегия производственного предприятия XXI века: взгляд отрасли». Институт Якокки, Университет Лихай, Вифлеем, Пенсильвания.
- ^ Пресли, А., Дж. Миллс и Д. Лайлз (1995). «Гибкое аэрокосмическое производство». Nepcon East 1995, Бостон.
- ^ Санчес, Луис (ноябрь 2010 г.). «Обзор гибких производственных систем» . Международный журнал производственных исследований (39 (16): 3561-3600).
- ^ Андерсон, Дэвид (2005). «Декларация взаимозависимости» . Архивировано из оригинала 27 января 2018 года . Проверено 4 октября 2018 г.
- ^ Макдональд, Кент (1 ноября 2016 г.). «Как вы можете помочь Agile Alliance помочь вам» . Блог Agile Alliance . Проверено 4 июля 2017 г.
- ^ «Изучение Agile-манифеста» . Компания Ambysoft Inc. Проверено 6 апреля 2011 г.
- ^ Джим Хайсмит (2001). «История: Манифест Agile» . www.agilemanifesto.org.
- ^ Перейти обратно: а б Кент Бек ; Джеймс Греннинг; Роберт С. Мартин ; Майк Бидл; Джим Хайсмит ; Стив Меллор ; Арье ван Беннекум; Эндрю Хант ; Кен Швабер ; Алистер Кокберн ; Рон Джеффрис ; Джефф Сазерленд ; Уорд Каннингем ; Джон Керн; Дэйв Томас ; Мартин Фаулер ; Брайан Марик (2001). «Принципы Agile-манифеста» . Гибкий Альянс. Архивировано из оригинала 14 июня 2010 года . Проверено 6 июня 2010 г.
- ^ Институт управления проектами 2021 , 2.3.3 Подходы к развитию.
- ^ Рубин 2013 .
- ^ Институт управления проектами 2021 , §3.12 Включите изменения для достижения предполагаемого будущего состояния.
- ^ Моран, А. (2014). Гибкое управление рисками . Спрингер Верлаг. ISBN 978-3319050072 .
- ^ Бек, Кент (1999). «Принятие перемен с помощью экстремального программирования». Компьютер . 32 (10): 70–77. дои : 10.1109/2.796139 .
- ^ Мергель, Инес (июль 2016 г.). «Гибкое управление инновациями в правительстве: программа исследований» . Правительственная информация Ежеквартально . 33 (3): 516–523. дои : 10.1016/j.giq.2016.07.004 .
- ^ Пройсс, Дебора Хартманн (13 октября 2006 г.). «Исследование: совмещенные команды против фермы кабинок» . ИнфоQ . Проверено 23 октября 2018 г.
- ^ Кокберн, Алистер (2007). «Гибкая разработка программного обеспечения: совместная игра» . www.pearson.com (2-е изд.). Аддисон-Уэсли Профессионал . Проверено 23 октября 2018 г.
- ^ «Трансформация менеджмента | Исследования» .
- ^ Джайн, Парита; Шарма, Арун; Ахуджа, Лакшми (август 2018 г.). «Влияние гибкого процесса разработки программного обеспечения на качество программного продукта» . 2018 7-я Международная конференция по надежности, инфоком-технологиям и оптимизации (Тенденции и будущие направления) (ICRITO) . Нойда, Индия: IEEE. стр. 812–815. дои : 10.1109/ICRITO.2018.8748529 . ISBN 978-1-5386-4692-2 . S2CID 195775457 .
- ^ Институт управления проектами 2021 , §2.7.3.2 Информационные излучатели.
- ^ Кокберн, Алистер (19 июня 2008 г.). «Информационный радиатор» .
- ^ Эмблер, Скотт (12 апреля 2002 г.). Гибкое моделирование: эффективные практики экстремального программирования и унифицированного процесса . Джон Уайли и сыновья. стр. 12, 164, 363. ISBN. 978-0-471-20282-0 .
- ^ Василяускас, Видас (2014). «Разработка гибких методов управления проектами и командами» . Эйлин. Архивировано из оригинала 15 сентября 2014 года . Проверено 15 сентября 2014 г.
- ^ Джеффрис, Рон; Андерсон, Энн; Хендриксон, Чет (2001). Установлено экстремальное программирование . Аддисон-Уэсли. стр. 72–147 . ISBN 978-0201-70842-4 .
- ^ Лиза Криспин; Джанет Грегори (2009). Agile-тестирование: Практическое руководство для тестировщиков и Agile-команд . Аддисон-Уэсли.
- ^ Митчелл, Ян (2016). Гибкая разработка на практике . Дом Тамаре. п. 11. ISBN 978-1-908552-49-5 .
- ^ Ларман, Крейг (2004). Гибкая и итеративная разработка: Руководство для менеджера . Аддисон-Уэсли. п. 27. ISBN 978-0-13-111155-4 .
- ^ Бём, Б. ; Р. Тернер (2004). Баланс между ловкостью и дисциплиной: руководство для растерянных . Бостон, Массачусетс: Аддисон-Уэсли. ISBN 978-0-321-18612-6 . Приложение А, страницы 165–194.
- ^ Ларман, Крейг (2004). «Глава 11: Практические советы» . Гибкая и итеративная разработка: Руководство для менеджера . Аддисон-Уэсли Профессионал. п. 253. ИСБН 9780131111554 . Проверено 14 октября 2013 г.
- ^ Слайгер, Мишель; Бродерик, Стейша (2008). Мост менеджера проекта по разработке программного обеспечения к гибкости . Аддисон-Уэсли. п. 46. ИСБН 978-0-321-50275-9 .
- ^ Перейти обратно: а б Бём, Б. ; Р. Тернер (2004). Баланс между ловкостью и дисциплиной: руководство для растерянных . Бостон, Массачусетс: Аддисон-Уэсли. стр. 55–57. ISBN 978-0-321-18612-6 .
- ^ Ракитин, Стивен Р. (2001). «Манифест вызывает цинизм: письмо читателя редактору Стивена Р. Ракитина». IEEE-компьютер . 34 (12): 4. дои : 10.1109/MC.2001.10095 . S2CID 221106984 .
Статья под названием «Гибкая разработка программного обеспечения: бизнес инноваций»… является еще одной попыткой подорвать дисциплину разработки программного обеспечения… Мы хотим тратить все свое время на программирование. Помните, настоящие программисты не пишут документацию.
- ^ Перейти обратно: а б Скотт Эмблер (16 апреля 2023 г.). «Agile/Lean Документация: стратегии гибкой разработки программного обеспечения» .
- ^ Скотт Эмблер. «Едва достаточно хорошие модели и документы: лучшая практика Agile» . Архивировано из оригинала 8 октября 2014 года . Проверено 24 января 2014 г.
- ^ Джеффри Уайзман (18 июля 2007 г.). «Требуют ли гибкие методы документации?» . ИнфоВ. цитирование Купер, Ян (6 июля 2007 г.). «Сигналы стаккато: Agile и документация» . WordPress.com .
- ^ Перейти обратно: а б с Абрахамсон П., Сало О., Ронкайнен Дж., Варста Дж. (2002). Гибкие методы разработки программного обеспечения: обзор и анализ (PDF) (Технический отчет). ВТТ . 478.
- ^ «Руководство по гибким практикам» . Гибкий Альянс. Архивировано из оригинала 9 февраля 2014 года.
- ^ Пью, Кен (2011). Lean-Agile-разработка на основе приемочного тестирования: лучшее программное обеспечение благодаря сотрудничеству . Аддисон-Уэсли. ISBN 978-0321714084 .
- ^ Аджич, Гойко. (2009) Преодоление разрыва в общении: спецификация на примере и гибкое приемочное тестирование , Neuri Limited,
- ^ Аджич, Гойко (2011). Спецификация на примере: как успешные команды создают правильное программное обеспечение . Мэннинг. ISBN 978-0-321-27865-4 .
- ^ Челимский, Дэвид, Дэйв Астелс, Зак Деннис, Аслак Хеллесой, Брайан Хелмкамп и Дэн Норт. Книга RSpec: Разработка, основанная на поведении, с RSpec, Cucumber и друзьями. Прагматичная книжная полка.
- ^ «Примерный дизайн» . Проверено 15 апреля 2013 г.
- ^ «История разработки через тестирование» (PDF) . Проверено 15 апреля 2013 г.
- ^ Домашняя страница гибкого моделирования (AM), эффективные методы моделирования и документации.
- ^ Атласиан. «Журнал продукта: ваш окончательный список дел» . Атласиан . Проверено 19 декабря 2021 г.
- ^ Перейти обратно: а б «Что такое бэклог продукта?» . Скрам.орг . Проверено 19 декабря 2021 г.
- ^ Перейти обратно: а б с «Основная практика Agile: приоритетные требования» . www.agilemodeling.com . Проверено 19 декабря 2021 г.
- ^ «Артефакт: Список рабочих элементов» . www.utm.mx. Проверено 19 декабря 2021 г.
- ^ «Владелец продукта | Дирекция оцифровки» . Проверено 15 ноября 2021 г.
- ^ Что такое межфункциональная команда? Определение и значение
- ^ Использование XFN в качестве аббревиатуры
- ^ Блог лидеров под названием XFN.
- ^ Краевски, LJ и LP Ritzman. 2005. Управление операциями: процессы и цепочки создания стоимости. Образование Пирсона, река Аппер-Седл.
- ^ Перейти обратно: а б Айдын, Миннесота; Хармсен, Ф.; Слоотен; Стэгви, РА (2004). «Используется гибкий метод разработки информационных систем». Тюрк Дж. Элек Энгин . 12 (2): 127–138.
- ^ Моррис, Дэвид (2015). Парадокс гибкой трансформации: почему слишком усердные попытки стать гибкими мешают организациям стать по-настоящему гибкими . Новая Зеландия: Университет Окленда. дои : 10.13140/RG.2.2.32698.08640 .
- ^ Абрахамссон П., Варста Дж., Сипонен М.Т. и Ронкайнен Дж. (2003). Новые направления в гибких методах: сравнительный анализ. Труды ICSE'03 , 244-254.
- ^ Мирахорли, М.; Рад, АК; Шамс, Ф.; Пазоки, М.; Мирахорли, А. (2008). «Техника RDP: практика настройки XP». Материалы международного семинара 2008 года по изучению agile-практик или перестрелок в agile-загоне (APOS '08) . АКМ. стр. 23–32. дои : 10.1145/1370143.1370149 . ISBN 978-1-60558-021-0 . S2CID 9528636 .
- ^ Швабер, К. (2006) Скрам сложен и разрушительен.
- ^ Водде, Б. (2016) История LeSS. Заключительный доклад. Скрам Австралия, Мельбурн. Апрель 2016 г.
- ^ Лагстедт А. и Дальберг Т. (2018). Понимание редкости выбора метода ISD – ограниченная рациональность и функциональная глупость. Материалы конференции PACIS 2018. 154. https://aisel.aisnet.org/pacis2018/154 .
- ^ Парк, Дж. С., МакМахон, П. Е. и Майбург, Б. (2016). Скрам на базе Essence. Заметки по разработке программного обеспечения ACM SIGSOFT, 41 (1), стр. 1–8.
- ^ Бек, К. (1999). Объяснение экстремального программирования: примите изменения . Бостон, Массачусетс: Аддисон-Уэсли. ISBN 978-0-321-27865-4 .
- ^ Эванс, Ян. «Гибкая доставка в British Telecom» . Проверено 21 февраля 2011 г.
- ^ Перейти обратно: а б В. Скотт Эмблер (2006) Supersize Me в журнале доктора Добба, 15 февраля 2006 г.
- ^ Шааф, Р.Дж. (2007). Конференция Agility XL Systems and Software Technology 2007. Архивировано 13 марта 2016 г. в Wayback Machine , Тампа, Флорида.
- ^ «Преодолев расстояние» . Sdmagazine.com . Проверено 1 февраля 2011 г.
- ^ Фаулер, Мартин. «Использование гибкого процесса разработки программного обеспечения при оффшорной разработке» . Мартинфаулер.com . Проверено 6 июня 2010 г.
- ^ Семинар II по гибким процессам «Управление несколькими одновременными гибкими проектами». Вашингтон: OOPSLA 2002 г.
- ^ Коули, Оисин; Ван, Сяофэн; Ричардсон, Ита (2010). «Методологии бережливой/гибкой разработки программного обеспечения в регулируемой среде – современное состояние». В Абрахамссоне, Пекка; Оза, Нилай (ред.). Программное обеспечение и системы бережливого предприятия . Конспекты лекций по обработке деловой информации. Том. 65. стр. 31–36. дои : 10.1007/978-3-642-16416-3_4 . hdl : 10344/683 . ISBN 978-3-642-16415-6 .
- ^ Макхью, Мартин; Маккаффери, Фергал; Коуди, Гаррет (4 ноября 2014 г.). «Гибкая реализация в организации, занимающейся программным обеспечением медицинского оборудования». В Митасиунасе, Антанасе; Раут, Терри; О'Коннор, Рори В.; и другие. (ред.). Улучшение процесса разработки программного обеспечения и определение возможностей . Коммуникации в компьютерной и информатике. Том. 477. стр. 190–201. дои : 10.1007/978-3-319-13036-1_17 . ISBN 978-3-319-13035-4 .
- ^ Ван, Ян; Рамадани, Жасмин; Вагнер, Стефан (29 ноября 2017 г.). «Исследовательское исследование по применению процесса разработки Scrum для систем, критически важных для безопасности». Улучшение процесса разработки программного обеспечения, ориентированного на продукт . Конспекты лекций по информатике. Том. 10611. С. 324–340. arXiv : 1703.05375 . Бибкод : 2017arXiv170305375W . дои : 10.1007/978-3-319-69926-4_23 . ISBN 9783319699257 . S2CID 4585465 .
- ^ «SafeScrum — СИНТЕФ» . Синтеф.номер . Проверено 26 марта 2019 г.
- ^ Тор Миклебуст, Тор Столхан, Гейр Кьетил Ханссен, Тормод Вен и Борге Хаугсет: Scrum, документация и стандарт программного обеспечения IEC 61508-3: 2010, http://www.sintef.no/globalassets/ec-61508-documentation-and -safescrum-psam12.pdf
- ^ Фицджеральд, Б.; Стол, К.-Дж.; О'Салливан, Р.; О'Брайен, Д. (май 2013 г.). «Масштабирование гибких методов в регулируемой среде: пример из отрасли». 2013 35-я Международная конференция по программной инженерии (ICSE) . стр. 863–872. дои : 10.1109/ICSE.2013.6606635 . HDL : 10344/3055 . ISBN 978-1-4673-3076-3 . S2CID 192403 .
- ^ Бек, Кент (2000). Объяснение экстремального программирования . Аддисон-Уэсли. стр. 1–24 . ISBN 978-0201616415 .
- ^ Датта, Субхаджит (2006). «Индекс измерения гибкости: показатель перекрестка методологий разработки программного обеспечения». ACM-SE 44 Материалы 44-й ежегодной Юго-восточной региональной конференции . п. 271. дои : 10.1145/1185448.1185509 . ISBN 1595933158 .
- ^ Питер Лаппо; Генри CT Эндрю. «Оценка гибкости» (PDF) . Архивировано из оригинала (PDF) 15 сентября 2009 года . Проверено 6 июня 2010 г.
- ^ Джо Литтл (2 декабря 2007 г.). «Тест Nokia. Тест, специфичный для Scrum» . Agileconsortium.blogspot.com . Проверено 6 июня 2010 г.
- ^ Марк Зойферт; Майберг, Швеция. «Тест Карлскруны. Общий тест на внедрение Agile» . Mayberg.se . Проверено 5 апреля 2014 г.
- ^ «Насколько вы гибки? (Пройдите тест из 42 пунктов)» . allaboutagile.com/. Архивировано из оригинала 5 мая 2014 года . Проверено 3 апреля 2014 г.
- ^ «Результаты исследования гибких методологий» (PDF) . Сияющие Технологии. Январь 2003 г. Архивировано из оригинала (PDF) 21 августа 2010 г. . Проверено 3 июня 2010 г.
95% заявили, что эффекта либо не было, либо произошло снижение затрат... 93% заявили, что производительность стала лучше или значительно лучше... 88% заявили, что качество стало лучше или значительно лучше... 83% заявили, что удовлетворенность бизнесом стала выше или значительно лучше
- ^ «Отчет о состоянии Agile за 2013 год: почему Agile?» . Stateofagile.com. 27 января 2014 года. Архивировано из оригинала 28 августа 2014 года . Проверено 13 августа 2014 г.
- ^ Status Quo Agile , Второе исследование успеха и форм использования гибких методов. Проверено 1 июля 2015 г.
- ^ Эмблер, Скотт (3 августа 2006 г.). «Опрос показал: Agile работает на практике» . Доктор Добб . Проверено 3 июня 2010 г.
Только 6% указали, что их производительность снизилась... Об изменении производительности сообщили 34% респондентов, а 60% сообщили о повышении производительности... 66% [ответили], что качество выше... 58% организаций сообщают повышение удовлетворенности, тогда как только 3% сообщают о снижении удовлетворенности.
- ^ «Ответ на вопрос «Где доказательства того, что гибкие методы работают?» . Agilemodeling.com. 19 января 2007 года . Проверено 2 апреля 2010 г.
- ^ Шор и Уорден 2008 , с. 47
- ^ Бек, Кент (2000). Объяснение экстремального программирования . Аддисон-Уэсли. стр. 48–49 . ISBN 978-0201616415 .
- ^ Роуз, Маргарет. «Определение спринта (разработки программного обеспечения)» . searchsoftwarequality.techtarget.com . Проверено 2 октября 2015 г.
- ^ Гольдштейн, Илан (11 октября 2011 г.). «Проблемы спринта – когда спринты превращаются в ползание» . www.axisagile.com.au . Проверено 8 июня 2014 г.
- ^ «Роли в проекте и распределение ответственности» . agile-only.com . Проверено 15 июня 2014 г.
- ^ Борн, Линда. «Чем на самом деле занимается спонсор проекта?» . blogs.pmi.org . Архивировано из оригинала 7 июня 2014 года . Проверено 8 июня 2014 г.
- ^ «9-й отчет о состоянии Agile» . Этап Agile-исследования . Версия первая. Архивировано из оригинала 12 января 2015 года . Проверено 8 июня 2014 г.
- ^ Симс, Крис; Джонсон, Хиллари Луиза (15 февраля 2011 г.). Элементы Scrum (изд. Kindle). Димаксикон. п. 73.
- ^ Ротман, Джоанна Ротман (25 августа 2011 г.). «Когда у вас вообще нет владельца продукта» . www.jrothman.com . Проверено 8 июня 2014 г.
- ^ Фокс, Алисса (8 апреля 2014 г.). «Работа в нескольких Agile-командах» . techwhirl.com/ . Проверено 14 июня 2014 г.
- ^ «Ежедневное Scrum-совещание» . www.mountaingoatsoftware.com . Проверено 14 июня 2014 г.
- ^ Перейти обратно: а б Мэй, Роберт. «Эффективное планирование спринта» . www.agileexecutives.org . Архивировано из оригинала 28 июня 2014 года . Проверено 14 июня 2014 г.
- ^ Берчук, Стив. «Миссия выполнима: ScrumMaster и технический участник» . www.agileconnection.com . Проверено 14 июня 2014 г.
- ^ «Как внедрить Agile Scrum» . Проверено 4 января 2022 г.
- ^ Намта, Раджниш. «Мысли об автоматизации тестирования в Agile» . www.infoq.com . Проверено 14 июня 2014 г.
- ^ Перейти обратно: а б Банда, Цви (22 марта 2014 г.). «Техдолг + Красный Октябрь» . Проверено 8 июня 2014 г.
- ^ Шор, Джеймс. «Искусство гибкой разработки: рефакторинг» . www.jamesshore.com . Проверено 14 июня 2014 г.
- ^ «Шаг 4: Планирование спринта (задачи)» . www.allaboutagile.com . Архивировано из оригинала 29 июня 2014 года . Проверено 14 июня 2014 г.
- ^ Джордж, Клэр (3 марта 2014 г.). «Почему ограничение незавершенной работы имеет значение» . сайт Leankit.com . Проверено 14 июня 2014 г.
- ^ «Совещание по планированию спринта» . www.mountaingoatsoftware.com . Проверено 14 июня 2014 г.
- ^ Макмиллан, Кейт (13 мая 2010 г.). «Время, ресурсы, объем... и качество» . www.adeptechllc.com . Проверено 15 июня 2014 г.
- ^ «Текущее исследование ограничений Agile» . Procedia Информатика . 78 : 291–297. Январь 2016 г. doi : 10.1016/j.procs.2016.02.056 .
- ^ Перейти обратно: а б «Призыв к закупкам для Agile. Что это значит?» . 1 ноября 2019 г.
- ^ Моран, Алан (2015). Управление Agile: стратегия, реализация, организация и люди . Спрингер. ISBN 978-3-319-16262-1 .
- ^ ExecutiveBrief, Какой жизненный цикл лучше всего подходит для вашего проекта? , ПМ Хата. По состоянию на 23 октября 2009 г.
- ^ «Гибкое управление проектами» . Версия первая . Проверено 1 июня 2015 г.
- ^ «Что такое Agile-менеджмент?» . Проект «Лейнвейс» . Проверено 1 июня 2015 г.
- ^ ЮСАИД. «Эксплуатационная политика программного цикла ADS, глава 201». Архивировано 23 октября 2019 года в Wayback Machine . Проверено 19 апреля 2017 г.
- ^ Институт управления проектами , Руководство по своду знаний по управлению проектами (Руководство PMBOK), шестое издание
- ^ Рише, Жан-Лу (2013). Гибкие инновации . Примеры и прикладные исследования, № 31. ЭССЕК-ИСИС. ISBN 978-2-36456-091-8
- ^ Смит, Престон Дж. (2007). Гибкая разработка продуктов . Джосси-Басс. п. 25. ISBN 978-0-7879-9584-3 .
- ^ Ньютон Ли (2014). «Попадание в чарты Billboard: музыкальное производство как гибкая разработка программного обеспечения», Digital Da Vinci: компьютеры в музыке . Springer Science+Business Media. ISBN 978-1-4939-0535-5 .
- ^ Моран, Алан (2015). Управление Agile: стратегия, реализация, организация и люди . Спрингер Верлаг. ISBN 978-3-319-16262-1 .
- ^ Барретт, М.; Гуделл, Дж. (2022), «Инструменты Lean-Agile разработки», Learning Engineering Toolkit , Routledge, стр. 269–278, doi : 10.4324/9781003276579-16
- ^ «Гибкое программирование – для вашей семьи» .
- ^ Ларман, Крейг; Бас Водде (13 августа 2009 г.). Десять основных организационных препятствий на пути широкомасштабного внедрения Agile . ИнформИТ.
- ^ «Введение в управление гибридными проектами» . 20 июля 2016 г.
- ^ Барлоу, Джордан Б.; Джастин Скотт Гибони; Марк Джеффри Кейт; Дэвид В. Уилсон; Райан М. Шютцлер; Пол Бенджамин Лоури; Энтони Вэнс (2011). «Обзор и руководство по гибкой разработке в крупных организациях» . Сообщения Ассоциации информационных систем . 29 (1): 25–44. дои : 10.17705/1CAIS.02902 .
- ^ Куперсмит, Купе (4 июля 2011 г.). «Agile — это мода» .
- ^ Перейти обратно: а б Крухтен, Филипп (20 июня 2011 г.). «Подростковый кризис Agile?» . ИнфоВ.
- ↑ Ричард Утц, «Против административной речи», Хроника высшего образования , 24 июня 2020 г.
- ^ Кон, Майк (2015). Достижение успеха с помощью Agile . Пирсон. стр. 5–10. ISBN 978-0-321-57936-2 .
Дальнейшее чтение [ править ]
- Абрахамссон, П.; Сало, О.; Ронкайнен Дж.; Варста, Дж. (2002). «Методы гибкой разработки программного обеспечения: обзор и анализ» . Публикации ВТТ. 478. Архивировано из оригинала 7 сентября 2011 года . Проверено 20 февраля 2012 г.
- Ashmore, Sondra; Runyan, Kristin (2014). Introduction to Agile Methods. Addison-Wesley. ISBN 978-0321929563.
- Barlow, Jordan B.; Justin Scott Giboney; Mark Jeffery Keith; David W. Wilson; Ryan M. Schuetzler; Paul Benjamin Lowry; Anthony Vance (2011). "Overview and Guidance on Agile Development in Large Organizations". Communications of the Association for Information Systems. 29 (1): 25–44. doi:10.17705/1CAIS.02902.
- Cohen, D.; Lindvall, M.; Costa, P. (2004). "An introduction to agile methods". In Zelkowitz, Marvin (ed.). Advances in Software Engineering. Advances in Computers. Vol. 62. Academic Press. pp. 1–66. ISBN 978-0-08-047190-7.
- Collier, Ken W. (2011). Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing. Pearson Education. ISBN 9780321669544.
What is a self-organizing team?
- Dingsøyr, Torgeir; Dybå, Tore; Moe, Nils Brede (2010). Agile Software Development: Current Research and Future Directions. Springer. ISBN 978-3-642-12575-1.
- Fowler, Martin (2001). "Is Design Dead?". In Succi, Giancarlo; Marchesi, Michele (eds.). Extreme Programming Examined. Addison-Wesley. pp. 3–18. ISBN 978-0-201-71040-3.
- Larman, Craig; Basili, Victor R. (June 2003). "Iterative and Incremental Development: A Brief History". IEEE Computer. 36 (3): 47–56. doi:10.1109/MC.2003.1204375. S2CID 9240477.
- Casagni, Michelle; Benito, Robert; Mayfield, Kathleen M.; Northern, Carlton (8 September 2013). "Handbook for Implementing Agile in Department of Defense Information Technology Acquisition". The Mitre Corporation. MITRE.
- Моран, Алан (2015). Управление Agile: стратегия, реализация, организация и люди . Спрингер. ISBN 978-3-319-16262-1 .
- Риле, Дирк. «Сравнение систем ценностей адаптивной разработки программного обеспечения и экстремального программирования: как методологии могут учиться друг у друга» . В Суччи и Маркези, 2001 г.
- Rubin, Kenneth (2013). Essential Scrum. A Practical Guide to the Most Popular Agile Process. Addison-Wesley. ISBN 978-0-13-704329-3.
- Shore, James; Warden, Shane (2008). The Art of Agile Development. O'Reilly Media. ISBN 978-0-596-52767-9.
- Project Management Institute (2021). A guide to the project management body of knowledge (PMBOK guide). Project Management Institute (7th ed.). Newtown Square, PA. ISBN 978-1-62825-664-2.
{{cite book}}: CS1 maint: location missing publisher (link) - Stephens, M.; Rosenberg, D. (2003). Extreme Programming Refactored: The Case Against XP. Apress. ISBN 978-1-59059-096-6.
- Swamidass, P. M., ed. (2000), "Heavyweight project organizationHEAVYWEIGHT PROJECT ORGANIZATION", Encyclopedia of Production and Manufacturing Management, Boston, MA: Springer US, pp. 261–262, doi:10.1007/1-4020-0612-8_400, ISBN 978-1-4020-0612-8, retrieved 22 June 2022
- Takeuchi, Hirotaka; Nonaka, Ikujiro (1 January 1986). "The New New Product Development Game". Harvard Business Review. ISSN 0017-8012. Retrieved 25 July 2021.
- "Introduction to Hybrid project management". 20 July 2016.
External links[edit]
- Agile Manifesto
- Agile Glossary of the Agile Alliance
- The New Methodology - Martin Fowler's description of the background to agile methods
- AgilePatterns.org
