Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
Инструменты
  • Компилятор
  • Отладчик
  • Профайлер
  • Дизайнер графического интерфейса
  • Моделирование
  • IDE
  • Автоматизация сборки
  • Автоматизация выпуска
  • Инфраструктура как код
  • Тестирование
Стандарты и свод знаний
  • БАБОК
  • CMMI
  • Стандарты IEEE
  • ISO 9001
  • Стандарты ISO / IEC
  • PMBOK
  • SWEBOK
  • ITIL
  • IREB
Глоссарии
  • Искусственный интеллект
  • Информатика
  • Электротехника и электроника
Контуры
  • План разработки программного обеспечения
  • v
  • т
  • е

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

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

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

История [ править ]

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

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

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

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

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

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

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

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

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

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

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

Как пояснил Скотт Амблер : [21]

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

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

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

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

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

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

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

Обзор [ править ]

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

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

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

Эффективное и личное общение [ править ]

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

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

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

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

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

Ориентация на качество [ править ]

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

Философия [ править ]

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

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

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

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

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

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

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

Agile против водопада [ править ]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Адаптация метода [ править ]

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

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

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

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

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

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

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

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

  • Scaled Agile framework (SAFe), [62] Дин Леффингвелл и др.
  • Дисциплинированная гибкая доставка (DAD), Скотт Амблер и др.
  • Масштабная схватка (LeSS), Крейг Ларман и Бас Водде
  • Nexus (масштабируемый профессиональный Scrum), [63] Кен Швабер.
  • Scrum at Scale, [64] Джефф Сазерленд , Алекс Браун
  • Enterprise Scrum, [65] Майк Бидл
  • Setchu (легкий фреймворк на основе Scrum), [66] Майкл Эббадж.
  • XSCALE [67]
  • Гибкий путь [68] -
  • Комплексная разработка программного обеспечения [69]

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

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

Регулируемые домены [ править ]

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

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

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

Опыт и принятие [ править ]

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

Измерение гибкости [ править ]

Внутренние оценки [ править ]

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

Общественные опросы [ править ]

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

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

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

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

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

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

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

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

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

Отсутствие спонсорской поддержки [ править ]

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

Недостаточная подготовка [ править ]

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

Неправильно заполнена роль владельца продукта [ править ]

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

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

Команды не сфокусированы [ править ]

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

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

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

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

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

Назначение задач [ править ]

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

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

Скрам-мастер как участник [ править ]

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

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

Отсутствие автоматизации тестирования [ править ]

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

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

Разрешение нарастания технического долга [ править ]

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

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

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

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

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

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

Выгорание разработчика [ править ]

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

Гибкое управление [ править ]

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

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

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

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

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

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

Приложения, не связанные с разработкой программного обеспечения [ править ]

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

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

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

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

Критика [ править ]

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

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

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

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

-  Филипп Крюхтен [126]

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

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

См. Также [ править ]

  • Самоуправление работников

Ссылки [ править ]

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

Дальнейшее чтение [ править ]

  • Abrahamsson, P .; Сало, О .; Ronkainen, J .; Варста, Дж. (2002). «Методы гибкой разработки программного обеспечения: обзор и анализ» . Публикации VTT. 478. Архивировано из оригинала 7 сентября 2011 года . Проверено 20 февраля 2012 года .
  • Эшмор, Сондра; Рунян, Кристин (2014). Введение в гибкие методы . Эддисон-Уэсли. ISBN 978-0321929563.
  • Cohen, D .; Lindvall, M .; Коста, П. (2004). «Введение в гибкие методы» . В Zelkowitz, Марвин (ред.). Достижения в области разработки программного обеспечения . Достижения в области компьютеров. 62 . Академическая пресса. С. 1–66. ISBN 978-0-08-047190-7.
  • Дингсёйр, Торгейр; Диба, Тор; Мо, Нильс Бреде (2010). Гибкая разработка программного обеспечения: текущие исследования и будущие направления . Springer. ISBN 978-3-642-12575-1.
  • Фаулер, Мартин (2001). "Дизайн мертв?" . В Суччи, Джанкарло; Марчези, Микеле (ред.). Экстремальное программирование . Эддисон-Уэсли. С.  3–18 . ISBN 978-0-201-71040-3.
  • Ларман, Крейг; Базили, Виктор Р. (июнь 2003 г.). «Итеративное и инкрементное развитие: краткая история». Компьютер IEEE . 36 (3): 47–56. DOI : 10,1109 / MC.2003.1204375 . S2CID  9240477 .
  • Касаньи, Мишель; Бенито, Роберт; Mayfield, Dr Kathleen M .; Северный, Карлтон (8 сентября 2013 г.). «Руководство по внедрению гибкой разработки в приобретение информационных технологий Министерства обороны» . Корпорация Митра . МИТРА.
  • Моран, Алан (2015). Управление Agile: стратегия, реализация, организация и люди . Springer. ISBN 978-3-319-16262-1.
  • Риле, Дирк. «Сравнение систем ценностей адаптивной разработки программного обеспечения и экстремального программирования: как методологии могут учиться друг у друга» .В Суччи и Марчези 2001
  • Шор, Джеймс; Уорден, Шейн (2008). Искусство гибкой разработки . O'Reilly Media. ISBN 978-0-596-52767-9.
  • Стивенс, М .; Розенберг, Д. (2003). Рефакторинг экстремального программирования: аргументы против XP . Апресс. ISBN 978-1-59059-096-6.

Внешние ссылки [ править ]

  • Agile манифест
  • Глоссарий Agile Alliance
  • Новая методология - описание Мартином Фаулером предыстории гибких методов
  • AgilePatterns.org